I bought one of these recently, and it's amazing how powerful it is given that it's a toy. It sits on the bus between the CPU and the cartridge, so you effectively get to change up to three bytes of program text / rodata* on the fly.
My favourite code is ANTOSA. This is a code for Super Mario Bros. which turns all pipes you can't enter upside-down. SMB1 has been disassembled with commentary, so it's now possible to see how the code works. It turns out there is a table of blocks for the top two layers of both non-warp and warp pipes, that looks like this:
VerticalPipeData
98dd: 11 10 .bulk $11,$10 ;used by pipes that lead somewhere
98df: 15 14 .bulk $15,$14
98e1: 13 12 .bulk $13,$12 ;used by decoration pipes
98e3: 15 14 .bulk $15,$14
The code to draw the pipes gets this address of this table and stores it in the Y register. Then, if the pipe isn't a warp pipe, it executes 4 INY (increment Y) instructions in a row to adjust the offset.
The ANTOSA code just replaces two of the INY instructions with a two-byte BVS (Branch on Overflow Set) instruction. However, the Overflow flag is never set at this point, so effectively this instruction is a two-byte no-op.
The practical upshot is that Y is only incremented by 2, which means it points two bytes inside the "pipes that lead somewhere" data rather than directly at the "used by decoration pipes" data. It turns out that the first two bytes determine the top of the pipe, and the second two bytes determine the second layer, so decoration pipes are effectively drawn (second layer, top layer). And voila -- "upside down" non-warp pipes.
If it was intentional, it was very clever. But I suspect it wasn't -- BVS is an odd choice for a two-byte NOP! An alternative would be change one of the INYs to a DEY (decrement Y), producing the functionally-equivalent codes EETOKX, EETOSX, EETOVX or EETONX, depending on which INY you change. I admit ANTOSA sounds cooler.
The Game Genie decoder at https://games.technoplaza.net/ggencoder/js/ claims that ANTOSA means, "Overwrite $18ED with 0x70". 0x70 is indeed BVS, but how does that address (or its endian-corrected $ED18) correspond to any INY instructions in the disassembly?
There is a guy on Youtube called "Displaced Gamers" that explains how NES games work. There is an interesting episode where he breaks down how a certain item in the game Faxanadu behaves.
It's a pendant that is supposed to increase your attack power, but when you get it does the opposite. In the video he explains exactly what is going on in the code: the game was shipped with a bug.
He then goes about crafting a Game Genie code to fix the bug. It's a fascinating video:
It's impressive how much of those patches are NOPing out code bloat. An enterprising hacker could probably do some interesting stuff with the space freed up just fixing the bugs.
It was watching the recently-HN'ed Displaced Gamers video on Super Mario's warp zones that actually got me curious about how the Game Genie codes were encoded :)
I'm definitely going to go through his past videos - looks like so much interesting stuff in there.
How were the original codes collected? I assumed the devs themselves were somehow involved in the process? But then I read the Wikipedia article and it outlines how Nintendo tried to shut it down, so that seems unlikely. I guess the manufacturers really just manually sat down and figured them all out on their own... pretty crazy.
> The process of searching for working codes would have been slow and tedious, though as Menzies explains, the team came up with little tricks to speed things up. "I wired up a Commodore 64 to control a prototype Game Genie using a pop-up utility on the Commodore, so we could type codes directly in hex, which was a big improvement over using the NES controller. Also we managed to daisy-chain two Game Genies so we could enter up to six codes at once, which sped things up a bit. [...]
> "It wasn't very glamorous," adds Rigby. "And it took about three days to go through a game, sometimes longer for some of the popular RPGs. The thing I remember most was the very first dev kit; it was a few rows of switches soldered onto the top of a black 5.25-inch floppy disk box. They were binary switches and you had to flick the position to 0 or 1 to represent the address and the value you wanted to change to." [...]
When I was a kid I had a game genie on the NES and Genesis, and a GameShark on the PSX. The Genesis one in particular (well maybe it was the GameShark, memory from that long ago is a bit fuzzy) had a VHS that explained how to make your own cheat codes. There were basically tools in the device that let you snapshot the memory at a specific point in time, then you could do an action, and get essentially a diff between the snapshots. By seeing what values changed, you could figure out what codes to set. The easiest was always infinite lives - snapshot, then kill yourself, and compare what changed. Do it a few times and you'll find the address for the life counter, so you'd set that to 99 and try it out til you got the right code and locked the value at 99.
The device really was cool as shit, it was my first introduction into doing anything with computers really, I spent hours creating my own codes as a kid.
IIRC cheat codes were often published in popular gaming magazines as well, which is how you found most of them in the world before widespread Internet & PC access. I'd assume that either manufacturers or some other party found common codes manually via similar methods to this.
Oh man I remember that “make your own GG codes” tutorial tape. My nerdy preteen self spent many hours making my own (usually terrible) cheat codes and bragging about them at the lunch table the next day. Thinking back on it, half the codes were dumb stuff like “turn Sonic red” that probably would have a been a big hit if the modern Sonic fandom existed back in the 90s.
I hit my apex a few years later in the n64 era when a few games started to leave in cut content or beta stuff. Gamesharking cut content back into Goldeneye and Banjo Kazooie blew the other kids’ minds back then.
Funnily enough, a few years ago I found myself using Cheat Engine to skip a grindy part of a game - and it turned out that the code hunting skills from my childhood transferred perfectly. The exact same techniques from that old VHS tape applied, all wrapped up in a modern GUI.
Pure speculation on my part about how they did it back then, but nowadays one way on emulators is to save the game state just before some variable changes, then allow the variable to change, then save the game state again and look at a diff of both save states. For example save the game just before losing a life and just after losing a life to see what potential memory addresses change when a life is lost. You will get a bunch of other data as well for example when you die the level resets, your score might change etc etc... but as you repeat this process over and over again you will get a sense that address range X-Y is level data, range Y-Z is enemy data, A-B is this data, so on so forth and eventually you'll be able to narrow things down.
fyi, the Game Genie was actually rom patches not memory writing. But knowing the ram address would definitely make finding the rom to patch in disassembly much easier.
Game Shark on later systems did "freeze" ram and the Pro models on psx/n64 had really nice code searching features like you're describing.
Minor note but many games did have ram in cart space (that's how battery backups worked, but games also used the ram for other things - most didn't need 4kb+ just for saves), so some codes were ram freezes. The game genie just couldn't force anything in system ram because it would cause bus conflicts.
Also patching isn't really the right word either. They were more like conditional freezes, because of bank switching. The game genie had no idea what bank was loaded at any given time so the codes say "if this address is this right now, make it that instead" so it would (ideally) only be active when the right bank was set. But that's why some gg codes had weird side effects, because they were affecting other banks than the important one.
Yeah I think Nintendo, like Disney, benefits from a mystique that there are "secrets" of the company. They know they can monetize things by introducing scarcity and then officially releasing them, even if those releases are not as satisfying as the public clamors for. But if you release everything, some of the mystery goes away and it's inherently less valuable.
Not even emulators - I remember hacking PC-DOS games with TSR like programs. I can't even remember the name of those programs, but you basically had a hotkey and it interrupts the game and lets you do the search you mentioned above (search, play, re-search with new value)
Yeah, I remember a detailed walkthrough on how to use something like that to change the amount of money you had in SimCity. It would take over the system, and could write the RAM out to disk and compare with a previous write, etc.
My first hack was opening a simcity save, find the amount of money translated in hex, replace it by ffff ... and wonder why now I had -1$ ? Then I learned...
At least for normal kids back in the day, you got little booklets with codes printed in them and they were pretty opaque as to how they were obtained.
There was a guide with it that more or less said to try random things and that maybe F would have more effect than 0 but it gave no indication that I can recall of how the device worked or why F might do more than 0.
Of course now I know that it's just modifying bits of memory (and how that can screw things up...) and that if you're doing a life counter or something, F is a bigger number, but yeah, it was never remotely clear to me as a kid what it was doing.
I had a similar device for the snes, "action replay" cart. It explained how to figure out codes for yourself. Me and a friend spent a day trying to get street fighter 2 to allow us to play as boss characters (Vega etc).
We got as far as the screen showing the correct portraits before the fight.
We were 11 at the time. It must have been very child friendly
I once came up with a game genie code for a game in 15 minutes. My then-girlfriend (high school) called me up on the phone and wanted help because there weren't any game genie codes that did what she wanted.
The answer these days is emulation & memory search. Memory search gets used for hacking native PC games these days too although it's a lot harder when anti-cheat is involved.
You give it a query like "show me values that decreased since we started observing" and you repeat the process to winnow it down to a memory location or set of locations. You then try fixing the memory location to a value and see what the game does.
Incidentally, in Link to the Past, the heart containers are denominated in units of 4, which can throw you off. Going from 4 hearts to 3 means the value goes from 16 to 12. If you went down to 3.5 hearts it'd be 14.
Even more curious is how do ppl discover the hex codes for like Gameshark? I had a friend who would just guesstimate and successfully able to manipulate playstation games. It was fascinating to watch.
I'm not sure if this applies to the playstation, but I remember the nintendo 64 gameshark I had had some "code finding" features that involved using a button on the cartridge to filter down to memory addresses that had changed a certain way since the last button press. This meant that if you were looking for say, the address where your character's health was stored, you could press the button, get hit in the game, press the button again, and search for values in memory that had decreased since the last button press. Doing this several times was a fairly reliable way of finding things. I'm a bit fuzzy on the details but that was the general idea.
Most modern emulators have similar but much more fleshed out features. They're nice not only for finding cheat codes but for reverse engineering games for the purposes of making romhacks or tool assisted speedruns and things like that.
My main exposure to this technique was with the various in-game plugins one could install on a hacked Sony PSP.
Even though I had an interest in programming from a young age, before learning how to use those plug-ins, it hadn't really dawned on me that everything in the game, like your health, location, stats, and even your characters current action, were all states stored in memory somehow.
Using those plugins (or similar), you can narrow down and manipulate all sorts of values. Infinite ammo? Just lock the value to something greater than 0. Even just locking the height value of your position opened up interesting avenues because you could circumvent gravity in a way that was relatively easy to find.
Tangentially, if this sort of thing entertains you as it does me, the magic system in the Magic 2.0 book series by Scott Meyer effectively works like a cheat engine.
At a basic level, this is how modern tools like CheatEngine work today. Find all the memory addresses containing your current health level. Do something to manipulate that value, find all the addresses that reflect the new value, rinse and repeat until you know where your health is stored, then write whatever you want to that address.
It can do more than that of course, but it's cool to see that the gameshark I had as a little kid worked in a similar fashion.
huh, okay I always wondered what the button did. I always assumed it was to 'activate' codes that were input, maybe for a different game that I hadnt played yet and thus hadn't needed to use it yet.
For some reason I thought I had remembered reading about pressing the button for extra lives, or for clipping, but not having the game it was for, when I was reading about it at the time.
Incidentally, Game genie and Gameshark were the first time I realized I was committing piracy (or any crime), when I was asked to leave a store for writing down a code that was in one of those 10,000 Game Codes books. It's been a long sordid tale of hidden algebra notecards and microscopic formula sheets ever since.
> The code is GOSSIP (amazing coincidence that it happens to also be an English word). This works in Capcom's Ghosts 'n Goblins to start your player with a really funky weapon.
Oh, the potential for easter eggs if you anticipated the use of a Game Genie by players, this was meta-gaming at its earliest in strictly offline mode. You could even hide codes in-story for later replays and whatnot. What's not to love about such a hacky mode of expression, a hacking-friendly barebones paradigm.
Don’t know how it was done back in the days. But dumping a ROM should be straight forward. The resulting machine code can be massaged into assembly using a disassembler. 6502 assembly is kind of easy to read, since the instruction set is small compared to modern day CPUs. Once you identified a routine you want to change, you look up the instructions address in ROM, and hijack the corresponding addresses at runtime to put your own instructions and data on the bus. For sure everything but easy, but totally doable.
Really? Hmmm, I would have expected it to extend the life of the NES's slot, at least if the GG was left permanently inserted. Because then the Game Genie's slot would be subject to wear + tear + oxidation, not the NES's slot.
This is pure speculation on my part and is, it seems, incorrect.
I'm not sure we ever tried unplugging the cartridge from the device while inside the console, that sounds like it would have been a good idea.
IIRC it was mostly how the wedge on top pushed things down so the bundle would correctly be detected as completely inserted, eventually the Game Genie was pretty much required.
> After all, given 2 Game Genie codes, one that granted 5 lives on startup and another code that granted 9 lives, and the only difference between the 2 codes was one character, even a novice player could probably figure out that modifying that one character to any of the acceptable letter characters would grant between 1 and 16 lives on startup.
I fail to see why that was an outcome they wanted to avoid.
I bought some as a kid, and the real value wasn't additional codes for games already covered, but codes for new games that didn't have any yet.
I would have felt pretty ripped off if I had spent what little money I could get on the newest Super Mario Bros. 3 codes only to discover it was six extra lives when I already had a code for three.
At least some of those code books also included instructions for that kind of experimentation though. I very clearly remember my dad using those instructions to change Mario's jump height in SMB1 to just bypass whole levels by modifying the existing jump height codes.
I also remember being able to do something like this with the Sega genesis game genie… you could modify some of the codes with simple changes to change the number of free lives given, for example.
Love this! Was in my bookmarks as I had to make a couple of codes late last year to slow the ball in arkanoid, so it could be enjoyed by someone who couldn't keep up. Needed to use FCEU to find the ball speed info and some online references to the 6502 ASM instruction set for substituting instructions to keep the ball slowed.
I had the Game Genie. Young me had no idea how it worked, but I sort of had an intuitive guess when I entered some random codes in and mario level 1 suddenly became full of random bits of pixels you could climb up and jump around on. Amazing read.
I had a friend whose mother wouldn't allow him to get one because the commercial showed the TV exploding and she was afraid that would happen to them..in hindsight, it was a good excuse to not have to buy your kid something he really wanted
My favourite code is ANTOSA. This is a code for Super Mario Bros. which turns all pipes you can't enter upside-down. SMB1 has been disassembled with commentary, so it's now possible to see how the code works. It turns out there is a table of blocks for the top two layers of both non-warp and warp pipes, that looks like this:
The code to draw the pipes gets this address of this table and stores it in the Y register. Then, if the pipe isn't a warp pipe, it executes 4 INY (increment Y) instructions in a row to adjust the offset.The ANTOSA code just replaces two of the INY instructions with a two-byte BVS (Branch on Overflow Set) instruction. However, the Overflow flag is never set at this point, so effectively this instruction is a two-byte no-op.
The practical upshot is that Y is only incremented by 2, which means it points two bytes inside the "pipes that lead somewhere" data rather than directly at the "used by decoration pipes" data. It turns out that the first two bytes determine the top of the pipe, and the second two bytes determine the second layer, so decoration pipes are effectively drawn (second layer, top layer). And voila -- "upside down" non-warp pipes.
If it was intentional, it was very clever. But I suspect it wasn't -- BVS is an odd choice for a two-byte NOP! An alternative would be change one of the INYs to a DEY (decrement Y), producing the functionally-equivalent codes EETOKX, EETOSX, EETOVX or EETONX, depending on which INY you change. I admit ANTOSA sounds cooler.
The full SMB disassembly (not mine) is here if you're interested: https://6502disassembly.com/nes-smb/SuperMarioBros.html
* Typically. NES cartridges could also contain RAM.