I first played Prince of Persia in 1995 on an IBM PC XT. I still go back to it from time to time: the rotoscoped animation, the way the prince hangs from a ledge, the clank of a gate slamming shut. Thirty years later it still feels like nothing else.
In 2012 Jordan Mechner published the original Apple II 6502 assembly source, recovered from 3.5" floppy disks that had sat in a box for over 20 years (the restoration itself is quite a story): github.com/jmechner/Prince-of-Persia-Apple-II
C# is my favourite language, so I set myself an experiment. I would hand that source to an AI model and ask it to port the game to C#. I wouldn't read the code or edit it myself. My only job was to play the result and say what was wrong. Every new frontier model that came out got the same project, with nothing but prompts.
Source is in https://github.com/priyanr/PrinceOfPersia_C-Sharp_Port_By_AI Here's how it went.
Round 1 — Claude Opus 4.6 (February 2026) #
My first prompt was simple: "in this original code there 6502 assembly code for prince of persia, use the save level files and try to do it in c# console."
Over two days Opus 4.6 produced a C# console game, then a level editor, then a Raylib graphics version. It parsed the original level files correctly: rooms, tiles, gates, guard positions. It even rendered something that looked like the Apple II game.
But it didn't play like Prince of Persia. My prompts from those days tell the story:
- "its bad not able to play its running graphics is scrambled"
- "now char coming but movement everything wrong ... prince is not in floor"
- "now it dropped below floor and arrow keys doesnt move"
The core problem, as I learned later, was the architecture. The prince moved one tile at a time, hopping from cell to cell. The real game plays hand-drawn animation frames with a small movement per frame.
Round 2 — OpenAI Codex (March 2026) #
I tried Codex too, though I've forgotten which model it was. I gave it the same codebase: "this is prince of persia original assembly code to c# port done by claude still graphics not good can you fix it."
It made sensible small fixes: sharp pixel filtering so the art wasn't blurred, transparent sprite backgrounds, open gates you could walk through, and pillar tops that no longer acted as walls. The prince still ended up in wrong positions and still got stuck. It polished the surface, but the engine underneath was still wrong.
Round 3 — Claude Opus 5 (September 2026) #
This is where I changed the rules a little. I wrote two Claude Code skills: one that controls DOSBox (launch a program, send keys, take screenshots) and one that controls any Windows program. Then I pointed Opus 5 at my original DOS copy of Prince of Persia and said: compare against the real thing, and run until you succeed or until 6am.
It worked through the night, and the first thing it did was diagnose the architecture problem. The old engine was a tile-grid engine, while the real game is driven by frame sequences. So it rebuilt the engine around the original's own design.
Then it went further than I expected. It worked out the formats of the DOS game files and read the real data straight out of them: every animation frame of the prince, the dungeon art, and all 15 levels. It found the original animation tables inside PRINCE.EXE by searching for byte patterns it recognised from the Apple II source, and it confirmed each table against a second known value before trusting it. None of the game's copyrighted data went into my repo. The C# program reads it live from my own DOS install.
In the morning I had something playable. The prince dropped in, landed, turned, ran, jumped, fell through the gap and crouched on landing, all with the real animation. In a second session I played the first screens in DOSBox while it watched my screenshots, and it found a bug in how it detected ledges: it was looking for a ledge in the wrong cell. It fixed that by going back to the original assembly routine.
But the levels still didn't look right. The bricks, the gates and the decorations were all slightly off. Opus 5 had placed every piece by matching it against screenshots, one piece at a time, and whatever it couldn't explain it filled in with guesswork.
Round 4 — Claude Opus 5.5 (September 2026): one prompt #
When Opus 5.5 came out I gave it a single prompt: "the character moves runs jumps but gate positions bricks all different, you are new model let see anything u can improve."
It took a completely different approach. Instead of tuning positions by eye, it found the original game's own room-drawing routine, as documented in SDLPoP by Dávid Nagy and the princed.org community, an open-source port of the DOS game reconstructed from its disassembly, and ported that routine. The result, DosRoomDrawer.cs, is a straight C# port of SDLPoP's room-drawing code ( src/seg008.c), and the file says so in its header.
SDLPoP's documentation explained what the earlier sessions had only guessed at:
- The "random" brick pattern isn't random at all. The original seeds its random number generator from the room, row and column, so every wall looks the same on every visit.
- The gate at the start of level 1 is actually open in the level data. The original game presses a hidden button as you drop in, which is why you hear the gate slam shut.
Opus 5.5 found some things on its own, by checking against my files and the real game:
PRINCE.EXEis actually compressed (Microsoft EXEPACK). The earlier tables had only worked because they happened to sit in a stretch the packer left untouched. It wrote an unpacker and read the tile-drawing tables out of my own copy of the executable.- The screenshot crop used in earlier sessions was off by one pixel row, and an earlier theory about "stencil colours" was wrong. Those colours are the real teal of the exit door.
Then it checked its work pixel by pixel against the real game running in DOSBox. On the first screen of level 1, the number of pixels that differed from the original went from 8,429 to 2 (a torch flame caught at a different moment). The second room and the exit door on level 3 matched too.
It wasn't flawless. It also changed where the prince's sprite is drawn, based on the original code, but it had only verified that with him facing one way. Facing the other way, he sank a few pixels into walls. I noticed something was off and gave it my backup from before its changes. It proved that the movement itself was identical in all test ticks, found the sprite problem, and reverted just that part. That self-check is also a sign of progress.
For the first time, the levels look like Prince of Persia.
What I take away #
- Opus 4.6: could read 6502 and write C#, but picked the wrong architecture and couldn't tell.
- Codex (March 2026): good small fixes, but didn't question the foundation and never ran the game.
- Opus 5: with tools to see the real game, it diagnosed the architecture, rebuilt it, and dug the real data out of the original files. That was the first playable version.
- Opus 5.5: from one prompt, went looking for how the original actually does it instead of approximating, and proved the result pixel by pixel. To be fair, the key to the last session was knowledge that already existed: the room-drawing routine that Dávid Nagy and the SDLPoP community had documented from years of reverse-engineering. Opus 5.5 knew where to look, ported it and verified it.
I'm not sure it could have worked all of that out from the DOS binary alone. So I asked it, and it said:
"Honestly, probably not in one prompt. I didn't reverse-engineer the drawing code. I read SDLPoP's reconstruction and ported it. I only found the tables inside PRINCE.EXE because SDLPoP told me what their contents were. The previous model searched the executable without that key and found nothing. Without SDLPoP, I'd have had to disassemble the 16-bit x86 drawing code myself. That's possible in principle, and some clues were already there: the observation that decoration sits one cell to the right, and the random-number constants being Microsoft C's. But it's a much longer job, and I'd expect it to take many sessions of disassembly and checking against DOSBox, not one prompt. What I did bring was knowing that SDLPoP existed, reading it correctly, spotting that the EXE was compressed, and proving the result pixel by pixel."
The biggest jump wasn't only the models getting smarter. It came from giving them a way to see the original and test themselves against it. From Opus 5 onward the model could check its own work, and I stopped being the only tester.
There's still plenty to do: guards and sword fighting, the palace levels, and the prince's exact landing positions. I'll run the same experiment on the next model and see how far it gets.
The code, with the full history of every session, is on GitHub: github.com/priyanr/PrinceOfPersia_C-Sharp_Port_By_AI
Credits #
This experiment stands on decades of work by people who love this game as much as I do:
- Jordan Mechner , for making Prince of Persia and for publishing the original Apple II source:github.com/jmechner/Prince-of-Persia-Apple-II
- Dávid Nagy and the princed.org community , for SDLPoP, the open-source port of the DOS game reconstructed from its disassembly:github.com/NagyD/SDLPoP .
The file that makes my rooms pixel-exact,
POPGame/Rendering/DosRoomDrawer.cs, is a C# port of SDLPoP's room-drawing code (src/seg008.c), and it carries this notice:This file is a C# port of the room-drawing code of SDLPoP (src/seg008.c), https://github.com/NagyD/SDLPoP — "SDLPoP, a port/conversion of the DOS game Prince of Persia. Copyright (C) 2013-2025 Dávid Nagy", licensed under the GNU General Public License, version 3 or (at your option) any later version. Because of that, my whole project is released under the same license, GPL-3.0-or-later. Modified 2026: translated to C#, restructured to emit placement lists for a framebuffer renderer, and driven by tables read from the player's PRINCE.EXE. This file, like the rest of POPCS, is distributed under the GNU GPL v3 or later. - Fabien Sanglard , whose Prince of Persia code review is the best guided tour of the original source:fabiensanglard.net/prince_of_persia
No original game data is included in my project. The C# code reads everything from my own copy of the DOS game at runtime. This is a non-commercial fan project, not affiliated with or endorsed by Ubisoft or Jordan Mechner. Prince of Persia is a trademark of Ubisoft Entertainment.
Game play videos by each model