How the Game Genie Worked: Hardware-Level Memory Injection Explained

A plastic brick sat between your cartridge and your console, watched the processor ask the game for a byte, and answered before the cartridge could. That is the whole trick, and it took a lawsuit to keep it legal.

Published by Andrew B. · updated 12 Oct 2026

A processor does not know what a game is. It knows that at a certain moment it needs the byte stored at a certain address, and it puts that address on a bundle of wires and waits for something to put a byte back. On a cartridge console, the thing that answers is the cartridge.

The Game Genie's entire design follows from one observation: nothing in that arrangement checks who answered.

What Was the Game Genie? The Ultimate Cheat Device

The Era of Impossible Games and Playground Rumors

The late-1980s cartridge game was a fixed object. There were no patches, no difficulty sliders added later, no way to tell the developer that the sixth level was unfair. A game shipped at whatever difficulty the publisher chose, often tuned to keep arcade-style quarters flowing or to make eight hours of content last a rental weekend.

What filled the gap was rumour. Codes passed around schoolyards, half of them invented, and a magazine tip section that could not verify much of what it printed. Plenty of players were looking for something that did not exist in the game at all.

Galoob's Promise: Rewriting the Rules of Play

The device that answered was developed by Codemasters, the British studio, and sold in the United States by Lewis Galoob Toys and in Canada by Camerica. The NES version arrived in 1990 — announced in May, with a July launch planned — and versions for the Super NES, Game Boy, Mega Drive/Genesis and Game Gear followed.

The promise on the box was infinite lives, infinite time, start on level five. The mechanism behind it was narrower and stranger than the marketing suggested: the Game Genie could not give you anything. It could only change a number the game was about to read, and hope that number meant what the code author thought it meant.

The Man in the Middle: Hardware Architecture of the Game Genie

The Cartridge Passthrough Mechanism

Physically the NES Game Genie is a pass-through with a 72-pin connector on each side: one accepts the game cartridge, the other plugs into the console. Every line the console would have sent to the cartridge now goes through the Genie first.

That matters for a reason people often get wrong. The Genie is not a replacement cartridge and it is not an emulator. The real game is still in the machine, still supplying almost every byte the processor asks for. The device is a filter on a conversation that is otherwise untouched.

The Boot ROM and the Code Entry Sequence

Power on with a Genie installed and you do not get the game, you get the Genie's own menu. It manages this by presenting its own 4 KiB program ROM at $C000–$FFFF, mirrored four times, with $8000–$BFFF left as open bus. As far as the console is concerned, that little ROM *is* the cartridge.

The menu's graphics are a nice piece of corner-cutting: rather than carrying real character ROM, the device generates pattern data from a handful of PPU address lines (A2 and A4–A7), which yields sixteen distinct shapes — enough to draw letters and a box, and nothing more.

When you press Start, the code-entry program writes your codes into the device's own registers — address high, address low, compare, replace, three sets of them — and then writes a value with bit 0 set to $8000, which flips the device into game mode. The second write, a plain $00, passes through to the cartridge. From then on the Genie accepts no further configuration: it stays in game mode until the console is power-cycled.

Halting the CPU vs. Intercepting the Bus

This is the part worth being precise about, because it is what separates the Game Genie from everything that came after it.

The Genie never interrupts the processor. It does not pause the game, it does not run code of its own alongside the game, it does not have a timer that fires and rewrites memory. Once it is in game mode it is a purely reactive piece of logic sitting on the bus: it watches CPU reads in the $8000–$FFFF range, and for up to three addresses it has been given, it answers with its own byte instead of letting the cartridge answer.

Later devices worked the other way round. Action Replay units of the same era paused the running program, captured its memory state and let you edit it in that frozen state. That approach can reach anything in RAM, but it needs execution time and a way to take control. The Genie needed neither, which is why it is a brick with no buttons.

The Mechanics of On-the-Fly Byte Substitution

Decoding the Cipher: Translating Letters to Hexadecimal

Game Genie codes are not words, and the letters are not arbitrary. The NES version uses a sixteen-letter alphabet in which each letter stands for one hexadecimal digit — four bits:

Sixteen letters, sixteen values, printable in a magazine and pronounceable down a phone line. A six-letter code is therefore 24 bits of payload; an eight-letter code is 32.

Those bits are not laid out in reading order. They are scrambled across a fixed map, so bits of the address and bits of the data interleave — bit 3 of the third letter, for instance, is not data at all; it signals whether the code is six letters or eight. The scrambling has no security purpose. It makes a one-character typo produce a wrong code rather than a nearly-right one, and it stops the codes from looking like the plain hex they are.

Address, Value, and Compare: The Three Pillars of a Cheat Code

Unscrambled, a six-letter NES code is two things: a 15-bit address and an 8-bit value. Take SXIOPO, the infinite-lives code for Super Mario Bros. It decodes to the value ADh at address 11D9h, which in the processor's own terms is 91D9h — the documentation notes you add 8000h, because the device only ever intercepts the upper half of the address space.

An eight-letter code adds a third field, an 8-bit compare value, and changes the rule. The substitution now happens only if the byte already at that address matches the compare; otherwise the cartridge's own byte is passed through untouched.

That third field exists because of bank switching. Larger games map different chunks of ROM into the same address window at different times, so address 91D9h might hold the lives counter during gameplay and something else entirely on the title screen. The compare byte lets a code say: patch this address, but only when what is there is what I expect.

Hijacking the Data Bus: Reading from ROM vs. Reading from Game Genie

Here is the limit that defines what Game Genie codes can and cannot do: the Genie patches reads from ROM. It cannot write to RAM.

Your lives counter lives in RAM. The Genie cannot touch it. What it can touch is the game's own code, which lives in ROM, and the constants in that code. So a working code almost never says "set lives to 9". It says "the instruction that subtracts a life now subtracts zero", or "the byte the game copies into the lives counter at startup is now 9 instead of 3".

The EnHacklopedia's Metroid example makes it concrete. The missile counter sits in RAM at $6879, which no Genie code can reach. The instruction that decrements it, DEC $6879, sits in ROM at $D333. Change the operand byte at $D334 and the instruction decrements a harmless unused RAM address instead. The counter never moves — not because the Genie protected it, but because the game stopped being able to find it.

This is also why some codes have side effects that look like bugs. You are not editing a cheat menu. You are editing the program.

Architecture Differences: 8-Bit vs. 16-Bit Implementation

The NES Approach: Bypassing the Lockout Chip (10NES)

The common assumption is that the Game Genie had to defeat Nintendo's 10NES lockout, the way unlicensed publishers did. It did not, and the reason is structural.

The 10NES system is a handshake between two chips: a "lock" in the console and a matching "key" in the cartridge. Fail it and the console's CIC resets the processor about once a second, which is the blinking screen everyone remembers. Unlicensed cartridges had to get around that somehow — a voltage spike to stun the chip, a dongle that borrowed the key from a genuine cartridge, or Tengen's reverse-engineered Rabbit chip, which Nintendo sued over.

The Game Genie never had that problem, because the genuine cartridge is still plugged into the machine, and its key chip is still connected. Nintendo's own authentication authenticated the game it was supposed to authenticate. Documentation of the device's behaviour describes bus interception, a boot ROM and three sets of registers — and no lockout handling at all, because there was nothing to handle. Codemasters did not have to crack the lock. They stood behind someone who had the key.

The Sega Genesis Approach: Handling the Motorola 68000

The Mega Drive version faced a different machine. The Motorola 68000 is a 16-bit processor with a 24-bit address space, and it fetches a 16-bit word at a time, not a byte.

The code format follows the hardware exactly. A Genesis code is eight characters with a hyphen after the fourth — SCRA-BJX0 — drawn from a 32-symbol alphabet: the ten digits and twenty-two letters, with I, O, Q and U left out so that nobody mistakes a letter O for a zero. Thirty-two symbols means five bits each, and eight of them give 40 bits, which split into a 24-bit address and a 16-bit value. Decode that example and you get address 009C76h, value 5478h.

So where an NES code replaces one byte in a 32 KB window, a Genesis code replaces a full word anywhere in the 68000's address space. There is no compare field: the wider address means far less of the bank-switching ambiguity that made the NES's eight-letter codes necessary.

That extra reach had a side effect the marketing was happy to mention: because region locking on the Mega Drive was partly a matter of a few bytes in the cartridge header, the same byte-substitution trick could make an import run.

Pin Limitations and Hardware Revisions

A device that sits inside the bus is at the mercy of every signal it ignores.

• Three codes on the NES, and no more. The hardware has three address comparators. Enter two codes that target the same address with different values and only the first is enabled, because the comparison logic is asynchronous.
• Bus conflicts. If a code targets $C020–$FFFF while the cartridge also maps something at $4020–$7FFF, the Genie holds the cartridge's /ROMSEL line high, the cartridge may answer the read anyway, and two devices drive the data bus at once. At least one Legend of Zelda code depends on exactly that behaviour and crashes in emulators that do not reproduce it.
• Lines it never watched. Cartridges that decode character ROM using only PPU /A13, such as the MMC5 board, can scramble the Genie's own menu, because the device ignores that line.
• Pins it never wired. On the Super NES the Genie is incompatible with Star Fox and Super Mario RPG, which use cartridge pins that most titles left unused. Two NES hardware revisions exist — an ASIC with a separate 4 kB ROM, then a single epoxy blob doing both jobs — and three SNES versions that look identical from the outside.

Galoob vs. Nintendo: The Legal Battle Over Game States

Nintendo's Argument: Unauthorized Derivative Works

Codemasters and Galoob did not wait to be sued. On 17 May 1990 they went to the Northern District of California asking for a declaration that the Game Genie infringed nothing. Nintendo counterclaimed and asked the court to stop the device altogether.

Its argument was copyright's derivative-work right. A game under a Game Genie produces an audiovisual display Nintendo never authorised; that display is built out of Nintendo's work; therefore the device manufactures infringing derivative works, and Galoob encourages every buyer to make one.

It worked at first. On 2 July 1990 the court granted a preliminary injunction and the Game Genie came off American shelves — while sales continued in Canada. Nintendo posted a bond against the injunction, initially $100,000, later raised to $15 million.

Galoob's Defense: Fair Use and Temporary Memory Modification

Galoob's answer was that nothing is altered. The cartridge goes home unchanged. The Genie stores nothing, copies nothing and leaves nothing behind; switch the console off and every trace of it is gone.

At trial in 1991, Judge Fern M. Smith agreed. Her ruling of 12 July 1991 compared the device to skipping pages in a book or fast-forwarding a film, and held that players may "create new variations of play, for personal enjoyment" without creating a derivative work. She ruled in the alternative that even if it were infringement, it was fair use. The injunction lifted.

The bond then came due. At a December 1991 hearing the court found Galoob's losses exceeded $15 million, and Galoob collected the full amount plus legal fees — one of the more expensive preliminary injunctions in the industry's history.

The 9th Circuit Ruling and Its Impact on Modding

The Ninth Circuit affirmed on 21 May 1992. Its reasoning is the part that outlived the device: a derivative work has to exist in a "concrete or permanent form", and the display a Game Genie produces does not. It is a momentary state of a machine, not a thing that was made.

On fair use the court looked hardest at market harm and found none — the use was non-commercial, Nintendo showed no economic damage, and the device could not substitute for the game because you had to own the game to use it. Galoob was not a direct infringer and was not liable for what its customers did either. The Supreme Court declined to take the case in 1993, and Nintendo's appeal of the $15 million bond award failed too.

That holding is the quiet foundation under a great deal of what came later: trainers, memory editors, emulator cheat systems, and the general principle that changing how software behaves on your own machine, without fixing that change in a copy, is not the same as copying it.

The Legacy of Hardware Patching

From Physical Intercepts to Software Emulation (RAM Patching)

The hardware died; the idea did not. Two descendants split the difference.

The first is the RAM-writing cheat device. GameShark and Action Replay units did what the Genie structurally could not: reach into working memory and change the lives counter itself, rather than the instruction that touches it. That is why their codes read as plain address-and-value pairs, and it is the format the handheld-era guides still use — the GameShark and Action Replay codes for Pokémon Emerald or FireRed are addresses in RAM, not patched ROM reads.

The second is emulation. An emulator already decides what byte to hand its virtual processor, so a Game Genie code is a two-line feature: decode the letters, add 8000h to the address, and intercept the read. Thirty-year-old codes printed in magazines still work, because the specification they were written against is a documented text file rather than a secret.

Why Modern Consoles Killed the "Hardware Genie" Approach

Nothing about the legal position changed. The machine did.

A Game Genie needs three conditions, and a current console breaks all three. It needs a bus between the game and the processor that you can physically get into; games now load from a disc or a download into RAM, and there is no socket in the middle. It needs the game's code to sit at fixed, predictable addresses in a memory-mapped ROM; modern code is relocated, patched over the network, and different next week. And it needs a system that does not care who answered; current consoles verify what they run and refuse unsigned hardware outright.

The industry made the last point explicitly. Later DSi and 3DS firmware updates stopped older Action Replay units booting at all, and Wii firmware blocked the GameCube version in GameCube mode. What survives of the category are products that edit your save file rather than the running game — a category that exists precisely because the running game is no longer reachable.

So the Game Genie belongs to a specific hardware moment: wide enough open for a third party to step into the conversation, early enough that nobody had thought to ask who was answering. Of the 164 game guides on this site, the ones carrying cheat-device codes are all from that window and the handheld years just after it — and the built-in cheats and console commands that replaced them are, in the end, the same idea with the developer's permission.

If you want the longer arc — how codes went from debug tools to button sequences to paid XP boosters — that is the history of cheat codes.