Claude Fixed a 1991 DOS Game Bug in Five Minutes: An AI Reverse Engineering Case Study

A Reddit user shared a story that left him "grinning ear to ear": he picked up a Pentium 75 machine off Facebook Marketplace — partly to archive a stack of 5.25-inch floppy disks, partly to feed his retro gaming obsession. But when he tried to let his son experience a beloved DOS game from his childhood, he ran into a stubborn freeze. The fix came from Claude, which reverse-engineered the binary, diagnosed the root cause, and applied a 3-byte patch — all in five minutes.

A Pentium 75 and a Thirty-Year-Old Bug

His reasons for buying the old PC were practical: magnetic media that's survived thirty years is worth celebrating, and a genuine period-correct machine could both read floppies and run old games. Over the past week, he'd been soaking in the "thunk" of the CRT, the hum of the mechanical hard drive, and the chirp of the floppy — textures no DOSBox emulator can replicate.

The game he wanted to revisit was Operation Neptune, published by The Learning Company. Two days earlier, it had launched just fine — VGA graphics, AdLib sound, running for about 30 seconds before he quit. But when he actually sat his kid down to play, the game refused to cooperate: every attempt resulted in a full system freeze, forcing a Ctrl+Alt+Del reboot.

He tried everything in the standard troubleshooting playbook — re-transferring the files, tweaking the FreeDOS boot configuration, double-checking BIOS settings, confirming that other programs and sound functions worked normally. Nothing helped. It was a classic phantom fault: same files, worked two days ago, dead today.

How Claude Located the Root Cause in Five Minutes

Out of options, he fed the raw game binary and a description of the problem to Claude. What happened next surprised him: the AI disassembled the EXE, traced the execution path, identified the most likely root cause, and patched a new copy of the EXE with a 3-byte fix — all within five minutes. He copied it to the old machine, ran it, and it worked on the first try.

Claude's diagnosis was technically sharp. The game's sound library probed for devices in a fixed order: Roland MT-32 (via the MPU-401 MIDI port) → AdLib → Tandy/PS1 → PC speaker. It sent a reset command to port 330h and waited for the standard FEh "OK" response to determine whether an MPU-401 was present.

The critical flaw: the detection routine had a timeout, but the routine that actually sent commands afterward did not. When playing notes, the game used the D7h instruction — a command that only exists in the Roland MPU-401's "intelligent mode." Most sound cards' MIDI ports (Sound Blaster 16, various clones, many modern retro cards) operate in UART-only mode. They respond to the reset, so the game mistakenly concludes a Roland device is present — but they never acknowledge the D7h command. The result: the game falls into a tight polling loop with no timeout, waiting forever, locking up the entire machine.

MPU-401 Background: The MPU-401 was Roland's MIDI Processing Unit interface standard, introduced in 1984, operating on I/O ports 330h/331h. It has two modes. In Intelligent Mode, the MPU-401's onboard processor handles MIDI timing, tempo sync, and other complex tasks; the host simply sends high-level commands (e.g., D7h for "stop"). In UART Mode, the MPU-401 acts as a pass-through, forwarding raw MIDI bytes directly without interpreting any intelligent-mode commands. Many DOS-era games called intelligent-mode instructions specifically to support Roland sound modules, while later sound cards like the Sound Blaster cut costs by implementing only UART mode. This "false compatibility" problem plagued players at the time; community tools like SoftMPU — a TSR resident program — were developed precisely to emulate the intelligent-mode instruction set on top of UART mode, patching exactly this class of compatibility bug.

Why Did It Work Two Days Ago?

Claude also offered an honest, careful set of hypotheses about why the game ran fine two days earlier — rather than forcing a single confident answer. It suggested a few possibilities: the sound card may have been in a different mode or configuration at the time; a TSR like SoftMPU might have been loaded; or the MPU port was disabled. It also asked what sound card was in the machine, and noted that the scenario the user described — "a 90s home PC with a Sound Blaster 16, just like I remember from childhood" — was precisely the configuration that would trigger this freeze. That matched the symptoms perfectly.

This kind of "I can't be certain, but here are the plausible explanations ranked by likelihood" framing actually increases the diagnosis's credibility. Rather than fabricating a single authoritative answer to appear omniscient, Claude reasoned from hardware behavior and gave a probability-ordered list.

The Technical Craft Behind a 3-Byte Patch

The solution was elegant in its simplicity. Claude generated ON_NOMPU.EXE by changing just 3 bytes: at file offset 0x1FB06, the bytes BA 31 03 were replaced with EB 18 90. This modification makes the MPU detection logic jump directly to the "not found" exit path, so the game never touches port 330h and automatically falls back to AdLib audio.

In assembly terms, BA 31 03 is an instruction that loads 0x0331 (the MPU data/status port) into a register — the entry point of the problematic detection code. EB 18 is a short jump, and 90 is a NOP pad. Together, they form an unconditional branch that bypasses the entire faulty probe routine. Three bytes: no structural damage to the file, no collateral effects, and the infinite loop is cleanly severed.

This kind of work has traditionally belonged to experienced reverse engineers — people fluent in x86 real-mode assembly, DOS-era sound card I/O port conventions, the MPU-401 intelligent/UART mode distinction, and how to hot-patch a binary without recompiling. Now, one conversation and a binary file gets it done.

Technical Context: x86 Real Mode is the native operating mode of the 8086/8088 processor, and virtually all DOS programs ran in it. In real mode, the CPU reads and writes hardware I/O ports directly via IN/OUT instructions, with no driver abstraction layer from a modern OS in between. This means a program can unconditionally poll a port in a tight loop — and this "bare metal" programming style is exactly why a port-polling loop without timeout protection can lock up an entire machine. Binary patching is the practice of directly modifying machine code bytes at specific offsets in an executable file, without access to source code and without recompiling — a foundational technique in reverse engineering and software preservation. The combination of EB (JMP short) and 90 (NOP) is one of the most common patterns in binary patches: the jump bypasses the problematic code block, the NOP maintains byte alignment, and together they sever a bad execution path without disturbing the relative address calculations of surrounding code.

A Small Story With a Large Signal

The original poster noted that this "doesn't compare to someone using AI to discover a new planet" — and he's right. But that's precisely what makes it interesting. It illustrates where large language models deliver real engineering value: not replacing experts, but compressing work that would have taken hours or days of professional debugging into a few minutes, and making it accessible to people who aren't specialists.

For retro computing, vintage game preservation, and data archival — long-tail domains where software is long-abandoned, source code is often lost, and community resources are thin — this capability is especially valuable. An AI that can understand, diagnose, and repair at the binary level means a meaningful amount of digital heritage that was at risk of being lost forever now has a path to survival.

Of course, some perspective is warranted: Claude's diagnosis contained speculative elements, and the patch's first-try success reflects both the quality of the analysis and the relative clarity of this particular problem. But none of that diminishes what happened on that Pentium 75 — it's a vivid, concrete example of AI-assisted reverse engineering actually working in the wild.