Why can't Mario go backwards?

Super Mario Bros. scrolls in one direction and one direction only. There’s a reason for that, and understanding why tells you something specific about how the NES rendered anything at all.

The NES graphics system is built around a component called the PPU, or Picture Processing Unit, and the PPU maintains two nametables in its own dedicated memory. A nametable is a 32×30 grid of tile indices, each index pointing to an 8×8 pixel tile in the cartridge’s character ROM. Two nametables gives you two screens worth of tile layout, and the PPU can scroll smoothly between them by adjusting a single register. This is how Super Mario Bros. draws its levels: one nametable holds the currently visible screen, the other is the staging area where new tiles are being written just offscreen, one column at a time, as you move right.

That last part is the key constraint. The CPU is writing new tiles into the offscreen nametable continuously, just fast enough to stay ahead of where you’re looking. It’s not reading from some complete map in RAM. The level data is stored as a compressed stream in ROM, read forward sequentially and decoded on the fly. Tiles get placed, you scroll past them, and the memory they occupied gets recycled for the next column. The pipeline only runs in one direction because the data source only runs in one direction.

Reversing that would require the game to either store the entire decoded level in RAM, which at 2 KB total system RAM is not happening, or re-read and re-decode the ROM stream from an earlier point, which means tracking your exact position in the stream, seeking backward, and redrawing everything that was previously on screen, including any changes you made to it, like broken bricks, collected coins, and cleared enemies. None of that state is preserved once it leaves the active window, because there’s nowhere to put it. The game tracks what’s currently on screen. What’s behind you isn’t on screen, so from the game’s perspective, it’s not anywhere.

This is also why the left edge of the screen is a hard wall in Mario but not the right. Moving right just means the camera follows you. Moving left would mean asking the game to reconstruct something it already threw away.

The PPU’s nametable setup contributed another wrinkle. The NES only had enough VRAM for two nametables, but the address space was laid out for four. The remaining two were either mirrored from the existing ones or, on cartridges with extra VRAM chips, actually populated. Super Mario Bros. used horizontal mirroring, which was appropriate for a horizontally scrolling game. The mapper didn’t need to do anything exotic because the scroll direction was always the same and the nametable arrangement matched it perfectly. Adding bidirectional scrolling would have required rethinking the entire mirroring setup, not just the scroll logic.

Later Mario games solved pieces of this with better hardware. Super Mario Bros. 3 used the MMC3 mapper, which supported four-way scrolling and gave the game more control over how the PPU addressed tile data. Some levels scroll vertically, some have large open areas, and the mapper handles the nametable switching underneath. Super Mario World on the SNES had 128 KB of RAM and a much more capable graphics system, which meant level data could be structured to support arbitrary movement within a loaded area.

The one-way pipeline was a product of specific constraints, but the design instinct it created outlasted the constraint. Forward momentum as the core mechanic, the idea that progress means moving right and the past is gone, became so central to how platformers feel that later games kept it voluntarily. Auto-scrolling levels, one-way doors, chase sequences that prevent backtracking: these exist in games with plenty of RAM to track world state, built by developers who could have allowed backward movement if they’d wanted to. The hardware made the rule first. The designers decided they liked it.