AI Helped Me Reverse Engineer a Nintendo Game

When I was a kid, I played a game called Super Uwol on a friend's Nintendo. A little character jumping between platforms, dodging enemies, grabbing coins. Nothing fancy. The kind of game that lived in the back of your brain for twenty years, quietly refusing to leave.

Last month, I decided to see if I could take the actual game cartridge -- well, the ROM file -- and figure out how it worked. No source code. No documentation. Just a binary blob of ones and zeros, the way the Nintendo's processor saw it.

Then I asked AI to help me make sense of what I found.

We rebuilt the game from scratch. Ninety-one percent accuracy. The same jump arcs, the same gravity, the same enemy patrol paths. All extracted from raw bytes that no human had documented.

Here is how that happened, what AI actually contributed, and why it matters beyond a nerdy weekend project.

The Starting Point: A Binary Blob

A Nintendo cartridge ROM is a .nes file. It contains everything -- the game's code, its graphics, its level layouts, its physics rules -- packed into a single binary. No labels. No comments. No variable names. Just bytes.

The CPU inside a Nintendo is a 6502 processor. Same chip that powered the Apple II and the Commodore 64. Eight-bit. Fifty-six instructions. Three registers. Simple enough that a person can read the assembly language one instruction at a time.

The problem is not complexity. It is volume. Thousands of lines of assembly with no map and no legend. Figuring out which bytes are game code and which bytes are sprite graphics or level data or music -- that is the real challenge.

I started by building a disassembler from scratch. A disassembler takes raw machine code and translates it back into assembly language -- the human-readable version of what the CPU executes. I built it by hand in Python, not because good disassemblers don't exist, but because building one forces you to understand how the hardware actually works.

The first useful foothold: the Nintendo has an interrupt vector table at the very end of the ROM. Three addresses that tell you where the code entry points are. From there, you follow every jump instruction. Each one leads to more code. Slowly, a map of the program emerges from the noise.

Where AI Changed the Game

After the disassembler did its job, I had thousands of lines of 6502 assembly. Anonymous addresses. No comments. Just opcodes and hex values.

This is where I started working with Claude -- Anthropic's AI -- and later Claude Code, their command-line tool for working directly with code.

I would paste a block of assembly and ask a simple question: "What does this routine do?"

The AI looked at a loop that loads a value from a memory address, adds 2 to it every frame, caps it at 8, then adds it to a Y-position value. Its response: "This is a gravity routine. Acceleration with terminal velocity, applied to vertical position."

It was right. In about twelve instructions, the game's entire gravity system was sitting there. Acceleration, terminal velocity, position update -- the core physics of a platformer.

Once we found the physics engine, the constants fell out. Nine of them, each sitting at a specific memory address in the ROM.

Gravity acceleration -- how fast you fall. Jump velocity -- how high you go. Terminal velocity -- the maximum fall speed. Horizontal friction. Movement speed. Platform collision threshold. Enemy bounce velocity. Invincibility frames after getting hit. Coin pickup radius.

AI helped identify which addresses were constants versus variables by looking at how they were used. Constants are loaded but never written to -- the game reads them but never changes them. Variables get updated every frame. That distinction, across thousands of lines of assembly, is exactly the kind of pattern recognition that AI handles well.

Cracking the Level Data

Nintendo games store their levels as grids of tile indices. Each byte in the grid references a tile from a pattern table -- wall, platform, empty space, hazard. The challenge is figuring out where each room starts and ends in the ROM, how wide and tall the grid is, and which tile numbers mean what.

I fed chunks of the ROM to Claude and asked it to look for patterns. It spotted the repeating structure -- each room had a consistent header format, followed by a grid of bytes that mapped to a visual layout. Fifty-five rooms decoded.

Then the enemy AI. Three behavior types: patrol -- walk back and forth between two boundary points. Chase -- move toward the player when within a detection radius. Stationary -- fixed position, acts as an obstacle. Each enemy has a behavior byte, a starting position, and a movement boundary.

Nothing sophisticated. But it is the complete enemy system, extracted entirely from bytes with no documentation.

The Rebuild

With the extracted data -- nine physics constants, fifty-five room layouts, three enemy behavior types -- I rebuilt the game in Python using pygame. 3,582 lines of code total, counting the disassembler and the game itself.

The physics engine uses the exact constants from the ROM. Not approximations -- the actual byte values from the cartridge. Same gravity. Same jump height. Same friction. Same terminal velocity.

The acid test was playing both games side by side. The original NES ROM running in an emulator on the left. The Python rebuild on the right. Same room. Same starting position.

Jump in both -- the arcs match. Walk into an enemy -- same bounce behavior. Navigate to a deeper room -- the layout matches tile for tile.

Ninety-one percent accuracy.

The nine percent gap comes from edge cases. The Nintendo uses hardware sprites with pixel-level bounding boxes, which behave differently from pygame's rectangle-based collision detection. The NES runs at approximately 60.1 frames per second, and pygame's clock has slight drift. Some enemy chase trigger distances are off by a pixel or two.

The gap is in rendering details, not in understanding. The physics model is correct. The level data is exact. The enemy behaviors match.

What AI Actually Did -- And What It Did Not

Let me be honest about this, because the internet has a bad habit of either overhyping AI or dismissing it entirely. The truth is more useful than either extreme.

What AI did well: pattern recognition. It was genuinely good at looking at blocks of assembly language and identifying what they do. Loops, conditionals, subroutine boundaries -- it could pick these out faster than I could. It named things. It turned anonymous memory address $0410 into "gravity_accel." It spotted the physics engine structure when I was still looking at it as disconnected routines.

It was also fast at generating the pygame scaffold -- the game loop, sprite rendering, input handling. Boilerplate that would have taken me a day took about an hour. And it served as a hardware reference manual. Instead of looking up NES details in documentation, I could ask and get accurate answers in seconds.

What AI did not do: it did not build the disassembler. I wrote that by hand. It could not distinguish code from data in the ROM -- that required manual analysis of interrupt vectors and jump tables. And it made mistakes. Early on, it misidentified a lookup table as a subroutine. It hallucinated a "sound engine" in a section of the ROM that was actually tilemap data. Every claim it made had to be verified against the actual behavior of the game.

The accuracy verification -- playing both games side by side, comparing frame by frame -- was entirely manual.

AI was a force multiplier, not a replacement. It turned what would have been a multi-week project into a multi-day project. But it could not have done any of it without the disassembler, the hardware knowledge, and someone who knew which questions to ask.

Why This Matters for Your Business

This is the part where a story about a Nintendo game becomes relevant to the plumber in Asheville or the property manager in Hendersonville.

Every business has legacy systems. Maybe it is not a Nintendo cartridge. Maybe it is a fifteen-year-old Access database that nobody remembers how to modify. A custom invoicing system built by a developer who retired in 2018. A spreadsheet with macros that somehow runs the entire scheduling operation and nobody dares touch it.

These systems have the same fundamental problem as that ROM file. They work, but nobody fully understands how. The documentation is gone -- or never existed. The original developer is unavailable. The code is a black box.

AI is remarkably good at reading old code and explaining what it does. Not perfectly -- you still need a human who knows the right questions to ask. But the combination of AI pattern recognition and human judgment can crack open systems that have been impenetrable for years.

We used AI to extract physics constants from a twenty-nine-year-old game cartridge. The same approach works on a Visual Basic application from 2009. Or a PHP website from 2014. Or a custom ERP system that your business depends on but nobody can modify.

The specific technique varies. The principle does not. AI reads the code. A human asks the right questions. Together, they build understanding that did not exist before.

The Honest Takeaway

AI did not reverse engineer a Nintendo game by itself. It accelerated the work by roughly five times. It handled the tedious parts -- reading thousands of lines of assembly, identifying patterns, cross-referencing hardware documentation -- while a human handled the judgment calls.

That ratio -- five times faster, but still requiring human expertise -- is roughly what we see across every AI project we work on. Not magic. Not useless. A very good assistant that makes hard problems approachable and slow problems fast.

If you have old systems that nobody understands, old code that nobody can modify, or old processes that nobody has documented -- that is the same problem we solved with a Nintendo cartridge. The tools exist. The approach works.

You just need someone who knows which questions to ask.

---

Blue Octopus Technology helps businesses understand and modernize their legacy systems. If you have technology that works but nobody can explain, let's talk.