Hello there! I'm working to get homebrew sequenced music working on the Sega Saturn, and I was wondering of some of you here might be able to answer some of my questions regarding that.
First, I was wondering about the possibility of expanding the amount of RAM available to the SCSP, thus addressing one of its known core weaknesses compared to contemporaries such as the PS1's SPU (which had hardware ADPCM to make the effective amount of sound available RAM almost four times as much as the SCSP had). One most obvious thing would be to simply swap sound data into the SCSP's RAM from the CD-ROM drive, but of course that comes with equally obvious bandwidth and seek time limitations, not the mention the massive wear and tear that would have on the physical drive itself. As well as, of course, the fact that doing this doesn't expand the actual amount of RAM in any way, which means that anything that's playing on the SCSP at any given second must still fit into 512 KiB of RAM.
With that said, there's also the Saturn's cartridge slot. Which, as far as I understand, can address up to 4 MiB of additional RAM per cartridge. I also understand that the SCSP has access to the cartridge slot via the SCU's "B-bus" that it shares with the two VDPs (whereas the "A-bus" is connected to the two SH-2s).
So my question with that is: does the SCSP have direct access to the cartridge slot via this bus; as in: can it access it the same way that it can access its own 512 KiB of sound RAM, thus effectively expanding its memory capacity to a total of 4.5 MiB? Or, like with the CD-ROM drive, would data have to be swapped such that the SCSP can theoretically read as much data as it wants from the cartridge slot, but only actually use up to, again, 512 KiB of said data at any given time?
There are a number of possibilities that I've been thinking about if the former is true. For instance, if you were to take two Sega Saturns that each have a 4 MiB RAM cartridge attached to them and have the two consoles play in tandem, then such a setup would provide a total of 8.5 MiB for SCSP that would effectively equal — and actually even slightly surpass — the effective amount of sound RAM of the Dreamcast's AICA when its 4:1 ADPCM compression scheme is applied. (Which, relative to the SCSP with its lack of compression, would indeed roughly be 8 MiB.) Such a setup would effectively give you an AICA on Sega Saturn, except arguably even better than an actual AICA because then you would also have the SCSP's FM support, not to mention two DSPs to play with instead of just one (that is, a single DSP each per 32 channels) à la the PS2's SPU2 and its two reverb units (in its case, one each per 24 channels). Meanwhile, even a much smaller 2 MiB expansion cartridge attached to a single Sega Saturn would result in a total of 2560 KiB for SCSP that would surpass the effective amount of sound RAM of the PS1's SPU when its own 32:9 ADPCM compression scheme is applied! (Which, again relative to the SCSP and its lack of compression, which would roughly be 1820 KiB.) Meanwhile, even in a scenario where sound data must indeed be swapped from the cartridge slot, then if you were to again take two Sega Saturns that both have 4 MiB RAM expansions attached to them and have the two consoles play in tandem, then that would again provide a total of 8.5 MiB for SCSP. And in this case, one could theoretically simulate the Model 3's SCSP setup including its 64 total sound channels, dual 68K processors, dual DSPs, 1 MiB of total sound RAM, and — most critically — roughly half of its 16.5 MiB sample ROM.
However, one concern that I do have about all of this is the necessity using the SCU's B-bus to shuffle sound data around. Indeed, given the proportion between the SCSP's small pool of local 512 KiB of sound RAM and the as much as 4 MiB of cartridge RAM, it's very likely — and almost certainly if one is trying to push SCSP to its absolute limits — that the B-bus is going to have sound data shuffled across it almost literally all of the time. Which means that if the SCU has to shuttle VDP data to another part of the system or stream graphical data from the CD-ROM drive (or in the case of homebrew, wherever the game data is coming from, like perhaps the Video CD slot), then wouldn't that create the potential for bus contention? And if so, then wouldn't that be a problem if you wanted to implement this solution in an actual game (versus, say, just playing said music in a sequence player where presumably almost nothing intenstive is going on with the VDPs)?
As for the second thing, I'm looking for some solid information about the SCSP's DSP, which seems to be somewhat scarce. From what I have found out about it, the SCSP's DSP can execute up to 128 steps of instructions written for it, doing so in an exact order with no looping, conditions, or repeats. It's also apparently programmable to at least some extent, with effects running on there as "modules" that are essentially mini-programs that run on the DSP. All of this seems to differ significantly from what I know about the PS1's SPU, which on the contrary appears to have only a reverb unit that's effectively a "fixed-function DSP" of sorts, in the sense that it's logic baked into the SPU itself that does nothing but calculate reverb coefficients and can't be programmed (easily) to do anything else.
Meanwhile, AICA supposedly inherits a similar if not identical DSP. I've heard some rumblings that there have been some changes made to AICA's DSP versus that in the SCSP, but I don't know about any documentation that exists about what said changes actually are. In any case, I'm assuming that at least inherits the same effects that its SCSP equivalent does?
As far as official SEGA documents go, "SCSP/DSP Effect Module Specifications" (ST-069-121693) provides a list of the DSP modules available as standard on the SCSP. The document describes said list as "tentative" with the values outlined within supposedly subject to change, but it also appears to be the latest reference released that I'm aware of. The DSP modules mentioned are listed below (with conversions of RAM usage for each from the provided kilowords to kibibytes):
DSP module name = Steps usage for module / RAM usage for module
Reverb = 34 steps / 30 KiB
Early Reflection = 100 steps / 26 KiB
Echo (Delay) = 20 steps / 52 KiB
Pitch Shifter = 64 steps / 30 KiB
Chorus = 22 steps / 2 KiB
Flanger = 20 steps / 4 KiB
Symphonic = 21 steps / 2 KiB
Surround = 23 steps / 30 KiB
Voice Cancel = 36 steps / 0 KiB
Auto Pan = 4 steps / 0 KiB
Phaser = 22 steps / 4 KiB
Distortion = 20 steps / 0 KiB
Filter = 5 steps / 0 KiB
Parametric EQ = 5 steps / 0 KiB
So based on everything that I've read in those documents and elsewhere, it appears that you can use any amount and combination of the DSP modules listed above — including more than one of the same module — on any of the SCSP's 32 hardware voices as long as the total number of "steps" spent executing them doesn't exceed 128 and the total number of modules used doesn't exceed 16, is this correct?
Some more questions: are these DSP programs above built into the SCSP itself (as in, any game running any sound driver can access them) or are they only available via certain SEGA-provided sound drivers (as in, the DSP is effectively useless by itself without explicitly giving it code to run)? Also, would the programmable nature of the DSP mean that it's theoretically possible to write custom DSP programs that can do whatever you want, as long as it can be run within the DSP's 128 steps and without exceeding the available sound RAM? (See: ST-228-R1-030596, a "dAsms User Manual" where dAsms is apparently assembly for the DSP.) And how would any of the above be different, if at all, for AICA on the Dreamcast?
Finally, [/I]I was wondering about the possibility of reverse-engineering the official sequenced file formats for Saturn-based music such that custom music can be written to them[/I]. I'm specfically talking about SEQ/TON, which I presume is roughly equivalent to the PS1's SEQ/VAB in that SEQ is a relatively small MIDI-like series of note events and such while TON is a relatively large collection of raw sample files and instrument definitions that the SEQ file references. As well as to Dreamcast's MSB/MPB, for that matter (a somewhat more obscure format from my experience, as far as readily available information about exactly how they work). The closest thing that I could find for documentation of Saturn's SEQ format is a MIDI conversion program by CyberWarriorX named "seq2mid" (currently maintained by Misty De Méo on GitHub here). Meanwhile, TON has an official overview for it in the form of "Tone Editor User's Manual Addendum: File Formats" (ST-235-030795), and some of kingshriek's old Python conversion scripts such as "toncnv" might also be of use. But what I would really like to find out is how close SEQ is to SMF MIDI format 0, which according to certain people in the PlayStation scene is extremely close close — if not practically identical save for a few minor changes — to both PS1's SEQ format and the PS2's SQ format. If it helps, an official MIDI converter specification does exist for SEQ on Saturn (ST-066-121593). And with that in mind, how trivial would it be to use something like a DAW or MIDI sequencer (à la FL Studio or Logic Pro) or a tracker (à la Famitracker or Furnace) to create custom SEQ/TON files that can be played back on a real Sega Saturn like any other sequenced OST?
First, I was wondering about the possibility of expanding the amount of RAM available to the SCSP, thus addressing one of its known core weaknesses compared to contemporaries such as the PS1's SPU (which had hardware ADPCM to make the effective amount of sound available RAM almost four times as much as the SCSP had). One most obvious thing would be to simply swap sound data into the SCSP's RAM from the CD-ROM drive, but of course that comes with equally obvious bandwidth and seek time limitations, not the mention the massive wear and tear that would have on the physical drive itself. As well as, of course, the fact that doing this doesn't expand the actual amount of RAM in any way, which means that anything that's playing on the SCSP at any given second must still fit into 512 KiB of RAM.
With that said, there's also the Saturn's cartridge slot. Which, as far as I understand, can address up to 4 MiB of additional RAM per cartridge. I also understand that the SCSP has access to the cartridge slot via the SCU's "B-bus" that it shares with the two VDPs (whereas the "A-bus" is connected to the two SH-2s).
So my question with that is: does the SCSP have direct access to the cartridge slot via this bus; as in: can it access it the same way that it can access its own 512 KiB of sound RAM, thus effectively expanding its memory capacity to a total of 4.5 MiB? Or, like with the CD-ROM drive, would data have to be swapped such that the SCSP can theoretically read as much data as it wants from the cartridge slot, but only actually use up to, again, 512 KiB of said data at any given time?
There are a number of possibilities that I've been thinking about if the former is true. For instance, if you were to take two Sega Saturns that each have a 4 MiB RAM cartridge attached to them and have the two consoles play in tandem, then such a setup would provide a total of 8.5 MiB for SCSP that would effectively equal — and actually even slightly surpass — the effective amount of sound RAM of the Dreamcast's AICA when its 4:1 ADPCM compression scheme is applied. (Which, relative to the SCSP with its lack of compression, would indeed roughly be 8 MiB.) Such a setup would effectively give you an AICA on Sega Saturn, except arguably even better than an actual AICA because then you would also have the SCSP's FM support, not to mention two DSPs to play with instead of just one (that is, a single DSP each per 32 channels) à la the PS2's SPU2 and its two reverb units (in its case, one each per 24 channels). Meanwhile, even a much smaller 2 MiB expansion cartridge attached to a single Sega Saturn would result in a total of 2560 KiB for SCSP that would surpass the effective amount of sound RAM of the PS1's SPU when its own 32:9 ADPCM compression scheme is applied! (Which, again relative to the SCSP and its lack of compression, which would roughly be 1820 KiB.) Meanwhile, even in a scenario where sound data must indeed be swapped from the cartridge slot, then if you were to again take two Sega Saturns that both have 4 MiB RAM expansions attached to them and have the two consoles play in tandem, then that would again provide a total of 8.5 MiB for SCSP. And in this case, one could theoretically simulate the Model 3's SCSP setup including its 64 total sound channels, dual 68K processors, dual DSPs, 1 MiB of total sound RAM, and — most critically — roughly half of its 16.5 MiB sample ROM.
However, one concern that I do have about all of this is the necessity using the SCU's B-bus to shuffle sound data around. Indeed, given the proportion between the SCSP's small pool of local 512 KiB of sound RAM and the as much as 4 MiB of cartridge RAM, it's very likely — and almost certainly if one is trying to push SCSP to its absolute limits — that the B-bus is going to have sound data shuffled across it almost literally all of the time. Which means that if the SCU has to shuttle VDP data to another part of the system or stream graphical data from the CD-ROM drive (or in the case of homebrew, wherever the game data is coming from, like perhaps the Video CD slot), then wouldn't that create the potential for bus contention? And if so, then wouldn't that be a problem if you wanted to implement this solution in an actual game (versus, say, just playing said music in a sequence player where presumably almost nothing intenstive is going on with the VDPs)?
As for the second thing, I'm looking for some solid information about the SCSP's DSP, which seems to be somewhat scarce. From what I have found out about it, the SCSP's DSP can execute up to 128 steps of instructions written for it, doing so in an exact order with no looping, conditions, or repeats. It's also apparently programmable to at least some extent, with effects running on there as "modules" that are essentially mini-programs that run on the DSP. All of this seems to differ significantly from what I know about the PS1's SPU, which on the contrary appears to have only a reverb unit that's effectively a "fixed-function DSP" of sorts, in the sense that it's logic baked into the SPU itself that does nothing but calculate reverb coefficients and can't be programmed (easily) to do anything else.
Meanwhile, AICA supposedly inherits a similar if not identical DSP. I've heard some rumblings that there have been some changes made to AICA's DSP versus that in the SCSP, but I don't know about any documentation that exists about what said changes actually are. In any case, I'm assuming that at least inherits the same effects that its SCSP equivalent does?
As far as official SEGA documents go, "SCSP/DSP Effect Module Specifications" (ST-069-121693) provides a list of the DSP modules available as standard on the SCSP. The document describes said list as "tentative" with the values outlined within supposedly subject to change, but it also appears to be the latest reference released that I'm aware of. The DSP modules mentioned are listed below (with conversions of RAM usage for each from the provided kilowords to kibibytes):
DSP module name = Steps usage for module / RAM usage for module
Reverb = 34 steps / 30 KiB
Early Reflection = 100 steps / 26 KiB
Echo (Delay) = 20 steps / 52 KiB
Pitch Shifter = 64 steps / 30 KiB
Chorus = 22 steps / 2 KiB
Flanger = 20 steps / 4 KiB
Symphonic = 21 steps / 2 KiB
Surround = 23 steps / 30 KiB
Voice Cancel = 36 steps / 0 KiB
Auto Pan = 4 steps / 0 KiB
Phaser = 22 steps / 4 KiB
Distortion = 20 steps / 0 KiB
Filter = 5 steps / 0 KiB
Parametric EQ = 5 steps / 0 KiB
So based on everything that I've read in those documents and elsewhere, it appears that you can use any amount and combination of the DSP modules listed above — including more than one of the same module — on any of the SCSP's 32 hardware voices as long as the total number of "steps" spent executing them doesn't exceed 128 and the total number of modules used doesn't exceed 16, is this correct?
Some more questions: are these DSP programs above built into the SCSP itself (as in, any game running any sound driver can access them) or are they only available via certain SEGA-provided sound drivers (as in, the DSP is effectively useless by itself without explicitly giving it code to run)? Also, would the programmable nature of the DSP mean that it's theoretically possible to write custom DSP programs that can do whatever you want, as long as it can be run within the DSP's 128 steps and without exceeding the available sound RAM? (See: ST-228-R1-030596, a "dAsms User Manual" where dAsms is apparently assembly for the DSP.) And how would any of the above be different, if at all, for AICA on the Dreamcast?
Finally, [/I]I was wondering about the possibility of reverse-engineering the official sequenced file formats for Saturn-based music such that custom music can be written to them[/I]. I'm specfically talking about SEQ/TON, which I presume is roughly equivalent to the PS1's SEQ/VAB in that SEQ is a relatively small MIDI-like series of note events and such while TON is a relatively large collection of raw sample files and instrument definitions that the SEQ file references. As well as to Dreamcast's MSB/MPB, for that matter (a somewhat more obscure format from my experience, as far as readily available information about exactly how they work). The closest thing that I could find for documentation of Saturn's SEQ format is a MIDI conversion program by CyberWarriorX named "seq2mid" (currently maintained by Misty De Méo on GitHub here). Meanwhile, TON has an official overview for it in the form of "Tone Editor User's Manual Addendum: File Formats" (ST-235-030795), and some of kingshriek's old Python conversion scripts such as "toncnv" might also be of use. But what I would really like to find out is how close SEQ is to SMF MIDI format 0, which according to certain people in the PlayStation scene is extremely close close — if not practically identical save for a few minor changes — to both PS1's SEQ format and the PS2's SQ format. If it helps, an official MIDI converter specification does exist for SEQ on Saturn (ST-066-121593). And with that in mind, how trivial would it be to use something like a DAW or MIDI sequencer (à la FL Studio or Logic Pro) or a tracker (à la Famitracker or Furnace) to create custom SEQ/TON files that can be played back on a real Sega Saturn like any other sequenced OST?
