The MSX Lode Runner TRS-80 Bootleg Project

Introduction - My History with Lode Runner - The Present - The Port - Technical Details - Download - Playing the Game

Spare me the self-indulgence, I want me a free game!


For those few of you that have never heard of Lode Runner, it is an arcade/puzzle game written in 1983 by Doug Smith for the Apple II computer. Since then it has been ported to pretty much every computer and console in existence since then (with one notable exception) and even spawned a series of five (5) arcade machines by Irem.

A true classic, the series continues even today - most recently released on Xbox Live Arcade in April 2009.

Here is the wikipedia entry.

My History with Lode Runner

Despite not owning a platform that had a port of Lode Runner until I finally acquired my father's hand-me-down PC/XT, it remains one of my all-time favourite video games.

I first encountered Lode Runner on a friend's Apple IIe in glorious monochrome green-screen. My affinity towards arcade, platform and puzzle games is no doubt the reason I'm so fond of Lode Runner. That the graphics and playability was far superior to any Apple II game I had seen before it was also a contributing factor.

But I didn't own an Apple II, and my TRS-80 was probably the only computer that never received a port of the game.

I decided to write my own port for my TRS-80 Model 4P, for which I had recently acquired a MicroLabs high resolution graphics board. But it had to be a pixel-perfect copy of the Apple II version - anything short would not suffice. And so I spent many hours over several days at my friend's place, painstakingly pouring over the Apple II screen, transcribing the graphics and the animation onto TRS-80 graphics paper as my friend played and re-played the 1st level under my instruction. I also noted the exact layout of the first handful of levels to re-create as I developed the game on the TRS-80. Eventually we discovered the format of the level data on disk, and my friend one day presented me with a roll of print-out with a hex dump of all 150 levels; some 37KB of hex data to enter by hand if I'd ever completed it.

From there I spent countless hours coding away in spaghetti Z80 assembler. Having coded the routines to display the level I set about animating the player and have them move around the screen. This is where the logic got hairy; replicating the pixel-perfect animation as you moved around the level appeared to me to require a separate routine for every transition between frames. At that time not very experienced in writing assembler, it was a complete mess. But it did actually work - player movement was complete except for dropping from the ropes. It did look impressive!

I'm not clear on when/why I stopped work, but it may well have had something to do with the fact that I had acquired a TRS-80 Color Computer, and not long after that, an Amiga 500. So TRS-80 Lode Runner lay unfinished and forgotten - almost.

I resurrected my notes (which I still have, BTW) and started re-coding in AMOS BASIC on the Amiga 500. This time I attempted to refine the animation code, with some success, but again the project stalled at around the same point. I re-started it again on the Amiga 500 in Lattice C this time, further refining the animation logic, but again stalled at the same point. Years later, the project was resurrected yet again - this time in C on the PC under DOS. The animation was by now table-driven, and I'd managed to complete the player movement, which could also be used to animate the enemies. A colleague at the time contributed some enemy AI to the game - but there it stalled for the final time.

Throughout all this, my original aim of having a pixel-perfect port for the TRS-80 was still something in the back of my mind.

The Present

More recently I had thought about resurrecting the project again - with the ultimate aim of producing a TRS-80 port, probably coded in C - and had decided to disassemble the C64 version for reference. I decided against trying to disassemble the Apple II version for several reasons; the Apple II version is disk-based whilst the C64 version is a ROM cartridge, the Apple II screen memory is interleaved and would complicate my understanding of the graphics routines, and the C64 has sprites which would simplify the graphics routines. I did get a start on it, but it was unexpectedly difficult to reverse-engineer for me, not knowing much technically about the C64.

Frustrated with my lack of progress, I then had the idea of porting an existing Z80-based version of the game to the TRS-80, much like I did with my own Space Invaders TRS-80 Bootleg Project. It wouldn't perhaps satisfy my ultimate aim, but it was a step in the right direction, and would perhaps give me some insight into both the animation logic and the enemy AI. Searching for a suitable candidate, I decided on the MSX version of the game. Unfortunately it wasn't actually coded by Doug Smith, but he presumably had some input into the port, given the prominence of his name on the title screen?!?

Hence this project page.

The Port

I've managed to port the MSX version of Lode Runner to the TRS-80 Model 4/4P equipped with a MicroLabs/RadioShack hires graphics board. The game is fully playable as it runs on the MSX, except for the fact that the graphics are monochrome. This, however, is no impediment as the original Apple II version was designed to be perfectly playable on a monochrome monitor.

As with all my port projects, the aim is to load the original unmodified ROM image into the TRS-80 and have the loader patch the image to then run on the TRS-80. It's the "purist" in me, and not only serves to better document the changes made, it allows the distribution of the patch without requiring the distribution of any copyright material.

Technical Details

For those interested, the TRS-80 Model 4/4P with hires board is well suited to running foreign software because of the relatively "empty" memory map; almost the full 64K is available to emulate the original hardware. And because the hires screen is port-mapped rather than memory-mapped, it doesn't require a footprint in system memory.

The down-side is that the hires graphics are particularly slow; games that move significant amounts of graphics around on the screen simply won't be able to run on the TRS-80. The trick is to choose games that don't have much moving around. Lode Runner is, fortunately, a good example.

The MSX Lode Runner cartridge occupies 32KB from $4000-$BFFF - free memory on the TRS-80. As a bonus, it is also free when the TRS-80 DOS is running, so it can be loaded into its final execution address directly from disk. The TRS-80 loader resides at $C000.

The MSX(1) doesn't have a true bitmap mode, but one of the tilemap modes can be used as a pseudo-bitmap mode by modifying the tile data rather than the tilemap (screen) data. Lode Runner happens to use this mode. The tile data is 1 bit-per-pixel (same as the TRS-80 hires), with another layer of colour data mapped elsewhere, which I ignore completely for this port. Fortunately, most of the graphics show correctly in monochrome and can be used as-is.

Lode Runner divides the screen into 8x10-pixel "characters", which are written to the screen in a single routine used by everything from the title screen to the game itself. Amazingly, simply skipping some MSX hardware initialisation and patching this routine to draw to the TRS-80 hires memory (instead) was enough to get the program running far enough to see the title screen.

Interrupts were next. Most arcade games, and many computer/console games, run off the hardware vertical video blanking interrupt (60Hz mostly) and Lode Runner is no exception. Patching Lode Runner was simply a matter of hooking the TRS-80 60Hz RTC interrupt, and replicating the code in the MSX's system ISR before Lode Runner's ISR gets called. Finally patch a few BIOS calls to do nothing and viola - the main game is running!

Keyboard/joystick emulation was next. This was simply a matter of hooking the joystick and keyboard BIOS routines, and instead reading the TRS-80 keyboard and re-arranging the bits to correspond to the MSX joystick and keyboard layout. Initially I simply mapped the appropriate keys to the MSX joystick bits, and I could actually play a game. Later on it transpired that I needed to emulate a dozen or so keys for the in-game menu, so I added the keys that the game actually used. I was afraid that the extra keyboard processing would adversely affect the game, but it does not appear to be the case.

Finally, that left the hard bit - sprites. The MSX has hardware sprites, and quite obviously, the TRS-80 doesn't. So I'd have to emulate the sprites in software. Lode Runner uses only 6 of the MSX's 32 available sprites, so I was hoping that it wasn't going to be too taxing on the CPU. There were a few ways I could tackle the emulation; the most complicated and processor-intensive solution was to emulate the hardware registers in the MSX VDP. But I was looker for a simpler way, and set about studying how Lode Runner in particular used the sprites.

In a nutshell, Lode Runner updates the sprites once every 60Hz interrupt. Even more conveniently, it is in the ISR that it copies the new sprite data across to the old data, which meant I had access to both the old and new sprite register values in one place - score! The first step was to create my own copy of the sprite data table, since I required multiple versions with different pixel offset - something the MSX does not require. Then I patched in a sprite draw routine where the original code actually updated the hardware sprite registers, which determined which sprite version had to be drawn on the TRS-80 screen. The draw routine reads the background tile data and overlays the sprite on top of it as it displays the sprite. The result - sprites with persistent trails.

The next step in sprite emulation was to do the wipe routine. It was relatively simple, much like the draw routine it reads the background tile data and simply draws it over the old sprite. I was able to take a bit of a short cut when determining which background tiles absolutely had to be re-drawn; as a result it only needs to redraw 2 tiles each time, instead of 4. Looking good!

There is a spiral wipe/draw effect that is used when starting/ending a level. For technical reasons, I have only implemented the “wipe”, not the draw. This is because the code actually updates the tilemap memory, rather than the tile data, as it does for the rest of the game. Since I don't emulate the tilemap (video) memory, it would be quite difficult to implement this effect as-is. I don't think the end result justifies the effort in this case. Sorry.

Lastly, there were a few minor niggly bits that required fixes and/or fudges to get looking nicer on the TRS-80. It's 100% playable, with the occasional glitch when a sprite doesn't get erased properly. I'm not sure what the cause of this is, and haven't had the inclination to look into it as it is a fairly rare occurrence, and doesn't affect game-play.

On a real TRS-80

Currently, the game won't run properly on a real TRS-80. The problem is that the Grafyx Solution board only allows access to video memory during horizontal and vertical blanking periods. During the active display, the board asserts WAIT#, which halts the CPU altogether until the next blanking period. Note that this is not a problem with any of the TRS-80 emulators. As-is, the video bandwidth isn't sufficient on real hardware to handle all the sprites.

My plan is to profile the sprite code and determine if/how to work around this problem. One possibility may be to update the sprites every 2nd frame.

Apparently the Radio Shack hires board is even worse – it holds the CPU until the next VBLANK! However, it does have an undocumented feature that disables the WAIT# generation completely, at the expense of a hashed display during video updates. If anyone out there has a real Radio Shack board, I'd appreciate if you could contact me as I'd be interested to see if there's enough bandwidth in this mode. Please note that I'd have to modify Lode Runner to run on the Radio Shack board.




TRS-80 patch source code and development disk image set to enable assembly of the patches and running the game.



Release Candidate 2 - bootable LSDOS 6 disk image with the game.



SPOILER ALERT - A single bitmap that shows all 76 levels of MSX Lode Runner.



Commented disassembly of MSX Lode Runner. It is currently around 50% complete, with the remaining code comprising animation routines and game AI. Most of the mechanics of the implementation are fully commented.

Playing the Game

The game itself uses the following keys:

TRS-80 Key(s)


Arrow keys

Movement (I have noticed it's not very playable on non-clustered keyboards. I might look at an alternate key mapping to improve playability).


Dig left

<X> or <Y>

Dig right


Maps to the MSX <ESC> key. Brings up in-game menu. Subsequent command keys are indicated on the menu.