External sound chips other than the POKEY

[ApolloBoy]

Just curious, is it possible for the 7800 to support an external sound chip other than the POKEY? I'm kind of becoming interested in programming for the 7800 again and I want to know if it's possible to use, say, a YM2612 instead of a POKEY for music.

[supercat]

Just curious, is it possible for the 7800 to support an external sound chip other than the POKEY? I'm kind of becoming interested in programming for the 7800 again and I want to know if it's possible to use, say, a YM2612 instead of a POKEY for music.

 

Sure, it's easy to use just about any type of sound chip on the 7800. My personal preference would probably be to use a modern microcontroller with a PLD for bus interfacing. Small micros are cheaper than sound chips but more versatile. Note that the SpeakJet used in the AtariVox is nothing more than a microcontroller with some custom code.

 

On the 7800, I would think the most interesting audio design possibility would be to have a 4-bit 15.75KHz ADPCM decoder with a data queue that's loaded on the bus cycles following an access to certain addresses. Using this approach, digitized audio would be entirely practical in a 7800 game with relatively minimal overhead.

[Bruce Tomlin]

On the 7800, I would think the most interesting audio design possibility would be to have a 4-bit 15.75KHz ADPCM decoder with a data queue that's loaded on the bus cycles following an access to certain addresses. Using this approach, digitized audio would be entirely practical in a 7800 game with relatively minimal overhead.

...as if the MARIA doesn't suck up enough bus cycles already!

 

It better have a pretty decent FIFO, since the 7800 will just get a few cycles per scan line during display if the MARIA is really busy, so you have to fill it during retrace. Yeah, 1000+ bus transactions per frame just for sound, that's exactly what the 7800 needs.

 

(combining the channels into pairs of 8 bit writes will not help because then you have to do rotates and ORs, which is even more work)

[supercat]

On the 7800, I would think the most interesting audio design possibility would be to have a 4-bit 15.75KHz ADPCM decoder with a data queue that's loaded on the bus cycles following an access to certain addresses. Using this approach, digitized audio would be entirely practical in a 7800 game with relatively minimal overhead.

...as if the MARIA doesn't suck up enough bus cycles already!

 

A frame worth of data at 15.2KHz 4-bit ADPCM is 128 bytes. Each display list item is 3 bus cycles plus the data it displays, right? So I'd figure a display list item fetched from a "trigger" address, followed by a display list item for the data itself which would be expected to appear on the fifth through twentieth cycle afterward. Do eight lines like that per frame and you've got all the audio data you need at a cost of under 200 stolen cycles. The CPU code to manage the audio wouldn't be difficult:

 lda framesleft
 beq no_audio
 dec framesleft
 lda aud_ptr_l
 clc
 adc #16
 sta aud_ptr_l
 bcc aud_done
 lda aud_ptr_h
 adc #7; Really 8
 sta aud_ptr_h
 jmp aud_done
no_audio:
 lda #SILENCE_LEN; Cut the number of cycles for the display list when not doing anything useful
 sta aud_length
 lda #SILENCE_TRIG
 sta aud_trig		; A byte of the trigger address -- nuke this to disable audio output.
aud_done:

Run that code once per frame. Entirely reasonable.

 

It better have a pretty decent FIFO, since the 7800 will just get a few cycles per scan line during display if the MARIA is really busy, so you have to fill it during retrace. Yeah, 1000+ bus transactions per frame just for sound, that's exactly what the 7800 needs.

 

How do you figure 1000+ transactions per frame? I figure under 200 for Maria plus 30 for the CPU. So under 256 cycles for everything.

Edited February 22, 2007 by supercat

[Schmutzpuppe]

Just curious, is it possible for the 7800 to support an external sound chip other than the POKEY? I'm kind of becoming interested in programming for the 7800 again and I want to know if it's possible to use, say, a YM2612 instead of a POKEY for music.

I also thought about this and took a look for something similar to the AY but I didn't found anything useable.

It looks as if simple sound chips aren’t very common these days…

[supercat]

It looks as if simple sound chips aren’t very common these days…

 

Probably because a small micro can easily be made to do anything one of those other sound chips can. If a 7800 cart had a PLD with a spare pin (for an address decode), it could produce better-than-POKEY sound just by adding an 8-pin DIP (CY8C2713). Those are $5 in onesies or $2.50 in hundreds. No other components required. Too bad I never have enough round tuits these days.

Edited February 23, 2007 by supercat

[Bruce Tomlin]

A frame worth of data at 15.2KHz 4-bit ADPCM is 128 bytes. Each display list item is 3 bus cycles plus the data it displays, right? So I'd figure a display list item fetched from a "trigger" address, followed by a display list item for the data itself which would be expected to appear on the fifth through twentieth cycle afterward. Do eight lines like that per frame and you've got all the audio data you need at a cost of under 200 stolen cycles. The CPU code to manage the audio wouldn't be difficult:

The horizontal sync frequency is 15-ish KHz, or one sample per scanline, meaning 260 or so samples per screen. Then multiply by the number of channels. So 256-ish samples times four is 1024-ish bus writes just to send the ADPCM data to the chip.

 

Hmm, now I see what you're thinking... put adjacent samples in the same byte. That would indeed double your data rate with no need to 4xROR.

 

I still think you're going to have a problem if you use a lot of graphics. The 7800 is okay with a bunch of sprites, but once you try to use big areas of bitmap or character data, especially as a background, Maria will eat your CPU alive.

[supercat]

I still think you're going to have a problem if you use a lot of graphics. The 7800 is okay with a bunch of sprites, but once you try to use big areas of bitmap or character data, especially as a background, Maria will eat your CPU alive.

 

I recognize that trying to spread the data throughout the frame would complicate things, so my thought was to put all the sound data on 4 or so scan lines that weren't being used to show anything. One 4-bit sound channel at a speed of 15.2Khz would work out to 128 bytes/frame. Buffering that much data in a small micro shouldn't be a problem, and no cycles would be added during the busier parts of the frame.

 

Another approach would be to store all the sound data within a small micro. This might be somewhat easier from a hardware perspective, though in some ways I think it's nicer to "unify" the sound data in one place. A CY8C27143 ($2.50 in qty 100) is an 8-pin DIP micro with 16K of flash and two analog outputs. It could probably be added to many cart designs without requiring any "extra" chips.

 

For example, an audio-enhanced cart with 48K ROM, the audio, and nothing else could probably be implemented using a 27512 EPROM, the audio chip, and a quad NOR.

 

Start by feeding A14 and A15 into a NOR gate (low when address is $4000-$FFFF). Drive the EPROM chip-select with that.

Feed that output into another NOR gate to generate RAMHI.

Feed A13 into a third NOR gate to generate /A13.

Feed /A13 and RAMHI into a fourth NOR gate (goes high for accesses $2000-$3FFF)

 

Then feed that output along with D0 and D4 into the micro. The software in the micro will be configured to shift in serial data after the select input has been high for 500ns.

 

Thus, to send a byte of data to the PSOC, one would do something like:

 sta $3FFF; Will trash RAM at $1FFF
 lsr
 sta $3FFF
 lsr
 sta $3FFF
 lsr
 sta $3FFF

Obviously this approach wouldn't be much good if one had to feed digitized audio data to the PSOC, but it could be entirely practical if using the PSOC as an alternative to the POKEY for music generation (in which case the amount of data required would be reasonably small).

Edited February 27, 2007 by supercat

[supercat]

The more I think about the PSOC (CY8C27143) approach, the more I like it. If one put a resistor between D0 and the PSOC pin, it would be pretty straightforward to include a boot-loader in the PSOC that would allow its flash to be read and written via 7800 code. This would not only aid development, but it would also allow some of the flash to be used for storing things like high scores.

 

If I were designing a PSOC-based sound system for the 7800, my instinct would be to provide eight channels of wave-table synthesis and two arbitrary-loop sound channels.

 

Each wavetable synthesis channel would compute, 16,000 times/second:

uint16 phase,freq;
uint8 volume;		/* 0-127 max */

phase=phase+freq;
output = wavetable[phase/256] * volume;

using any of up to 48 256-byte wavetables. The arbitrary-loop sound generators would compute:

uint24 waveptr;
uint16 freq,wave_end,wave_loop;
uint8 loop_count,volume;

waveptr = waveptr + freq;
if (waveptr/256 > wave_end)
{
 wave_ptr = wave_ptr - 256*(wave_loop);
 if (wave_count > 0)
wave_count = wave_count-1;
 else
/* Fetch next set of parameters from queue */
}
output = flash[wave_ptr/256] * volume;

Something like that would be pretty straightforward to code, but would be incredibly versatile. How interested would anyone be in such a thing?

Edited February 27, 2007 by supercat

[Bruce Tomlin]

I think if you're going to go the trouble of putting a CPU on the board to play sound, you might as well load the sound into the CPU's flash and just give it commands to play from a list. Just two bytes is all you need, sound number and channel number. There's really no point in pushing a bunch of PCM sound data across the 7800's bus when the Maria is already sucking up enough cycles.