Detailed Basics

Lazy Bastard
This is a modification of/addendum to my first section of the never-finished FPSXHFAQ, of the same title (Detailed Basics). Feel free to jump in and add something; I'll probably do the same as the mood strikes me. As a note, I use the acronym "PAR" loosely. Technically, it stands for "Pro Action Replay", a cheat device that was only released for a few systems, but use of the term "PAR" to describe RAM codes rather than ROM ones, or raw hex codes rather than hacking/cheat device-specific formatted ones, has become so prevalent, I'll just use it here as well.

Could you just do the FAQ without me asking questions?

Yes. However, technically, that will make this a guide. Heheh. OK, OK, I'll start it.

PSX : the original Playstation [GSpro]


Above is the basic structure of a PSX GS code. XX represents the code type. These include 80, 30, D0, 50, and so on (check out the FAQ on code types by CMX of GSCCC for a complete list, or the one LMZ will probably be releasing soon after this). YYYYYY represents the address. This is simply the location in memory that the code affects. ZZZZ is the value, which is what's at that location.

When you're searching for something, or browsing with the Memory Editor for that matter, the GS displays all addresses as starting with 80, but (despite the interesting note below) try to think of 80 as the direct write code type. This isn't really vital information to an average hacker, but for those seeking to reach a higher level of skill, it's definitely a bit of knowledge to have.

[I'm not really sure why exactly, but the "80" is really part of the address. The proof is 

(from PlayStation Developer's Guide, v2.5c) :

"Most PlayStation applications will run using the address ranges 0x80000000 to 0x80200000 (2 Mb RAM)."

This is probably why all psx "cheat devices" use the 80 type.] : LiquidManZero

Thanks, Liquid.

N64 - Nintendo64 [GSPro]

See the above PSX GS code structure synopsis, though the N64's working memory falls into the following range: 00000000 - 00800000


SNES - Super Nintendo [PAR]

Hacking SNES generally requires an emulator, such as SNES9x, ZSNES, SNESGT, and so forth. Drop by or Google around a bit. Unless, of course, you manage to acquire an extremely rare SNES Pro Action Replay cart. That possibility excluded, let's move on.


Above is the basic structure of an SNES PAR code. XXXXXX is the address, and YY is the value at that address.

Most SNES PAR codes fall between address 7E0000 and 7FFFFF. In fact, most SNES emulators will only search in this area, though they'll allow code input to other areas, such as 010000-02FFFF, as well as input of Game Genie codes.

NES - Regular (original) Nintendo [PAR]

Hacking NES requires an emulator, such as NNNesterJ, JNES, NESten, and so forth. Again, check out, or Google a little.


Above is the basic structure of an NES RAM code. Occasionally, an emulator will use the format XXXX YY; the difference is simply that the code is truncated to exclude the beginning 00 (it's actually a little easier to look at). XXXXXX represents the address, and YY represents the value at that address. The reason these aren't referred to as PAR codes is that there was no Pro Action Replay for the NES, and hence NES hacking, in the strict sense, did not exist until the advent of NES emulators (and furthermore, emulators with memory searching/modifying abilites).


Genesis [PAR]


Above, as usual now (heh), is the basic structure of a Genesis PAR code (32X uses the same structure). I'm not sure if there was a PAR cartridge released for Genesis, but the rarity of such an item means you'll probably be hacking by use of a Genesis emulator, such as Kega Fusion, Gens (and its awesome variations), DGen, and so forth. As noted, check out Zophar, or use Google.

GBA - Nintendo Game Boy Advance [PAR]


Above is the basic structure of a GBA code. XX represents the code type. YYYYYY represents the address. This is simply the location in memory that the code affects. ZZZZ is the value, which is what's at that location. In the process of hacking, you'll see codes in the format XXXXXXXX ZZZZ, where XXXXXXXX is the address, and ZZZZ is the value, though it can be converted for specific cheat systems, or used raw with later versions of the CodeBreaker.

As you'll be hacking with an emulator, I'd recommend VBA-H (VBA Hacking edition), normal VBA, or No$GBA, though there are pros and cons to each of these, and none, as of today (03-20-07), are much better than simply sufficient. On the other hand, I haven't created a GBA emulator, or hacking system, so I shouldn't complain :)

Anyone want to write a quick one up for Saturn, Sega Master System, Game Gear, or Game Boy/Game Boy Color?


-An explanation of memory searches

For the sake of simplicity, I'm going to call the hacking device/utility/system/whatever for any given console/platform the "hacking system". Note also that the names of search types for various hacking systems may differ slightly, and some search types may not exist for a given hacking system, but common sense should lead you in the right direction. Let me know if you have any questions, though.

OK, let's start with Unknown Value searches. When you start a search, the hacking system takes a snapshot of the area of memory you're searching in (usually, this is the entire memory, but in the case of systems like the PSX GSPro, you're going to be searching in one of several areas´┐Żunless you connect from your console to a PC via a parallel cable or comms link, but that's for another FAQ). You'll then have to return to the game for at least a moment before you can run any searches; this is the case after any search. Anyway, when you run an Equal To Last search, the system goes through that snapshot, and keeps only the addresses whose values didn't change since the last search. In other words, anything that changed in the game since the last search is discarded. Only those things in the game that are exactly the same as they were before still remain. Inversely, when you run a Different (or Not Equal, heh) To Last search, the hacking system goes through its snapshot and keeps only addresses whose values have changed. Greater Than Last searches yield only addresses whose values have increased, and Less Than Last searches return addresses whose values have decreased.

Searches run at any point after the first search are run on what remains of the snapshot. If you start a search, return to the game, run a Greater Than Last search, return to the game, and run a Different To Last search, the hacking system takes the initial snapshot, discards anything that hasn't increased, then discards anything that hasn't changed.

Known Value searches are even simpler. The same snapshot principles apply here, only the snapshot is taken during the first search, and is only kept for a second while the hacking system runs through it and keeps only the addresses containing the value you entered. The second search keeps only the addresses of those values that match your new inputted value (heh, inputted). So if you run a Known Value search for "00087", return to the game, then run another for "00005", the hacking system grabs all addresses with the value "00087", and then out of those keeps only the ones whose values became "00005". Keep in mind that Known Value searches are generally in decimal, not hex, though in some systems, you can toggle between the two. Something of note to beginners is that the decimal equivalent of hex numbers like "FFFF" (65535 in decimal) is five digits long rather than four. Read the FAQ I wrote on Hexadecimal if you want to know about...well...hexadecimal, heh.

Unknown Value searches are used to find anything for which you don't know an exact value, such as life meters, characters, coordinates, rooms, etc. There are those rare times when life meters work in sections, when rooms or characters are in sequence, and so on; in these instances, you could use Known Value searches, but for the most part you'll use Unknown Value searches.

Known Value searches are used to find something for which you know an exact value, such as HP/MP, lives, ammo, levels for games that are actually divided into levels, and so on.

So, if you think a value is 23, run a Known Value search for "00023"; if you think a value has increased, start an Unknown Value search before the next time it increases, then run a Greater Than Last search after it get the idea.

It's sometimes a good plan (it's standard procedure for me) to run an Equal To Last search right after the initial snapshot, when nothing has changed yet. This is in order to eliminate addresses with values that constantly change many times per second, and to eliminate things such as time (unless you're hacking for something involving time).

Occasionally, you may see large areas of memory filled with values of either F's or 0's. Large groups of F or 0-filled values commonly represent something that's just not in use right now, so keep in mind that it's not always safe to assume that large chunks of these are going to remain as empty sections of memory.

Anyway, back on subject; let's use our imagination and hack an infinite lives code.

We have 9 lives (we're a cat!). We know the value we're searching for, so let's run a Known Value search for "00009". This done, we'll return to the game, do nothing, and now run a search for "00009" again to narrow the results. This is the same as running an Equal To Last search. Now we lose 1 life, and run a search for "00008". Next, we'll gain a life, and run a search for "00009". Continuing this pattern, we should eventually narrow the search down to a few results, and test these results until we find the address that controls how many lives we have.

For the sake of another example, let's say we just couldn't seem to find that address. 

Perhaps the memory sees that "9" as 6D hex, and starts numbers at 100 decimal for some odd reason, or has some other wierd system. In any case, we have no idea of what value to search for. We'll have to run an Unknown value search. Starting back where we were (with 9 lives), we start the search, do nothing, and run an Equal To Last search. Now we lose a life, and run a Less Than Last search. Next we gain a life and run a Greater Than Last search, and continue this pattern until we have a few results left. In the case of hacking systems like the PSX GSPro, we'll repeat these steps through each area of memory, until we've either found the code, or searched through the entire memory. After testing all of these results, if we still haven't found our code, one of two things (or both) has happened: we've either made a mistake at some point, or we're wrong about how we think the memory works in this game. Now we either give up, start over with the same method, or try to think of a different way to hack the code. If you're meticulous (and were while you were hacking), you'll choose the third option.

This text was brought to you by, unless someone else gave it to you, in which case it was only written by someone at Heheh.