Thursday, August 27, 2009

Decompilation Update

As predicted, progress is slow and steady.

The most satisfying way of working is attempting to solve as many unknowns in a particular area, and then moving on when the going gets tough. Going back to a set of routines with a fresh pair of eyes really helps.

Some areas that I've worked on:

1/ Car control (X Position, Acceleration, Gear Changes)
2/ Road splitting code (High level areas including the 'road splitting state')
3/ Elements relating to the current track segment
4/ Sprite rendering code (Very complex, so moved on temporarily from there)

I've successfully understood various memory locations, and slowly routines become understandable from the meaningless muddle they originally were.

Tuesday, August 11, 2009

Outrun Decompilation Oddities

The decompilation is moving along reasonably nicely. I've slowly picking up a decent understanding of the game code.

One interesting thing with the decompilation is that it uncovers code routines and text that don't appear to be in the final game.

For example, check the strings in the following screenshot:


BIN CHAN E
COLOR BANK GA TARINA NOYO !
1 STAGE 127 KO INAINI SHITENE

If you set the program counter to 0x7644 (by typing pc=0x7644) in the mame debugger, and resume execution you will see for yourself.

Any idea if this string is used, or whether it means anything interesting?

UPDATED: Thanks to bluepillnation who points me towards the following link relating to Space Harrier.

Firstly, the text can be translated roughly as follows:

To BIN CHAN
Color bank is lacking.
Make it less than 127 for one stage. 


Bin Chan is a developer who worked on OutRun, Space Harrier and Afterburner. He is listed as BIN in the hi-score table.

It's suggested that this is some kind of protection. "Sega use the MCU to copy tilebank values on most of the system16 games, maybe they use it to copy a colour bank value on space harrier too, but it's not obvious until you get to that stage".

Monday, August 10, 2009

OutRun Decompilation Project

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.