This might not be completely on topic, but I think Ristar uses a modification of the S3K driver, with the ability to play back multiple samples. Almost makes me wish they had toyed with that sort of thing sooner, so we'd see better multi-pcm implementations before the end of the system's life cycle. I think the sample output itself is crushed to a certain degree, but I noticed that multiple samples playing on top of each other don't exactly lose quality (rather they're just a bit quieter).
It seems to be a bug in the song itself: Code (ASM): smpsFMAlterVol 8 dc.b nG4, $06, nG5, nG4, nRst, $18 smpsFMAlterVol -6 It increases the volume attenuation by 8, but only lowers it by 6 afterwards. Attenuation makes the audio quieter, so what happens is that the channel gets quieter and quieter over time until the value wraps back around to maximum volume. It just takes a while because it has to go from 0 all the way to 256 before it wraps. Sonic & Knuckles corrected this by changing the 8 to a 6, bringing it in line with other parts of the song: Code (ASM): smpsFMAlterVol 6 dc.b nG4, $06, nG5, nG4, nRst, $18 smpsFMAlterVol -6 That's not the only bug this song has though - here's one not even S&K fixed: Code (ASM): smpsFMAlterVol -$03, $D3 [...] smpsFMAlterVol $03, $D3 These commands are used repeatedly on the PSG3 channel, but they aren't smpsPSGAlterVol commands, so they don't work - instead they're just ignored and the volume isn't changed at all. The smpsFMAlterVol commands used in the PSG3 channel and the ones used in the FM channels are technically different commands though: notice how one only has one parameter while the other has two? The one with two parameters is command $E5, while the one with one parameter is $E6 - SMPS2ASM just gives them identical names as a form of syntax sugar. smpsPSGAlterVol is $EC. In the original SMPS source code, these commands were called CMVADD ($E6), PFVADD, ($E5), and PVADD ($EC). As you can see, the $E5 and $EC commands have very similar names, so you can tell how the developer got them confused. It's ironic, too, because PFVADD would have worked: while CMVADD is for changing the volume attenuation of an FM channel, and PVADD is for doing the same to a PSG channel, PFVADD was intended for both. For some reason, S3K's driver just removed its ability to alter the volume of PSG channels. The major problem with using PFVADD however is that, like I said, it takes two parameters instead of one. Since the dev intended to use the one-parameter PVADD, this means that the command causes a byte of note data to be skipped every time it's used. See those $D3 values in the above examples? Those are nMaxPSG1 notes. There's also one instance where the command skips an nRst note rest. This would have completely broken the song, but, bizarrely, the dev seems to have just worked around the issue by padding-out the song data with more notes: if you restore the skipped notes, then the entire channel becomes desynchronised. This is the case even with the version from the November prototype. Buggy command usage like this is actually pretty common: for example, the sound effect for sliding in Oil Ocean uses an FM volume command on a PSG channel. In Sonic 2's driver, this actually works fine, but in S1 and S3K's drivers, it causes the sound to glitch. Likewise, a very similar bug is the reason Wing Fortress's music has a really loud instrument in the Simon Wai prototype.
Oh, wow. That's pretty interesting. I suspect a very similar bug must have affected Sonic 3D's Green Grove Zone, Act 2 music:
Basically an obscure bug with the melody getting quieter and vanishing completely that occurs if someone leaves the song running in the sound test for a long time or leaves the game unpaused on Green Grove Zone Act 2 for a long period of time.
The bug seems to be a problem with the FM2 channel: Code (ASM): Snd_GreenGZ2_FM2: smpsPan panCenter, $00 smpsSetvoice $07 smpsModSet $07, $01, $03, $05 smpsFMAlterVol $FC smpsAlterPitch $0C Snd_GreenGZ2_Loop05: dc.b nC4, $06, nRst, nG3, nBb3, nRst, nG3, nRst, nC4, nRst, nG3, nRst dc.b nBb3, nBb3, $0C, nG3 smpsLoop $00, $03, Snd_GreenGZ2_Loop05 dc.b nC4, $06, nRst, nG3, nBb3, nRst, nG3, nRst, nC4, nRst, nG3, nRst dc.b nG3, nG3, nRst, nG3, nRst smpsFMAlterVol $04 smpsAlterPitch $F4 smpsCall Snd_GreenGZ2_Call05 smpsCall Snd_GreenGZ2_Call06 smpsCall Snd_GreenGZ2_Call07 Snd_GreenGZ2_Loop06: dc.b nRst, $60 smpsLoop $00, $10, Snd_GreenGZ2_Loop06 smpsCall Snd_GreenGZ2_Call06 smpsCall Snd_GreenGZ2_Call07 smpsCall Snd_GreenGZ2_Call05 smpsSetvoice $09 smpsFMAlterVol $02 smpsAlterPitch $0C dc.b nA5, $60, nG5, nF5, smpsNoAttack, nF5, nG5, nF5, nE5, smpsNoAttack, nE5, nA5 dc.b nG5, nF5, nFs5, nA5, nAb5, nG5 smpsFMAlterVol $FE smpsAlterPitch $F4 smpsSetvoice $04 smpsFMAlterVol $01 smpsModSet $07, $01, $03, $05 dc.b nG5, $06, nA5, nB5, nC6, nA5, nB5, nC6, nD6, nB5, nC6, nD6 dc.b nE6, nC6, nD6, nE6, nF6 smpsFMAlterVol $FF smpsCall Snd_GreenGZ2_Call07 smpsJump Snd_GreenGZ2_FM2 In particular, Snd_GreenGZ2_Call06 increases the volume by 1, but that's okay because Snd_GreenGZ2_Call07 always decreases the volume by 1 afterwards. The problem is that there's one place at the end where Snd_GreenGZ2_Call07 is called without Snd_GreenGZ2_Call06 being called before it, so every loop of the song 'leaks' a volume level.
Just out of curiosity, how does Sonic Jam handle audio in the included games? I remember hearing the game code is largely macro-translated to the Saturn architecture, but obviously the sound engine would require some special handling. Not to mention it sounds a lil bit different, particularly the sound effects.
It's been a while since I looked into it, but I'm pretty sure they just used recordings of the music and SFX. Notice how when you get Speed Sneakers, the song restarts instead of seamlessly speeding up, and there's a big pause whenever a new song starts, almost like the Mega CD seeking to a new CD song?
Ah, that's of course the obvious telltale sign, but I missed it while checking out a longplay. Sorta disappointing, but the path of least resistance I suppose. Thanks for the writeup, by the way, I dig the info.
It depends on what counts as 'the Sonic engine', I suppose. I once disassembled parts of Quackshot, and noticed it used a very similar object system to the Sonic games (it had an earlier version of the Sprite Status Table - specifically, the 'routine' variable was an index instead of an offset). Also like Sonic, it used SMPS as well as the level chunk system (I can't remember if it was 256x256 or 128x128). I think these games may have just been using a standard game engine that Sega of Japan (or maybe just Yuji Naka) created, which was intended to be used by multiple games. I don't think Ristar or Quackshot is based on Sonic specifically, but I think the three are all based on the same generic game engine. Much like how S1 and Ristar's drivers are based on SMPS 68k, but they aren't based on each other.
