A 1997 DOS game, reverse-engineered and ported in under a day

The game

PYROMANIA is a Bomberman-style freeware game by Christoph Brzozowski (“Software 32”, 1997): up to four players at one keyboard, monsters, eight power-ups, six graphic sets, MOD music. It is a 32-bit protected-mode program on the DOS32 extender, hand-written assembly, with its assets packed in a custom archive (PYRO.DAT, “VLIB” with an LZ variant called “PACK”).

How detailed was the briefing?

Not very. These three messages, plus a one-line “build it in Rust”, are the entire functional specification Felix wrote:

Everything else (architecture, file formats, timing, which bugs of the original count as bugs, test strategy, review loops) came out of the agent’s own process: a brainstorming phase with multiple-choice questions, a written design spec, and one written implementation plan per stage, each of which Felix approved with a single word.

Every decision Felix actually made

How autonomous was it?

Felix sent about 30 messages in total. Roughly half of them are one-word approvals (ja, passt, los, jo mach weiter). Between two approvals the agent typically worked for one to three hours without input: dispatching research agents, writing a plan, implementing it test-first, running an independent review, fixing the findings, and deploying.

The agent recorded every judgement call it made on its own as a ruling with “what it costs if I’m wrong”, and listed all of them at the end of each stage (11 in stage 4, 16 in stage 5). Examples: preserving the original’s double-buffered sprite table so that collisions see positions from two frames ago; reconstructing the 6-bit palette from the 8-bit asset, after checking that the inverse is exact for all 64 levels; reproducing the help screen’s page-turn order from the disassembly rather than from its own earlier (slightly wrong) analysis notes.

The one bug the human found

Felix noticed the menu music restarting too early. The agent checked the MOD files and found that almost every song ends with a Bxx “jump to order” effect: BOMBT2 plays orders 0–23 once and then loops from order 6, so the intro is heard only once. The build had rendered one pass to OGG and looped the whole file. The fix was tools/modloop.py, a small MOD timing simulator (speed/tempo Fxx, Bxx, Dxx, pattern delay EEx) that computes the loop point. The Nix build asserts that the computed song length matches the rendered WAV within 0.5 s, and the browser sets loopStart/loopEnd. BOMBT2 now loops 35.34 s → 150.54 s. While checking the build output, the agent also noticed that a newly added JS file was missing from the web bundle, which would have broken the page, and fixed that before deploying.

Timeline

Times are CEST, from the session log and git history. Filled dots are messages from Felix.

The method

The agent ran the same loop for every stage, using a skill library (“superpowers”) for process discipline:

Reverse engineering: “wörtlich” (verbatim)

The plans declare the analysis documents binding: “take this pseudocode line by line, with all constants”. That is why the port reproduces things a hand-written remake would never get right:

• Timing: 70 Hz in Mode 13h menus, 59.94 Hz in Mode X rounds, one logic step per vsync, no timer.
• Randomness: the original’s Park-Miller RNG (0x13be8) and its exact call order. Even the help screen’s pixel dissolve consumes random numbers in the original’s planar VGA order (plane 0–3, then row, then column).
• Palette fades: they stop one step short, so the help screen is 15/16 as bright as its picture. The port matches.
• Collisions: the original double-buffers its sprite table and swaps at end of frame, so hit tests see positions from two frames ago. Rebuilt.
• Menus: the cursor resets after every submenu; a held ESC can skip two menu levels; MONSTER IQ “GENIUS” can only be set through the config file. All kept.

Test oracles

• Pixel references: DOSBox-X captures of the original (logo, menu, round start, options, help, credits), compared to the port’s render pixel by pixel. Monsters are matched against all 16 walk frames, because their facing depends on the RNG seed.
• Real data: converter tests run against the actual PYRO.DAT.
• Determinism: same seed and same inputs give the same frames, which makes timeline tests like “the ending takes 5 913 frames ±2” possible.
• Browser acceptance: Playwright in Chromium. Keys are pressed with down/up and a 100 ms hold. The canvas is read via toDataURL, because screenshots can lag behind the canvas.

Toolbox

The agent ran about 660 shell commands, 85 browser automation calls and 23 memory operations in the session.

QA: what the reviewers found

At the end of each stage the agent packaged the whole diff and handed it to a fresh Claude Opus instance that had not written any of the code. The package included the plan, the spec and the list of the agent’s own rulings. Findings rated critical or important were fixed in one pass, each fix starting with a failing test. Minor findings were listed for Felix.

No review found a critical issue. All tests, clippy and rustfmt were green at every stage boundary.

Bugs that never shipped

Bugs of the 1997 original, fixed on purpose

Felix chose “fix clear bugs, keep the feel”. Each fix is marked // Korrektur: in the code (24 places). The game’s timing, RNG sequence and quirks stay untouched. Some of them:

• Flash was supposed to detonate bombs in its path, as the manual says, but read the wrong array and almost never did.
• When P2–P4 ran out of Flash charges, the game locked player 1’s bomb key instead of their own.
• Monsters kept their step counter across rounds and could walk off the 16-px grid from round 2 on. Confirmed in DOSBox.
• A key press in the last phase of the credits was never read from the BIOS buffer, so the fade restarted every frame and the program hung on a grey screen. Confirmed in DOSBox, see below.
• The credits’ ember filter wrote up to 11.6 KB past its 64 KB buffer.
• The default joystick sensitivity produced a dead zone of 0, so the player walked constantly.
• The key-name table calls both 0x15 and 0x2C “Z” (there is no “Y”), and calls PrtScr “/ KEYPAD”.
• Placing hidden extras could loop forever on a full map. The quicksort read before its array. Player 4 used the wrong sprite base.

Bugs the port could have inherited, but didn’t

The security report listed unchecked LZ match lengths, unchecked allocations and file-controlled table indices in PYRO.EXE. The Rust converter parses the same formats with explicit bounds and size limits, and the reviews above stress-tested exactly that with crafted inputs. The browser never parses PYRO.DAT at all, only the pre-converted PNG/JSON/OGG files. The saved config from localStorage is length-checked, magic-checked and clamped field by field.

Screenshots

Left: the original in DOSBox-X. Right: the port’s core rendering the same frame. These pairs are the actual pixel tests in crates/pyro-core/tests/reference.rs.

Honest notes

• Gamepads are covered by unit tests only. No real controller was attached during development.
• In the last stage several tests were written in the same step as the code, so the agent didn’t see them fail first. Its ledger says so.
• Reviewers can be wrong. One stage-5 finding contradicted the disassembly, and the agent kept the original behavior after checking.
• The analysis notes contained mistakes too, e.g. the order of page turning in the help screen. Where note and disassembly disagreed, the disassembly won, and the rulings record that.
• “Under a day” is wall-clock time including waiting for approvals and hours with the human AFK, not a benchmark.