Remembering Deathchase Extras: Interview with Richard "The Executioner" Wilson

For issue 114's Remembering Deathchase anniversary article, I interviewed three programmers who were inspired enough by Mervyn Estcourt's classic to create the own homage and small excerpts of each appeared in a boxout. Here's the first full interview, with Richard Wilson, author of the WinAPE utility and Deathchase: Amstrad CPC.

JD: Hi Richard. Why did you choose Deathchase to remake?
RW: I had read a lot about Deathchase being one of the most famous games on the Spectrum and knew it was missing from the CPC. At the time I was looking for a relatively easy project and thought the conversion would be fairly straightforward.

JD: What do you like about the game (if you do!), either technically or as a game?
RW: I've always been a fan of racing and driving games and wanted to do one of my own. Deathchase ran fast on the Spectrum, so I thought I'd like to find out how the 3D engine worked. The engine itself is quite a simple idea and well implemented. Not strictly proper 3D, but when the trees are coming towards you at the pace they do, it doesn't really matter.

JD: What was the process of breaking down the code like, and how long did it take?
RW: Breaking down the code requires a good disassembler (I used WinAPE) which can keep track of data areas, a lot of patience and a good knowledge of Z80. The process took me a couple of days.

JD: If you can explain (in as much layman terms as possible!) how the process worked?
RW: The game (and every game for that matter) is divided into 3 parts: Code, Data and Variables. In a modern game, those parts may be well defined and in different areas, but in an old Z80 game, generally they are mixed together, so the first task is to determine what's actually code and what's data and variables.

Once you've got the code separated from the data and variables, you can then go about finding out what each code routine does. You look for hints like setting registers to point at areas of the memory or input-output range which are used for the display or sound devices, then work out what each routine does, either just by just looking at the code or stepping through it with an emulator. You can also look more closely at the data areas you've found to determine if they make up some form of graphics or sound data. It's generally easiest to start with small routines and work out what they are doing, then see where they get called from.

A good example of this is the print_b routine in the deathchase.asm source code. You know the Spectrum character set is in ROM at #3C00, so it's easy enough to work out that the routine takes a string and draws it on the screen. Deathchase uses this routine extensively to display almost all messages, so when it gets called you can work out what part of the game it's from. It's used to show the score, the level, the GAME OVER message and so on.

It's a long process to work out what ALL the routines do, but then comes the last step: re-writing the bits that won't work as specified on the CPC. For example, the print_b routine for the CPC calls draw_char which is quite a bit more complicated than the Spectrum equivalent, but does the same thing.

JD: What do you think of Deathchase's status as one of the most iconic games on the Spectrum?
RW: I think it's well deserved. It's technically quite impressive to get any form of 3D engine running so fast, and it's the speed which makes it so playable.

JD: And what do you think it does to deserve that mantle?
RW: Getting that sort of performance out of a 3.8MHz Z80 is always impressive and always requires some serious coding tricks. I modified the engine itself very little to run on the CPC, and it needed some slow down loops in there to bring it back down to a playable speed. The game itself is quite simple by today's standards, but it's the simple ideas that work the best so long as you have the playability and re-playability.

My thanks once more to Richard for his time. More soon!