Re: RT.SYNTH -- anybody tried it?

[Colin Klipsch <cklipsch@radix.net>]

In article <1134745299.945169.32750@g49g2000cwa.googlegroups.com>,
 "sicklittlemonkey" <Nick.Westgate@gmail.com> wrote:

> > Current site [of Catakig] is on SourceForge.

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.

(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.

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!)

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.

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.)


-- Colin K.