Sonic Megamix Tech Tease

(Best seen full-screen, high quality. No sound; read below for info)

Intro

Hello, again!

Now that I’ve been promoting my Patreon, I’ve gotten asked several times about Megamix. I don’t usually post about it, but in the spirit of trying to get used to the concept of keeping patrons relatively updated, I thought I’d give this a shot. Don’t get terribly used to it, though; I certainly won’t be spoiling new things on a daily basis or anything, even if the campaign does pick up and allow me to work on this regularly :P

The video isn’t super-high quality because I just wanted to do a quickie update, and recording this setup in that manner was actually pretty difficult. Don’t worry that you’ve gone deaf or that your speakers have blown; I intentionally excluded sound from the video since it wasn’t important in this case, and there was too much ambience and other stuff going on

Testing Via USB Transfer

The first thing you may notice in the video is that I’m using a Mega Everdrive, which I had bought a while ago with some of my “Cool Official Sonic Dude Money”. This is important because it’s actually part of what’s happening in the video, even though it’s a cartridge and I’m running a game being developed for CD

The Mega Everdrive has a USB port that can be used by developers, and has primarily been used for transferring built ROM images for running via some officially-released software. In this case, I’ve created a Genesis-side client program and PC-side server program that allow me to run Sonic Megamix over USB instead of having to constantly burn CDs for testing, which makes the process much faster and cheaper, and thus, hardware testing isn’t as much of a pain. This is very good because there are a few fatal errors that can occur on hardware that aren’t reproduced in emulators, one of the biggest being “Address Error”. This is when you attempt WORD or DWORD access at an odd address, because the Genesis’ Motorola 68000 processor requires data and code to be WORD-aligned (anything larger than a BYTE must always start at an even address). It’s very easy to make this mistake, and it can also end up happening just due to bad code/bad data, so it can come up frequently in a project like this

First, my custom client program is sent to the Genesis via the officially-released ROM image transfer program, and is received by the Mega Everdrive OS, which is constantly listening for this sort of transfer. Once the client program is running, it waits for user input to send requests to the server. At this point, on PC side, the server program is run to listen for client requests. It doesn’t do anything until the request is actually made. Once the client and server are both running, pressing C on the Genesis controller causes the client program to send the first request to the server, which causes the initialization program to be transferred from PC to the Genesis and SegaCD hardware, which in turn sends further requests for the other game files that need to be called from the PC server

The PC-side files are specially built separate from the files meant to be burned onto CD because using this method causes the Genesis to run in “mode 1”, cartridge boot with CD access, which causes memory to be mapped to different locations than with “mode 0”, booting from CD. This is accomplished with equates for address offsetting, though, so it uses the same source files as the CD version and is very simple to move to and from. Otherwise, the programs and their operation on the hardware are exactly the same as if I were to burn them to CD and run them that way

The camera is panned back and forth between the television with Genesis output and my PC to show the server updating its status during transfer and the on-screen results

Megamix Content Update

Next, you’ll see that I enter the new Sunny Shores Zone and play around with it a bit. This is the newest level first shown in the previous update video, “Never Cancelled”, but that video is very tease-y in that it only shows split-seconds of some of the new features. This time, you get a better look at part of Sunny Shores Act 1 and some of its brand-new enemies

Mini-Debugger

Once I’m done playing around in Sunny Shores, you’ll notice that there’s sort of a “crash screen”. What’s happened here is that I’ve pushed the user break buttons to manually enter a mini in-game debugger that I created to help with fixing hardware problems. This debugger is meant to appear any time an “exception” occurs (such as the previously-described “Address Error), and displays the contents of the CPU registers at the time of crash, as well as providing a movable memory window that by default shows the current contents of the stack. Using this information makes it possible to find out where and why the exception (effectively, the "crash”) occurred so that the error can be fixed

Engine Rebuild

After I power-down the hardware while the debugger is being displayed, I power back on and initiate the client/server process again, this time from a different folder location with different files. You’ll notice that what appears on-screen is significantly less-developed than what I showed earlier. This is because I’ve begun a teardown and rebuild of the engine to improve performance and allow us to do some more complicated stuff

This new build is actually set up to run game logic from the SegaCD’s “SubCPU”, which runs at 12Mhz, as opposed to the Genesis’ “MainCPU”, which runs at 7Mhz. That’s a gain of almost twice the processing speed even without other considerations, and there are a few

Firstly, what you see here is very primitive because the entire engine is being rebuilt piece-by-piece. The first thing I took care of was level layout display, followed by parallax scrolling, basic sprite display, basic Sonic player implementation, object position loading with sprite display, and ring position loading with sprite display

The key thing here is that the SubCPU is entirely isolated from the Genesis hardware; it can only directly access SegaCD hardware. For this reason, I had to create a system of communicating output from the SubCPU SegaCD side to the MainCPU Genesis side for processing, and input from the MainCPU Genesis side to the SubCPU SegaCD side for handling in the logic code. It took me a while, and it’s not perfect, but you can see that data manipulated and generated by the SubCPU is being displayed on-screen, having been passed to the MainCPU and processed by the MainCPU I/O processing code. This is vaguely similar to how the SubCPU was used to process special SegaCD commands in the original version, except that a ton more data needs to be managed, and this actually allows for more true parallelism; whereas the SubCPU would only work when it was called for a specific task by the MainCPU in the old version, the new version can run game logic code on the SubCPU while the MainCPU is still processing I/O. This also results in a slight speedup because I/O can now be processed at the same time as game logic, and therefore not reduce the amount of process time that can be dedicated to it

Sonic CD was written in the same way as the original version of Megamix - Its main level gameplay ran primarily on the slower MainCPU and used the SubCPU for the occasional SegaCD hardware task. This is probably due to the fact that it took less time and effort to convert the Sonic the Hedgehog (1) source for SegaCD in this manner than if they had to break it down more, balance storage, create an I/O communication system, and make several other changes. Other SegaCD ports of Genesis games were done in this manner too, and I don’t currently know of any officially-released SegaCD game that actually does run primarily on the SubCPU throughout all parts of the game (For clarity, the then-newly-created Sonic CD Special Stage did run primarily from the SubCPU, and unfortunately, it was still very slow due to the amount of live-rendered graphic data that had to be constantly transferred from the SegaCD to the Genesis, even when using DMA)

There are some other changes in the new Megamix build as well. Given that a lot of memory had to be rearranged and sorted between the MainCPU and SubCPU sides, what were once hard addresses have been converted to named data declarations. This is also important in that some data formats had to change, and thus their storage size would also change. One large factor, though, is that the original game liked to use optimized code where SystemRAM addresses greater than or equal to $FFFF8000 were stored as WORDs and not DWORDs, cutting their storage requirement in half. With the vast majority of all RAM data having been moved from the Genesis SystemRAM (accessible only to MainCPU) to WORDRAM (flip-flop between MainCPU and SubCPU but no simultaneous access) and ProgramRAM (accessible only to the SubCPU), this caused the data to be stored in entirely different address regions that couldn’t take advantage of the nature of signed value storage to concatenate address references. For this reason, storage for address pointers had to be doubled, data referencing addresses had to be corrected, and code using such data had to be modified to replace special addressing tricks that could no longer be used

Other general enhancements are in progress as well, such as the conversion of the object processing routine to function more like Sonic 3 than Sonics 1 and 2. The difference is that in 1 and 2, data for an active object stores its type as a 1-byte ID number, and every time it’s called, its code address has to be found in a lookup table using the ID number, and its current state is handled by another 1-byte “routine” value that’s used as an index into a jump table to run the appropriate part of the object’s code. This is fine, but Sonic 3 changed this format in that, now, “object type” is no longer an ID value but a DWORD pointer to the code that makes up the object, so no more using a look-up table for every object on every frame. This also means that the code location can be changed, so you could have it point directly to any particular routine for the object rather than using a “routine” index with a jump table. This is overall faster, and also makes it possible to list only placed object types in a lookup table, omitting objects that are only spawned during gameplay since they can be referenced directly by the code. An unfortunate side-effect, though, is that it increases the storage requirement for a single active object entry, so not only is more memory being used, but several parts of the engine have to be changed to accommodate the new entry size. Changing variable offset values to equates along the way is helpful in keeping up when the order of variables in an entry has to be changed, though

As for the red and yellow sparkles that follow Sonic around this time, those are markers that I added to display “hotspot” positions. These are the positions at which Sonic is actively testing for collision with the level; very helpful in figuring out why something appears to be wrong with the path physics

I’m hoping for this version to supercede the original, but currently there are still a lot of basic things missing from the engine, there are some bugs, the objects that are in aren’t implemented in there entirety, and there’s a whole lot of game that I have to go over and convert to get everything we currently have working with this new system

In this case, there’s also a slight problem with my mini-debugger. It works fine with the MainCPU, and therefore, with the old version of Megamix, but it only rarely catches SubCPU exceptions, which means that it’s useless for a lot of problems with the new version. This probably has something to do with having to catch them on the SubCPU and communicate them to the MainCPU before having it launch the debugger, but so far I haven’t seen any errors in the code, exception vector settings, or communication. It’s strange; I’ll need some more time to look at it extremely closely if I’m to fix it

Patreon and Releases

So, yeah, you might have noticed that in my side-project disclosure, I listed Megamix. As of this writing, I currently have only three patrons, and all of them are Sonic fans, so, here’s the deal-

If I receive a few more patrons, I will personally and to the best of my ability create a bugfix version of “Sonic 1 Megamix” and release it ASAP (could take at least a month or two given the current state of the code)

Now, you might be wondering why I put quotation marks on the name. Well, what we have in development now are actually two distinct games - “Sonic 1 Megamix”, the game you know as represented by release “4.0b”, and “Sonic Megamix”, the game with a greater amount of new content that you’ve mostly only seen in videos. The reasoning behind this is that we used to call the game “Sonic 1 Megamix”, but “recently”, when we started getting more hardcore with content changes, it was starting to resemble Sonic 1 less and less, so we wanted to move away from that aspect. Thus, we removed the “1” and it became “Sonic Megamix”. However, there will be such distinction between the two that I decided to have them both, with “Sonic 1 Megamix” returning as bonus content within “Sonic Megamix”

What I’m offering now is an elaboration of what you know as “4.0b”, which was released “unstable”. I intend to fix bugs, apply tweaks, and if possible without overextending development, maybe add a little extra value in some way. This would be a stand-alone release as “Sonic 1 Megamix”, and would contain none of the content intended for “Sonic Megamix” (such as the newer graphics, the newer layouts, the new enemies and bosses, the CD soundtrack, new gameplay elements…). I know that’s disappointing, but it’s going to take much longer to make that content suitable for end-users, and it will also involve more people than just me. In the mean-time, I know that people enjoyed what I now (again) call “Sonic 1 Megamix” and were disappointed by the state in which it was released at “v4.0b”, so, I will remedy the situation by personally creating a (hopefully) much better release version. Long-term, “Sonic 1 Megamix” will still become a bonus for “Sonic Megamix”, as well as probably gaining a few reasons to go back to it again

Closing

I hope you guys have enjoyed this! I’ll try to do more if I can find sufficient reason, but this kind of presentation ends up being work in and of itself :P