In a previous blog, we showed how our Sim68020 simulator can provide simulation and emulation capabilities for the Motorola 68020 microprocessor, using emulation of a Microsoft Flight Simulator test rig as an example.
While nowadays, specialist processors tend to be used in safety-critical avionics, this wasn’t always the case. As well as being used in aircraft like the Eurofighter Typhoon, the Motorola 68K processor family found its way into a variety of devices such as PCs, printers and games consoles such as the SEGA Mega Drive (known as the SEGA Genesis in North America).
Here at Rapita, we love a bit of retro gaming, so we couldn’t resist the temptation to test the Sim68020 out on some of the classics.
First, we wanted to see if we could run the original Sonic the Hedgehog by SEGA. The purpose of the simulator is to be able to run original compiled binary executables without modification, so there's no reason this wouldn't be possible.

The first step was to extract the program data from an original game cartridge using a USB ROM dumper. Now all we had to do was pass the file to the simulator, and the game was running! One slight problem came up, though… we couldn’t see any output!

To create an image on a CRT television, the Mega Drive sends instructions via memory mapped IO to its Video Display Processor (VDP) which generates the analogue video signal to send to a television. This is an ideal use case for the Sim68020’s plugin system – we can intercept those commands and emulate the behavior of the VDP to display an image on the host PC.

This is the first screen the plugin drew - there are clearly some issues, but we could see the SEGA logo, demonstrating that the game code in the background was indeed working.
After fixing a few issues with interpreting the data and some endianness problems it started to produce some more recognizable output.

Finally, after some more debugging all the sprite and background layers were working.

Whilst it’s nice to be able to run the code and see the graphical output, it would be much better if we could play the game! It turned out not to be too difficult to set this up – once again memory mapped IO is used internally to interface with the controllers, so we can extend the plugin to read keystrokes from Windows and pass the data to the simulator, and voila, it becomes fully playable!
This was a good test of Sim68020’s instruction set handling as the code for Sonic the Hedgehog was written directly in Assembly and hand-optimized for performance, utilizing unusual instructions where necessary. What if you wanted to see exactly which instructions have been executed? Sim68020 can generate a branch trace, which allows it to be used with RapiCover Zero, so we can generate an object code coverage report for Sonic the Hedgehog!

This is great but I’m sure the question on everyone’s lips is: “can it run DOOM?”
Yes! As it happens, this was even easier as the game was open sourced by the developers so we could simply recompile it for the 68020. DOOM uses a simple frame buffer rather than a dedicated graphics processor, so we could make use of the shared memory plugin that comes with the simulator to render the output to screen.

A real 68020 microprocessor would not be fast enough to run the game at an acceptable framerate, but another advantage of the simulator is that it can be made to run much faster than the real hardware, reducing the time it takes to run functional tests.
It was a lot of fun getting the Sim68020 to let us play Sonic and DOOM, and it was a good demonstrator of the flexibility of the simulator. Interested in simulation for the 68020 or another legacy processor? Get in touch.