[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RT.SYNTH -- anybody tried it?
Colin Klipsch wrote:
Greetings Colin!
Greetings, all. Howdy, Nick.
I'll try to confirm a few things raised in this thread about Catakig's
audio output, since there seems to be a little interest...
Catakig adopts a ratio of exactly 47 cycles of the emulated CPU for
every sample of 22,050 Hz audio output. This gives an effective machine
speed of 1.036 MHz, slightly faster than the Apple II's true speed.
Then it's a real testament to the accuracy of your filtering
implementation if DAC522 sounds good, since it (for a couple of
reasons) must choose the nearest *even* number of cycles, 46.
Having your sampling run through all possible phase relationships
with my generated pulses every 2162 cycles would make any inaccuracy
*very* audible at the "beat" frequency of around 500Hz!
(You can also run Catakig's Apple IIs at much faster speeds, but that's
accomplished in the application by simply calling the emulation engine
more frequently, and by upping the playback rate. It doesn't change how
the audio signal is computed.)
The "input" audio stream from the Apple II, which is to be filtered to
make the "output" stream actually heard by the user, is taken to be a
pure square wave with a time resolution of 1.036 MHz. The goal then is
to transform a 1-bit 1-MHz signal into an 8-bit 22-kHz signal. Two
things are basically done: (1) a low-pass FIR filter is applied that
eliminates all frequencies above 11 kHz; and (2) only 1 out of every 47
samples of the full output signal is actually generated. Amazingly
enough, DSP theory allows us to skip all those other samples, assuming
the input signal has no frequencies above the Nyquist limit of the
output signal -- which is precisely what the low-pass filter
accomplishes.
Now, actually computing the filter -- a linear combination using 188
coefficients, in my case -- in the obvious way for every output sample
would be too costly. I instead use pre-computed lookup tables that take
advantage of the fact that there are only two possible input signal
values ("0" and "1"), and that a partial sum of the coefficients after
index "i" is basically how much the output value, any output value,
should change if the speaker flips at point "i". There's never any need
to keep around 188 values of the input signal to get each output sample,
let alone compute with them. All we need to know is exactly when (down
to the cycle) the speaker flipped relative to an affected sample.
Beautiful optimization! The fastest computation is the one you
can move to compile time! ;-)
Of course, this then requires that you tally your CPU cycles religiously
as you emulate 6502 instructions, so that when a $C03x reference occurs,
you have the information you need. That's easy to do of course.
That's the super-condensed version of what is going on in Catakig's
audio production. I hope it's clear, so far as it goes. (And yes,
Michael M. was the one who pointed me in the right direction. Thanks
again, Michael!)
You're welcome--you did all the heavy lifting...to excellent effect.
To answer a couple other questions people asked:
* Catakig 1 will run on older 680x0 Macs, but generally not well. Quite
lousy in fact, if I may be blunt. You'll definitely need one of the
faster models -- over 30 MHz, as someone mentioned. I recommend at
least MacOS 8 also.
* Catakig 1 will run decently on pretty much any PowerPC Mac that
supports MacOS 8 or 9. Speed of the host machine is not a concern. I
actually developed it on a 66-MHz machine, one of the very first
PowerMacs, and it runs well even there. Any later Mac will be faster
yet.
* Catakig 2, as noted, is only for PowerPC Macs running MacOS X. It
will not be back-ported to older platforms. However, Catakig 2 will
eventually be compiled for Intel Macs, when their day arrives.
Maybe I need to get a PowerPC Mac running...
In theory Catakig 2 could also be compiled for an Intel Linux or BSD
machine with GNUStep installed, and OpenGL. There are probably
obstacles I haven't allowed for though, even though supporting such
platforms is one of my goals. I certainly haven't tried it myself yet.
There is also the issue of Apple's NIB interface files, which I'm using
currently, and which I understand GNUStep can't work with anyway.
* Yes indeedy, the CVS repository on SourceForge is woefully out of
date. My own private copy of the source code has evolved substantially
since the last check-in. This is partly because I've developed an
allergy to CVS, and partly because the SF admins have been promising to
offer Subversion support, any day now. According to their newsletters,
this might actually happen in the next couple months. When it does,
repository updates should become more frequent.
But after some recent prodding by by Nick, I'll try to upload a current
copy of the source, probably avoiding CVS when I do. Just a big
tarball, probably. If anyone else here has an interest in that, please
let me know.
(I love this newsgroup by the way, even though I rarely make a post. I
am a regular reader though.)
It's good to know you're here. ;-)
-michael
Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."