(This is a cross-post of one of my blog posts, where I go over the technical background of the various SMPS drivers used by the Sonic series. I figure this info is relevant enough to belong here rather than left hidden on some random blog.) The majority of the ‘classic’ Sonic games use the same generic sound driver, dubbed ‘SMPS‘ by the ROM-hacking community (and ‘Sound-Source’ by ex Mega Drive musicians). These games include… Sonic the Hedgehog Sonic the Hedgehog 2 Sonic the Hedgehog CD Sonic the Hedgehog 3 Sonic & Knuckles Chaotix Sonic 3D: Flickies' Island Even some of the more loosely-related games like Flicky and Sonic the Hedgehog’s Gameworld use SMPS. However, these weren’t copy-and-paste jobs: it’s not like these games all used the exact same sound driver unmodified from 1991 through to 1996. Oh no, the majority used heavily modified versions of SMPS, each specifically suited to its respective game. SMPS But what is SMPS? Well, it was Sega of Japan’s custom in-house sound driver. It was neat, and let you do a bunch of fancy stuff with the hardware. It evolved over the lifespan of the Mega Drive, and, according to ValleyBell, even existed before the Mega Drive, with a primitive version of it being found in old Sega arcade games (particularly Space Harrier). SMPS even made its way to other platforms, such as the Sega Mega CD (utilising its 8-channel PCM sound chip), the Sega 32X (using its PWM sound channels), the Sega Master System, and the Sega Pico. To make things even more confusing, two distinct versions of SMPS existed: one for each of the Mega Drive’s CPUs. You see, the Mega Drive features a Motorola 68000 as its main CPU, and a Zilog Z80 as a sound co-processor. Running a sound driver on either CPU has its upsides and downsides, and so, to allow their developers the ability to choose whatever works for them best, Sega maintained two entirely separate versions of SMPS. These versions are commonly known as ‘SMPS 68k’ and ‘SMPS Z80’. Sonic the Hedgehog Let’s start at the beginning: Sonic 1 used a pretty bog-standard version of SMPS 68k, known as Type 1b. Essentially, it was the second minor revision (b) of the second major revision (1) of the driver. Modifications to this particular driver include the removal of unneeded features such as ‘panning animation’, and the addition of custom features such as the ability to play the famous “Se-ga” sound. We know from the game’s prototype that many of these modifications were made late into the game’s development. The curious thing about this game’s sound driver is that it’s SMPS 68k, and not SMPS Z80. As I said, each version had its strengths and weaknesses, and Sonic 1 doesn’t make use of SMPS 68k’s strengths at all. If anything, SMPS 68k was a burden: using up 0x5C0 bytes of RAM and costing precious 68k cycles. ValleyBell (an expert in all things SMPS) claims that a likely reason for this is that no version of SMPS Z80 existed at the time that could play drums using the Mega Drive's DAC sound channel. Games using such a version of SMPS Z80 only started appearing after the release of Sonic 1, suggesting this theory is correct. Speaking of the DAC channel, one of this driver’s cuter modifications is that its DAC driver was compressed. Many other games simply leave it uncompressed on the cartridge when there’s no good reason to. This modification saves a considerable amount of cartridge space, especially considering that the DAC driver contains most of the game’s DAC samples (DPCM data is massive). Sonic the Hedgehog 2 Now this is where things get interesting. Sonic 2’s sound driver is by far my favourite, namely for its sheer insanity. You’d probably expect that, as its direct sequel, Sonic 2 reuses Sonic 1’s sound driver albeit maybe with some extra modifications, and, well, that’s kind of the case. You see, Sonic 2’s sound driver runs on the Z80. Did the devs finally get their hands on that brand new version of SMPS Z80 that they supposedly wanted to use in the last game? No, no they did not. Instead… they converted Sonic 1’s driver to run on the Z80. They rewrote the entire driver in another assembly language. Not only that, but in the process they fixed countless bugs and created a driver that was considerably leaner, cleaner, and lighter than even SMPS Z80 itself. In addition, they modified the driver to support compressed music data – a feature I’ve only seen in one other SMPS game (that being Mega Man: The Wily Wars). They were able to do this, despite the decompressed music data taking up a considerable amount of the Z80’s limited 0x2000 bytes of RAM, because this converted driver was just so efficient that there was plenty of Z80 RAM to spare. Safe to say, even to this day, I am beyond impressed with this driver. This was not an automated thing, mind you: this port was done 100% by hand, and whoever did it was nitpicking every little design choice in the original driver and implementing them even better in theirs. The only downside to this sound driver is just how specialised it is: like Sonic 1’s driver, features that were unused were removed. This includes the “Special SFX” system previously used by Green Hill Zone’s waterfalls. SMPS 68k already lags behind SMPS Z80 in terms of features, and with even more features being torn out during the development of both Sonic 1 and 2, I do unfortunately consider Sonic 2’s driver something of an ‘SMPS-lite’. Sonic the Hedgehog CD This game’s unique because it uses two different versions of SMPS: SMPS PCM for music, and SMPS Z80 for sound effects. SMPS PCM is the Mega CD port of SMPS. It’s based on SMPS 68k because the Mega CD only has a 68000 CPU. In lieu of the Mega Drive’s FM, PSG, and DAC sound hardware, SMPS PCM makes use of the Mega CD’s 8-channel PCM chip. This driver is used to play the music of the game’s past levels. The PCM chip was not ideal for playing the game’s SFX on, so another sound driver is used to play SFX on the Mega Drive’s sound hardware. For this, the developers chose SMPS Z80 Type 1 FM (‘FM’ referring to its inability to use DAC drums, instead opting for FM versions). In keeping with tradition, this driver was heavily modified. The largest modifications were to work around a problem specific to Mega CD games: without a cartridge, there was nowhere for the Z80’s data to go… except for RAM. The devs needed to fit, not only the driver (both its variables and code), but also all of the game’s SFX in the Z80’s measly 0x2000 bytes of RAM. To address this, they once again began removing features that weren’t needed. In particular, they removed the driver’s ability to play music. As this driver was meant for nothing more than playing SFX anyway, this was fine. But still, it’s a rather major modification to make. Also, since they realised SFX would no longer be competing with music for access to the console’s sound hardware, they extended the SFX from being able to use only 3 of the console’s FM channels to having access to all 6. The final modification they made is perhaps the most controversial: in order to save even more RAM, the devs also removed the driver’s ability to use the console’s PSG sound hardware. This limited all of the game’s SFX to FM only. As many of Sonic CD’s SFX are recycled from Sonic 1, this meant some PSG-specific sounds had to be converted to FM. One such SFX was the jump sound, which has gone on to create something of a rift in the fanbase, with some preferring it to the original, and others hating it. The ironic thing is that this modification wasn’t even necessary: in 2018 I made a ROM-hack of Sonic CD that replaced its driver with the one from Sonic & Knuckles, without needing to remove its support for PSG SFX: The comment section of this video will be quick to tell me the FM versions of the SFX were better anyway. [Update: Apparently the devs actually removed PSG support because the official Mega CD developer manuals claimed that the Z80 could not use the PSG while the console was in CD mode. Personally, I haven't seen any proof of this actually being the case, as my aforementioned ROM-hack works just fine on real hardware. Thanks to MarkeyJester for this information.] Sonic the Hedgehog 3, Sonic & Knuckles, and Sonic 3D: Flickies' Island These three games all use the same driver, aside from some differing DAC samples and the occasional bug. At this point, I suppose Sonic Team finally got their hands on a suitable version of SMPS Z80 (particularly Type 2 DAC), and replaced their ageing SMPS 68k Type 1b-based setup with it. A shame, really: Sonic 2’s driver really was cool. Curiously, Sonic 3D Blast’s ROM contains a little developer message: Sound Driver for Sonic Series Coded by Y.Kashima & M.Sets. Sun Sep 1 1996 17:02 It’s interesting that they describe this as ‘Sound Driver for Sonic Series’, suggesting that this was intended to be the driver used by all future Sonic games for the console. Having some developer credits is nice too. Once again, this driver was heavily modified, though not quite as much as earlier games. If anything, I’d put it roughly on par with Sonic 1’s driver: some unused features were removed (often poorly, resulting in a bunch of leftovers), a couple of series-staple features were added (such as the ring SFX alternating between the left and right speakers), and a few unique features were implemented (namely the Universal FM Voice Bank and Continuous SFX system), but overall it’s nothing too fancy. If anything, I think what this driver is most noteworthy for is just how buggy and poorly-made it is. A large part of this blame rests on SMPS Z80 itself: being the ‘original’ version of SMPS (SMPS 68k started off as a 68k port of SMPS Z80), this driver’s codebase is ancient, and has accumulated numerous poor design decisions. The code in general is hideous and bloated, doing completely unnecessary things such as… Using self-modifying code to store a variable for later retrieval… literally in the next instruction Calling a whole subroutine just to decrement a value using three instructions when one would have worked fine Using an offset table to another offset table Countless bugs have also accumulated from the many overhauls, upgrades, and downgrades the driver had undergone in its life. Frankly, to go from Sonic 2’s driver to this is just depressing. This driver is also so bloated that it genuinely has trouble fitting in the Z80’s RAM. Remember how Sonic 2’s driver was so lean that it had enough spare RAM to fit a music decompression buffer? The only real upside to this driver is how many features it has, despite removing a bunch to fit itself in RAM (such as the SFX priority system, pitch-sliding, and the music’s ability to use the sixth FM channel). Chaotix Apparently I’m not the only one who thought the previous driver sucked, because Chaotix starts over from scratch with a brand new one. Using a clean copy of SMPS Z80 Type 2 DAC as a base, a brave developer known as ‘Milpo’ set about righting some of the wrongs of the previous driver. It’s still a little rubbish because it’s SMPS Z80, but I've gotta give credit where it’s due. What’s notable about this driver is that it started off as a regular Mega Drive sound driver, but it was extended to support the 32X during Chaotix’s development. To my knowledge, this driver is not related to the ‘official’ SMPS 32X driver seen in other games such as Metal Head, as that driver is based on SMPS 68k instead of SMPS Z80. Specifically, this driver gained support for an extra four percussion tracks, using four PWM channels on the 32X. As four percussion tracks was pretty overkill, support for the driver’s original percussion track (that being the DAC channel) was removed. Another special thing about this driver is that it apparently has a name, according to a little developer comment hidden in its code: casablanca version by MILPO [Update: 'Casablanca' actually appears to be the codename for Chaotix, as it apparently appears in the credits sequence of the game's prototypes. Thanks to Black Squirrel for this info.] Unfortunately, of the drivers I’ve covered here, this is the one I have by far the least experience with, so there’s not much more I can say about it. I suppose one last bit of trivia I can give is that this driver’s DAC capabilities were enhanced despite them eventually being removed: namely, the “Sonic Crackers” prototype featured automatic bank-switching. Closing SMPS is fun. Many times, devs seemed to just leave it unmodified, but when they did modify it, oh boy the things they would do with it. Honestly, I think modern programmers could learn a thing or two from SMPS – it wasn’t a general-purpose software library that was limited to the features it came with by default and you were expected to treat like a black-box: if you wanted a special feature, you could add it yourself. SMPS was simply designed to be played with, being distributed to developers in source code form. It reminds me of the dwm window manager, which, rather than rely on configuration files, requires its users to modify its source code to change its behaviour. Some developers took this to heart, and maintained their own forks of SMPS, such as the SMPS Treasure variant. All that rambling aside, the details of Sonic’s history with SMPS don’t seem to be very well documented, so hopefully this post has changed that.