IA Solves Decades-Old Mystery

Posted on October 1, 2026 in rick-dangerous , reverse-engineering

Is this title clickbait enough?

Many (as in decades indeed) years ago I completely reversed-engineered Rick Dangerous, a 1989 game for Atari, Amiga, IBM PC and a few others platforms.

I manually disassembled and figured out the IBM PC binary, and ported the result mechanically to C. I also browsed the Atari binary, but mostly only to extract its higher-quality graphics.

Purists were quick to point at some minor quirks: though rendering the Atari graphics, the game would exhibit some PC-only effects, such as Rick walking behind, not in front of, some parts of the layout. Nothing important really.

And then there was submap 18 in map 2 (Egypt) . I have played Rick a lot over the years. Give it a try or two, there is no single map that I cannot finish. Except for submap 18. No way it can be played on the port. This issue has been sitting unresolved for a few decades.

Enters AI

After my last experience at reverse-engineering Masquerade, I wanted to try something more ambitious, and thus have launched Claude against Rick Dangerous. I gave it:

• The IBM-PC and Atari original disk images
• Access to Ghidra via its MCP
• Access to the Hatari Atari emulator

I will describe the process in another post. Let us just say that I first I asked Claude to build a knowledge base of the game, that would be complete enough to support writing a port in any language, in a pure mechanical way. No assumptions, no gaps, just transposition.

Once that was finished, I gave Claude access to my original port's C code, and ask for a review. It found and fixed a range of minor issues (using signed instead of unsigned integers in a few places...) but nothing significant really. It just made the code overall prettier.

And submap 18 remained unplayable.

Can AI Solve the Game?

So I got more ambitious and asked Claude to draft a plan for solving the game. In a cheap enough way: we are certainly not going to scan graphics.

Claude proposed, and then implemented, a rather reasonable plan:

• Add a headless mode to the game, no graphics
• Add an MCP server into the game, so a model could control it
• The MCP server also reports the complete state of the game
• Add a solver into the game, with tree-based algorithms
• Use the model only when the solver cannot figure things out by itself

And then, with the model guiding the solver, Claude went on solving maps after maps. Most were solved plainly by the solver (i.e. zero tokens cost), some required some "thinking". All in all, things were progressing smoothly, until we reached submap 18.

The Submap That Cannot Be Played

At that point, the solver failed, consistently and repeatedly, despite the model trying to give it hints and directions and constraints. Nothing would work.

To the point that Claude, running out of options, decided to play the map according to the Atari original binary code, using its knowledge base and the Ghidra project. It also compared the Atari code with the IBM-PC code. And something came out. Unfortunately, I have not kept the exact transcript, but it goes like this:

• There is a discrepancy in one place between Atari and port
• But port is truthful to IBM-PC
• It's one constant that is off by one, really
• On the PC, submap 18 exits directly to submap 20

Claude fixed the constant, solved map 19, and the many maps after that one.

Mystery Solved

What does this all mean?

One can only assume, but probably this: whoever did the IBM-PC port of the original Atari game made a mistake. A very small and undetectable one. And then QA detected that submap 18 could not be played. Yet time and money were running, and so... they just swept it under the carpet and patched the game so that submap 18 was skipped.

A careful examination of both platforms routing tables confirms it:

  ST  room 17 (0x11)  header @0x4770e  pTransitions = 0x47a28
    @0x47a28  00 00 00 18 00 04 77 00 00 18   left  edge, row 0x18 -> room 16 (0x10), entry row 0x18
    @0x47a32  00 01 00 38 00 04 77 1c 00 18   right edge, row 0x38 -> room 18 (0x12), entry row 0x18   <<<
    @0x47a3c  00 ff                           end of list
  PC  room 17 (0x11)  header @ds1:0x8554  pTransitions = 0x8721
    @ds1:0x8721  00 18 4c 85 18 00            left  edge, row 0x18 -> room 16 (0x10), entry row 0x18
    @ds1:0x8727  01 38 64 85 68 00            right edge, row 0x38 -> room 19 (0x13), entry row 0x68   <<<
    @ds1:0x872d  ff                           end of list

The port, being a mix of PC/Atari data, was trying to play an unplayable submap.

Rejoice!

The mystery is now solved, and further releases of the port will now be fully playable, end-to-end, including submap 18.

Want to try it? It is there!