Re: Cinematronics sound board behavior...

On Wed, 23 Jun 1999 18:25:32 -0700, Clay Cowgill <ClayC@diamondmm.com> wrote:

>> Remember the CCPU runs at 5mhz with many of it's
>> instructions being executed in 1 cycle. You need to be very fast to
>> catch the shift strobe of a shift register, which I believe will only
>> last for two 5mhz cycles!
>>
>I was kinda thinking 16V8 or something to just latch the info... The Scenix
>might be able to do it, but for a dollar or two it might just be worth the
>PAL...

I don't think you'd have any problems prying a buck or two more out of my
wallet!

The thing that concerns me though, is that you might need a differently
programmed 16V8 for each card. Many of the cards use a DATA/CLOCK shift
register to expand the 6 I/O lines to as many as they need. There is then a
third LATCH line to latch in the shift register to the latch used to drive the
sound circuits.

The problem is there was no consistency as to which lines from the CCPU go to
the DATA/CLOCK/LATCH lines, though there is some sharing. Armor Attack and
Solar Quest share a common shift register, as do Solar Quest and Boxing Bugs.

Tailgunner used a totally different approach. A 3 to 8 mux. This would also
need to be in the 16V8.

I was just thinking since the Scenix was so damned fast, it could be loaded with
subroutines for each sound board, and the proper routine could be called for the
proper sound board. Emulating shift/mux/latches as needed. I believe the
fastest pulse it would need to detect is 400ns.

Another alternative might be to use one of those RAM based PALs, and reload the
logic as needed. That would be pretty slick, if not expensive.

>It looks like the Scenix at 50MHz can outrun the SmartMedia card. :-) I
>think the numbers work out for CPU power.
>
>I can set the address on the memory and retrieve a byte of data in roughly
>29 Scenix cycles (20ns each). That doesn't include any overhead obtaining
>the address from Scenix RAM etc. I can then grab subsequent bytes from the
>memory in just 5 scenix cycles.
>
>So, If I (arbitrarily) set 22.1KHz as the playback rate, I've got about
>45.249us before I need to pump out a word from the DAC. Sending a word to
>the DAC will take about 50 scenix cycles. Soooo. Let's just take a
>wild-ass guess and say there's 100 cycles of math and overhead needed to
>combine samples and do "whatever" (poll inputs, etc).
>
>Overhead + output = ~150 cycles = ~3us
>Getting one "voice" of data = ~30 cycles = ~600ns
>
>Needing a new word written to the DAC takes 3us from our 45.249us refresh
>rate. That leaves about 42.25us for fetching data from the SmartMedia card
>or at 600ns per voice... about 70 voices without per-voice overhead.
>
>The conclusion here looks to be that even generating eight or so "virtual"
>sound channels leaves lots of CPU left over. Even if I totally botched the
>timing diagrams and I'm off by a factor of 5 there's still enough "oomph" to
>do the job. ;-)

I don't think you'll need to generate 8 simultaneous channels. The Boxing Bug
card contains more than 10 sounds (12? 13?). I'm sure they don't play all at
once. Of course you will need some kind of logic to map the 12 channels to the
8 slots as their needed. This kind of coding can eat up cycles fast (as lookup
tables are accesses, etc.)

If you could pull it off, the way to go would be to design something that could
drive all 13 channels of Boxing Bugs. Any hardware that could do this, could
run all the other games.

>> Another IRQ task could supply the data to the DAC as needed, with a
>> foreground task doing the mixing/level shifting, keeping a very small
>> (4 to 8 byte) buffer full for the DAC.
>>
>Yeah, there's about ~130 bytes of scratch RAM to use. Taking advantage of
>the sequential reads on the SmartMedia card to buffer (8?) bytes per voice
>per access frees up even more of the lots-o-free MIPS. Hmmmm. I've got a
>bunch of 20MHz oscillators I bought... Maybe just use those to be cheap...
>
>> My biggest concern is that the different soundboards interface quite
>> different from each other. There will have to be a different routine
>> written for nearly each card, I'm wondering if the Scenix has enough
>> code space for this.
>>
>Yeah, we've got about 2K words of codespace. Worst case we could have a
>little PIC 16C54 out there to just be the IO procesor. Couple bucks...
>
>> Another idea may be to have an external processor (with a lot of code
>> space and the ability to run "Real C" code) as the overall controller.
>> Reading information from the Scenix (acting as the I/O interface to
>> the CCPU), doing the waveform playing logic, the mixing, etc. and
>> sending the results back to the scenix which could buffer and play the
>> sounds out the DAC.
>>
>Ehhh... I forgot just how much speed the Scenix really has. I don't think
>we'd need any assist except to maybe just make things easier. The Scenix at
>50MHz spends four cycles bit-banging the 80ns /WE clock on the SmartMedia
>card... The AD5310 (a single supply, serial, voltage out, 10bit DAC in a
>neato-little6-lead SOT 23 package) only needs about 33ns per cycle (the
>Scenix would actually do about 60ns bit-banging it) so it's plenty fast.

I wasn't suggesting the 2nd processor for speed, mostly for code space (the same
reason you might add a PIC) and the ability to run 'C' code -- which might speed
up engineering time up a bit.

>> But however it's done, I'm willing to work out all the interface logic
>> for all the sound boards.
>>
>>That would be really cool.

No problem! I've volunteered for the *easy* part!! (I'll even through in all
the samples you'll need for free!)

-Zonn
Received on Thu Jun 24 02:30:09 1999