This one never ran on a home console — it ran on a custom arcade cabinet built by Namco. That machine had no operating system, no disc drive, and a whole separate computer inside it dedicated purely to sound. To make the game run on a PC, I had to rebuild that entire arcade board in software first, then translate the game itself. The hardest part isn't writing it; it's proving it's correct. So I ran a modified copy of MAME alongside my version and compared the two, step by step, until they matched exactly.

• Five different crashes turned out to be one bug. They all traced back to a single table the game uses to decide what a fighter does next. Rather than assume I'd found the right table, I checked it against six cases that were already known to be correct before trusting it.
• The performance readouts were lying to me. Three separate speed counters all cheerfully reported a healthy 60 frames per second while the game was really running at 12 — because each one was measuring something my own code controlled. Finding the one honest measurement revealed the real problem, which was also quietly starving the computer-controlled opponents.
• The arcade board had a copy-protection chip designed to stop exactly this. Missing one small value from it made the fighters visibly explode on screen. I worked the correct value out mathematically rather than guessing at it.
• The sound hardware was rebuilt from nothing — an entire second processor and a 32-voice sound chip, running over a billion instructions without hitting a single thing I hadn't implemented.

The original PlayStation had very little memory, so this game constantly swaps pieces of itself in and out — and all thirteen playable characters occupy the same slot, loaded on demand. An earlier attempt at this port had to be abandoned entirely because it couldn't handle that swapping, which the game cannot run without.

• The game froze whenever you performed a finishing move. The cause was a message from the disc drive that never got delivered — the game was waiting for a signal I hadn't wired up, checking roughly 40 million times a second, forever.
• Every negative number in the game was wrong. A single flaw in the translation meant small negative values came out as huge positive ones. One search that was supposed to stop at a marker simply never stopped.
• All thirteen characters were quietly loading each other's data, because they share one memory slot. The fix was teaching the loader to tell them apart.
• The save system was rebuilt from scratch after the original path proved broken — I traced where the game keeps its progress in memory and saved that directly instead.

The Sega 32X was an unusual machine: three processors running at once, passing messages between each other. All three had to be translated and kept in step. I wrote the translation tools for this one myself — about 1,600 lines that read the original cartridge and produce equivalent modern code. Nothing in the game was redrawn or re-authored; every piece of artwork and data is read from the original cartridge.

• The game refused to boot because of a single line. One incorrect write to a memory-control register was corrupting the routine that unpacks the game's graphics and wiping 64 KB of working memory. One line changed, and the first real frame appeared.
• What looked like a hang turned out to be impatience. Comparing against a reference emulator proved my version was behaving identically to real hardware — I had simply been giving up at frame 320, and the game doesn't start drawing until frame 428.
• I rewrote the graphics system from the ground up so it could be shared unchanged between the PC and Dreamcast versions. A 26-frame side-by-side comparison came back pixel-for-pixel identical.
• I built a 60 fps mode, measured it, and shipped it turned off. It worked — but side by side it looked worse than the original 20 fps, so it isn't the default.

The most complete of these projects, and a genuine community effort. It starts from bruddog's painstaking reverse-engineering of the 1991 original and sblueman's 2026 roster mod, and rebuilds them to run natively on three modern platforms. Everything the NES used to do — graphics, sound, the cartridge's memory switching, battery saves — is rewritten from scratch. On top of that sit features the 1991 game never had: two-point conversions, a widescreen field, a TV-broadcast presentation layer, real weather drawn from thirty years of records, roster and team editors, and online play.

• Correctness was proven, not assumed. 200 million steps were run side by side against an independent reference with zero differences, plus an 8,200-frame scripted playthrough — kickoff to touchdown — reproducing identical frames every time.
• The Game Boy Advance version went from 27 to 43 frames per second over four rounds of optimisation on hardware from 2001 with a fraction of a modern phone's power.
• The NES's notorious flicker is gone. The original console could only draw eight players per row, so linemen visibly vanished. Players disappearing during a down went from 1,875 occurrences to zero.
• It plays the Super Nintendo version's actual music — a second sound system was built inside an NES game to run the real sequence data.
• The broadcast graphics were measured, not eyeballed: the first-down line lands within two pixels on 98.6% of checks, and 25,373 down-and-distance comparisons found zero disagreements.
• The 1991 rosters were verified against an original cartridge — 8,232 individual fields, no differences.

This starts from the NFL Blitz 2026 Signature Edition, a community mod of the Nintendo 64 original, and it was the hardest of these to even begin. Most projects like this have a map of the program — a list of where everything lives. This cartridge has none. There is just raw machine code with no labels at all, so the first job was writing a tool to work out where each routine starts and what it does. It now starts up, manages its own tasks and produces drawing instructions — but those instructions are currently counted and thrown away, so nothing appears on screen yet.

• The entire game froze, and one unnamed routine was responsible. Every task was waiting for a message. The culprit was a data transfer that never completed, with everything else queued behind it.
• I found a bug in the underlying runtime itself where a list of tasks could point at itself — four million bogus entries before a guard fixed it.
• 61 system routines identified purely by reading raw code, with no labels to work from — covering graphics, sound, controllers and task management.
• Two fixes worth sending back upstream to the tools this is built on.
• Confirmed the 30 fps cap is a design decision, not a limitation — doubling the underlying rate still produced exactly 30.

The newest of these, and a clear illustration that "it runs" and "it plays" are two different milestones. It starts up, loads the real game over its own launcher, and reaches the main game loop running steadily at the correct speed without crashing — and then waits forever on a single job that nothing ever picks up.

• The port was deadlocking against itself. My version only advanced its internal clock when the game asked it to — and this particular game waits for the clock without ever asking. Fixed by driving the clock independently.
• One function did nothing at all. The routine responsible for switching between tasks was an empty placeholder, so no task the game created had ever actually run — and this game runs its entire main loop inside one.
• A tiny misalignment made every instruction wrong. The translator was reading the file's header as if it were program code. Every result looked plausible and every one was incorrect.
• I built three custom debugging tools to find the remaining fault, and they proved the stalled component is never being reached at all — a precisely located problem rather than a vague one.

A Sega CD game is two processors working together — the Genesis underneath and the CD add-on on top — sharing memory and constantly negotiating over who gets to use it. The interesting result here is an engineering one: adding support for the second processor cost almost nothing, because the same translator serves both. That's the entire argument for building it this way.

• Getting memory sharing right was the gate to the first picture. Before it, the screen was black; after it, the game was writing sixty thousand bytes of graphics data.
• One mistake was hiding in every instruction of a certain type. A whole class of operations was updating memory addresses twice and writing to the wrong place. Fixing it in eight places took an internal failure count from 17 to zero and unblocked character select.
• The intro looped forever because two different chunks of the game load into the same place and were being confused for each other.

The opposite problem from the projects above. Here the game's code isn't known in advance, so it has to be translated while the game is running, on a console from 1999 with a fraction of a modern PC's power. The inspiration is Bleemcast! — Randy Linden's remarkable 2000 proof that this is possible at all. This is the project I learned the most from and the one furthest from finished.

• Taken through seven rounds of optimisation and proven to produce byte-identical results to a slow-but-correct reference, on real Dreamcast hardware.
• The main loop went from 32 instructions to 11 — a five-fold speedup — and the number of expensive round-trips dropped by a factor of 667.
• Rendering revealed a genuine hardware quirk that documentation had wrong.
• Reverse-engineered the arcade board's sound processor from documentation and reference code, and got the original sound driver running.

FOOTSIES is hifight's free fighting game, made for practising spacing and timing. This isn't a translation like the projects above — it's a complete rewrite of the game's engine, with every timing value pulled directly out of the original so the feel is identical. Then taken to seven consoles, several of which predate the original by decades. Original game by hifight; ports by me.

• A pixel-exact debug view reproducing the original's collision display — which is also how the timing was verified rather than assumed.
• A best-of-five ladder, guard meter, one-hit-kill specials and a practice mode.
• Original additions not in hifight's version: a projectile, a glide and a parry.