2600 in 2006

The concept is interesting, although 12K & 256 byte samples might get a little limitting. You'd need some kind of Windows emulator for developing & testing the samples. How would you program the flash? The interface should be as asynchronous as possible (i.e. start/end points/looping), so the 7800 code can only do updates on a frame basis.

 

Although a wavetable APU would be neat* (speech is a neat twist), I think a simple frequency generator would be much easier to use for music (though not for SFX). The easiest way is a wide accumulator with the MSB driving the output.

 

Finally, how difficult would it be to put in a shift register (FIFO?) with an address decoder? Your code chews up a lot of cycles doing that shifting. (Also, the smaller the address footprint, the better.)

 

* I loved my Gravis Ultrasound (original Classic); RAM+DSP+DAC. But I've always felt if they had included direct DAC access the same as a SoundBlaster Pro, they would have made a significant dent in the market. ('cause the FPS games of the time only used the SB DAC, not FM.)

The concept is interesting, although 12K & 256 byte samples might get a little limitting. You'd need some kind of Windows emulator for developing & testing the samples. How would you program the flash? The interface should be as asynchronous as possible (i.e. start/end points/looping), so the 7800 code can only do updates on a frame basis.

 

The sampled-audio channels could accommodate samples of any length. The wave-table channels would be limitted to using 256-byte wave tables (no need for 16-bit pointer maths, pointer comparisons, etc.)

 

Although a wavetable APU would be neat* (speech is a neat twist), I think a simple frequency generator would be much easier to use for music (though not for SFX). The easiest way is a wide accumulator with the MSB driving the output.

 

So just feed in one or two simple wave tables for basic waveforms if that's what you want.

 

Finally, how difficult would it be to put in a shift register (FIFO?) with an address decoder? Your code chews up a lot of cycles doing that shifting. (Also, the smaller the address footprint, the better.)

 

Using 40 cycles for 2 bytes isn't all that horrible (the boot-loader mode is trickier since it has to read and write, but no biggie). As for address footprint, if the address can overlay some other space, who cares? For example, if the EPROM chip-select disables the EPROM on write cycles, then writes to the EPROM space could go to the GADGETT since they would otherwise serve no purpose. Smaller address footprints require actually decoding more address lines, which in turn requires more hardware.

 

If one went with a 20-pin DIP instead of the 8, one could shift in 4 bits at a time instead of two, but I don't know that having to work the command set around 32-bit chunks would be terribly elegant. Otherwise one could add a 74HC165 to grab all 8 bits of the bus at once, but that's another chip.

 

* I loved my Gravis Ultrasound (original Classic); RAM+DSP+DAC. But I've always felt if they had included direct DAC access the same as a SoundBlaster Pro, they would have made a significant dent in the market. ('cause the FPS games of the time only used the SB DAC, not FM.)

 

That was a case of programmers coding for the lowest common denominator. No reason to code for 1% of the audience. On the other hand, if a card contains a GADGETT anybody who plays the cart is also going ot have a GADGETT.

For a quick speech synth you could use a set of SPO256 phoneme samples.

 

Here's a set

For a quick speech synth you could use a set of SPO256 phoneme samples.

 

Those would be nice if they weren't so big. Even cutting the sample rate in half and using 4-bit data they'd still be too big. The SPO256 certainly didn't have 130KB of ROM in it; how did it store things?

Those would be nice if they weren't so big. Even cutting the sample rate in half and using 4-bit data they'd still be too big. The SPO256 certainly didn't have 130KB of ROM in it; how did it store things?

The real thing uses a programmable digital filter modelled on the human vocal tract. A 16K ROM holds both the filter 'model' and code for operating the chip. I'm guessing this would be hard to implement ?

 

The reason I suggested the samples is I was playing with this which uses the same technique.