(Last edited 5/15/2023; changes in bold.) This is partially an info/research dump, partly a request for help/advice/suggestions, and hopefully something that sparks some discussion. For some months now I’ve ruminated on the idea of a Mode 1 port of Sonic CD, long enough to have assembled a “spec list” of sorts for possible features and additions and a GitHub repository where I've written down some ideas. Only recently though have I started to take a more serious look at this idea, namely by exploring Devon’s partial disassembly, combing through his dumped MMD data to figure out just how much there is. and even writing some code to work out how to do things. Ultimately, whether or not this is possible depends on a couple of factors, not the least of which is the amount of non-program-code data in the game excluding FMVs and CDDA audio. First of all, I should share the the spec list: Gameplay-wise, the port should be identical to and indistinguishable from the original Mode 2 version in its default settings. Various bugs from the original would be preserved, all fixable with a conditional assembly switch. All of the unused leftovers from Sonic 1 and the betas would be removed to save space. The disassembly will emulate the styling of Hivebrain’s disassembly (mainly because that’s the style I’m most comfortable with). CDDA audio and FMV data are, out of necessity, still loaded from disc, but everything else, including all executable code, is loaded from cartridge. Consolidate all sub-CPU code (but not data) into a single "ROM" that is uploaded to the Mega CD PRG-RAM during init (and possibly compressed, more on this later). Rework the Z80 sound driver to read the bytecode from ROM instead of Z80 RAM, add PSG support, and add PSG versions of the jump and skid sounds. The player will have the option to choose whether to use the FM or PSG versions of those sounds, with FM as the default. Recompress all Kosinski-compressed data with the MDComp implementation to reduce their size. Compress any uncompressed data that can be compressed, such as the 256x256 mappings. Nemesis compression will be eliminated altogether in favor of Kosinski. Consolidate the different SMPS-PCM drivers into one (but the music PCM samples are too large to fit in PRG-RAM all at once, more on that later). Build system should generate a bin+cue folder with the CDDA audio of the appropriate soundtrack and the FMV data files for use with emulators, as well as a burnable ISO image of same. Said disc should also include a Mode 2 stub that prints a message explaining that the disc is meant to be used with the Sonic CD Mode 1 ROM. If space allows, add CDDA slots for past music, allowing the use of such tracks as the Church of Kondo remasters or King Meteor’s US past concepts. If space allows, upgrade to a full Z80 driver such as a modification of Flamewing’s clone driver (which decompresses Kosinski-compressed bytecode from ROM), and add FM/PSG versions of all music as an option. This would allow three different music modes: FM/PSG+PCM, CDDA+PCM, and all CDDA, with the second as the default option. This could even be extended to allow the game to run in a reduced-functionality mode if no disc is provided: restricted to PCM and FM/PSG music and no FMVs, but everything else is fully functional. The game should be able to use both its own CD, as well as copies of the Mode 2 original (though I believe this would complicate things by requiring two file lists). During init, the sub-CPU should check the drive and determine if there is a disc present, and if so, what disc is inserted. If it is the dedicated disc generated by the build system, FMVs and all music modes are available. If a copy of Sonic CD Mode 2 is detected, FMVs will play, but CDDA past music will be unavailable. If a non-Sonic disc or an audio CD is inserted, CDDA audio will be available, but FMVs will be disabled. If no disc is detected, the game will still be playable, but music will be limited to FM/PSG+PCM, and FMVs will of course be unavailable. Game will have both cartridge SRAM and Mega CD BURAM support, including saving and loading to both, and transferring saves between the two. Save files should be identical to and fully compatible with the Mode 2 version, with saves generated by one readable by the other. The Mega CD Backup Cart is, of course, not supported. If space allows, add some accessibility features, including but not limited to, disabling Time Overs and allowing mistakes to not cost the ability to time travel. A lofty set of goals, including a couple of far-fetched ones. However, from what I have gathered thus far, I’m convinced that it should be possible. I’ve already concluded that compressing everything using MDComp Kosinski would be the best option, given its high compression ratio. I spent nearly a week going through Devon’s dumped data, finding and eliminating all duplicates, decompressed all of the Nemesis and Kosinski files, and recompressing everything with MDComp Kosinski to get an estimate of the amount of data. The end result: all graphics, chunk and block maps, stamps and stamp maps, and PCM samples, Kosinski compressed, plus the uncompressed frames of Sonic’s level and special stage sprites, work out to around 2.96 megabytes). Pushing it, but not unworkable. That said, there are a few other challenges that will need to be overcome. I’ve solved a few of them on my own, but others I want suggestions on, and in all cases, feedback is warmly welcomed. The game’s HUGE chunk mappings. 70 different sets of 256x256 tiles, ranging from 53 to 62 KB in size uncompressed, with no two exactly alike (unique for every zone, act, and time period). They do compress down nicely to around 20 KB in size each with Kosinski, and with the Mega CD providing a free 256 KB RAM expansion, there’s no problem finding a place to decompress them. However, even compressed they take up a lot of space ($115940 bytes, a little over 1.1 MB), so it would be quite helpful if their size could be reduced. Obviously we can’t reduce the tables down to 28 (one for each zone and time period), since some of the levels have different backgrounds, but I suspect a few of them could be consolidated, perhaps even more so if they were converted to a 128x128-based system. EDIT: at AlexField's suggestion, tried MarkeyJester's Twizzler compression, and it gets the chunks even smaller than Kosinski, down to $10259B bytes, freeing up $133A5 bytes for code and other data. That seems like the way to go, so converting to 128x128 might not be neccessary in the long run. EDIT 2: converting the game to 128x128 is not possible at all, since several of the levels end up exceeding the 255 chunk limit when I tried using LevelConverter. Getting rid of Nemesis compression in favor of Kosinski. Overall, recompressing all Nemesis-compressed graphics as Kosinski takes up less space overall, even if it is less effective for some files. However, that means we would need a completely different system for loading graphics. I am admittedly not familiar with the KosM system used in S3K, but Hivebrain’s Sonic1Squared has a PLC system based on standard Kosinski that might do the trick. EDIT: it would need to be modified somewhat, as it is only meant for loading graphics at the start of a level, and Sonic CD has a section art system that loads swaps in additional art mid level by loading PLCs when the camera x-pos crosses certain boundaries. SMPS-PCM and the samples for the past tracks. The original game has separate drivers for each level, differing only in the addition/removal of a couple SFX and changing out the music bytecode and their samples. The SFX samples and their bytecode, along with all music bytecode and sample metadata, could be put together in one driver, but the music samples themselves are far too large to fit in the program RAM (nearly 690 KB total). The best solution I can think of is reworking the SMPS-PCM to use seperate sample banks for SFX and music, with the latter being switchable: there would be an area of PRG ram reserved for music samples, and the driver keeps track of which set of samples are loaded (the ID of the music track would also be used as an index to the bytecode and sample metadata). When the driver is commanded to play a song, it checks if the required bank is already loaded, and if not, a bankswitch is performed as follows: the sample RAM is cleared, the sub CPU signals it needs new samples and gives word RAM to main CPU, the main CPU decompresses them from ROM to word RAM and returns the word RAM, the sub CPU copies them from there to the program RAM. (Some sample code for handling this, plus a redesigned CDDA play handler, can be found here.) Overhauling the command system. Mode 1 will of course eliminate most of the sub-CPU commands for loading files from disc, but let’s face it, the communication protocol the game uses is painfully basic. It seems the developers didn’t even consider the possibility of passing additional arguments with commands, something that would, for instance, allow pruning all the CDDA play commands down to just one (see the above link). I definitely want to revise the handling of commands with this in mind, but I am open to ideas for completely overhauling the protocol. An exception handler for the sub CPU. There are a couple of excellent error handlers for the Mega Drive, but I don’t think I’ve seen any attempt to make the same for the Mega CD sub CPU. The BIOS provides jump table entries for most of the error exceptions and the user traps that can be set during user program init. After studying VladikComper’s error handler, I think I have an idea of how it could be extended to handle sub CPU exceptions, although it would require building the entire handler from source rather than using a pre-assembled bundle. I do want to know if anyone else has examined something in this regard or has any suggestions. The game will need a Sega screen to be added, as the original did not have one (the security module effectively replacing it). I don't consider porting the Sega chant to be feasible given the size of its DAC sample, so why not just extract the assets from the security module and the code from the BIOS ROM that runs it, and make it into a Sega screen? The game's object position lists and object IDs. Each level has its own unique list of objects and object IDs, and these would need to be merged together into a single unified list. The game essentially uses Sonic 1's format, with the addition of a byte containing time zone information. However, this format is limited to a total of 126 unique objects due to the use of bit 7 of the ID byte to indicate whether the object gets a respawn entry or not. I won't be able to get a count on the total number of objects until I can go through all the level MMDs and examine their lists, but said total, including title screen and DA garden objects (special stage objects run on the sub CPU), is 254 or less, then a custom format based on Sonic 2's (essentially adding the time zone byte to Sonic 2's format) would work. Otherwise, we could use Sonic 3K's system, or even just use a full word for the object ID (as long as all OST offsets are in the form of named symbols, then this shouldn't pose a problem). Additionally, the title screen and time warp have non-standard methods of running objects and finding free OST slots; these would be converted to use the same slot finders and object executors as the levels. I’ll probably add more here as I remember them. For the moment though, I do welcome ideas and suggestions if anyone has them. As a final note, I have to say I’m convinced by the untapped potential of Mode 1; CDDA audio and affine transformations are one thing, but I genuinely wonder what things could be done with a free 256 KB RAM expansion.