I'm something of an OutRun obsessive. I've got the arcade machine in my parent's garage (they keep requesting that I remove it) and I coded the OutRun driver for Jemu2. The game has so many memories attached to it, and it will always hold a lofty place in my heart beyond what it probably deserves.
One coding project that I've dabbled with on rainy days, is a full decompilation and reverse engineering of the original arcade ROMs. This is a massive undertaking, and one that I suspect I will never truly complete. But it is intriguing to pull apart the game I loved so much as a kid, to find out exactly how it works.
The ultimate goals of this project are:
1/ Reimplement OutRun in portable C, so that it can be compiled to pretty much any modern handheld/computer. And the code can be easily extended/modified.
2/ Create a level editor for the game. Potentially for the original arcade version and the version created in step 1.
Realistically, it will probably just be a bit of fun. If you can call pouring through thousands of lines of unlabelled, uncommented, decompiled 68000 assembler fun that is.
So far, my steps have been as follows:
1/ Wrote a program to de-interleave the arcade ROMs and spit them back out. I've then decompiled them to text files.
2/ Made some notes on the OutRun hardware via reference to the Mame source code.
3/ Begun commenting the decompiled assembler, using the Mame debugger for assistance.
Progress is promising. I started by figuring out all the routines for the text layer of the hardware. As the name suggests, this is essentially a layer of 8x8 tiles that is used to print things like "INSERT COIN" to the screen, and some other static graphics like the HUD elements.
It's been quick to rattle through the code and comment exactly when and where the graphics are blitted. So I quickly have an understanding of the general code structure, from the service tests through to high score tables and even the OutRun easter egg, which prints Yu Suzuki's name.
I've also figured out a lot of other important information, including the memory address used to store the games internal state (e.g. attract mode / music selection / high score entry / in-game / clock countdown / map screen), which makes identifying roughly what individual areas of code are performing far simpler.
There's a lot more I've managed to achieve, although this is a project whereby progress is slow until you reach a tipping point. The most similar project I've worked on previously was converting Speedball 2 to J2ME phones. But as this was an official port, I had access to nicely commented and labelled 68000 assembler - much easier.
In other news, I haven't forgotten about FlashGear, just put it on hold for the time being, until I get the motivation to polish it up for a release.