ponèSound - Sound control library


Gear Supporter
Link: ponut64/SCSP_poneSound

What is it?
It is a program written in C for the Saturn's MC68EC000 which will interface and control function of the SCSP.
The MC68EC000 is a low-power, economized variant of the Motorola 68000 processor found in the Genesis, Commodore Amiga, Atari ST, and Sharp X68000. It has the same ISA (instruction set architecture) as such. Its clock-speed is 11.2 MHz, though the minimum execution time for an instruction is 4 cycles.

SCSP stands for Saturn Custom Sound Processor. This is a complex sound processing chip with an embedded linear DSP, 32-channel audio support in either FM Synthesis, 8-bit PCM, or 16-bit big endian PCM. The DSP embedded in this chip is referred to as the SCSP-DSP, and is ostensibly directly linked to the output of audio samples to the DAC (digital to audio converter).

The SCSP's most noteworthy shortcoming in comparison to other major sound chips at this time is a complete lack support for compressed audio. Despite having 512KB of dedicated memory attached to it, this meant that audio samples on Saturn games are frequently at a lower frequency, or lower quantity, than on other consoles of the time.

Interestingly, the MegaDrive/Genesis seemed to share this bottleneck in comparison to the Super Nintendo. The SNES had 64KB of dedicated audio RAM and was capable of playing back compressed audio from the beginning. Sega developers would have had to make a solution for compressed PCM samples on their own, if they wanted it.

On Saturn, developers seemed to be content with the limitations on PCM audio samples, given that the system was readily able to play back Redbook audio (CD audio). However, Redbook audio takes up a lot of space on the CD despite taking no space in system RAM. Sega both contracted with third parties and developed solutions internally to resolve this problem, despite the overall hardware design being intended to make use of FM Synthesis ('chip tunes') to achieve this.

The result of this was that many "late-life" official Saturn games used compressed audio in the form of ADPCM. In every documented case, the best we can guess is the main CPUs handled the decompression of the PCM data, rather than the sound CPU.
The leading format for compressed audio on Saturn was CRI ADX. ADX is an advanced form of ADPCM. Its compression ratio is near 4:1, and the decompressed audio is of a higher quality than could be found from other common ADPCM formats of the 90's (IMA).
The compression rate, ease of decompression, and quality of ADX were all high enough such that Burning Rangers manages streaming multiple channels of ADX sound from the CD at once: Not just stereo music, but also character voices. (*citation needed?)

Sega also developed a library called "SEGA_ADP" and a compression tool to go along with it. The format supported by these tools is Dialogic ADPCM. Other games have been spotted using IMA formats.

As noted earlier, it is not known if any official game used the sound CPU to decompress audio in real-time. SEGA had an official driver for the 68K that was written in assembly, its source code is available in SBL6. It is more than plausible that one or another developer modified or re-wrote this driver -- or to save time on developing for the system, they may have bypassed it altogether. Use of the sound CPU is not at all required to control the SCSP. Ultimately, the SCSP's register settings control the playback of sound, and both main CPUs may access these registers.

That said, it has been proven by developers on many other 68K-based systems that the chip is more than capable of real-time decompression of acceptable quality ADPCM in addition to managing the functions of a full-speed 2D game. Most commonly, IMA is the ADPCM format chosen for this because one of IMA's goals in design was to be able to be decompressed quickly by commodity processors lacking division and multiplication instructions. While the 68K has these instructions, they are quite slow. Theoretically, an 11.2 MHz 68K should be able to decompress over 50,000 samples per second of IMA format audio.

However, the Saturn's 68K has the potential to be severely crippled by the fact that it must share access to memory with at least one high-speed processor at all times. I say "at all times" because one must assume the game is playing audio all the time, whether music or otherwise, and said sound effects are played back from memory.

If you would like to look at the exact memory module specifications, the model is (Hitachi) HM51S4270AJ-7 @ 20 MHz (*speed?).

So the SCSP manual is publicly available on antime's website, but the key takeaways from it are:
1. Sound RAM has 126 available memory cycles between refresh cycles
2. Each sound slot (of 32) uses two of those cycles when playing back sound
3. The highest priority memory access alternates between SCSP (PCM) and SCSP (DSP).
4. All other devices in the system have a higher priority memory access than the sound CPU
5. All other devices in the system have a lower priority memory access than the SCSP (and its DSP).

So we might gather -
1. Each active sound slot increases the execution delay of memory-bound instructions by the sound CPU by an average of 1.5%
2. A moment of access by any other chip in the system will increase the execution delay of memory-bound instructions by 0.75% (in that moment)

In practice, these limitations may be trivial. Unless sequenced music is being used (a la MIDI), only a few sound slots will be active at a time (let's say, 8), though this is not a required limitation. Every sound slot is a potential sound generator. At its peak, PCM activity will increase the sound CPU's memory access delay by 50%. Peak SCSP-DSP activity may even take the other half, and completely block the sound CPUs memory access. Constant access by any other chip in the system may have the same effect.

All that said, plausibly speaking, it isn't likely for the sound CPU to be choked on memory. The memory is faster than the processor itself. It is still possible for this to cause a problem however, as the SCSP (and its DSP) are faster than the memory (at 22.05 MHz).

I've talked up the 'problem' of getting the 68K to playback compressed audio in real-time like its some big deal -- but no, it's really just a 68k. If a Genesis or Atari ST can do it, so can it.

My particular driver uses ADX, and not IMA. ADX is substantially slower than IMA. I only decided to use ADX because... well, it was easier to debug. I couldn't figure out how to properly decompress IMA, even though its simpler and faster. The driver is capable of decompressing about 25,000 ADX samples per second, in addition to other basic functions the driver must perform. In future, additional features or circumstances may mandate a switch to IMA to increase performance. For now, the driver meets its basic goals. The 68K program and linked library are written entirely in C.

The comparison between optimized ADX decompression and IMA decompression is that:
ADX uses 1 multiplication, 1 logical branch, 1 bitwise AND, 3 table lookups, 2 adds, 2 shifts an average of 7 bits per sample.
(Theoretical: 68K : 170 cycles per sample, SH2 : 17 cycles per sample)
IMA uses 3 logical branches, 1 bitwise OR, 1 bitwise AND, 2 table lookups, 2 adds, 1 shift an average of 3 bits per sample.
(Theoretical: 68K : 86 cycles per sample, SH2 : 22 cycles per sample)

I will give a general disclaimer that results as far as sound system emulation are not guaranteed.
Mednafen may introduce static and pops to the sound output which are not present on a real console.
SSF blows out the high dynamic range more than a real console.
Yabause is not prepared to emulate a custom sound driver such as this and so it doesn't work at all.
Of course, who knows. Could just be that these are real things, but the digital to analogue conversion of the SCSP covers them up so we would never actually hear a real Saturn produce these artifacts.
Last edited:
If the source for Dialogic PCM is available, then making it IMA compliant is trivial. It just consists of a slightly larger table, changing your clamp delta range to +- 32K, and changing your index clamp to 88 instead of 44. Since Dialogic is a 12bpp algorithm, it may be shifting left 4 to make it 16bit, so this can be removed.
Getting IMA compliant decompression on its own is trivial. I just couldn't read Microsoft's stupid header properly.
If you want to be pedantic about it (and you do, otherwise why post on the Internet?), the two SCSP revisions use different memory. The older one uses HM514270, while the newer one with the integrated m68k uses the same HM514260 as is used for eg. workram-L, and the CD block. AFAIK, the only difference is the interface, the '70 uses an unusual LWE/HWE scheme while the '60 the normal LCAS/UCAS scheme. The SCSP (both revisions) supports a full megabyte of RAM, and the ST-V board even includes an unpopulated footprint for a second chip. I believe the documentation mentions somewhere that the sound development kits also came with 1MB.

As a sidenote, I believe that the memory access priority table is the reason why the documentation warns against keeping the m68k in reset. If the m68k is placed into reset while in the middle of a bus transaction, I suspect that the lower-priority RAM refresh will be blocked until the m68k is released from reset again. Since the m68k reset line isn't connected to the SCSP, it has no way of knowing that the transaction should be aborted, and just keeps waiting until it's completed.
Did I understand right that this is a 68k implementation of ADX? That's pretty damn neat.

As for your write up, software ADPCM decoding was supported on the Saturn since before the console was released (the console startup sound itself is ADPCM). Other solutions like only came about to make it easier on developers. CRI ADX was one such thing and it evolved into a powerful middleware tool. I think the first versions were in late 97 but I'm not sure... 1998 Saturn games definitely used it, so the tools to make such files must have been available by 1997.

Oh, and regarding the memory bandwidth limitation. At least one game chokes sample playback because the SH2s are busy polling the 68k, leaving it with no time to play sound - Virtua Fighter 2, of all games. If you played the game a lot, you can recall how it cuts off the end of sound samples constantly. It was even a problem on some emulators too, where if the emulated 68k access latency wasn't slow enough (allowing for the 68k to be hit even more often), the sound wouldn't work.