AtariAge "CPU comparison"

[Sik]

Compare the clarity of "Nintendo!" in Tetris Attack to "Say-Gah" in the Sonic games to see what a difference bit depth makes. Or compare the clarity of any Super NES game to its GBA port, which is usually a pile of hiss and aliasing because of its 8-bit DAC usually filled by software mixing at 18 kHz.

Sample rate (and more importantly proper timing) makes an even bigger difference than bit depth does, though (the latter matters mostly for quiet noise, the former matters for whether it even sounds correctly at all). Mind you, SNES still gets an edge there.

Also let's say Sega's sound engine wasn't exactly the best at PCM either even for the system's standards... (in fact the Seeegaaa sound is played with code that's unique to that sample with a busy loop just for that reason, which is also why it can't play properly anything else during that time)

[TOUKO]

Also let's say Sega's sound engine wasn't exactly the best at PCM either even for the system's standards... (in fact the Seeegaaa sound is played with code that's unique to that sample with a busy loop just for that reason, which is also why it can't play properly anything else during that time)

i think it's the case on almost all platforms, on PCE you'd be surprised how PCM drivers are bad, even in SF2 .

[Stef]

Do you really want to compare which version of SF2 has the worst sound PCM driver ? :p

[TOUKO]

Do you really want to compare which version of SF2 has the worst sound PCM driver ? :p

LOL, can i take a wildcard ??

SF2 driver eat 10/15% for a single pcm, and close to 20% for 2.PCM are not as bad as MD because fortunately,even with a so bad driver, timings for accessing to the sound chip are not as tight than the 2612 ones, the PCE's sound chip run at 3,58 mhz without any latency for reading/writing registers .

for managing sprites, i think a well organised SAT is also important, it's not so good to spend too many cycles for changing something in the sprites table .

[HihiDanni]

Seeing stuff like the Genesis Z80 getting paused every frame for things such as end-of-frame DMA transfers makes me appreciate how isolated the SPC-700 is from the rest of the system, since it doesn't have to fight over shared resources. On the other hand it means a convoluted upload process and garbage loading times. I'm hopeful about getting two simultaneous streaming samples, but I'm going to need to modify the SNESGSS sound driver, and I know basically nothing about how the SPC-700 works.

[TOUKO]

Seeing stuff like the Genesis Z80 getting paused every frame for things such as end-of-frame DMA transfers makes me appreciate how isolated the SPC-700 is from the rest of the system, since it doesn't have to fight over shared resources

if i am right, Z80 is stopped only if you want access to the 68K bus,else it run freely .
SPC-700 is isolated yes, but so isolated that it cannot accessing to ROM datas, for me it's not a better solution .

[HihiDanni]

The waveform stops updating when the Z80 is paused. On the SPC you're uploading data into a buffer space representing the sample that the DSP is reading continuously. I think the Genesis could have benefited from a PCM buffer rather than relying on a CPU to provide individual updates.

[tepples]

But then the samples are on the cartridge, and the cartridge is on the 68K bus. Would it have been hard for the Z80 to use its 8K of exclusive RAM as a circular buffer? It'd be filled during draw time, when DMA is unlikely to be running, and emptied during vblank to leave room for BLAST PROCESSING. Can the Z80 see the vcount in Genesis mode?

[TOUKO]

I think the Genesis could have benefited from a PCM buffer rather than relying on a CPU to provide individual updates.

Of course you're right, but SPC can also benefit to have a DMA(or another mecanism) for updating his RAM without using the CPU .The Z80 have also some drawback.

But then the samples are on the cartridge, and the cartridge is on the 68K bus. Would it have been hard for the Z80 to use its 8K of exclusive RAM as a circular buffer

Yes ,it's how works some MD's PCM drivers,they use a buffer and fill it in active display,of course this cause some PCM delay (if I remember correctly,stef's driver has up to a 4 frames delay),and steal some 68K cycles .
Another problem is to use timed code to send datas to the 2612 DAC,and cherry on the cake, the 2612 is damn slow,but results are better than PCM hear in SF2 for exemple, not scratchy, but can be heavily distorded .

SPC-700, is not perfect too, and have also some drawback, mainly with only 64K of RAM,sounds are perceived muffled by many people .

Can the Z80 see the vcount in Genesis mode?

Yes, but unfortunately it's the only irq to be saw by Z80,the 2612's timers and hsync lines are not connected,this is why you need timed code to play PCM .

[HihiDanni]

SPC can also benefit to have a DMA(or another mecanism) for updating his RAM without using the CPU

The SNES can DMA stuff to the APU I/O registers, but the audio-side CPU has to individually read each byte out of these. It would have been nice if the APU could finish the transfer of each byte without CPU intervention.

[TOUKO]

it seems that some guys here try to feed SPC ram with HDMA, but i don't know if it works or not .

[HihiDanni]

HDMA should work, since it's basically a mechanism for periodically writing bytes to registers, and these periods can be made long enough for the SPC to process each byte sent over. This means you can have your game doing other stuff with the streaming happening with periodic interrupts instead of the program spending time in a busy loop waiting to send the next byte. Streaming audio in this way is a great workaround to the 64kb limit, though I can imagine why it didn't see widespread usage since it basically needs driver-side support.

[TOUKO]

Streaming audio in this way is a great workaround to the 64kb limit

Yes,if it really usefull/doable in game,i agree,even in psychopaticteen's bad apple demo it would be an accomplishment.

[Stef]

But then the samples are on the cartridge, and the cartridge is on the 68K bus. Would it have been hard for the Z80 to use its 8K of exclusive RAM as a circular buffer? It'd be filled during draw time, when DMA is unlikely to be running, and emptied during vblank to leave room for BLAST PROCESSING. Can the Z80 see the vcount in Genesis mode?

It's feasible and actually exactly how work my XGM sound driver. It does even more than that: it takes care of the DMA bus contention but also allow to play up to 4 PCM at same time (at 14 Khz) while playing the music, that is everything running on the Z80.
That give you an idea about how bad the SF2 driver is (100% of the Z80 CPU used for that awful 2 PCM mixing at 7.5 Khz).

Using PCM buffering in Z80 memory is the basic idea which bring much more possibilities in term of PCM Megadrive sound driver.
As said Touko it adds a bit of delay to the PCM playback but honestly it's not much noticeable for SFX and for the music you can fix them in amount (what the XGM driver is doing).

About the VCounter, yeah you can access it but accessing the VDP mean you use the 68K bus so you should avoid to access it in DMA potential period. I was using the V-Int for music tempo and guess when DMA could occurs but now i'm using the 68k to give XGM tempo, that offer more flexibility (for PAL / NTSC timing) and also give finer control for the BUS contention issue.

[Sik]

To be fair, honestly the interruption problem would have been solved if the Z80 got priority over the VDP during DMA. That'd have slowed down video transfers a bit but it'd mean PCM never has to get interrupted. (also this really was never problem with FM and PSG as the hardware keeps playing them and timing-wise at worst you get a delay of like 1/7 of the frame, practically unhearable?) Though the problem with Sega's driver is a flawed design instead =P (halt PCM while processing FM and PSG, which takes up a good chunk of the frame! that's why it sounds so scratchy)

I'd argue the SPC memory limitation is worse, honestly. I mean, it's a sample based system, where access to more memory is even more important. But of course there's the bus conflict issue, I wonder if that could have been handled with the priority I mentioned.