tag:blogger.com,1999:blog-56330372010-03-04T22:11:16.094ZLatest Project: OutRun Decompilation Past Projects: JSnes, JavaGear, JEmu2ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.comBlogger50125tag:blogger.com,1999:blog-5633037.post-71542451971394553862010-03-04T22:11:00.001Z2010-03-04T22:11:16.271Z

This blog is now located at __FTP_MIGRATION_NEW_URL__. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to __FTP_MIGRATION_FEED_URL__.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-76709455674634080842010-02-22T17:16:00.003Z2010-03-04T21:53:45.471Z

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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com6tag:blogger.com,1999:blog-5633037.post-29874095014056921692010-02-02T15:28:00.002Z2010-02-02T15:29:31.555Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-79806388535172580192010-01-14T14:36:00.002Z2010-02-26T11:26:54.655Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-67668727173738392302010-01-12T12:12:00.000Z2010-01-12T12:12:25.728Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com3tag:blogger.com,1999:blog-5633037.post-57416587106218932642010-01-11T11:56:00.000Z2010-01-11T11:56:37.616Z

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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-47390597409981857312010-01-05T00:22:00.003Z2010-03-02T13:41:45.535Z

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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com4tag:blogger.com,1999:blog-5633037.post-59760002976365534162009-12-11T15:27:00.000Z2009-12-11T15:27:42.331Z

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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-66299457530908964862009-11-27T17:24:00.001Z2009-11-27T17:43:29.500Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-8510022513772338592009-11-11T01:03:00.000Z2009-11-11T01:03:08.114Z

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,

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com5tag:blogger.com,1999:blog-5633037.post-36416740957717710152009-11-10T10:41:00.003Z2009-11-10T14:37:05.001Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-33267295399632258652009-10-20T00:56:00.004+01:002009-11-17T15:37:59.362Z

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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-55716330300524279762009-09-29T22:18:00.003+01:002009-09-29T22:35:42.304+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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-16106479745709278512009-09-17T11:10:00.002+01:002009-09-17T11:23:56.661+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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-81857991764584680802009-09-10T15:08:00.005+01:002009-11-10T10:50:53.501Z

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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com3tag:blogger.com,1999:blog-5633037.post-47277439735464621832009-08-27T17:07:00.003+01:002009-08-27T17:16:25.190+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 '

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-21824844658877568072009-08-11T23:03:00.004+01:002009-09-21T09:55:32.538+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 ECOLOR BANK GA TARINA NOYO !1 STAGE 127 KO INAINI SHITENEIf you set the program

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com2tag:blogger.com,1999:blog-5633037.post-85384920538006826572009-08-10T11:33:00.005+01:002009-08-10T12:04:29.756+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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-41271452790877976112009-03-24T21:36:00.001Z2009-03-24T21:37:09.935Z

Now it runs pretty well:http://www.javagear.co.uk/flashgearBasically I missed a few Flash related things as I was working too late. I knew the code wasn't that bad! :)

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com2tag:blogger.com,1999:blog-5633037.post-15647485437955240982009-03-23T10:01:00.003Z2009-03-23T22:30:14.691Z

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,

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-24182396222216934452009-03-23T09:58:00.003Z2009-03-23T10:01:21.304Z

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 hereA video can be found hereLooks 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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-3110471223152878882008-07-02T11:14:00.002+01:002008-07-02T11:26:15.355+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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com3tag:blogger.com,1999:blog-5633037.post-18983730990094034732008-06-02T17:16:00.002+01:002008-06-02T17:17:59.320+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.

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com1tag:blogger.com,1999:blog-5633037.post-58891497734029892802008-05-20T14:14:00.000+01:002008-05-20T14:15:18.419+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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com0tag:blogger.com,1999:blog-5633037.post-27010253551692483692008-05-11T21:02:00.004+01:002008-05-11T21:08:04.445+01:00

JavaGear Android PortI'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

ythttp://www.blogger.com/profile/06951854683143825385noreply@blogger.com8