Turbo Tomato: Up and Running

In the previous devlog, I wrote about the history of Turbo Tomato and why, now, after all this time, I was resurrecting it.

In this post I'll document the initial steps to get this old game running in a modern development environment. Many yaks are shaved along the way.

The first task was to extract the project directory from a 40Gb(!) WinUAE backup archive. I've been a Mac user since 2012, so that's how old this one was.

Turbo Tomato exists as 50,000 lines of Motorola 68000 assembly language source code, numerous asset files in various legacy formats, a whole directory of tools to convert and wrangle these in to the raw binary formats used by the game, and a scattering of AmigaDOS and ARexx scripts to in the darkness bind them. Yikes.

    

Next, I tried to get the main binary to assemble. I'd recently come across the Amiga-Assembly extension for Visual Studio Code (AA) and it seemed like a good fit for this. Unfortunately (for me), the extension is designed around having separate source files that are assembled into object files individually and then linked together (like a C compiler), but the TT sources were organised as a unity build of one main source file that INCLUDEd all the others. Every time I saved a source file, AA would try to assemble it, but fail the fail of a thousand errors because the source was never designed to be built this way. It would have been too much work to update all the code, so I opted to disable the automatic building in AA and drive the build process with my own makefile.

My build pipeline relies on VASM and VLINK, modern portable tools that can run on macOS. Luckily it only took a couple of hours hacking on the TT source code to convert it from the old Amiga DevPac format to something VASM could ingest, but then my luck ran out.

One of our source files is missing.

Somehow, and I don't know how, I'd managed to lose one of the TT source files! I dived down a recovery rabbit-hole and spent the next week searching all my old hard drives and emails looking for this file, but eventually had to admit defeat. The file was gone. Was the resurrection gone with it?

No. I'm not unfamiliar with digging in to Amiga binaries, let's say, and I had a working binary of TT from 1997. Using the existing source code and ReSource, a well-known Amiga reverse engineering tool, I was able to locate the missing code in the binary and convert it back to usable source code again. Fortunately, the amount of missing code was quite small (about 1Kb), so this only took a few evenings' work.

TT could now build and start from VSCode! But it didn't work. It just showed a blank black screen. A frustrating two days of debugging followed, not aided by it being impossible to run TT under the nice modern source debugger in Amiga-Assembly because - as I eventually discovered - it doesn't support the debugged program loading libraries from disk. I had to use the much simpler UAE built-in debugger instead.

Of course, in the end, I found the problem, and it was such a stupid bug. I'd used "CUSTOM" in the source code as the symbol for the Amiga hardware base address ($dff000), but in the new AmigaOS system headers I was using with VASM this symbol was defined as $40 (a printer page size!) instead. No wonder the game was doing nothing (except perhaps trashing low memory).

I switched to "_custom", rebuilt the binary, and...

It worked! I'll admit I did a little cheer and air-punch in my chair at this point.

I now had a modern development environment that could build a (more or less) working Turbo Tomato and run it in UAE.

Next, let's see what state the game is in.