[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Steal RAM -- Question
sicklittlemonkey wrote:
Michael J. Mahon wrote:
Since the initial state of the toggle is not generally predictable,
one either *should* or *should not* toggle the speaker for best results.
;-)
To toggle or not to toggle, eh? The mind boggles.
Since the speaker and cassette T flipflops are not reset on the
][ and ][+, their initial state is indeterminate. Starting with
the //e, they are in the IOU, and so are (probably) reset at power
on (but probably not when /RESET is asserted). In any case, by
the time control reaches an application program, there is no way
to be sure what state the speaker toggle is in.
The good news is that if all sounds are made by performing an even
number of toggles, they will all at least sound consistent from one
"sounding" to the next.
In my earlier post, I ascribed the asymmetry of the low-to-high and
high-to-low toggle sounds to the wrong cause. It isn't the way that
the speaker is driven as much as the way that the toggle level is
coupled to the speaker driver.
Prior to the //c, the toggle was AC-coupled to the Darlington driver
through an RC circuit with a time constant of about 5 milliseconds.
The effect is that no matter which way the toggle goes, after 5-10
milliseconds, it's back to its "rest" state: no current through speaker.
As long as the toggle is changing at least every 5-10 milliseconds
(100-200Hz), the AC-coupling makes little difference, and the speaker
sees each toggle as a full-scale current transition.
But if more than 5-10 ms. elapses between toggles, then what happens
on the *next* toggle depends on whether it is high-to-low or low-to-
high. If it is high-to-low, it will simply try to turn off the already
off Darlington driver, producing essentially no sound. If it is a
low-to-high transition, then it will produce a maximum "tick".
As a result, sounds with toggle intervals longer than 5-10 ms. or--
very importantly--short sounds with asymmetric pulses *separated* by
periods of silence *will* be affected, since the "attack" caused by
the first speaker pulse will either be heard or not, depending on the
initial state of the speaker toggle.
In the //c, the actual circuit of the audio op amp is not given, but
the diagram suggests that it is DC-coupled to the toggle, so it shows
no time-constant effects.
My sound programs, using DAC522 to generate sound by pulse-width-
modulation of a 22kHz carrier, are not much affected by the initial
state of the toggle, because they switch the toggle continuously at
a rate of 44kHz, making the AC-coupling of the output irrelevant.
This shows that people who write reference manuals don't always know
the correct answer, either. ;-)
Well, I think we've known that since, shall we say, the dawn of
civilization - not to put too fine a point on it.
"In the beginning was the word--and it was wrong." ;-)
The more surprising fact is that no-one had corrected this 4 years
later in the //e manual. They massaged the text, but surely someone
technical at Apple was reading these manuals.
By that time, the Apple II team was very light on hardware
expertise.
Anyway, it's ancient history, but the factoid persists!
So it is with memes...
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."