RE: Cinematronics sound board behavior...

> 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.
        [...]
> Tailgunner used a totally different approach. A 3 to 8 mux. This would
> also
> need to be in the 16V8.
>
Well, I'm pretty sure I can handle all that in one of my big CPLD's I use on
the multigame stuff. Would you happen to have a little interface
description for each "type" of sound interface? (Just so I could come up
with a basic macrocell count and whatnot.)

> 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.
>
Hmmm. That's a good alternative too, but it might get pretty tight in there
to make sure the inputs get serviced when playing sounds. Spending a little
on a CPLD/PAL might be worth it to keep the code easy to write.

> 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.
>
Yeah, but probably *way* overkill. ;-) They generally have a ton of I/O
and cells which I doubt we'd need.

> 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.)
>
I was originally thinking 4 voice, but thought that might not be enough so I
just doubled it. All the more I was thinking for steering logic was just
using a byte as flags-- test bits and when I find a zero, set it to one and
use that channel for the next required sound. The sounds are just stored in
absolute locations on the SmartMedia card with a little FAT for each game
that's loaded into Scenix RAM (based on game select lines on the inputs)
depending on what game is selected on a reset.

> 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.
>
True. That'd be safe. My primary application is for the Sega G-80 which
doesn't have a huge voice requirement (it's also why I like the CPLD in
front of the Scenix-- I can just have a different program loaded on the CPLD
for G-80 or Cinemat operation and run the same code on the Scenix). I think
I have I/O lines to spare (at least on an SX28, might be tight on an SX18).

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

> No problem! I've volunteered for the *easy* part!! (I'll even through in
> all
> the samples you'll need for free!)
>
(...and if you order now...! :-)

What format are the samples (8 bit? 16 bit? absolute? adpcm? something
custom?) Any idea how big the total is memory footprint is?

-Clay
Received on Thu Jun 24 15:38:39 1999