Ponut
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)
/e:
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.
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)
/e:
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:
