Jump to content
  • entries
    62
  • comments
    464
  • views
    86,900

GADGETT


supercat

869 views

Although I'm more interested in 2600 development than 7800 development, I've had an idea for a POKEY alternative for 7800 developers. My intention would be to release an open-source framework that other developers could build upon if desired.

 

The GADGETT (Great Audio Doesn't Get Easier Than This) would be an 8-pin DIP Cypress microcontroller which would be programmed with a small bootloader and would attach to a few pins on the 7800 bus. The part in question costs $2.50 in quantity 100 and could be added to a 7800 cart with no other components required except a one or two resistors.

 

I've sketched out the CPU/RAM requirements and would expect the following to be workable:

  • Six-voice wave-table synthesizer; each voice would mix two 256-byte wave tables in arbitrary proportion, and both mixers would be controlled by independent envelope generators. Maybe vibrato/pitch envelopes as well--not sure about that one.
  • Two digitized waveform channels, with arbitrary playback speed, looping, and event queueing. Wave data could be 4- or 8-bit.
  • Probably about 12K of flash available for wave and envelope tables, digitized waveforms, high scores, etc.

To make something like a piano sound, one could load two waveforms--one for a "bright" piano wave and one for a more mellow wave, and two envelopes--one with a quick decay and one with a slower decay. Attach the first wave to the first envelope and the second to the second envelope. When a note was played it would start with a bright sound and fade into a mellower one.

 

To produce speech, one would have to store digitized phonemes in memory and then queue up a list of events to play them. Since the player would support looping, vowel sounds would not need to take up huge amounts of space. Alternatively, one could simply store spoken messages although 12K of storage wouldn't be a whole lot for that.

 

I don't want to go so crazy on the specs that I can't get the thing done, but I don't want to make something so wimpy that it's not worth using. If the micro features a write-protected bootloader, code in the 7800 could pump it with whatever sound generation software and wave tables were desired. I could supply a binary code image for a decent sound generator, but if anyone wanted to write their own they could.

 

In bootloader mode, one would send/receive a byte of data from the GADGETT using something like the following:

; Write the byte in the accumulator; read a byte into the accumulator
 sta temp
 asl
 asl
 asl
 asl
 sta $8000 ; GADGETT latches data on D4 and outputs data through a resistor on D0
 lsr $3F  ; Or some other unused address
 ror
 sta $8000
 lsr $3F
 ror
 sta $8000
 lsr $3F
 ror
 sta $8000
 lsr $3F
 ror
 lsr
 lsr
 lsr
 lsr
 sta temp2
 lda temp
 sta $8000
 lsr $3F  ; Or some other unused address
 ror
 sta $8000
 lsr $3F
 ror
 sta $8000
 lsr $3F
 ror
 sta $8000
 lsr $3F
 ror
 and #$F0
 ora temp2

A little clunky, but not totally outrageous. Once the music player was started, it would switch to using both D0 and D4 as inputs from the 6502 thus allowing two-byte commands to be transmitted quickly:

 sta $8000
 lsr
 sta $8000
 lsr
 sta $8000
 lsr
 sta $8000
 txa
 sta $8000
 lsr
 sta $8000
 lsr
 sta $8000
 lsr
 sta $8000

Anyone like the concept?

5 Comments


Recommended Comments

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

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...