How Chromatron was recompiled from Windows XP and PowerPC binaries with AI

Four attempts with Claude and GPT-Codex to rebuild a 20-year-old game from its binaries, compared, ending in a Rust build that matches 307,199 of 307,200 pixels.

Piotr Migdał of Quesma rebuilt the 20-year-old puzzle game Chromatron from its Windows XP and PowerPC binaries. He tried four routes with Claude and GPT-Codex models. Only the fourth, Claude Opus 4.6 with PyGhidra and Rust, produced a faithful clone: 307,199 of 307,200 pixels match the original.

What the project is#

Chromatron is a laser and mirror puzzle game by Sean Barrett of Silver Spaceship Software. Migdał, writing on the Quesma blog in March 2026, wanted to play it again. The only Mac version was for PowerPC, which Apple dropped in 2006. He says he had no earlier experience with binary formats or decompilation, and picked Chromatron because it was small enough to have a fair chance. The listing here is Recompiled a 20-year-old puzzle game for Apple Silicon and the web.

The goal was native builds for Apple Silicon, Windows, Linux and the web. A clear goal matters: his advice is to decide up front whether you want a pixel-perfect recompilation, a remaster or a remake.

The setup#

All four attempts started from the same two files, the Windows XP and PowerPC binaries. What changed was the model, the way it reached Ghidra and the target language.

The verdicts are Migdał's own. Ghidra was the disassembler throughout. Only the first attempt used an MCP server for it, a close cousin of Ghidra MCP.

The workflow, step by step#

Attempt 1. He connected Claude to Ghidra through GhidrAssistMCP and asked it to decompile the game and recompile it for Apple Silicon. He rejected suggestions to use an emulator. Progress was slow and needed heavy guidance: the board, toolbox and levels each took several iterations, and decoding assets took the longest.

Attempt 2. He ran the PowerPC code through m2c, a machine-code-to-C tool, hoping that generating code first and fixing it afterward would go better. Object positions were right on the first try, but asset decoding was hard. The model got there eventually, but attempt 1 was already further along, so he dropped this route.

Attempt 3. He moved to Cursor with GPT-5.2-Codex. He had misconfigured Ghidra so that the agent used its built-in headless mode, and that worked better than the MCP setup. Sessions ran one to two hours with little feedback. The laser beam was broken at first and fixed in one or two prompts. This build was fully playable.

Attempt 4. After a month-long break for another project, he used GPT-5.3-Codex to polish the C++ version, then restarted from scratch in Rust with Opus 4.6. The model worked mainly from the Windows binary and used the PowerPC one to cross-reference. The first pass worked. He credits his own experience, the choice of Rust, PyGhidra and the newer models. Rendering moved from SDL2 to the pure-Rust winit and softbuffer, which removed C dependencies and made the WebAssembly build simple.

What went wrong, and how it was fixed#

• Invented content. In attempt 1 the model made up fonts and text, and when asked whether they existed in the decompiled code, it insisted they did not. Migdał's conclusion is that a hallucination hurts more than an admission of ignorance.
• Claims that images matched. Models said two screenshots were the same when they were not. He added a pixelwise comparison against screenshots from MobyGames, which ended the argument. Gemini 3 Pro helped as an outside look at images but was not enough alone.
• Fragile MCP. He found the MCP setup shaky, while headless mode and then PyGhidra worked more smoothly. The model could learn to drive Ghidra itself.
• The font. Most of the effort went here. Models proposed Geneva, MS Sans Serif and sserife.fon, and kept saying the gap was only resolution. He wrote a small manual comparison tool that needed no recompile and found the answer: VGASYS, the Windows system font and default GDI font.
• Weak visual judgment. Models are strong at code and weak at looking at output. They often dismissed visible differences as unimportant.
• Guardrails. He notes that requests containing disassembled code may be silently redirected, citing GPT-5.3-Codex quietly dropping to GPT-5.2 and a friend's account being flagged.

Results#

• 307,199 of 307,200 pixels match the original. The one different pixel comes from the draw order of the laser beam and the grid overlay.
• The game binary is about 40 kB compressed and 96 kB unpacked.
• It runs on an Apple Silicon MacBook, and the same codebase builds for Windows, Linux and Wasm. The web version saves progress automatically.

What you can reuse#

• Start small. A 96 kB binary is a reasonable first target. Obscure asset formats were manageable, but the font cost the most time.
• Build an objective check before trusting the model. A pixelwise screenshot comparison beat every verbal claim. The same idea fits audio, save files or level data.
• Make small comparison tools for the hard part. The font tool let him test candidates without rebuilding.
• Let the model run Ghidra directly. If MCP is flaky, try headless mode or PyGhidra.
• Pick a target language you like. Decompiled output is pseudo-C, but models translate it. He chose Rust for control, brevity and safety, and found popular rendering libraries easiest for the model.
• Be ready to switch frameworks and to restart. Replacing SDL2 simplified the web build, and a fresh start with what he had learned beat patching attempt 1.
• Retry as models improve. The same task failed with one model and worked with the next.

Related: the port old software with AI topic, game decompilation, Claude Code with Ghidra, Codex projects, the models page, and the broader guide AI-assisted game decompilation.