Long before today’s sprawling open-world adventures or thriving modding communities, there was Jet Set Willy, a game that defined both frustration and fascination for a generation of home computer users. It was one of the first titles I ever played on the Tatung Einstein TC-01, a computer that found its way into our home thanks to my parents. They were “keeping up with the Joneses,” swept up in the early 1980s buzz surrounding the new world of home computing.

My parents weren’t technical, and their interest faded quickly. I, on the other hand, was hooked. I spent countless hours exploring the Einstein’s menus, typing BASIC commands, and loading games and programs, mesmerised by the idea that this beige box could do almost anything, if only I could figure out how. I was far too young to grasp its full potential back then, but that early curiosity set me on a lifelong path involving computers.

Remembering Jet Set Willy

Jet Set Willy wasn’t just any game, it was the game that tested your patience, skill, and sanity. Brutally difficult, entirely unforgiving, and yet endlessly addictive, it represented the best (and worst) of 1980s gaming. Like most 8-bit classics of the time, it demanded perfection: one mistimed jump or a single collision with a deadly pixel, and you’d lose a life. Run out of lives, and it was straight back to the beginning.

The game was written by the legendary Matthew Smith, who had already achieved cult status with his earlier hit Manic Miner. Astonishingly, Smith developed these games when he was just 17 years old, demonstrating a level of creativity and technical mastery that inspired a generation of bedroom coders. His original ZX Spectrum version of Jet Set Willy became a template for numerous ports and adaptations, including the version I played on the Tatung Einstein.

Even decades later, that combination of charm, challenge, and pixel-perfect chaos still has an undeniable pull. But as anyone who’s played it knows, finishing the game without cheating was almost mythical.

From Nostalgia to Code

Fast forward to the present. I’m now part of the team building content for tatungbytes.co.uk, a project dedicated to preserving and celebrating the Tatung Einstein and its software. My curiosity about the machine has come full circle, and I’ve set myself a new challenge: to learn Z80 assembly language and explore how these classic games were actually constructed.

Naturally, I chose to start with Jet Set Willy. The goal? To see if I could make it a little less punishing. I wanted to modify the game’s assembly code so that the player never truly “died” — no more lives lost on collision. But I also wanted to experiment with using modern AI tools, like ChatGPT, to assist with the reverse engineering process. Could an AI help analyse tens of thousands of lines of 8-bit assembly and identify where the logic for player lives was hidden?

The Challenge: Modding Jet Set Willy

That’s exactly what I set out to do. Armed with disassembly tools, community documentation, and a healthy dose of nostalgia, I began digging into the game’s binary, tens of thousands of Z80 instructions, cryptic labels, and unfamiliar memory addresses. My mission was simple: find the section of code that controlled player lives, then patch it so they never decreased.

What followed was part detective work, part digital archaeology, and part experiment in human–AI collaboration. Here’s how it unfolded.

Extracting and Disassembling

To extract the .COM file from the .DSK image of the game, I used the extract.py script from the tatungbytes tools collection. This Python command-line utility can unpack all files stored in a Tatung Einstein disk image, making it ideal for game modding and software preservation projects.

The command is simply:

python3 extract.py JETSET.DSK .

The above spits out JETSET.COM, the only file on the disc.

Once I had the JETSET.COM file, I disassembled it using z80dasm, a Z80 disassembler, with the following command on Debian:

z80dasm -a -l -g 0x00 JETSET.COM > JETSET.ASM


Explanation of the command:

• -a : Enables automatic instruction alignment and analysis, improving readability.
• -l : Includes a label table, giving symbolic names to jump targets for easier navigation.
• -g 0x00 : Sets the load address (in this case, 0x00) so the disassembly maps correctly to the program’s memory layout.
• The final part (JETSET.COM > JETSET.ASM) tells the tool to read the binary and output a readable assembly listing to a text file.

The result was a (kind-of) human-readable version of the game’s code — all 20,000+ lines of it. No comments, no labels, just raw instructions.

Using ChatGPT to Examine the Code

I then fed sections of the .ASM file into ChatGPT, asking it to identify logic related to player lives. I explained that the player starts with seven lives, and that somewhere in the code, a counter must track this value and decrement it upon death.

Within moments, ChatGPT highlighted a promising snippet:

ld hl,0f25dh
ld a,(hl)
and a
jr z, ...
dec (hl)


Here’s what’s happening:

• The instruction ld hl,0f25dh loads the memory address 0F25Dh (where the number of remaining lives is stored) into the HL register pair.
• ld a,(hl) loads the current life count into the accumulator register (A).
• and a checks whether the value is zero — if it is, the next instruction (jr z, ...) jumps to the game-over routine.
• If not zero, the dec (hl) instruction decreases the value stored at that memory address, reducing the player’s lives by one.

Patching the Code

My first instinct was to remove or comment out the DEC (HL) instruction. However, doing so shifts subsequent instructions in memory, breaking all the carefully calculated jump targets that reference fixed addresses. The result: instant crashes.

The solution? Replace the instruction with a NOP — short for No Operation. The NOP instruction literally tells the processor to “do nothing” for one cycle, preserving memory alignment and ensuring all jumps still land where they should.

In assembly, it looks like this:

nop


By replacing dec (hl) with nop, we effectively neutralise the life-decrementing logic without disrupting the program’s structure.

Assembling and Testing

To reassemble the modified .ASM file, insert it into a .DSK image, and test it in the MAME emulator, I used the AsmToDsk GUI tool from tatungbytes.co.uk. This utility automates the process of assembling, packaging, and injecting files back into an Einstein disk image for testing.

Sure enough, when running the modified version, collisions no longer decreased the player’s life count. The game could now be played indefinitely, still challenging, but no longer an exercise in masochism.

Completing Jet Set Willy is now actually achievable!

Reflections

This small project combined the best of two eras: the creativity and raw technical ingenuity of 1980s coding, and the analytical power of modern AI. With tools like ChatGPT, what once required potentially hours of manual reverse engineering can now be understood in seconds.

For me, the experience was more than a modding experiment, it was a rediscovery of the machine that first sparked my love of computing. The Tatung Einstein may have been a forgotten footnote in the history of 8-bit computers, but projects like this prove it still has plenty to teach us about curiosity, persistence, and the joy of exploration.

‍