On top of allowing multiple states to be used (thus theoretically allowing multiple Mega Drives to be emulated at once), this also makes for incredibly efficient rewind support. This is essentially 'proto-C++' object-oriented C. I intend to eventually leverage this to create a libretro core.Īnother major feature of the emulator's code is that it avoids global state: all of the emulator's subsystems access their state through a struct pointer which is passed as a parameter to every function. The core contains all of the emulation logic, while the frontend contains all of the platform-dependent code for reading input and presenting the video and audio to the user. Additionally, being written in strict C89 means that the emulator can be built with vintage compilers for ancient platforms (16-bit DOS port, anyone?).Īnother novel feature is that the emulator is separated into two components: the core and the frontend. These projects will only work on certain platforms, while my emulator should theoretically run on any platform that you can compile C for, so long as the RAM requirements are met. What's the difference? Well, many other C projects make mistakes like using fixed-size integer types such as 'uint32_t' for no reason whatsoever (they aren't even guaranteed by the C standard to exist, breaking compatibility with platforms where they don't), treating 'int' like it's always a 32-bit type (breaking compatibility with platforms where 'int' isn't 32-bit), and using logic that only works on little-endian architectures (breaking compatibility with platforms with big-endian CPUs). You might be thinking 'Hey, that's not unique at all!', but here's the thing: my emulator is written in portable C89. No, that's gross and bad and you should be ashamed of yourself for suggesting it.Unlike some other Mega Drive emulators, this one has been created entirely from scratch: no MAME or Gens code here! In fact, I think that the codebase is what makes this emulator unique: it's written in. I figured that writing an emulator would be a good way to put that knowledge to the test. That's almost 10 years ago! I know practically everything there is to know about how games use the Mega Drive hardware, which means that I know everything that would have to be done in order to run those games on other platforms. I've been programming for the Mega Drive since late 2012. For example, did you know that Sonic 3's Data Select menu uses Plane B for the foreground and Plane A for the background, rather than the other way around like it usually is? Why
I figure that they'll come in handy for ROM-hack development, or even just finding out how a game works internally. If you want to see exactly which features are and aren't currently emulated, there's a list here.Īs you can see, the emulator comes with some debugging utilities. Other games just don't boot, like Combat Cars and Micro Machines. Basically, games that do run in the emulator may be missing certain effects. The basic hardware of the Mega Drive is emulated, but not to completion: things like the YM2612's SSG-EG and LFO are missing, as well as support for the VDP's Window Plane and the 68k's instruction cycle durations. Sonic 3 is a little glitchy at the moment. I haven't done a whole lot of testing with this, but it does appear to work with Sonic 1, 2, 3, & Knuckles, Puyo Puyo, and ROM-hacks like Sonic 2 Recreation. clownmdemu! You'll never guess what the name's short for! :D
Waiting for it to be 'ready' is a fool's errand. It's not even close to being complete, but when will it ever be? So I figure that I might as well release it now, because there will always be some feature left to be implemented, or some game that doesn't work right. Since September last year, I've been working on-and-off on a Mega Drive emulator.