Reassembler - Emulation & Decompilation

Gateway's Broken Arches

2012-01-31T21:57:00.002Z

Have you noticed that Gateway's arches are randomly broken in the original OutRun? At times arches don't join, sometimes they float in the air and occasionally complete pillars are missing.

It's not very noticeable at high speed, and the precise nature of the breakage isn't consistent. Overall though, it spoils the illusion of what would otherwise be a cool level.

For my rewrite, there's a simple solution to this problem; but not for the original game sadly. OutRun's software engine can display 76 scenery sprites at any one time, which are initialized dynamically as the level progresses. Further sprites are reserved for traffic and other essential objects.

Each Gateway arch comprises 4 sprites (two pillars and two joining sections). So we can display 19 complete arches at any one time. Therefore, on complex stretches of road where no free slots can be allocated, some of the pillar components are simply skipped.

Thankfully, we don't have memory or speed restrictions on a modern PC and can allocate additional slots to dynamically spawn sprites. In fact, it's as easy as changing a single number. And here's a screenshot to (somewhat) prove it.

The illusion when moving through the level is greatly improved, and when I eventually increase the frame rate beyond the original 30fps, this level will be awesome!

OutRun C++ Engine Tech Demo

2012-01-29T17:21:00.002Z

Finally, after years of hard labour, here's a technical demo of the OutRun C++ port. The demo showcases recent work porting the core level rendering engine. The benefit of rewriting the engine, is that it will facilitate modifications and enhancements to the original game that Yu Suzuki only dreamed of.

Now, let's get arty and check out some stills from the demo. I've implemented the ability to change the horizon y coordinate, so we can experience viewpoints never seen in the original game. How about a bird's eye view of the start line?

We can also straddle left and right, so it's possible to find further interesting camera angles. Although this one reveals that our surf-boarding friend isn't actually in the water! Messing with the original engine can highlight its limitations of course. This demo allows you to scroll further left and right than the original engine, which can cause glitches.

It's fun to be able to browse the scenery in detail:

Here's a beach-side postcard scene for you:

And finally a view down the final straight of Coconut Beach before the road fork. Alas, the road fork code hasn't been ported yet, so this is the road to nowhere at the moment.

The keys for the demo are:

Space: Toggle automatic movement through level
Cursor Up: Advance slowly
Cursor Left/Right: Move camera left/right
A/Z: Adjust horizon
Escape: Quit

Requirements:

OutRun Revision B ROMs. They must be named correctly and placed in the roms subdirectory. No other set will work. Although you can use the patched set from OutRun Enhanced Edition. I would recommend running the demo from the console to see any error messages.
Microsoft Visual C++ runtime libraries.

Other Notes:

Having control over the rendering engine surfaces glitches and limitations present in the original code. Using unpatched roms, the sprite zoom bug mentioned in this post is evident. You can use patched roms to eliminate this.
There is a bug where a random shadow pops into view dependent on the camera x coordinate. This is present in MAME as well, but is hard to reproduce when you're actually racing through the level. I need to get this verified on hardware to help track down a solution and determine whether it's a video emulation issue or a bug in the original codebase.

Download here: outrun_tech_demo1.zip

Let me know what you think by leaving a comment below.

OutRun Sprite Zoom Bug

2012-01-16T23:54:00.003Z

OutRun uses a lookup table to set the horizontal and vertical zoom values of sprites based on their z co-ordinate.

Unfortunately, one of the vertical zoom entries in this table is incorrect. If you drive as slowly as possibly by gently tapping the accelerator, there is a single position where sprites snap to an erroneous vertical zoom value. This causes the sprite to clip incorrectly and jolt to a different offset.

You can see an example of this behaviour in the animation below. Note the third palm tree from the left suddenly snaps and zooms to an incorrect position.

Unbelievably, this applies to all sprites in the game. Although it's only noticeable when driving at low speeds. However, once spotted it's hard to ignore.

I've updated OutRun: Enhanced Edition with a patch for the bug.

In other news, expect an early tech demo of my C++ port very shortly. It was in coding the port that I spotted this bug.

OutRun Conversion Update

2011-11-23T22:32:00.001Z

I haven't written about the OutRun conversion to C++ for some time. That's because I put it on hold whilst I focused on the anniversary edition, amongst other projects. Having a break was sensible and necessary, as it's such intense work.

Compared with other 68k conversions I've worked on professionally, this is much tougher, due to the sheer complexity and in some cases poor quality of the original code. Even after a first draft, a huge amount of refactoring will be needed so that the codebase can be extended.

Things are slowly coming together. Don't hold your breath whilst waiting for this; I'm doing it at a very steady pace. I've taken a screenshot of my desktop, which shows that much of the level data is now being parsed. Underlying this, many of the sprite rendering routines are ported. I've included a MAME screenshot for comparison so you can see what's currently missing.

OutRun Original Japanese Version

2011-11-13T20:28:00.001Z

Japanese only static sit-down cabinet design with roof

Interior shot from a more beat-up cabinet. Note the unique bezel design

Following my comparison of Rev A and Rev B of the OutRun ROMs, I've turned my attention to the original Japanese release of the ROMs. There are a number of differences and bug fixes which are detailed below.

1. There is no backup RAM. Therefore, the code doesn't contain the routines to handle backup RAM found in later revisions. For example, the code to calculate backup RAM checksums.

2. The mini upright and standard upright cabinets are not supported. The revision only includes motor code for the deluxe sitdown. As a result, Dip switch bank B functions differently. Dip switch #1 toggles the motor hardware. Dip switch #2 toggles advertise sound. MAME currently emulates this dip switch incorrectly, assuming it to be the same as later revisions.

3. The default scores are different. For example, in the original version YU has 1,000,000 points. In later revisions this became 5,000,000.

4. The code to initialise default scores is called from a different routine.

5. The music selection screen is set to a 15 second timeout, rather than 30. SELECT MUSIC BY STEERING text is omitted.

6. The code to set the y position of the backdrop tilemap is different (e.g. the position of the cloud backdrop on coconut beach). In the original version, the tilemap immediately snaps to the horizon y coordinate. In later revisions, the tilemap will smoothly scroll to a new position.

7. Traffic logic changes. The code that determines when to flag other cars on the road as being near the player's Ferrari is different. This will presumably cause different behaviour when approaching packs of traffic. I'm unsure why the code has been changed or what situation the coders were trying to mitigate.

8. The code to set the speed of other cars when bunched in traffic has been changed. In later revisions, the speed is capped but in the original version a higher speed can be obtained by the traffic. This is noticeable at the start of the game. In later revisions the truck on the right hand side initially speeds off, but then the other cars catch up and bunch together around it. In the original, the truck accelerates away and the other cars never catch it. Without observing the presumably rare bug the coders were attempting to fix, it's tough to say why this change was made.

9. Later versions of the game contain an optimization to not add sprites that are off screen to the display list. This version does not contain this optimization.

10. As most players know, the stages are in a different order and there are layout differences in places in the original version. As such, certain routines differ to compensate for this when setting up stage palettes and sprite effects when driving offroad.

11. In later revisions, a safety counter was added to bonus mode in the main game's switch. (Bonus mode is the section of the game that increments your bonus score after completing stage 5.) This ensures that bonus mode exits eventually and presumably fixes a rare hang that can take place in this version.

12. This version does not attempt to terminate the crash animation sequence when entering bonus mode.

13. There are minor changes to ensure the y placement of some sprite objects (including those on the intro sequence and some in completion screens) more accurately reflect the y position of the blitted road layer.

Minor Updates & Translation Request

2011-10-16T22:16:00.000+01:00

Thanks to jap-sai.com, I've managed to acquire a number of OutRun related goodies in the past few months. I've updated the VHS and laserdisc page with some screenshots and a link to a downloadable copy of the gameplay DVD.

I'm also looking for someone to assist in translating a number of Japanese texts, most importantly Yu Suzuki's Gameworks book. If you can help, please comment below. I'm willing to pay to have a decent translation done.

Update: Translation now in progress.

OutRun Rev A vs. Rev B

2011-09-24T17:25:00.004+01:00

I've looked into the code changes between the revision A and revision B roms. Comparing the roms isn't easy, because the addresses of the routines are aligned differently rendering a binary compare impractical. Therefore, my technique was to align a rough decompilation of the Rev A code to the addresses of the Rev B code in IDA.

I manually compared the code. It was easy to see if a function had changed in size for example as subsequent functions would be shifted to different addresses. Clearly, this is prone to human error and I may have missed something. But, if I have, it should be minor.

The differences are:

Easter Egg activation is more complex in Revision B. I have blogged about this already here.
The steering wheel vibration code for the Upright Mini cabinet has been altered. In Revision B, the vibration frequency has changed to make it less aggressive. I would guess this must was done in response to hardware problems reported by operators. The code can be found at address 0xEBA2 in Rev A and 0xEC42 in Rev B.

And that would appear to be it! Maybe not a huge surprise, given that I've not noticed any other differences playing the versions. I hope to compare the original version next, which may yield more interesting surprises.

As a final note, only IC118 and IC133 change between the revisions. The sub CPU code is identical.

OutRun Philko Bootleg

2011-09-12T21:16:00.005+01:00

I studied the 68k code for the OutRun Philko bootleg. This is identifiable by the copyright message reading BETA as opposed to SEGA, as shown in the screenshot below.

Although the hardware is different to the original Sega boardset (see MAME source code for details), it turns out that the game code is identical to the standard Rev B edition. The only changes are in fact the copyright message, the patched rom checksum and the encoding detailed below.

Bizarrely, Philko felt compelled to perform some crude encryption on their code by bitswapping it. As documented in the MAME source code, for the main CPU bits 11,12 and 6,7 should be swapped. For the sub CPU bits 14,15 and 2,3 should be swapped.

Here's a picture of the boardset, kindly provided by Luke Wells. If anyone has a higher quality snap, please feel free to send it over.

So this means a couple of things to bootleg board owners: I can potentially provide a version of OutRun Enhanced Edition if there's demand. Or owners can patch with a bitswapped Sega revision B romset, if they dislike the BETA copyright message.

Some questions of my own:

What was the intended cabinet for the Philko game?
Why identify the boardset as a bootleg by changing the copyright message?

Turbo OutRun Boardset

2011-09-10T16:23:00.001+01:00

I picked up a Turbo OutRun boardset this week. Unlike OutRun, Sega decided to mount the board in a protective cage. The cage has its own internal wiring as shown below.

The board was in very good condition, it didn't look the cage had ever been opened. The original serial (or selial) stickers were intact:

The board is still fitted with its original FD1094 suicide processor. I'm shocked that some of these are still working 22 years on! The white sticker on the processor reads: SEGA 317-0106.

Here's a closeup of the connections, for my own reference:

And here we have it running on the wiring harness made by RetroClinic. I took the board out of the cage to plug it in.

Space Harrier: Enduro Racer Edition

2011-09-06T22:55:00.002+01:00

This is a customized version of Space Harrier, modified to run on Enduro Racer hardware.

This means that the game is fully playable on the Enduro boardset without the programmed security i8751 CPU.

Normally, if you try to run Space Harrier on Enduro Racer hardware, the game controls will not function and therefore the game is unusable.

I'd like to thank Mark at retroclinic.com for performing the hardware testing. Without him, this wouldn't have been possible as I don't own either boardset. Please note that currently this requires Enduro Racer hardware with the earlier YM2203 sound board.

Download here: sharrier_enduro_v101.zip (18K)

Version 1.0.1: JunoMan from Sega Resurrection suggested a more elegant solution. Results should be the same. Thanks!
Version 1.0.0: Initial Release

Please note that no portions of the original game code are included in this package.

OutRun Enhanced Edition

2011-08-11T16:51:00.001+01:00

OutRun Enhanced Edition is an updated version of OutRun, Sega's seminal arcade racer. It is intended to be programmed to EPROMs and used with the original arcade hardware.

Enhancements:

High score saving using existing RAM (no hardware modification required)
Improved freeplay mode with attract; press start to begin
Music is played during the music selection (radio dial) screen
Dipswitch-selectable "MPH" / "km/h" speed display

Bug Fixes to Sega's original release:

Spurious sound in attract mode
Misplaced tile on music select screen (above steering wheel)
Mixed up ROM ID numbers on Memory Test diagnostic screen
Incorrect sprite zoom lookup table

Compatibility, programming and installation instructions can be found in the documentation.

I'd like to thank Darren Finck for jointly working with me on this project and for providing hardware testing. We have released the enhanced edition to celebrate OutRun's 25th anniversary in September.

Download here: outrun_enhanced_v102.zip (22K)

Online documentation here.

Please note that no portions of the original game code are included in this package.

Version 1.0.2: Fixed sprite zoom lookup table. This is a bug in the original game code.

Version 1.0.1:BUGFIX: The in-game music would continually play throughout attract mode if you failed to achieve a highscore.

Now the in-game music is stopped at game over.

This issue was present in the original game, but the music would eventually stop during attract mode when the Best Outrunners screen displayed. It could arguably be considered a bug in the original game too.

Please note, that if you achieve a high score, Last Wave is correctly played into attract mode as per the original game.

Note that if you are upgrading from the previous version (1.0.0), you only need to program IC 118 and IC 133.

Version 1.0.0: Initial Release.

OutRun Controller Project

2011-07-24T18:21:00.003+01:00

The aim of this project was to have a fully playable OutRun PCB in my lounge, without the overhead of the original controls or cabinet. As an extra requirement, I wanted to be able to swap the original control panel in if desired without any complex rewiring.

The original hardware consists of three analog controls: the accelerator, brake and steering. A perfect replacement pad appeared to be the Dreamcast controller. It contains two analog triggers, which we can map to acceleration and braking plus an analog thumbstick for the steering.

Unfortunately, the original Dreamcast pad uses hall effect sensors for the analog controls and would be unsuitable. Thankfully, many of the third party controllers aren't made to the same standard and instead use cheaper potentiometers, just like the original arcade hardware! In addition to this, there are plenty of digital buttons we can map to things like the gear change and the start button.

I plumped for a Madcatz Dreamcast pad. It's a nasty piece of work, but suitable for rewiring. I cut the original cable off, bypassing the pad's logic circuits and soldered wires directly onto the necessary components. One problem is that many of the components are connected via the pad circuity in a way that makes them unusable. For example, the buttons share a ground connection and the pots are also connected. You'll want to use a continuity tester and cut the PCB tracks between the components.

Thanks to some forum assistance, I found out that the connectors on the OutRun wiring harness are 'Amp Mate N Lok' which can be bought from Swallow Amusements. Using these connectors, I was able to create a wiring harness that would plug straight into the original OutRun wiring loom. It's possible to create your own plugs without buying an official (and expensive) crimping tool. You can simply add solder to the wire, press it into the crimping pin and hope it makes a firm connection. When it does, crush the crimping pin around the wire with some pliers. It might take some time to get it right, but you can still achieve decent results.

One other thing to note is that the OutRun 50P controller connector requires 5v to be sent to pins A24 and A25 or your controls won't work. An odd design decision on behalf of Sega it would seem. The pinouts for the ports can be found below:

AMP 50P

Pin A1 Coin Sw #2 Pin B1 Coin Sw Ground
Pin A2 Coin Sw #1 Pin B2
Pin A3 Pin B3
Pin A4 Shift Switch Pin B4 Shift Switch Ground
Pin A5 Start Sw Pin B5 Start Sw Ground
Pin A6 Service Sw Pin B6 Service & Test Ground
Pin A7 Test Sw Pin B7
Pin A8 Pin B8
Pin A9 Pin B9
Pin A10 Pin B10
Pin A11 Pin B11
Pin A12 Pin B12
Pin A13 Pin B13
Pin A14 Pin B14 Ground
Pin A15 Pin B15 Ground
Pin A16 Pin B16
Pin A17 Pin B17 +5V
Pin A18 Pin B18
Pin A19 Pin B19
Pin A20 Pin B20
Pin A21 Start Lamp Pin B21 Start Lamp Ground
Pin A22 Pin B22
Pin A23 Pin B23
Pin A24 +5V Pin B24
Pin A25 +5V Pin B25

AMP 20P

Pin A1 Accel Pot Pin B1 Steering Pot
Pin A2 Accel Pot Wiper Pin B2 Steering Pot Wiper
Pin A3 Accel Pot Pin B3 Steering Pot
Pin A4 Pin B4 Brake Pot
Pin A5 Pin B5 Brake Pot Wiper
Pin A6 Pin B6 Brake Pot
Pin A7 Pin B7
Pin A8 Pin B8
Pin A9 Pin B9
Pin A10 Pin B10

Here's a video of the final setup in action!

Road Layer and Slave CPU Code Converted

2010-12-05T22:04:00.000Z

The entire code for the slave 68k CPU has been ported. This CPU solely controls road generation and interfacing with the road hardware. It's probably the most complex area of the game code. As expected, debugging the code was relatively painful. The code now needs a considerable clean-up, but I'll do that once more of the game code is hooked up, to ensure it's more obvious if I break something whilst refactoring.

The following screenshot shows a section of curved track using both road layers on Coconut Beach. You can begin to see that all the elements are coming together and we're now in a position where we have the building blocks to rewrite the higher level code.

Translation Update & Driving Cabinet

2010-11-24T15:07:00.001Z

Currently going gang busters on the slave CPU road code. It's big, it's ugly, but it's unfortunately necessary to translate a large chunk to C++ before I can proceed with more visible aspects of the game code. The level generation is highly dependent on it. Even after translation, I expected to spend a couple of weeks doing a line by line debug - Visual Studio vs. Mame Debugger. Let battle commence.

Meanwhile, Garnet Hertz provided an update back in October, with regard to their real life OutRun driving cabinet.

Check out a recent video here:

Sprite Support Implemented

2010-11-16T00:33:00.000Z

A big step forward; I now have full sprite support in my framework.

Furthermore, I have ported all the low-level OutRun routines from 68k to C++ that abstract the sprite hardware from the general game code. This was a considerable effort and required some serious debugging.

You can think of the dependencies as follows:

High-Level OutRun Game Code (68k) -> Low-Level OutRun Sprite Routines (68k) -> Video Hardware.

I'm at the stage where the second two components in this sequence are done. The ported routines control some of the following areas:

Initializing and caching sprite palette data in RAM
Ordering sprites based on priority
Converting the programmer friendly format used by OutRun game objects to the format required by hardware
Setting horizontal and vertical zoom settings from a lookup table
Setting the height and width from a lookup table in relation to the above
Setting the sprite anchor point
Setting rendering hints based on horizontal flip bits etc.

Here's a slightly dull screenshot, which shows the OutRun logo being rendered. Well most of it, the observant among you will notice I didn't hook up the bird sprites as it was getting late:

It doesn't look like much, but the important thing is I can initialize a sprite simply by setting a few jump table properties using fully ported code. Here's an example of the code required to initialize a sprite object, where 'e' is a jump table entry:

e->jump_index = 0;

e->x = 0;

e->y = 0x70;

e->road_priority = 0xFF;

e->priority = 0x1FA;

e->zoom = 0x7F;

e->pal_src = 0x99;

e->draw_props = 0;

e->control = 0;

e->shadow = 3;

e->addr = ADDRESS_OF_SPRITE_DATA;

map_palette(e);

do_spr_order_shadows(e);

So progress is good. Once I get to the stage where there is something more interesting, I'll release a demo build.

OutRun Papercraft Model

2010-11-11T11:13:00.000Z

Picked up the September 2004 issue of Dorimaga magazine. It includes Sega History Papercraft Vol 4, which is a constructable model of the hydraulic sitdown OutRun Cabinet. How cool is that?

Support for Tile Layers Implemented

2010-11-06T13:05:00.001Z

The hardware tile layer is now supported in my framework. So in addition to the text layer previously mentioned, the ported code can now utilize tiles.

Here's a screenshot to provide an example of this, using ported code to display the tiles from the music selection screen:

Much of the detail from the music select screen is missing, because it also makes use of sprites, which are currently unsupported by the framework.

To summarize the components of the port, the following 68k code has been ported to C++ in order to reach the above stage:

Routines to setup palette ram
A new text routine to blit text with a height of two tiles to the text layer (this displays the Select Music By Steering text string)
The routine which decompresses a tile map from rom and outputs it to tile ram
The routine to update tile hardware on a vertical interrupt

And the framework itself emulates the following:

Tile Layers
Text Layers
Palette Hardware

So we're getting to a stage where basic routines are coming along nicely. The final ported C++ code is more readable and far more concise than the original assembler.

The OutRun Rewrite Begins

2010-11-02T23:39:00.000Z

I've made a start on the rewrite. Here's a quick summary of what I've been up to aside from brushing up on my C++ skills. Firstly I've installed and configured a suitable build environment, which consists of:

- Visual Studio 2010 Express C++
- DirectX SDK
- SDL (for rendering)

From there I've written code to:

- Read the tile and data roms into memory.
- Ported emulation code to emulate the text layer and convert the pixel format.
- Rewritten three 68k assembler routines decompiled from the OutRun source code.

The end result is that I can now use a fully ported C++ routine that blits text, in the form of tiles, to the screen. This routine takes the precise same input format as the original code. In the following screenshot, I've called the routine to display various text strings from the game. A simple call to blit_text(address_of_text_data) renders the text with the correct palette and screen positioning. Exactly the same as the original assembler.

The structure of the text data (which contains palette info, tile info and screen positioning) is pulled straight from ROM. Although I imagine I will eventually extract such data structures so that they are completely native.

I appreciate that drawing some text isn't particularly riveting, but the first steps in a project are always the most laborious. I'm pretty happy with the way things are going.

GOAL

2010-10-12T23:24:00.000+01:00

Decompilation is complete: 13 months later, over 400 subroutines, ~20,000 of lines of commented assembler (a rough estimate) and countless late nights.

Pretty much everything is done to a standard I'm satisfied with. But it's important to also consider what has been omitted:

Sitdown Motor Code. I have only decompiled a small portion of this, as it's not particularly useful for the rewrite. It's also hard to verify without a simulation of the hardware. Having said that, I've decompiled and commented the motor code for both the upright hardware variants. This could be adapted to a simple rumble controller easily.
Z80 Sound Code. Currently, this isn't needed. The master 68000 CPU triggers the sound samples and sets sample volumes for the engine pitch. Therefore, it's straightforward to work out what is going on without resorting to lower levels. I may decompile this at a later stage out of curiosity.
Complex Algorithms. There are a minor number of routines which, although commented and broadly understood, could be better explained by someone with a better knowledge of Maths/Physics than myself. In many cases it's obvious that a routine is performing a square root or similar. But there are certain routines that I might have not fully grasped. Nevertheless, I am confident I have done enough to convert these to meaningful C routines that aren't gibberish.
I'm sure I'll find and fix mistakes in my comments as I convert the game.

The upcoming enormous challenge is to rewrite the game engine in comprehensible C++. I will be releasing the rewritten source code as I work, so that those interested can follow my progress. I initially expect visible results to be slow, so please be patient. If there are any questions, please post in the comments and I'll happily answer anything sensible.

Binary Translation, Emulation and Decompilation

2010-09-30T15:10:00.002+01:00

Here's a link to an interesting article outlining the choice between binary translation and emulation. It might help convey why I'm taking a radical approach in porting OutRun and not automating binary translation. As mentioned, binary translation certainly has its uses in producing code that can be hand optimised and altered. However, it ultimately results in code that is also unwieldy and in hard to decipher.

Even in cases where the original source code is available and can be translated by a tool, the results are often no better. I've worked with C code, automatically translated from 68k assembler, for a number of games during my days as a mobile developer. Often the output from such tools didn't resemble the target programming language in a meaningful manner.

Although decompiling and manually rewriting OutRun is a massive task, hopefully the end results will yield code that is understandable, portable and easy to enhance. By the end of the year, I will have completed the decompilation phase and commented an estimated tens of the thousands of lines of assembler. Maybe the end results will be superior to the original source code in areas. It's hard to say, as I don't have access to it!

One of the more gruelling aspects of the decompilation is the sheer amount of code. For example, I'm currently commenting code that controls the animation relating to smoke, dirt and other debris emitted from the Ferrari's wheels. The animation format and code to handle these routines differs yet again from all previous examples. I've lost count of how many animation formats the game contains.

One of the reasons the code is so bulky is that the programmers have seemingly reinvented the wheel for various aspects of the game. It wouldn't be difficult to code a generalised animation system, at the expense of a small amount of speed. As it is, many high-level features share little in terms of code or design despite relying on the same low-level routines. This results in a lot of code duplication.

OutRun Unused Lap Time Code

2010-09-08T23:54:00.002+01:00

There is a fair amount of unused code compiled into the OutRun ROMs. Much of it consists of redundant helper functions, that serve no interesting purpose.

I came across an unused routine today that's slightly more interesting. Firstly, OutRun stores the 'lap-time' of each stage you've completed - even though this information isn't really made use of (other than showing your previous lap-time on passing the checkpoint).

Either for debug purposes or as an unfinished feature the programmers included a routine to sequentially print these times during gameplay below the HUD.

Entering the following command in the mame debugger will print the lap-time for a particular stage you've already completed in a race.

d0 = x; pc = 7fea; g; [where x is the stage time to print]

Here's an example screen grab:

Here, I'm on Stage 3 and I've printed the lap-times for the previous two stages using the unused code routine. The lack of apostrophes in the additional lap print outs indicate that this idea was probably pulled at an early stage.

Code decompilation is progressing nicely. I'm on track to finish this year.

Animation Format

2010-08-23T20:58:00.000+01:00

I've disassembled the code relating to the animation sequences displayed after you complete a route. There are five animation sequences dependent on the route you've taken. I'd hoped that the animation format would be similar to the code to handle the animation sequences during collision, for example the Ferrari rolling over. Unfortunately it was completely different.

If you're using the same revision of the ROMs as myself, you can trigger the sequences instantly in the MAME debugger with the following command:

w@60be8 = x; pc = 9978; g [where x is the end sequence number 0-4]

Animation frames are stored in groups of 8 bytes, and formatted as follows:

+00 [Byte] Sprite Colour Palette
+01 [Byte] Bit 7: Make X Position Negative
           Bits 4-6: Sprite To Sprite Priority
           Bits 0-3: Top Bits Of Sprite Data Address
+02 [Word] Sprite Data Address
+04 [Byte] Sprite X Position
+05 [Byte] Sprite Y Position
+06 [Byte] Sprite To Road Priority
+07 [Byte] Bit 7: Set To Load Next Block Of Sprite Animation Data To 0x1E
           Bit 6: Set For H-Flip
           Bit 4:
           Bits 0-3: Animation Frame Delay (Before Incrementing To Next Block Of 8 Bytes)

Each sprite (or object if you like) is assigned an address containing the animation sequence data. The animation terminates when bit 7 of byte 7 of a chunk is set. Two other animations use the same format at the start of the game - the map waving the start flag, and the Ferrari driving in from the side of the screen.

Object Logic

2010-07-17T11:52:00.000+01:00

The sun has been out, I changed jobs plus I'm getting married in a couple of months. These factors have conspired against me getting as much done lately.

Having said that, I've finished decompiling and understanding the routines that handle both the logic of in-game objects and their rendering behaviour. In plain English, the scenery that makes up the levels. There are 15 routines in total with a lot of code duplication between them. The level object structure contains a field that denotes which routine should be used.

One example is the checkpoint sign at the end of a stage. Each sign consists of two objects; the pillar of the sign and the header which reads "CHECK". Each part of the sign is drawn by a separate routine. The top of the checkpoint sign is drawn by a routine that also determines when the user has past the sign (to handle further game logic like loading the next stage). Whereas the base is handled by a similar routine that doesn't make this check. Additionally, there are two checkpoint signs at the end of each level and only one of them handles the check. Therefore, it cannot be assumed that because an object looks the same, it will always be handled by the same routine.

There is further complexity in these routines. Let's take the water strip sprites, seen on the left hand side of Coconut Beach (Stage 1) as an example. Each strip is processed by a custom routine that examines its screen z value. If the z value is particularly close to the screen, the sprite is simply zoomed. However, at distances stretching into the horizon the frame is completely changed as well as zooming being applied. There are alternate versions of this routine that swap frames based on the y value of the sprite. This variant is only used on one of the Stage 5 levels.

The palette changing logic for the countdown lights at the start of the game is also embedded as part of this logic. Some routines handle collision checking where necessary too. It's worth noting that I had to play all 15 levels just to understand where the routines were used. Simply looking at the code to figure out what was going on was impossible at times.

Moving on, I'm going to work sequentially through the rest of the decompiled program code. I'm at a stage now where a significant amount of work is complete so there are just gaps to fill in.

Attract Mode Logic

2010-06-14T23:35:00.002+01:00

The crash code is now complete, and it was more complex than I'd anticipated.

On the other hand, the logic to automatically control the player's car during Attract Mode is a lot simpler. The code can be quite basic, because the traffic in OutRun intelligently attempts to move out of your way. A simple detail most home conversions didn't pick up upon.

Here's a simplified pseudo-code conversion if you're interested:

AttractModeAI()
{
  // Check upcoming road segment for straight/curve.
  // Choose route from pre defined table at road split.
  AICheckRoad(); 
 
  // Set steering value based on upcoming road segment                  
  AISetSteering();  
  
  // If speed is below a certain amount, just accelerate
  if (car_speed < 0xFA)
  {
    accelerator = MAX_VALUE;
    return;
  }
  
  // If AI Traffic is close, set brake on
  if (traffic_close)
  {
    traffic_close = false;
    brake = 0xC0;
  }
  
  // If either wheel of the car is off-road
  else if (wheels_offroad)
  {
    brake = 0xC0;
  }
  
  // Upcoming road: Straight Road
  if (road_type == STRAIGHT)
  {
    curve_counter = 0;
  }
  
  // Upcoming road: Curved Road
  else
  {
    if (++curve_counter == 1)
    {
      // Set road curve value based on hard coded road data. 
      // High value = Sharper Bend
      road_curve_value = value - 1;
    }
    // toggle brake on bends. 
    // The brake flickers on/off in OutRun attract mode
    else if (road_curve_value != 0 && ((road_curve_value <= 0xA) 
            || (road_curve_value & 8)))
    {
      brake = 0xA0;
      road_curve_value--;
      return;
    }   
  }
  
  accelerator = MAX_VALUE;
  return;
}

Collision

2010-06-03T00:37:00.002+01:00

I'm currently working on disassembling the OutRun collision and crash handling code.

Once you start looking into the code in detail, you realise what an adventurous coding exercise OutRun is. I mean, how many ways do you need to crash in one game? Evidentally quite a lot... I can't quite fathom the level of detail they went into with regard to the collision routines. It's not sloppy coding as such, just simply attention to detail on an excessive scale. Sega must have had a supply of strong caffeine in the 80s.

Check out the graph I produced in IDA below of one of the main crash routines. This isn't even all of the collision and crash code, it's simply one function which can be toggled by the master jump table!

On a positive note, all the code blocks covered by the above graph are now decompiled and commented. On a negative note, mainly for my sanity, there are still more. Argh!

There are two main types of crash in OutRun: hitting traffic and hitting scenery. Hitting scenery can be broken down into three new types of crash depending on the speed your travelling at. There's the low speed bump, where the car rises in the air (using the same movement lookup table as the birds flying on the logo in attract mode fact fans), the medium speed spin and the full speed flip. Each of these has multiple internal states to contend with and each crash factors in aspects like your speed, road curvature, height, whether there's a further crash resulting from the first crash and a selection of passenger animations. For example just the lower speed crashes offer a choice of the woman hitting the man, the man scratching head & girl tapping car, the man scratching head & girl pointing or man looking subdued and girl pointing.

Also, whilst the object format of the crash routines bears some similarity to previous bits of code I decompiled, actually most of it is new. Plus the animation sequencing format seems to be different, though I figured that out too.

PS I'm going to bed!

An Interview With Alan Laird

2010-05-18T00:12:00.012+01:00

Alan Laird worked on the Sinclair Spectrum and Amstrad CPC conversions of OutRun for Probe Software in 1988. Back in January 2000, I e-mailed him a series of questions about the conversion and he kindly took the time to answer.

I've answered your questions below, its been over 10 years so my memory is a little bit hazy in places.....

Firstly, how large was the team that worked on the Spectrum conversion, and how were the different tasks divided up?

Basically there were two people, Ian Morrison and myself. I've been out of touch with Ian for a number of years now so I don't know what he's doing.

Ian did most of the 3D engine code and I did everything else, but towards the end of the project I was pretty much the only person on the Spectrum version as Ian started working on the ST version.

We also did an Amstrad version based on the Spectrum code and John Bankier helped out with that.

How long did the conversion take?

Don't remember exactly. All I remember was that they wanted a Xmas release and the production house (Probe) got so paranoid about us running late that I ended up spending 2 weeks in their office in London. I think we got it done somewhere around early December after starting in the summer so about 4 or 5 months elapsed, this was whilst attending university, it was a rather stressful time.

Were you initially worried that the Spectrum would not be capable of replicating the original machine, and what were the main difficulties you encountered?

Yes, very worried, but it was too much of an opportunity to pass up. Clearly speed would be a difficulty, Outrun has a lot of graphics on screen so keeping the frame rate up whilst drawing those was difficult. Secondly because we didn't have fancy bitmap scaling hardware like the arcade machine, we had to store each graphic at a range of different sizes. There was a trade off between having enough sizes so that the game looked reasonably smooth and the storage space.

What hardware and software was used to convert the game?

It was developed on a PC based system called PDS that some other game developers had hacked together. This was a pretty decent Z80 assembler/debugger environment and at the time I think we used some flavour of 286 with initially a 10M hard drive. There was a dedicated comms board plugged into the Spectrum and an ISA card in the PC to form a kind of parallel interface between the two. You could squirt the entire assembled code down to the Spectrum in a fraction of a second. Much easier than the previous system using microdrives, multi-part assembles and the interface 1 network.

Were the graphics and sound written from scratch, or were some elements borrowed from the other conversions?

Outrun was really the third in an evolving series of driving games. First we did Nightmare Rally which was an original idea that Ian and I put together and then hawked around games houses before Ocean published it. Off the back of that we got a contract from Activision to convert Enduro Racer. This added the element of a track to the game. And off of that we got the Outrun contract from Probe. At each iteration the graphics engine become more sophisticated. Turbo and Europa were even better, they had much more flexibility in the 3D engine,infinitely variable curves and hills in the road and were getting decent frame rates as well. Sound code always came from third party specialists.

Nightmare Rally

OutRun

Turbo OutRun

Did you see or work on any of the other conversions, and if so, how do you think they compared?

As mentioned above I had a hand in the Amstrad version and Ian worked on the ST and Amiga versions. Amstrad was always difficult because it had the same processor as the Spectrum but twice as much video memory to move around. Amstrad users also hated getting Spectrum rewrites since they didn't take full advantage of the graphics flexibility. We didn't have much time on the Outrun conversion but Turbo and Europa were pretty decent. The ST and Amiga, although they were 16 bit 68000, still weren't terribly fast pieces of hardware and expectations were much higher so invariably they disappointed.

Amstrad CPC Conversion

How did you decide where to draw the line between graphical accuracy and speed? I ask this because the graphical accuracy on the game is outstanding, but one of the main criticisms at the time was that the speed suffered on certain stages.

There was a constant battle between me and the production house (Probe) over graphic density and speed. I wanted the game to look as realistic as possible and since I had full control over designing the course layouts I could put in lots of graphics to make it look good. Of course this brought the frame rate way down, I think it was averaging about 3fps in the end, but this game was never destined to be lightening fast.

A nerdy question: On the back of the OutRun packaging, the Spectrum screenshot is clearly different from the final game. The lorry is much larger and detailed, the sky is shaded differently, and the on-screen statistics are in different places. Why were these changes made, and does a copy of this early version still exist?

I think the graphic on the packaging was a mock up done by an artist so that it could get to the printers on time.

The large graphics were one of the first victims to storage space. We would generate a series of graphics at different scaling factors from full size down to almost nothing in steps of say 10%. What you find is that the largest graphics are only on screen for a fraction of a second as you zoom by something and they take up the most space, so naturally they got dropped pretty quickly. If we'd had the space they could have been left in since they are on screen for such a small amount of time they hardly affected speed.

The multi-loading system used on OutRun was rather complex, as it would load levels into memory as the game progressed, whilst holding as many as possible at one time. Was it developed specifically for OutRun?

Don't really remember too much about this aspect. I think the 48K version could hold about 4 levels at any one time including the most recently played level. So if you took the same route through the game each time you didn't need to reload but if you took a different route you would need to. Again it was down to the space needed by graphics, they just wouldn't all fit at the same time. We did +3 versions of the later games which made the whole thing a lot easier.

Did Turbo Outrun and / or Outrun Europa use the same engine as OutRun, or were they written from scratch?

As I mentioned, they were evolutions of the Outrun engine. By the last one the engine was actually getting quite good. Rendering speed was much faster both for the 3D landscape and the graphical objects. Not bad for such a primitive machine, remember that the Z80 didn't even have hardware multiply and divide operations so imagine how cumbersome doing 3D graphics was. We did everything in fixed precision arithmetic, 8 bit whole part, 8 bit fractional part and implemented multiply and divide using loops. For anything more complex like trig and log functions, we used pre-computed look up tables. Compare with today's Voodoo chipsets or a Dreamcast console, kids nowadays have it easy....

Can you briefly summarise the work that you have done since Spectrum programming?

I finished off my undergraduate degree (in Comp Sci) and then did a postgrad degree. After that I joined Baring Securities (of Nick Leeson fame) which later became ING Barings, working there for 5 years in London and mostly Tokyo. Now I'm with Merrill Lynch in Tokyo managing a development team doing real-time stock trading systems in C++. Ian set up his own games production house call ICE which did Turbo and Europa amongst others. Last I heard, which was about 6 or 7 years ago, he was headed to the States.

I lost interest in home computers for a long time and didn't really play games at all except for the odd arcade driving game until a couple of years ago when I got a couple of Voodoo cards for my work PC and discovered Quake. I've gotten right back into home computers now, although on a slightly different scale, with a network of Sun Sparcstations, a permanent internet connection and my own web sites. Its interesting to do a speed/memory/storage comparison of then and now. I started out with a 1K ZX81 and now I have 256M in my biggest machine, that's a quarter of a million times more memory amongst many other improvements. I still have all the old kit in my attic in London, maybe someday I'll dig it out and see if I can read those old microdrive catridges and floppy disks.

Hope this was interesting, it has been for me going back to those days and from all the interest on the web I see that the old games still live on. Thanks to everyone who's taken the time to collate information, build emulators and collect games.

Alan Laird - 2/1/2000.

Another article regarding the conversion can be found in the following issue of Sinclair User magazine from 1988:

OutRun Easter Egg - The Definite Guide!

2010-05-11T23:24:00.003+01:00

For a while it's been known that on some versions of OutRun holding the start button, just before a checkpoint, will reveal a secret message: "PROGRAM YU SUZUKI 1986 SEP".

However, it's also been known that this easter egg does not work on all versions of the game.

Well, that's until now. I've decompiled the code related to this and will list the differences below, including how to enable this easter egg on later revisions of the game.

Sitdown/Upright Revision A: This version works as stated. Just before any checkpoint, hold start (just before the sky is due to cycle to the upcoming level colour) to reveal the message. Easy.

Sitdown/Upright Revision B: Activating the egg on this version is more complex. First you will will need to achieve a high score, and enter "YU." as your name, complete with trailing full-stop.

Furthermore, the easter egg can only be activated when transitioning from Stage 2 to Stage 3 on this version of the game. Yes, they've actually included extra code to handle this.

It should also be noted that the egg can only be displayed once and is then deactivated. Also, if the user enters "YU." again on the high score table, the egg will also be deactivated. I'm not certain why this required such a rewrite - it's not as if it allows the user to cheat in the game.

The easter egg code is buried in the middle of a routine to handle setting up the sky palette fade from one level to the next. Which possibly indicates that the programmer wanted to keep the code hidden from more common routines that were shared with the team. I wonder who wrote this piece of code, and why it was heavily altered between revisions?

Aside from that I've completely disassembled the entire service test code - which enabled me to figure out a bunch of minor book keeeping information. I've also disassembled the palette changing code that handles the road, ground and sky when transitioning between levels. I've even disassembled some rather dull code relating to the coin chutes. Next - there's a load of tilemap code to be looked at. The quest continues!

Service Test

2010-05-01T00:28:00.003+01:00

I'm debugging the service test code at the moment. After some of the recent decompilation work, I fancied something easy. Nevertheless there are still some cool things to be discovered.

One thing you'll notice in MAME, is that the "Motor Test" fails:

The motor test, which only runs if the DIP switches are set to the Moving cabinet type, essentially moves the cabinet from left to right. The limit switches activate at the extremities and the pot values from the motor are recorded. A magnet also detects the centre position.

I quickly hooked up a simulation of the motor hardware in the Jemu2 driver I coded, using knowledge from the decompilation. Here are the results:

Notice that there are no error messages, and the values are correctly recorded.

As far as I can see register 0x140001 works as follows:

Bit 3 = Set to indicate left limit reached
Bit 4 = Set to indicate centre reached
Bit 5 = Set to indicate right limit reached

The desired motor position is written to register 0x140003.

The actual motor position can by read by writing '12' to the analogue select register 0x140012.

Finally, my gold plated Ferrari is here!

2010-04-14T11:12:00.010+01:00

In my unending quest to fill my house with OutRun related junk, I picked up the following Sega OutRun branded gold Ferrari:

The seller had this to say, I've no idea how accurate this information is with regard to the number produced:

Rare Sega "Out Run" Commemorative Ferrari 1986
Custom cast, gold plated, all metal scale model Ferrari Testerossa
Approx. 4 3/4" long x 1 1/8" high and weighs about 1.5lb
Fewer than 100 were produced and presented to the top tier arcade game distributors.
The model's exterior rear view mirrors while no longer attached, can be easily re-mounted and are included with the purchase

The only other information I can find this, and in fact the only other mention of it I've come across is on the following webpage:

The only information I know about it is that it was given out by Sega, apparently as part of a trophy to retailers who sold copies of Outrun. The back of the car, right behind the rear window, "OutRun" is engraved in it, and the license plate says "Sega". The bottom also has a nut on it, which is a definite indication that it is the top piece to some kind of trophy. After I bought it 8 years ago, I have never been able to find any other information on it since.

Intrigued, I asked for a bit more information and it seems they were samples for an advertising promotion:

They were salesman samples so they are quite rare, They were made to show Sega some of the advertising possibilities they could choose from and I got them directly from the salesman who had them made. He tells me they were never displayed, only passed around by top executives at Sega.

A gold plated Golden Axe branded axe was also thrown in with the bundle.

Does anyone else own one of these? And does anyone know whether it was in fact part of a trophy?

Progress Update

2010-04-12T21:29:00.001+01:00

Quick update on what I've been upto over the past week. I've decompiled and commented the following code:

- Palette setup for ground colour, road colours etc.
- Palette setup for sky shading effect
- Code to convert internal increment value to user friendly KP/H display. Including tile blitting.
- Code to setup the speed at which to scroll the sprites. This is independent from the road scrolling.
- Code to adjust x position of the car based on the curvature of the road, to ensure car 'sticks' to the road on curves.
- Code to convert steering value from hardware to a meaningful change in x position
- Code to prevent car from straying too far from the boundaries of the road.

There is still a LOT of code to go. This is a long slog!

OutRun Version Differences

2010-04-12T21:21:00.000+01:00

Here are some details of the visual differences between the first revision of the OutRun ROMs (deluxe sitdown) and the final revision (sitdown/upright, Rev B).

Notice the omission of "Select Music By Steering" on the original version:

Stage 1, Coconut Beach, has a different track layout.

Notice the absence of scenery on the right hand side, and in the central reservation.

The dual lanes at the start of the track also merge more quickly into a single road on this version.

Notice the strange positioning of the Flamingo huts on the right hand side of the road. These are replaced with palm trees on the later revision.

The well documented course map differences. Older revision shown top. I presume the levels were reordered, so that the more visually impressive levels were shown earlier in the game.

Service Test. Lack of Backup Ram clearing.

Memory Test. Deluxe Sitdown and later revisions.

Can anyone find any more? Once I complete the disassembly of OutRun, then it will be easier to compare the revisions to find out what other subtle, non-visual, changes were made.

Code Reuse At Sega

2010-04-08T10:22:00.001+01:00

Out of curiosity, and to follow up a previous post, I examined some of the Super Hang-On code to figure out the level of code reuse between the games as they share the same hardware. A quick glance at the code shows that a lot of the core routines, responsible for generating the road detailed in this post are identical. It appears that the slave CPU code to handle road splits is removed from Super Hang-On.

It's probably not a surprise, given that there are other obvious similarities between the titles, including some of the sampled sounds being identical.

Now the OutRun hardware supports two road layers. But as far as I know, Super Hang-On only uses a single road layer. Interestingly, there was a conversion of Super Hang-On to the Space Harrier hardware, which only supports a single road layer. Presumably, OutRun wasn't converted in the same manner, because of its reliance on two road layers for the wider roads (even when two distinct roads aren't displayed, the two road layers are sometimes in use).

One other example of code reuse I've found is between OutRun and Sonic the Hedgehog 2 on the Megadrive. Both games share the same random number generator, right down to the default random seed that's used.

OutRun Yu Suzuki Interview

2010-04-07T17:47:00.003+01:00

Back in 2008, RetroGamer magazine ran an interview with Yu Suzuki discussing the development of OutRun.

The article can be read online here.

It's interesting to read about the features that didn't make it into the final game:

“Because of budget and development time limitations, some of the contents I’d planned had to be squeezed or cut. I’d made preparations for eight individual characters and I wanted to include various events at each checkpoint, which would have made the player experience a story; something like the Cannonball Run film. I also wanted to give players a choice of supercars to drive, so that they could enjoy differences in car performance.”

Personally, I'm pleased the checkpoint events didn't make it, as they'd have potentially spoilt the flow of the gameplay. The changeable characters make sense, as the player sprites are drawn separately from the car sprite and have a table of offset co-ordinates. This also allows the car sprite to be horizontally flipped (it wouldn't look good if the players swapped seats, as per the Amiga port). There's no mention of the dual direction traffic that I uncovered in the game code though... :)

In other news, I've returned to working on the Master CPU decompilation at the moment. There's still a heck of a lot of code to plough through, but it's relatively trivial compared with the previous Slave CPU work.

One subtlety that I noticed whilst working on the code is that the position of the shadows in the game change dependent on which direction the car is facing (in practical terms it's set by the x position of the tilemap backdrop). This attention to detail is somewhat outstanding - I'd never even noticed this previously...

OutRun Automapping Tool

2010-03-10T14:02:00.000Z

At last! I've completed my disassembly of OutRun's slave CPU code. This was by far the most difficult part of the project to date. First, a quick summary of how the road data is stored.

The road data is split into three main components:

1/ The path that the road takes. This is stored as a set of words. Each word ultimately represents the x change of the next road segment, and length of that segment. This data is parsed by a series of functions that interpolate the data and create a nice smooth curve, dependent on the adjacent road segments.

It should be noted that this data does not control the width of the road, the height of the road or how many road layers are enabled.

From what I've seen each stage has a unique path and no data is reused. However, the road split at the end of each segment is reused and the data is mirrored on the x-axis to create the road split.

2/ The height of the road segment. This is divided into a series of segments. Multiple segments are applied to any stage and are reused between stages.

3/ The width of the road segment. This is actually controlled by the Master CPU. I've disassembled the relevant code, but will revisit it at some stage soon.

Finally, the x1, x2 co-ordinates of the road segment are used by the sprite hardware and the scenery positioned on the level.

Interestingly, this means that Outrun's road layer is very dynamic. It's possible to swap the sprites from one stage, with the road data from another. And it's easy to change the height mapping of any point of a level. Very little is hardcoded in terms of screen positioning, and the final world is very much generated in realtime. It's easy to see why an entire 68000 CPU was dedicated to this one task.

As a test of my understanding, I've already converted some of the functions from assembler to a quick java utility. This utility can output the path (point 1 of the list above) of any stage of the game as a CSV file that can be represented by Microsoft Excel. So now it's easy to create an accurate visual map of all the levels, to aid players of the game. Admittedly, once I amend this tool to take the width into account, it will be more useful.

Here is a link to an example from Stage 1 (coconut beach). As mentioned, this map doesn't contain the road split information at the end of the level.

Finally, pleased and amused that people have found the blog interesting - most unexpected. Keep the comments coming.

This blog has moved

2010-03-04T22:11:00.001Z

This blog is now located at http://reassembler.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://www.massdestruction.co.uk/jsnes/atom.xml.

C Compilers

2010-02-22T17:16:00.005Z

Following my previous post, where I questioned whether Gauntlet's code was written in C as opposed to assembler, I've come to the realisation that OutRun's slave CPU code was probably generated by a compiler and is not hand-written assembler.

The slave CPU controls the road rendering. So essentially it generates the curves, height variation, road splitting and appearance, from the level data.

This has added an extra layer of obfuscation to the decompilation, as the resulting code is less logical and is convoluted to follow. Maybe AM2 had spare CPU cycles to play with, and decided to simplify the source code to this complex area by writing the code in C, as opposed to assembly code as used by the main CPU.

One of the first instructions sets one of the address registers to point at the start of RAM:

lea ($60000).l,a5

The a5 register is never changed and there seems to be an over-reliance on using this block of memory, where a data register would be much faster:

move.l  d1,$712(a5)
; ...
add.l   $712(a5),d2     ; Why not use add.l d1,d2?

And then there are blocks of code that are just pure spaghetti or irrelevant. I don't know much about compilers, but back in 1986 it's clear they produced dreadful code.

ROM:00001C80 tst.w   $720(a5)
ROM:00001C84 beq.w   *+4          ; What is this here for?
ROM:00001C88 addi.w  #$100,d1

On the other hand, a quick look at Gauntlet's code in Mame's debugger does not seem to yield equal levels of insanity. Maybe Gauntlet was coded in assembler after all.

I'd like to know what compiler Sega/AM2 were using. Does anyone know if it's possible to determine from a signature in the code? Is C the likely source language?

UPDATE: Some useful information in the comments below. Thanks to the help of a couple of readers, it's possible that portions of this code have been adapted from a previous Sega title that uses similar road hardware. The original Hang-On from 1985 could be a contender, despite the road hardware differing. Would have to examine the code to be sure. I'd assume that Super Hang On, released after OutRun, which had identical road hardware, reuses this code.

This would also explain why certain blocks of code are unused, the alternate coding style and the relative addresses. As pointed out, you might expect to see NOPs and other quirks if C compiled.

UPDATE 2: Checked Super Hang-On, which runs on the OutRun hardware. A quick look through its slave CPU code reveals much of it is identical.

C Compilers for 68000

2010-02-02T15:28:00.002Z

Reading The Making of Gauntlet, I was interested to read the following comment:

With the switchover from the 6502 to the more capable 68000 microprocessor, the development environment at Atari had changed considerably. “We were actually entering our own code at this point. Our development tools changed, too. We were now programming in C instead of assembly language,” says Logg.

Was the game really programmed in C, as opposed to assembler, back in 1985 or is Ed Logg remembering this wrongly? Firstly, the Gauntlet hardware consisted of a 68010 CPU (not the 68000), with a 6502 for sound. Secondly, C compilers in the mid-80s weren't as robust and optimised as today. I can envisage a front-end or name entry screen being programmed in C. But I would expect the majority of the game engine to be assembler for performance reasons. Especially when the article mentions that optimisation was required to ensure the game ran acceptably with so many characters on-screen.

Does anyone have any thoughts on this?

Hidden Voices

2010-01-14T14:36:00.002Z

If you try OutRun's Sound Test, you'll notice there are four voices you can apparently play. These are the speech samples Get Ready, Congratulations and Check Point. The forth sample, "Voice 4", doesn't work. If, like me, you've lost sleep over such a monumental issue - read on!

The elusive fourth voice is, in fact, still in the ROM files, namely those containing the PCM sample data. You can import these ROMs straight into a sound editor like Audacity and play them. I imported the raw files as PCM 8-bit unsigned, with a sample rate of 8000Hz. Note that the sample rate of the individual samples does differ though.

The 192K of sample data is stored across the following files:

opr10188.71
opr10189.70
opr10190.69
opr10191.68 - This file contains Voice 4
opr10192.67
opr10193.66

These PCM files contain all samples from the drums used in the music, through to the sound effects and speech.

You can hear an mp3 I exported of the voice here. The voice is "You're Doing Great", and seems to be stored at around 4000Hz, which is a lower sample rate than the other voices, which are at 8000Hz. I imagine the sample was removed because the designers couldn't figure out a good way of invoking it. There is already a voice at the checkpoint stage, which is the main way of determining your progress. Using the voice mid-level, based on your current position and time, could have created bugs or just not proved that compelling.

I should admit that I haven't debugged the sound code much, so a lot of this is based on pretty rough experimentation. I haven't delved into the code to see if it's easy to hook this sound up somewhere with brief debugging. There are certainly no high-level calls from the 68000 code, as I've listed every sound that can be played (and there are more than just those in the sound test). Looking at the Z80 code might yield more information. But I don't envisage having to port this directly, as I am planning with the 68000 code.

Update: Thanks to the JAMMA+ forum I've been informed this hidden voice is apparently used in Space Harrier. So maybe the OutRun developers started by using some of the Space Harrier code as a framework. Certainly some of the error messages are the same as shown in previous blog posts.

Level Select

2010-01-12T12:12:00.000Z

Yesterday proved a little more fun. Whilst debugging the slave road CPU code, I figured out how to change the level order in OutRun. Using this, you could easily make a level select. Also found a way to have the road data from one level, with the object data from another. It doesn't always work, but does allow you to make some interesting permutations. Some level data for Stage 1 is also hardcoded, but when I finally rewrite the engine in C, this will be trivial to solve.

Slave CPU Code

2010-01-11T11:56:00.000Z

Spent most of yesterday working on the code that runs on the slave CPU. On a positive note, there isn't much of it. The code is minimal compared with the main CPU. It's a loop that handles rendering the road. On a negative, progress is slow. I spent most of the afternoon trying to figure out a few hundred lines of assembler and now feel like gouging my eyes out.

Outrun Unidesa Manual

2010-01-05T00:22:00.003Z

I've had no free time lately. But the following manual arrived in the post:

It's an OutRun arcade manual from a Spanish company called Unidesa (Universal De Desarrollos Electronicos S.A.) who seem to have licensed OutRun at some stage. The company still exists and has a website here.

I expected it to be a straight translation of the common English Sega manual that can be found at KLOV.

Whilst the manual initially does contain translations of the service tests and dip switch settings, it interestingly contains additional technical information not present in the Sega manual. Most importantly, it contains a fantastic diagram of the OutRun PCB, with all components labelled. If I had a scanner, I would scan these in, but for now I will simply list the additional pages. The diagrams are not hand drawn, like the English Sega manual.

1/ Video Board Block Diagram:
- Video board clearly divided into labelled components including ROM, RAM, Power Outputs and the explanations of what functions the other areas of the board performs. Each component is numbered.

2/ CPU Board Block Diagram
- Similar to the above. Divided into Main CPU, Slave CPU, Road Character Generator etc.

3/ General Wiring
- A superclear wiring diagram for the Outrun cabinet. This is far better than the Sega effort. Each wire leading into the PCB and other components is clearly labelled with its function and colour.

There are also a couple of detailed technical pages about the Hantarex monitor, that don't appear in the Sega manuals including a nice circuit diagram.

If anyone knows whether there was another manual to accompany this one, or has further information - please let me know.

Update: Here is a picture of the Unidesa white OutRun cabinet, via the JAMMA+ forums. The PCB is different from the Sega version, which would explain the alternate diagram in the manual. The game uses the European track layout.

Pre-Xmas Update

2009-12-11T15:27:00.000Z

Quick update - pretty busy with both work and some other interesting projects that I can't discuss yet. OutRun work will definitely be continuing as I've made good progress, it's just on hold for a short period.

Game Objects and Level Format

2009-11-27T17:24:00.001Z

I've made a lot of progress. After a lot of hard work I've figured out the internal object format used by OutRun for most sprites and game objects which is a big breakthrough. I understand the complete format, with the exception of a single bit that eludes me right now. The internal format is a lot more complex than the values finally written directly to the sprite hardware, as it includes aspects like:

Both Screen Co-ordinates & World co-ordinates
Sprite Z Values
Independent priority settings in relation to the road layer and other sprites
Specific Sprite routines to use
X/Y Draw anchors
Sprite Type
Frame Number
The way in which the sprites utilise a series of lookup tables to extract more properties
All the usual things you'd expect: h-flip values, palette settings and so forth.

The traffic sprite format uses a version of this, but adds additional properties:

Bits to denote the traffic's position in relation to other traffic. This is used to control its speed and lane changing behaviour.
Speed
Information regarding the side of the road the traffic has spawned on

Even after establishing the above, and also a lot of related code - one thing is pretty clear: the codebase to this game is advanced and complex.

I also understand the internal format used to store the scenery data for the entire set of levels. Writing a quick utility to spit this out in some kind of visual form would be an interesting exercise and a way of verifying this. Whilst all the code is documented and commented, looking at it actually hurts by brain. I'll follow up on this later.

Look Both Ways!

2009-11-11T01:03:00.000Z

One interesting aspect of disassembling games you're fond of, is that you might uncover hidden code that was unused in the final build. This can give an insight into some of the features that were planned that didn't make the final cut, either because of time, technical problems or maybe they simply didn't prove fun during playtesting.

Lately I've been disassembling the traffic handling code, and in doing so I stumbled upon an interesting memory address that controlled a block of code related to spawning traffic. I was unable to figure out exactly what it did from the code and couldn't find any references where the address was written to. So I fired up the MAME debugger and wrote to the memory address manually so that the block of code would always execute.

In Outrun, all traffic drives into the horizon before disappearing. To my surprise, setting this flag caused the traffic to drive away from the horizon in the opposite direction towards the player's Ferrari. I imagine that the original idea was to have two-way traffic. The fact that Outrun's hardware supports two separate road layers means that the final effect could have been quite impressive with independent flows of traffic on each road!

As it is, the code is clearly unfinished, and no graphics exist for traffic travelling in the opposite direction. But it demonstrates what the development team originally planned. It certainly would have been impressive back in 1986 if they'd pulled it off.

You can see for yourself in the MAME debugger by changing the address with: b@60b6b = 1 once the game has booted.

Extend Time!

2009-11-10T10:41:00.003Z

One of the aspects of OutRun that somewhat puzzled me as a player, was exactly how the "Extend Time!" feature at the end of each level worked.

This is the additional time that is added to the countdown timer on passing a checkpoint. I've never seen details published - until now....

Here's a table that shows the time, in seconds, that is added to your overall counter per stage. The rightmost route is show first. The DIP switches of the arcade cabinet can be set to four difficulty settings for timing, and each respective setting has its own column. If you are lucky enough to find a working cabinet in the wild, it's easy to determine the setting by looking at how much time you start the game with.

.
         | Easy | Norm | Hard | VHar |
         '------'------'------'------'
Stage 1  |  80     75     72     70  |
         '---------------------------'
Stage 2a |  65     65     65     65  |
Stage 2b |  62     62     62     62  |
         '---------------------------'
Stage 3a |  57     55     57     57  |
Stage 3b |  62     60     60     60  |
Stage 3c |  60     60     59     58  |
         '---------------------------'
Stage 4a |  66     65     64     62  |
Stage 4b |  63     62     60     60  |
Stage 4c |  61     60     58     58  |
Stage 4d |  65     65     63     63  |
         '---------------------------'
Stage 5a |  58     56     54     54  |
Stage 5b |  55     56     54     54  |
Stage 5c |  56     56     54     54  |
Stage 5d |  58     56     54     54  |
Stage 5e |  56     56     56     56  |
         '---------------------------'

To be honest, some of the entries are a little strange. For example, why is Stage 3a (Cloudy Mountain) more difficult on Normal than Very Hard? Is this an error in the table?

I'm working from the Overseas version of Outrun. I'm not sure yet whether the table differs for the Japanese version where Gateway has been moved to Stage 4.

It should also be pointed out that all the tracks in Outrun are the same length from a technical point of view. Obviously some will be tougher in terms of sharp bends and thinner stretches of road. The road split at the end of each level is hard coded and not read from the level data.

Moving onto the traffic in the game. Once again, this can be set by the DIP switches to four independent settings. I haven't reverse engineered the traffic code in detail yet, but I can provide some rough guidance as to how the settings affect each level in the game. It's my understanding that the following table represents the maximum number of vehicles that can be spawned simultaneously on each level.

.
         | Easy | Norm | Hard | VHar |
         '------'------'------'------'
Stage 1  |   2      3      4      5  |
         '---------------------------'
Stage 2  |   2      4      5      6  |
         '---------------------------'
Stage 3  |   3      5      6      7  |
         '---------------------------'
Stage 4  |   4      6      7      8  |
         '---------------------------'
Stage 5  |   5      7      8      8  |
         '---------------------------'

Looking at the code which spawns the traffic, hacking the game to support more traffic wouldn't be trivial because there are only 8 slots in the jump table reserved for traffic sprite routines.

OutRun Gameplay Laserdisc & VHS

2009-10-20T00:56:00.004+01:00

I'm still beavering away, reverse engineering the OutRun source. I'm focusing on the sprite routines and level data at the moment. Both of which are quite complex. I've uncovered some pretty intriguing stuff, and understand why OutRun uses the convoluted jump table I mentioned in an earlier post. It's related to rendering the level data, and many of the repeated routines handle sprites.

But I'm not going to talk about that right now, as there's still further work to be done. Instead let's take a look at some curiosities I've found on ebay over the years.

First up is a rare Japanese video laser disc (i.e. not a game in anyway), manufactured by Pony Canyon in 1988. Pony Canyon are a Japanese publisher, who also published the MSX 2 version of Outrun.

The laserdisc is a small 20cm disc, so requires an adapter to work in certain players. The content of the laserdisc is a short 18 min video showing the optimal way of completing each of OutRun's 15 stages. The gameplay makes use of the Geargacha technique, popularised by Japanese games magazine Gamest in 1987. This technique allows the player to drive off-road without loss of speed by carefully timed rapid gear shifting. It also allows the player to achieve a rocket start, flying off the line to top speed in seconds.

The accompanying booklet contains information on the stages in the game. I would love to get this translated if anyone can speak Japanese?

Pony Cannon also released the "Game Simulation Video" shown below in the same year. The video contains footage from Galaxy Force and Thunder Blade in addition to the same video of Outrun.

The booklet that accompanies the video, shows a range of these videos was available. Other titles included After Burner, Hang-On, R-Type, Street Fighter and more. Incidentally, at the time I purchased the Outrun LD, the same seller also had a Turbo Outrun disc. But I'm not a huge fan of Turbo Outrun, so I passed on that option.

This was also released on Laserdisc:

The OutRun movie makes a further reappearance on this rare DVD, included in early editions of the OutRun 20th anniversary soundtrack box set. I've partially scanned the inlay here. A copy of the footage can be found here.

In 1987, Sony released a separate gameplay laserdisc. Unlike the Pony Canyon edition, this is a full-size 12 inch disc. It contains a wonderful colour inlay of the OutRun stages, lifted from the original Japanese arcade flyer.

And here's the VHS version:

I believe the contents of this disc are different, but I haven't verified this yet. For starters, the runtime is slightly longer, the inlay indicates the stages are demonstrated in a different order and it is produced by Tyrell Corporation.

Tools and Tiles

2009-09-29T22:18:00.003+01:00

Wrote a quick tool, which takes an Outrun CPU 0 memory dump from the MAME debugger as input. As output it prints the jump table from that stage of the game that has been built and stored in RAM.

This is handy, because it formats the data and only shows the addresses which are currently enabled, and doesn't repeat addresses when they're called in succession. The table in RAM itself is 124 entries long, and updated at various points during runtime.

So here's the in-game output:

0. 0xB15E
1. 0x74E2
2. 0x3BEE
3. 0x4048 (16 times)
21. 0x4828 (15 times)
82. 0x4ADC
83. 0x5248 (5 times)
91. 0x9862
92. 0x9C84
93. 0xA568 (2 times)
95. 0x5EA8
103. 0xA816
104. 0xA7D2
105. 0xA816
106. 0xC5A4
123. 0x78B0
124. 0xE644

This has made it easier to figure out exactly where in code the program is updating this table.

What else? I've been looking into the tile handling code. Tilemaps are used in OutRun for the horizon graphics (two layers) , the text layer is a tilemap and obvious things like the music selection screen are a tilemap. Each tile entry in the map is a word. The compression format for the first tilemap I've analysed in ROM is as follows:

1/ If a word is not '0x0000', copy immediate word directly to tileram
2/ If a word is '0x0000' a long follows which details the compression.
The upper word of the long is the tilemap value to copy.
The lower word of the long is the number of times to copy that value.

And here's how OutRun manages to store your exact route history through the levels in just a byte.

1/ There are 5 stages, and a memory location increases by 0x10 for each stage you progress.
2/ Each stage forks twice, giving 15 stages in total. At each stage, this same memory location increments as follows when the left hand route is selected:

Stage 1 = +8 (1 << 3 - 0)
Stage 2 = +4 (1 << 3 - 1)
Stage 3 = +2 (1 << 3 - 2)
Stage 4 = +1 (1 << 3 - 3)
Stage 5 = Road doesn't split on this stage

3/ Later this indexes into a lookup table, which then makes it easy to update things like the stage map at the bottom right hand corner of the screen during gameplay.

Other than that, I'm thinking about how to represent the graphics once I convert the engine to C. Do I keep them in a similar format, and just render a final array of pixel data (similar to how an emulator would render it's display), or do I convert them to a native PNG or similar? This would make it easier for someone to replace them and change the game, but could run into problems with palette changes and so forth. Thoughts...

Anyway, this post might give you some idea of some of the things I'm doing at the moment. There's still a long way to go.

2009-09-17T11:10:00.002+01:00

Quick progress report: Commented all the code relating to detecting when the car is off-road. Figured out the memory location that determined which wheel was off. Established the memory location that determined the width of the road, and handles splitting the road between number of lanes and individual roads. Commented some slightly less interesting code relating to lap times, output lamps and various other areas.

Amusing OutRun link: Unbelievable. I have found someone with a more insane project than my own. A real world OutRun cabinet containing a golf-cart... The mind boggles?

Debugging

2009-09-10T15:08:00.005+01:00

I reached a point where it was time to switch to a competent interactive debugger, instead of working out of a series of text files that were becoming increasingly difficult to manage.

It took me a good few days to transfer my comments and knowledge to the new system. But the payoff is massive - I've immediately spotted mistakes, and identifying blocks of code has become a lot less painful.

In the screenshot you can see the commented block of code that transfers the in-game timer to the on-screen HUD.

Yesterday I also documented how the main branch table works in memory. In fact, I'm not even sure if branch table is the correct terminology. Figuring this out was important because actually determining the program flow in Outrun is tricky. The list of functions that are finally called is generated at runtime, and differs at different points of the game.

Firstly, there's a portion of ROM that contains a series of long addresses. Each of these addresses is a pointer to another portion of ROM. This second portion of ROM contains a set of properties related to the function, and the final address of the function itself. The final step is to compile these to a table within RAM. This table contains bits so that the functions can be enabled or disabled.

I presume this is some kind of optimisation, but it seems to add a lot of indirection and makes following the flow of code rather tough from the onset. Maybe some level of obfuscation was the idea? Perhaps someone reading who is a 68000 wiz will know.

Update: Figured this out. Some useful information in the comments regarding this from one of the blog readers and myself :)

Decompilation Update

2009-08-27T17:07:00.003+01:00

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.

Outrun Decompilation Oddities

2009-08-11T23:03:00.004+01:00

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 (a developer?)
Color bank is lacking.
Make it less than 128 for one stage.

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".

OutRun Decompilation Project

2009-08-10T11:33:00.005+01:00

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.

FlashGear

2009-03-24T21:36:00.001Z

Now it runs pretty well:
http://www.javagear.co.uk/flashgear

Basically I missed a few Flash related things as I was working too late. I knew the code wasn't that bad! :)

JavaGear Actionscript/Flash Port

2009-03-23T10:01:00.003Z

I quickly ported JavaGear to Actionscript 3 the other week to see how fast it would run. The actual port was really quick - took just over a day to get it up and running.

It seems that Actionscript is a pretty sluggish language for emulation purposes. The main bottleneck in the code is the Z80 emulation. The rendering and flash specific stuff is not really an issue.

Using a hacked version of Sonic, with some patched speed enhancements (replacing some of the idle cpu loops with halt instructions), it's just about playable. But I'd be lying if I said I wasn't disappointed with the overall performance.

I did a lot of profiling, but so far haven't made any breakthroughs. The core code is pretty fast anyway. I tried an alternate Z80 emulator from a Flash Spectrum emulator, and this was slower than my own.

Edit: give it a spin here
Be warned it's slow, so save any important work in case it stalls your PC ;)

DroidGear

2009-03-23T09:58:00.003Z

Due to my own laziness at porting JavaGear to Google Android, I'm pleased to say Stephan has taken it upon himself to start a port. The code can be found here

A video can be found here

Looks like something's up with the frameskipping code from the video - I don't think the emulator is skipping frames at all. The interface and auto screen flipping looks cool though.

JavaGear 0.97 Preview

2008-07-02T11:14:00.002+01:00

Upcoming in the next version:

1/ Big speed increase for mobile version. I've compiled my own customised version of proguard (the java obfuscator) . This results are great, and games run noticeably quicker. I'll have some precise data to back this up in due course.

2/ Decent standalone application version with menubar and windows .exe launcher for ease of use. Essentially the menubar is the final feature lacking from the rewritten javagear present in the original. It works better than the original though :)

JavaGear Updates

2008-06-02T17:16:00.002+01:00

So you've probably noticed that there have been a few minor updates to JavaGear recently.

I'm also working on implementing 'save state' support. It's a feature I've wanted for ages, but is mind numbingly dull to code. I've finally summed up the courage. It works, I've just got to hook up some UI for it now.

Any other feature requests are welcome.

JavaGear ME 0.92 Released

2008-05-20T14:14:00.000+01:00

JavaGear for MIDP2 Compatible mobile phones.
Also contains a standalone J2SE (PC compatible) build of JavaGear.

New Features:

Screen rotation
Screen can be enlarged with SCALE option (before it was only shrunk)
Lightgun emulation (touchscreen devices and with mouse on J2SE version)
SRAM is saved (Phantasy Star etc.)
NTSC/PAL selection
J2SE: Pass window size as command line parameter
Uses less memory than previous version

Improved Emulation Accuracy:

Z80: Fixed bug in FDCBxxyy, DDCBxxyy opcode timings
VDP: Fixed VDPbuffer bugs in accurate version (not used by any games)
VDP: Accurate mirroring of ports (not used by any games)
VDP: Fixed bug in line interrupt setting
Fixed bug in GameGear auto resizing code

Available here

2008-05-11T21:02:00.004+01:00

JavaGear Android Port

I've started to port JavaGear to Google's Android platform. The results are good, although it runs seriously slowly in the emulator. Based on the J2ME version, it will presumably run faster on an actual device.

There will be updates to the existing mobile version of JavaGear in due course. I'm hoping to add Lightgun support for touchscreen handsets.

There's still some debugging on the Android version to be done in the meantime, and I've got to merge the Android code into the main source tree, as it's forked at the moment.

2007-08-17T13:18:00.000+01:00

OutRun is now integrated with JEmu2.

2007-08-13T23:30:00.000+01:00

The OutRun driver for JEmu2 is pretty much done. I sent the code to Erik today :)

It was tricky to get the sound right - a hack was needed to ensure the music played at the correct speed, and I'm not entirely sure I've done it in the best way, but we'll see what he thinks!

I'll post a link when it's online and playable :)

2007-08-07T23:52:00.001+01:00

More good news on the OutRun front - controls are now fully emulated, so the game is playable.

I've also fixed a bug with sprite ram swapping, which has fixed the occasional corruption problems I previously mentioned.

Next steps are to implement sound :)

2007-07-31T23:38:00.001+01:00

I'm making quick progress. The road layer is now implemented. I've also implemented shadow support on the sprites, you can see these under the trees in the screenshots below. I *think* the graphics hardware is pretty much complete now.

I've started implementing the controls. The basic digital controls are done and I'll investigate the analogue controls next.

I will then double check the timings and interrupt handling of the driver as there are some quirks at times.

There's some other things to be done - some of the code could be optimised and refactored in a slightly better way. Once done, it should be really easy to add further System16 games to Jemu. I've been using finalburn as a reference - the source is much easier to read than mame :)

Regarding JSnes, just to clarify this isn't abandoned as such - merely halted for now.

2007-07-28T18:45:00.000+01:00

I've added sprite support to the Java OutRun arcade emulator driver I'm working on.

The major graphical hardware left to implement, as you'll see from the screenshots, is the road layer.

There's occassionally some very brief and minor corruption to the sprites. I'm not sure what this is yet.

2007-07-26T13:43:00.000+01:00

OK, so JSnes hasn't been updated in a while. This is purely because I lost interest and had other things to spend my time on.

In the meantime I worked on a mobile version of JavaGear for MIDP handsets.

I'm also adding OutRun support to Jemu2. You can see below that I have got the text layer and tile layer working.

2005-01-28T13:14:00.000Z

- Fixed a problem in the CPU core with the RTI instruction, (switching the Accumulator to and from 8 and 16 bits after popping the status register from the stack). Solved graphical corruption and problems in loads of games, including Contra 3:

- Bugfixed HDMA support, fixing a bunch of Commercial ROMs (Zool, Turrican 2 etc.).

- Corrected some SRAM mirroring issues, meaning Mario Allstars passes the protection check. Not entirely convinced I've nailed SRAM yet, as there are some other issues...

- Added HIROM support. Probably buggy for now, but good enough to get a decent number of titles running.

- Added a bunch of new opcodes. Roughly 230 out of 255 opcodes are now implemented. I add them as I come across ROMs using them, which helps prevent silly bugs.

- Thanks to the Snes9x forum for helping out with a couple of issues. Who knows, we might see a source code release in a few months.

As usual, if you can help out, please contact me.

2005-01-19T15:49:00.000Z

Got my websites back up (Finally!)

Fixed a few minor issues on JSnes:

- Fixed CPU cycles per scaline
- Implemented a handful of new opcodes.
- Fixed directPageIndexedIndirect memory mode in CPU emulation
- Fixed bug on certain 256 Colour mode backgrounds

There are still a lot of bugs, but the above also means that some more games start to run. A handful of basic commercial titles are now playable to some extent.

If you have decent snes / emulation knowledge and want to help out, please contact me.

2004-03-22T13:11:00.000Z

Sprites are now implemented. Support is included for all sizes, including those that are undocumented, as well as features like sprite priority rotation. Check out the new screenshots.

Also fixed a bug in VRAM reading, which caused graphical corruption in a few ROMs.

2004-03-16T14:49:00.000Z

Added support for screen fading, one of the easier bits of the PPU to emulate! In the CPU core, I fixed a bug with the TCS / TSC opcode; the 16-bit accumulator needed to be transferred to/from the stack pointer ignoring the status of the memory flag. I already knew this, but implemented it incorrectly. Oops. Now Ghosts N Ghouls runs further, before hitting an unimplemented opcode. Lots of commercial ROMs now start, but really need sprites implemented to play!

Sprites will be the next aspect of the PPU I emulate. Then, a few titles should be playable. A number of people have contacted me to ask when I'll release JSnes. I think there will be a release in a couple of months, once I've stabilised the emulator somewhat. This might be sooner, but no promises.

2004-03-15T11:45:00.000Z

Well, a short time without an update, but I've been hacking away. I researched offet-per-tile mode, which can be used in Modes 2, 4 and 6 by the Snes. Implementing this proved tricky, as no documentation exists on it, and quite a few emulators don't support it. Further to this, the game doctor I ordered didn't work and is being sent back for repair, so I couldn't run any tests on hardware. Bah!

The main problem I ran into with offset-per-tile is that my current line-by-line engine wasn't good enough to support it properly. If I'd realised this functionality existed when I'd started coding, I could have done things differently from the outset. As it was, most of my graphics rendering code needed a rewrite.

Anyway, offset-per-tile now seems to be working correctly in all but one demo I've tried. I'm sure there's more bugs to find.

I also improved the sound skipping code, which means the Infinity demo now runs. I also fixed directPageIndirect addressing, which fixed problems in the Super Mario Allstars + World double pack and a PD demo.

2004-03-02T15:00:00.000Z

Added HDMA support. Managed to get the basics working pretty quickly, but spent a while trying to get the repeat flag working properly. Also had some trouble with conflicting documentation. A lot of nice effects work in PD demos now!

Next, I'm going to work on bug fixing existing code to ensure everything is working as it should. Currently a few simple demos that should work don't, and I want to establish the reasons for this before implementing anything new.

2004-02-25T11:22:00.000Z

As promised, I've implemented correct (as opposed to hacky) subscreen support. This includes fixed colour and subscreen addition and subtraction. One obvious benefit of this is that the sky in Super Mario World is now correct (compare these new screenshots with the previous ones). Also, have a look at the transparent clouds in the Dwarf demo.

Nearly all the docs I found regarding subscreens were absolutely terrible and generally wrong. I have to thank Grog for his doc, which was both clear and correct. I've fixed a bunch of other graphic bugs, and will probably work on either HDMA or sprite support next.

2004-02-23T10:09:00.000Z

Implemented H-Blanking support, which was causing Super Mario World to hang. In fact, SMW now runs into the game... and I'm sure it would be playable, if I had sprites implemented! There are some graphical glitches, related to me not supporting subscreens correctly yet. I'll optimise the BG layer code next, and simultaneously correct this.

Found a small bug related to NMI interrupts, although I don't think was affecting anything. SMW also showed up a bug with the LSR absolute opcode. I also corrected a bug related to scrolling tilemaps vertically, which only manifested itself on certain titles.

Currently, 80% of all opcodes are implemented. SMW, Super Off-Road, Super Mario All-Stars, Gradius III and Super R-Type are among a handful of titles that seem to run into the game (minus sprites). A few other titles do stuff, but require more of the PPU to be emulated correctly before progressing further.

2004-02-17T10:31:00.000Z

I've worked on fixing more graphics related bugs (one of which was very silly and prevented 64x64 tilemaps working). I'm sure they'll be more to uncover yet. I've implemented horizontal and vertical tile flipping.

Super Mario World now partially works. Obviously, there are no sprites yet, and graphics emulation is incomplete. It doesn't run any further than the second screen at the moment, due to some kind of CPU/Interrupt bug which affects a bunch of ROMs. I'll try to solve this soon.

2004-02-12T13:10:00.000Z

No screenshots today, because I don't have anything interesting enough to post. However, I've worked on improving graphics emulation. I've started to clean a few bits of code, and most importantly, have implemented 16x16 tiles.

Some further opcodes and bugfixes in the core mean that a whole bunch of new PD demos run, or at least do something.

I've also ordered myself a Game Doctor SF7, which will enable me to test lots of interesting stuff on SNES hardware if I find the time.

2004-02-09T15:36:00.000Z

Here's an update of my progress:

150 CPU Opcodes are now emulated. I've bug fixed quite a few existing ones, and corrected various errors.
64x32 tilemaps now display correctly
Tilemap scrolling implemented
Automatic joypad reading implemented
SPU skipper implemented (Fakes the sound processor for now)

The result of all this is that a handful of new PD demos are working, and the following commericial ROMs are displaying some graphics:

Currently, these do not run any further due to unimplemented opcodes. Still, I'm on the right track...

2004-01-13T10:29:00.000Z

As promised some screenshots from some partially working new demos:

2004-01-12T17:36:00.000Z

Over the weekend, I added more opcodes to the processor emulation; roughly 90 out of 250 are now emulated. I fixed a daft bug with regard to the negative flag in certain instructions (actually cause by a typo). I also corrected the JML absolute long instruction. I did a little bug fixing on the video emulation, and now tiles with higher colour depths are decoded correctly. Following that, I implemented controller emulation.

The result of this work is that a bunch of new demos are working, or partially working. I'll post some screenshots later.

2004-01-08T10:09:00.000Z

Well, a very long time without an update, but I've been busy programming games at work and drinking too much over Christmas. Still, some progress has been made. I've added a load of CPU opcodes, fixed the usual range of silly bugs that come with starting an emulator from scratch and implemented interrupts (see the Hello World demo below). As a result, a handful of simple demos now work.

2003-09-02T10:08:00.000+01:00

Spent a while fixing minor PPU bugs, and other errors due to misinterpretation of documentation. The result is that the homebrew ROM that I've been experimenting with now runs! It only draws a simple image, but demonstrates DMA, CGRAM, and BG layers in operation.

2003-08-18T15:45:00.000+01:00

The demo that I'm trying to run uses DMA. I've now implemented basic DMA support, although there's no HDMA support yet. I've also emulated the hardware multiply and divide functionality supported by the SNES. The next stage is to actually output some graphics to the screen.

2003-08-11T11:25:00.000+01:00

Implemented all the opcodes necessary to run the homebrew ROM. Started work emulating the basics of the PPU (Picture Processing Unit). I'm going to start by emulating BG1 and Tile Based graphics. So far, PPU registers seem to get written to correctly, which is a promising start. The only real obstacle I've come up against is time!

2003-08-07T10:20:00.000+01:00

Have now implemented 30 65c816 Opcodes... almost enough to step through the homebrew ROM that I'm using. There are a few confusing issues (mainly due to limited documentation), but overall I've found the CPU a lot easier to emulate than the Z80.

My friend Peter has offered me a crate of beer once I get StarFox running (probably because he believes I won't). I wasn't planning on emulating the SuperFX CPU, might now I might consider porting some C code in that area...

2003-07-31T12:06:00.000+01:00

Work has started on JSNES. A Java based SNES Emulator. Like my other project, JavaGear, the source code will be released under the GNU GPL license, once I am happy with progress.

So far, I've implemented the following:

Basic ROM Loaders (Simple LoROM / HiROM detection)
LoROM memory map
12 x 65c816 Opcodes

I'm quite busy at the moment, so this project may never be completed, but it should prove an interesting learning experience.