You’ve Never Actually Played All of Super Mario Bros. Nobody Has.

You think you know Super Mario Bros. You’ve beaten Bowser, found the warp zones, maybe even pulled off the minus world glitch. You’ve seen it all.

You haven’t. Not even close.

Buried inside the NES cartridge you grew up with is code that has never executed in the lifetime of the game. Not because it’s broken. Not because it’s unreachable. But because the only way to trigger it is to play the game in a way no human reasonably would — forcing inputs so precise, so absurd, that the game’s own logic starts to unravel. And when you finally force that code to run, you discover something unsettling: the game you thought you knew was never a fixed thing. It was a negotiation.

Code doesn’t run. Code is given permission to run — by hardware, by timing, and by you.

Here’s what most people get wrong about how games work. We imagine code as a script, a movie that plays from beginning to end. Press start, the code runs. Jump, the jump function fires. It feels linear because that’s how we experience it as players. But underneath, Super Mario Bros. is a labyrinth of conditional branches — thousands of tiny forks in the road, each one dependent on a specific combination of button inputs, frame timings, enemy positions, and hardware states.

The NES doesn’t execute code. It responds to chaos.

Every frame — sixty times a second — the game checks: Where is Mario? What’s on screen? What buttons are pressed? Then it picks a path through the code. Most paths are well-trodden. You jump, you run, you die, you try again. But some paths are so narrow, so contingent on absurd combinations of events, that they might as well be sealed behind a locked door in a room nobody enters.

Except the door isn’t locked. You just have to knock in a way that makes no sense.

Speedrunners and tool-assisted creators have been knocking for years. By feeding frame-perfect inputs into emulators, they’ve forced the game into states the developers never imagined — corrupting memory, skipping entire levels, even reprogramming the game on the fly. And in doing so, they’ve stumbled into code routines that were always there, waiting, like rooms in a house that were built but never furnished.

The most interesting code in any game is the code nobody was supposed to see.

This is where it gets philosophical, and I’m going to take a side here because neutrality would be a disservice: the idea that a game’s code is a complete, static artifact is a lie we tell ourselves to feel in control. In reality, a game only exists in the moment of its execution. The cartridge on your shelf isn’t Super Mario Bros. — it’s a possibility space. The actual game is the specific path through that space that gets carved out each time someone plays.

Think about what that means for code coverage — the practice, sacred in software engineering, of ensuring every line of code gets tested. In a modern web app, you can write tests that methodically exercise every branch. In Super Mario Bros., reaching certain branches requires inputs so precise that no human could reproduce them without machine assistance. The code is reachable in theory. In practice, it’s a ghost.

And here’s the twist that should make every developer uncomfortable: your codebase probably has the same problem. Not because your tests are bad, but because code coverage measures whether a line was touched, not whether it was touched under the conditions that matter. A line that runs in a test harness and the same line running under production load with real user inputs are not the same event. They’re not even the same code, functionally speaking.

Code coverage tells you what was visited. It never tells you what was lived.

The NES hardware makes this even more fascinating. The developers at Nintendo in 1985 were working with 2 kilobytes of RAM and a processor that could barely tie its own shoes. Every byte mattered. They reused memory addresses for multiple purposes. They relied on hardware quirks — the way the PPU renders sprites, the timing of the NMI interrupt — as features, not bugs. The code is so tightly coupled to the hardware that you can’t really understand it without understanding the machine it runs on.

This is something modern developers have largely forgotten. We abstract away hardware. We write code that runs on containers that run on virtual machines that run on hypervisors that run on chips we’ll never touch. And we’ve gained enormous productivity from that abstraction. But we’ve lost something too — the understanding that code is not a pure logical artifact. It’s a physical event, dependent on the silicon it runs on, the timing of its execution, and the unpredictable chaos of the world it interacts with.

Super Mario Bros. reminds us because it can’t hide from its own hardware. Every quirk is visible. Every shortcut is a story. Every unreachable branch is a secret the machine keeps until someone is obsessive enough to force it open.

So can you run every line of code in Super Mario Bros.? Theoretically, yes. With enough patience, enough tooling, enough frame-perfect inputs, you could probably force every conditional branch to fire at least once. But that misses the point.

The question was never whether the code can run. The question is whether running it means anything — and the answer is that meaning only exists in the space between the code and the player stupid enough to find it.

The next time you boot up an old game, remember: you’re not playing a finished product. You’re collaborating with a machine that has secrets it’s waiting to share. Most players will never find them. That’s fine. The code doesn’t care. It just waits, frame after frame, for someone to ask the right question in the right way.

And somewhere, in a branch that’s never been taken, there’s a line of code that’s been running in silence for forty years — not because it was executed, but because it was possible.

That’s not a bug. That’s poetry.