[Coco] Orchestra 90CC

[Jeff Teunissen]

Joel Ewy wrote:
> Jeff Teunissen wrote:
>> ...
>> A 256 byte ring buffer being drained by 8KHz mono has to be updated at least
>> every 32ms. For 22050Hz stereo it's a much tighter 5.8ms...but that should be
>> well within the capability of, say, a 28.63636MHz (heh) C5 even while
>> multitasking in NitrOS-9.
>>
>> Obviously, this all assumes that the sound hardware (like the VDG in a
>> CoCo1/2) is accessing RAM when the '09 isn't, and also that there's a reliable
>> and accessible clock source (no halting floppy interface allowed, or you'd get
>> the same endlessly-repeating samples that you get when a Windows box hangs
>> while there is sound playing).
> 
> And if this were implemented in an FPGA (correct me if I'm wrong, those
> who know better than I) adding 256 bytes of special-purpose RAM in the
> FPGA itself, separate from the normally-addressed system RAM, wouldn't
> take too much doing.  In that case, the CPU fills the buffer and the
> sound hardware goes off on its merry way without respect to what the
> rest of the CoCo is doing.

Special-purpose RAM for that would suck, since you can't use it in software.
With this mechanism any zero-aligned, direct-addressable block of memory could
be used as a ring buffer for audio playback or recording.

Yeah, you could probably do it with special memory--but if you were doing that
you'd want a far bigger buffer, you'd probably only be able to transfer a byte
at a time into the sound buffer, you'd have to do overflow checks, recording
would be a total pain in the ass, and so on. :)

-- 
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek at d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project     http://www.quakeforge.net/
| Specializing in Debian GNU/Linux           http://www.d2dc.net/~deek/