WikiTemp - User contributions [en]

EnHacklopedia:Hacking NES

2010-10-10T07:40:49Z

Raing3: New page: ==Hacking using FCE Ultra Debug== FCE Ultra Debug's cheat console FCE Ultra Debug is a highly compatible NES emulator that helps f...

==Hacking using FCE Ultra Debug==

[[Image:Fceu_cheat.png|center|FCE Ultra Debug's cheat console]]

[[EnHacklopedia:Tools|FCE Ultra Debug]] is a highly compatible NES emulator that helps facilitate code hacking. It includes a RAM searcher as well as a debugger. The RAM searcher is labeled "Cheats" under the Tools menu and can also be accessed by the "Shift+F1" key combination. Cheats can be both added, removed, and searched for here. The "Known value" options searches for the specific byte entered in the space next to that button. Below this, the unknown value options exist. If the check box next to any of the bottom three options is checked, then the value is restricted to being with in the difference supplied. The RAM searcher only searches for 8-byte values and performs all searches in hexadecimal.

[[Image:Fceu_debug.png|center|FCE Ultra Debug's debugger]]

Also under the tools menu is the debugger, labeled "Debug"; It can also be accessed with F1. On the left is the disassembled 6502 code, with the top instruction being the current instruction to be executed. In the middle are several options. "Run" resumes the game, while "Step in" executes the next instruction. Step out continues execution until the subroutine is exected. Finally, step over skips the next instruction. The "seek to" option simply moves the disassembly to the location specified, while the seek PC moves the disassembly to the PC. Underneath this, the registers A, X, and Y are displayed, with the stack underneath. Finally, at the bottom, PPU and Sprite are listed.

==6502 Assembly==
The 6502 processor that the NES uses is an 8-bit processor. The 6502 provides 2 8-bit general purpose registers (X and Y), an 8-bit accumulator, an 8-bit stack pointer, an 8-bit status register, and a 16-bit program counter. With only 151 instructions defined, many desirable operations are missing, including any multi-byte operations; multiply, divide, and modulus operations, and several branch instructions. Additionally, the 6502 contains several potentially problematic bugs. The JMP instruction is partially broken. If JMP $xxFF is executed, the PC will not jump to the address stored in $xxFF and $xxFF+1 like it should but rather to the address stored in $xxFF and $xx00. Additionally, the 105 undefined instructions result in undocumented and hard to prevent effects, instead of a NOP or BRK instruction. A list of all the 6502 opcodes and their effects on the NES can be found in the [[EnHacklopedia:Documents|6502 reference]].

==Game Genie==

[[Image:Gg.png|center|NES Game Genie Code Entry Screen]]

===Description===
The Game Genie, made by Galoob, is a cheat device, like the Pro Action Replay. However, unlike the Pro Action Replay, the Game Genie patches ROM, whereas the Pro Action Replay edits RAM. For example, a code may patch the address 0x8000 with the value 0x3F. This means that instead of modifying 0x8000 to be 0x3F, instead the Game Genie will watch for the game to access 0x8000, and whenever that happens it will send 0x3F to the location that requested 0x8000. This method, however, has one drawback. Because the 6502 only has a 16-bit program counter, only 64 KB of memory can be referenced at a time. To get around this limitation, the NES employs what is known as "bank switching". Basically, the NES references the entire ROM in 64 KB pages, and when necessary switches the page. What this means is that the assembly code referenced at our location 0x8000 is not always the same. It may refer to 0x8000 or 0x18000 or something else, but all will be patched. This can cause bugs, which is obviously undesirable. To combat this, Galoob provides an 8-character Game Genie code, which an extra byte called "compare". For this example, compare will be 0x5A. What the Game Genie will do is watch the address 0x8000 to be called. When it is called, if the value at that location is 0x5A, then 0x3F will be return. Otherwise, the Game Genie will allow the game to operate as intended. Game Genie codes also have to be encoded. Encoding and decoding Game Genie codes is explained in the sections below. It is worthwhile to learn how to do these operations by hand. However, while not very hard, it is quite tedious. GG Encoder automates this process for you. Finally, decoded Game Genie codes are expressed in the format aabb:cc for 6-character and aabb?dd:cc, where aabb is the address to patch, cc is the patch value, and dd is the compare byte.

===Decoding Game Genie Codes===
Game Genie codes for the NES code in two formats: 6-character and 8-character. In any Game Genie code, only 16 different letters are used: A, E. P, O, Z, X, L, U, G, K, I, S, T, V, Y, and N. Left to right, each of these characters is assigned the bytes 0x0 through 0xF. To decode a game genie code, first rewrite the code in the for of hexadecimal. For example, the code GOSSIP would become 0x49DD51. To get the address out of a 6-character game genie code, the C-style equation is "addr = 0x8000 + ((n3 & 7) << 12) | ((n5 & 7) << 8) | ((n4 & 8) << 8) | ((n2 & 7) << 4) | ((n1 & 8) << 4 | (n4 & 7) | (n3 & 8);", where n0 is the highest nybble, n1 the next highest, etc., with n5 being the lowest nybble. This equation also works for 8-character Game Genie codes. The equations for decoding the data vary slightly between the two formats. For 6-character, it's "data = ((n1 & 7) << 4) | ((n0 & 8) << 4) | (n0 & 7) | (n5 & 8);" while for 8-character it is "data = ((n1 & 7) << 4) | ((n0 & 8) << 4) | (n0 & 7) | (n7 & 8);" Finally, 8-character Game Genie codes have the extra compare byte, which is decoded with "compare = ((n7 & 7) << 4) | ((n6 & 8) << 4) | (n6 & 7) | (n5 & 8);"

====Example 6-character Game Genie Code Decoding====
Decoding GOSSIP. First convert into hex, which gives us 0x49DD51. Then extract the address: addr = 0x8000 + ((0xD & 7) << 12) | ((1 & 7) << 8) | ((5 & 8) << 8) | ((0xD & 7) << 4) | (9 & 8) << 4) | (5 & 7) | (0xD & 8). This simplifies to 0x8000 + (5 << 12) | (1 << 8) | (0 << 8) | (5 << 4) | (8 << 4) | 5 | 8 = 0x8000 + 0x5000 | 0x100 | 0 | 0x50 | 0x80 | 5 | 8 = 0x8000 + 0x51DD = 0xD1DD. The only thing left to do is to grab the data: data = ((9 & 7) << 4) | ((4 & 8) << 4) | (4 & 7) | (1 & 8) = (1 << 4) | (0 << 4) | 4 | 0 = 0x10 | 4 = 0x14. The decoded Game Genie code is D1DD:14.

====Example 8-character Game Genie Code Decoding====
Decoding ZEXPYGLA. In hex, this gives us 0x28A17430. Extracting the address is the same as in the 6-character example: addr = 0x8000 + ((1 & 7) << 12) | ((4 & 7) << 8) | ((7 & 8) << 8) | ((0xA & 7) << 4) | ((8 & 8) << 4) | (7 & 7) | (1 & 8) = 0x8000 + (1 << 12) | (4 << 8) | (0 << 8) | (2 << 4) | (8 << 4) | 7 | 0 = 0x8000 + 0x1000 | 0x400 | 0 | 0x20 | 0x80 | 7 | 0 = 0x8000 + 0x14A7 = 0x94A7. Now get the data and compare values: data = ((8 & 7) << 4) | ((2 & 8) << 4) | (2 & 7) | (0 & 8) = (0 << 4) | (0 << 4) | 2 | 0 = 0 | 0 | 2 | 0 = 2; compare = ((0 & 7) << 4) | ((3 & 8) << 4) | (3 & 7) | (4 & 8) = (0 << 4) | (0 << 4) | 3 | 0 = 3. The final decoded version is 94A7?03:02.

===Encoding Game Genie Codes===

To Do

====Example 6-character Game Genie Code Encoding====
To Do

====Example 8-character Game Genie Code Encoding====
To Do

==Pro Action Replay==
To Do

==Known Value Searching - Metroid - Infinite Missiles==
This hack is performed on the Metroid (U) (PRG0) [!] rom. Results on the (E) or bad or overdump versions may be different. Boot up FCEUXD and start a game. Play through the game until you obtain missiles. If necessary, consult [http://www.gamefaqs.com/ GameFAQs]. Samus starts off with 5 missiles. This is plenty. Make a save state, just in case. Go to the cheat menu and do a known value search for 5. For me, this cut down the possibilities to 37. Shoot a missile then search for 4. I have 2 possibilies left. You may have more. While it's possible to just go ahead test each possibility, we can try to get rid of one. Walk around for a bit, but don't shoot. Then search for 4. Still 2 possibilities. Shoot another missile. Down to 3. Search for 3. Still two possibilities (0x0000 and 0x6879). Let's test them. Select the first possibility on the far right menu ($0000). Click on it. On the left, the address and value will be added. Click "add". The game froze. This is not good. So the other possibility is likely the right one. Load the save state, at the code, and test. You have infinite missiles.

==Basic Game Genie Code - Metroid - Infinite Missiles==
While the code just hacked is good for PAR, it won't work with a Game Genie. This section shows how to make the code into Game Genie. Because Game Genie patches ROM, we need to modify the assembly code to give us infinite missiles. We already have a starting point - the address where the number of missiles is stored out - 0x6879. Delete all codes and go to the debug menu. Under breakpoints, click add. In the left address box, put in our address, 0x6879. We're only looking at one address, so leave the right box blank. Underneath this, we can choose whether we want to break when the address is read from, written to, or executed, or any combination of the three. The missile address is subtracted from when a missile is shot, so this qualifies as a write. Choose this and click OK. Click the run button and shoot a missile. The game pauses and the debug menu comes up. This means that one of our breakpoints occurred, in this case our only one. On the left, the disassembly is shown, with the instruction on top being the one just executed. Here it is $D333: CE 79 68 DEC $6879 = #$04. DEC stands for decrement, or subtract one. It is subtracting one from the address given - our missile addresss! The rest is added on by FCEU. This tells you that after the operation, the value at $6879 will be 4. We want to disable this operation. The easiest way is to just NOP the instruction. NOP means nothing happens. While this would certainly achieve our goal, NOP is a one byte instruction (0xEA), whereas this DEC is three. The NOP would have to be used three times. Because the NES Game Genie only allows three codes to begin with, this is certainly undesirable. If only one NOP were to be used, all subsequent opcodes would be messed up. Indeed, here changing only 0xD333 to a NOP causes the game to reset when a missile is shot. Another option is to find some unused memory, and change the instruction so that the decrement occurs there. Opening the hex editor up and going to the 0x6800 block, there is much RAM that appears to be unused, including 0x6800. Our code will change DEC $6879 to DEC $6800. Just as CE 79 68 is DEC $6879, CE 00 68 is DEC $6800. Go in the hex editor to 0xD334 and modify 0x79 to 0x00. When shooting missiles, the missile count does not go down, and there are no apparent side effects. The final step is to format the code. We want to change the byte 0x79 to 0x00 at 0xD334. This makes the code D334?79:00, or AAUIGUPY.

[[Category:EnHacklopedia]]

File:Gg.png

2010-10-10T07:38:41Z

Raing3: NES Game Genie Code Entry Screen

NES Game Genie Code Entry Screen

File:Fceu debug.png

2010-10-10T07:37:38Z

Raing3: FCE Ultra Debug's debugger

FCE Ultra Debug's debugger

File:Fceu cheat.png

2010-10-10T07:35:00Z

Raing3: FCE Ultra Debug's cheat console

FCE Ultra Debug's cheat console

EnHacklopedia:Generic Code Hacking

2010-10-10T07:24:44Z

Raing3: New page: ==Using Trainers== Trainers come in various forms and are called different things (code generator, code searcher, etc). They may vary in look and features, but they all function the same w...

==Using Trainers==
Trainers come in various forms and are called different things (code generator, code searcher, etc). They may vary in look and features, but they all function the same way. They "dump" the memory from a game and search for values in it. Most trainers save this dump temporarily for making relative comparisons (greater/less/equal/different) at different points in the game. The idea being to change something in the game and compare the new memory to the old, in order to find which locations in memory have changed each time. This allows the hacker to find the address in memory of something, whether it be lives, health, or removing Lara Croft's underwear on Tomb Raider.

'''Typical Search Options'''
* Initial Dump / Start Search - This grabs the current memory for comparing to after causing something to change.
* Known Value - Searches for a user entered value.
* Greater Than - Find values that have increased.
* Less Than - Find values that have decreased.
* Different To / Not Equal To - Find values that have changed.
* Equal To - Find values that are the same.
* In-Range - Find any value within a certain range (like between 1 and 10).

'''An Example Search For a Health Bar'''
# Get to the point in the game where health is actually displayed.
# Start Search (Initial Dump).
# Get back in the game and lose health.
# Search for values that are Less Than.
# Go back to the game and lose health again.
# Search Less Than again.
# If health is gained by pickups or something, pick one up, and search Greater Than.
# Repeat this until the number of results shown by the trainer is reasonably small. Sometimes it will narrow all the way to 1 result, but don't count on it.
# Test the result(s) until one effects health.

===Known Value Searches===
A known value search is the most basic search that there is. It is used to search for things that you know the exact value of, generally something displayed onscreen, such as a score or number of lives. It's worth keeping in mind that the on-screen value is not necessarily the value that is stored in memory. It is not uncommon for the value to be stored in memory with one added or subtracted to it. Additionally, the value may be stored as a BCD or float values instead of a normal hexadecimal number. If searching for known values is not successful, unknown value searches may be necessary to find the code.

===Unknown Value Searches===
For use when the user doesn't know the exact value to search for, like timers, and health bars. Unknown value searches consist of comparing memory dumps in relation to how the target has changed. If health/time decreases, search "Less Than." If it increases, search "Greater than." Examples of such comparison search options include: Greater Than, Less Than, Different To, and Equal To.

===Signed Searches===
Some trainers allow signed searching by sign-extending values being compared, just as the game would sign them for doing things. This allows for finding things that would might be handled by a game as negative values. With a regular 32-bit search, for example, 0xFFFFFFE0 would be greater than 0x42C80000. However, if these were compared as signed, 0x42C80000 would be greater because 0xFFFFFFE0 is read as negative 0x20 (-32). Games use signed values for anything from acceleration to coordinates. For example, acceleration might be stored by a game as a negative value while driving in reverse because that's how vectors are stored. The direction is like the most significant bit, so looking at them signed makes them easy to search for. There are also times when games display a negative number for something on the screen as well.

* Unsigned
** For 8-bits
*** 0x00 -> 0xFF = 0 to 255.
**For 16-bits
***0x0000 -> 0xFFFF = 0 to 65535.
**For 32-bits
***0x00000000 -> 0xFFFFFFFF = 0 to 4294967295.
*Signed
**For 8-bits
***0x00 -> 0x7F = 0 to 127.
***0x80 -> 0xFF = -127 to -1.
**For 16-bits
***0x0000 -> 0x7FFF = 0 to 32767.
***0x8000 -> 0xFFFF = -32768 to -1.
**For 32-bits
***0x00000000 -> 0x7FFFFFFF = 0 to 2147483647.
***0x80000000 -> 0xFFFFFFFF = -2147483648 to -1.

==Hacking With Emulators==
An emulator is a computer program that acts as a virtual game console, so to speak. It imitates the actual hardware in order to run backups of games (ROMs) for the given system. There may not be an emulator for every system, or the ones available may not work very well (if at all). Not every emulator can run every game. This is partly because of incompetence on the part of emulator authors, especially in the case of Nintendo64. '''The authors do NOT provide ROMs, so don't ask!'''

Some emulators have built-in cheat searching utilities, just like trainers for the consoles themselves. They work the same way. More information on hacking with specific emulators may be found with the in-depth system info for some systems. There are alternatives to built-in trainers as well, like external programs used in conjunction with an emulator or using save states. These methods can be lifesavers when an emulator's cheating utilities are lacking or non-existent.

===Renegade===
Most trainers and hacking tools available are for specific consoles and/or emulators. [[EnHacklopedia:Tools|Renegade]], on the other hand, is one of the few hacking tools made to support many emulators and pretty much anything else that allows the user to save a copy of the memory. Renegade can seem overwhelming at first, but hacking normal codes with it is really the same as anything else.

[[Image:Renegade_code_search.png|center|Renegade: Code Search Window]]

'''Attaching to an Emulator'''
# Start the emulator, and get a game running.
# Pause the game. Most emulators have the option to pause emulation entirely. This is recommended.
# Open Renegade
# Go to the Cheating menu. Choose Attach To Emulator.
# Choose the emulator that's running in the dialog box. The textbox beside there will tell if the running emulator was found by Renegade or not.
# The Attach button should be enabled when it verifies the selected emulator is running. Click Attach
# Now go to the Cheating menu and choose Code Search, Memory Editor, or open both.
# Now the search options look pretty much the same as in any other trainer; there's just a lot more of them.
# Do an Initial Dump or Known Value search to start.
# Switch back to the emulator and change the thing being hacked.
# Pause the emulator again, switch back to Renegade, and search accordingly.
# Keep this up to narrow results as with any other trainer.
# When the time comes to test results, the results window displays the addresses in the form of raw addresses. This simply means that the user is expected to use the right code prefix, etc for the system being hacked (80/81 on N64, for instance).
# Another thing to note is that the results are automatically stored in a text file in the searches directory each time the Results button on the Code Search window is clicked. The filename is always search#.txt. The results can also be exported as N64 codes for easy testing.

'''Comparing Files'''
# Open the Code Search window without attaching to an emulator as described above. If it was already attached, simple select Detach From Emulator from the Cheating menu.
# There's an option to specify the byte order.
# Also notice the Header option. This can be configured to ignore the first so many bytes (header) of a file.
# If doing a Known Value search, one file is required to start.
#* On the Search Type dropdown list choose Known Value, In-Range, or any option that can be done with a single file.
#* Click the Search button and a file dialog appears. Choose the file to be searched. Searching will commence, and result count will be displayed
#* The search can be continued by simply setting the search type as desired, and clicking search again. The dialog will prompt for choosing the next file.
# For doing comparison searches, there is no actual "Initial Dump." Just start by comparing the first two files.
#* Set the search options for the desired comparison and click the Search button. The difference here is after the dialog prompts for the first file, it will immediately prompt for the second.
#* The search is continued the same as if it were started by searching for a known value. Choose search options, then click Search to be prompted for the next file.

===Save States===
Save states are like a RAM dump, a copy of the game's memory at any given time. These can be compared or viewed in a hex editor just like a regular RAM dump. Most emulators have the option of saving the current state of the game. Some are even nice enough to have an actual "RAM Dump" option.

'''Two Important Notes About Save Sates'''
# Save states typically have extra information in them besides the RAM dump itself. This is in the form of extra bytes before or after the actual dump shows up in the file. The number of bytes varies by emulator but not by game. This is because different emulator authors store information differently. Finding the right RAM addresses for values found in these files is just a matter of subtracting the size of the header from the address in the file. Meaning if the header is 0x40 bytes and the a code is found a 0x45690 in the file, the actual RAM address would be 0x45650. This is pretty much the same concept as porting codes, but the porting is being done from save sate address to RAM address.
# Some emulators will compress save states by default. These will need to be uncompressed before they can be handled as normal RAM dumps. Some emulators have the option of turning off the compression, others don't. In most cases, programs like WinRAR can decompress the save states because they use common compression algorithms. However, there are times when this won't work, and there isn't really any solution short of asking the emulator author.

==Guess and Check Style Hacking==
To Do

==Porting Codes==
To Do

==Pointers==

A pointer is an address in memory that actually contains the value of another address. Say for example the 8-bit values at 0x80045020 are 0x80 0x25 0x78 0x40. That's probably a pointer to the address 0x80257840, rather than just the values of something. Games use pointers to keep track of where certain blocks of data are located in the memory. The pointer usually references the beginning of such a block. Some cheat devices support loading these pointers from the address given in order to write to the address plus a user defined offset. For instance, health may be at 0x80257854 in memory. The pointer at 0x80045020 indicates that the block of data (player data in this case) starts at 0x80257840. The difference between the beginning of the data block and the health location is 0x14. Now a pointer code type could tell the device to load the value (pointer) at 0x80045020, add 0x14, and write the value for full health to the resulting address.

==Miscellaneous Hacking Tips==
To Do

===Fake Codes===
To Do

==Infinite Money/Ammo/Items==
'''[Difficulty: Beginner]'''

These are about the easiest codes to hack. To hack one, take the value of desired item to get infinite of, and do a known value search for it. Next, manipulate the amount of it (eg. lose a life), and search for the new value. Keep doing this until results are narrowed down enough to test some. This usually doesn't take much when searching for exact values. Most games store the simple stuff this way; however, some will use float or BCD values, depending on the game system.

== Have Items==
To Do

==Activating Unlockables==
To Do

==Level Modifier==
To Do

==Character/Team/Costume Modifier==
To Do

==Moon Jump==
'''[Difficulty: Intermediate to Hard]'''

With this type of hack, the objective is to find the player's up/down acceleration. A more technical name for this would be a Y Speed Modifier, because it alters the speed the player's Y coordinate is moving. This causes the game to think the player is floating upward just as if the jump button was pressed. In some games, there is no jump button, but this can still be done if there's a place to fall off of as falling is part of Y speed too.

There are multiple ways to go about these, since different games on different systems tend to handle it differently. The basic theory doesn't change much with the search methods though. Y speed is usually a 16 or 32 bit signed value in memory. It increases when moving upward, and decreases when falling. This is signed because most games store vectors this way. The value is based on both the direction being moved and how fast the player is moving in that direction. Most times, Y speed will be 0 when standing still, but don't rely on this. If the player has a little bouncing stance or something, the Y speed could very well be changing just slightly the whole time. Also note that on older systems (like NES/GBC), Y speed can be as simple as an 8-bit value being 0 on the ground and 1 or higher while moving upward.

===The GLEE Method===
The "GLEE" method was pioneered by macrox. The basic theory at the time was that the player's Y speed increases when not on the ground (whether rising or falling). This may seem to contradict the theory above, but it's still technically true. This is because the GLEE method treats moon jumps like most other basic codes: it uses unsigned searches. The steps are outlined below. It's probably best to set whatever search tool is being used to compare 32-bit values first, if available. If that option is unavailable or doesn't work, try 16-bit and so on.

# If the character is stands totally still on the ground, it's a reasonable assumption that Y speed isn't changing. Start a an unknown value search (initial dump). If the character jitters while standing or something, the Equal To searches mentioned here may need to be skipped. This makes it more difficult to narrow the results, but it's still possible.
# Move around a bit, then stand still again. Search Equal To. Repeat this step a couple times to eliminate some junk results.
# Now jump, or fall from a high place if the game has no jumping. While in the air and rising/falling, search Greater Than. Even if the game does allow jumping, falling from something instead to do the Greater Than might shave some extra results off the list.
# Once the player lands on the ground again and is standing still, search Less Than.
# Repeat the steps above until the results list is narrowed considerably.
# When ready to test some results, jump again (if possible) and do a Greater Than while still rising. Catching the value when just beginning to rise is best, though not always easy. The current value should give an idea of what to use for a moon jump value. Turn on a result at a time and look for effects on the player's Y speed.
# Once the correct address is found, try different values until the desired rising effect is reached. A value too high can orbit the player instantly (and even crash the game), and a value too low will force the player to the ground or perhaps keep the play from falling. On games that don't allow jumping, try freezing the value of each address to 0 and attempting to fall until an effect is noticed. Note that getting the rising effect on games which don't allow jumping sometimes still requires falling off something.
#* If the game doesn't allow rising without falling off something, then be possible to hack a code to tell the game the player is in the air. This can be hard or next to impossible on some games, but it works on others.
#* The idea is to start a new search while standing still. Then move to a different position, and search Equal To.
#* Fall off something, and search Different To while in the air. Following this up with an Equal To while still in the air might help cut down the results.
#* Once the player in back on the ground, search Different To again. Repeat these 3 steps until the results are narrowed.
#* Try the results with addresses nearest the Y speed address first. Doing this can sometimes save time, especially when it gets hard to reduce the amount of results and there are still a lot left. When testing results use the value from when the player was in the air along with the Y speed code to attempt forcing the player to rise.
# After locating the Y speed and the right value to get the player rising up without actually jumping to the moon, look up the button activator/joker for the game and the button value desired for the moon jump code. Using the same button the game does to jump is the preferred choice.
# Put the Y speed code with the activator and test it. If a code was hacked to tell the game the player is in the air, put this on an activator for the same button.
# Enjoy the new moon jump code.

===Signed Searching Method===
Another way to hack moon jumps is with signed searching. This can be useful on some systems, if a trainer is available with the option.

# Start an unknown value search while just standing still.
# If the game leaves the player standing completely still, then it's safe to assume the Y speed isn't changing. Move around then stand still again. Search Equal to. Repeat a few times if desired.
# Now here's where signed searching differs from GLEE. The Y speed is positive while rising up, negative while falling, and either 0 or slightly less when standing still. Press the jump button and quickly freeze the game while the player is still rising. Search Greater Than.
# As the player begins to fall, search Less Than.
# When the player hits the ground and is standing still again, search Greater Than.
# Now jump again, and quickly freeze the game while rising once more. Do a Greater Than search.
# This may have been enough to get down to a decent amount of results. If not, repeat the steps as needed, remembering the way Y speed values work signed.
# Once the results are done enough to warrant even looking at them, look for the positive, negative, 0/negative combination of current and previous values for each result. Pick out the ones worth trying and test them with the positive value. The value may still need to be increased a little, but again, keep in mind the signing factor. Don't raise it too high and turn it negative or the player will be glued to the ground.
# Take the right address and value, and put the code on an activator for pressing the jump button (or other button, if desired).
# Up, up, and away!

==Speed Modifier==
A speed modifier is a code that modifies the speed of an in-game character or object. In most cases, this is a 16 or 32-bit signed value in memory. When the character or object is stopped, the value is usually zero. Keep in mind that simpler systems such as the NES and GBC may use 8-bit values for the speed value.

To hack this code, a slight deviation of the GLEE method may be used.

# If the character is stands totally still on the ground, it's a reasonable assumption that the character's speed isn't changing. Start a an unknown value search (initial dump). If the character jitters while standing or something, the Equal To searches mentioned here may need to be skipped. This makes it more difficult to narrow the results, but it's still possible.
# Move around a bit, then stand still again. Search Equal To. Repeat this step a couple times to eliminate some junk results.
# Now start moving. Without stopping, do a Greater Than search.
# Once the character stops or diminishes in speed, do a Less Than search.
# Repeat the steps above until the results list is narrowed considerably.
# When ready to test some results, try setting the speed to something really low. If the character is going really slowly, a speed mod has been found!
# Once the correct address is found, try different values until the desired level of speed is reached. A value set too high may launch the character careening through the level or it may even crash the game.
# Once you have your code, it's a good idea to put an activator on it. Else, the character will always be moving at fast speeds. Some good choices for activators include a "moving/not moving" flag in memory, or even button activators if an alternative isn't found.

==Position Modifier==
Every game uses coordinate system to position a given object or character. These coordinates are located on a set of invisible axes. Two-dimensional games use two axes, referred to as the X and Y axes. Three dimensional games rely on three axes, referred to as the X, Y, and Z axes. The X axis is used for left/right movement, the Y axis for down/up movement, and the Z axis for near/far movement. As an object's X coordinate increases, it is moved to the right, and vice-versa. The same rule applies for the other axes. It is important to note that these axes have nothing to do with what is shown on the game screen. For example: the Y coordinate measures an object's absolute height, as opposed to how high the object is relative to the ground. It is recommended that 32-bit searches are used for three-dimensional games if the emulator or trainer has that option, although 16-bit searches will work just as well. For two dimensional games, 16-bit searches are usually sufficient.

# Identify the target object or character, preferably one whose movement can be controlled by the player. Begin an unknown value search.
# Identify the target axis. Hacking with only one axis in mind is much easier than attempting to keep track of movement on multiple axes. Remember that causing a change in the character's Y coordinates requires movement to a higher position in the level, which may not be easily accessible, so choosing to hack the X or Z coordinate may be easier.
# Move the character several game "feet"/"meters" to the left, right, away from the camera, or towards the camera. Perform a Different To search. It's important to move the character far enough away from the original point if doing a 16-bit search. As each coordinate is usually 32 bits in length (in three-dimensional games), it's extremely important to move the character so that the first half of the value changes. For example: 0x12345678 would need to become 0x1235789A (or higher) so that a 16-bit search registers the change and doesn't discard a potential code. This is not an issue with 32-bit searches.
# Move the character in the opposite direction, keeping the above warning in mind. Perform another Different To search.
# Repeat steps 3 and 4 until there is a manageable number of results, preferably less than 20 or 30.
# Test each code until the target character's movement on one axis is restricted.
# Now the codes for the other two axes need to be found. They will usually be in close proximity to the code that was just hacked. On some systems, one can usually find another part of the code by adding or subtracting 0x04 to or from the newly-found code's offset. The offset containing the X coordinate is usually first, followed by the Y coordinate, and then the Z coordinate. Note the existing values for the surrounding offsets and enter those as codes.
#* If the character is unable to move to the side or toward the game camera, then the correct code for the X or Z coordinate has most likely been found.
#* If the character is unable to jump, then the correct code for the Y coordinate has most likely been found.
# The first 16 bits of the value are usually enough to change a character or object's position, so assign those to a code and enjoy the results.

Due to their nature, position modifiers are very easy to find usable values for. Simply view the offsets from each of the codes for the target character/object's coordinates, and apply those to the target character/object's position modifier, or a completely different object's position modifier.

==Infinite Time==
Timers can be painfully simple, or they can send the hacker into violent tantrums. It all sort of depends on the game and system. The general idea is to just keep searching greater/less depending on the way the timer is counting, but they can vary a lot. Timers come in any size from 8-bit to 64-bit, but 16-bit and 32-bit ones are more common.

===Basic Timer Hack Strategy===
# First get to the point in the game where the timer starts counting up/down. Then pause/freeze and start an unknown value search (initial dump). 32-bit is probably the way to start, if possible. If this fails, try 16-bit and so on.
# Now let the timer count down just a little, and do a less than search. Keep letting it count down and doing less than until the results are narrowed enough to test.
# In some cases, restarting the timer and doing a greater than followed by continuing with the above step will help.
# Now when the results are narrowed enough to start testing, set a constant write/freeze on the address using a high value to see if the timer still counts down. If the trainer being used lists all the previous values of the timer, a little educated guessing can help with picking out the right result to try. Sometimes a timer will be as simple as the value on screen being the same value in memory, but don't bank on it.
# Don't be surprised if none of the results work. Try a different bit size or one of the extra tips below.

===Timer Tips===
* Clock style (00:00:00) timers tend to be 32-bit, but they can be found even if the user is searching 16-bit. One thing to be cautious of though is the amount of timer going by between searches. Let the seconds or minutes count up/down a couple digits, depending on the timer's speed.
* Don't be afraid to try searching the opposite direction when the search instructions above don't work. Sometimes a timer counting down on screen is really counting up internally. It's odd, but it happens. The timer on Starfox64 kept some hackers guessing for years because the timer on screen was stored a as 32-bit value counting down, while the real timer was a 16-bit value counting up! Just to add insult, the real timer was only a few bytes from the on-screen one.
* Beware of fake timers. A lot of timers there's both and on-screen timer and a real one. Test the code for as long as it would normally take the timer to run out to be sure it's really being stopped.
* In some cases, the right address is found, but attempts to freeze it will fail. This is because the game reads/writes the location faster than the cheat device can. The only way around this is to try hacking it with assembly. Hackers wanting to attempt this will need this address, so hang onto it.

==Size Modifier==
To Do

===Objects That Change Size Normally===
To Do

===Objects That Never Change Size===
To Do

==Image Modifier==
To Do

==Cutscene Modifier==
To Do

==Skip Intros==
To Do

==Assembly Hacking==
Assembly is a generic all-encompassing term for human-readable machine code. A CPU is very good at working with numbers and interpreting their meanings; humans are at a disadvantage here, and it makes working with machine code very difficult. Assembly makes it quite a bit easier by providing a 1:1 ratio to machine code. Where machine code might look like a long string of ones and zeros, assembly might look more like this:

Opcode Operands Comments
lw r0, =0x203FA70 @ Load pointer to lives variable
mov r1, #31 @ Load number of lives we want
str r1, [r0] @ Store lives value to variable
bx lr @ Return

This example is ARM/Thumb assembly for CPUs such as the ARM7 and ARM9 available in GBA and NDS. The comments help the programmer understand the assembly code even better than the CPU does; the CPU will execute any instruction given to it without determining the consequences or raising concern. The responsibility of executing the right instructions falls solely on the programmer. This example brings to light what is meant by "human readable machine code." Compared to "0011010011101001100101..." the assembly is a lot more understandable.

That aside, assembly is not without its own faults. It is often very difficult for a novice (with no previous programming experience) to learn and understand. This is due to assembly's naturally low level; an assembly programmer talks to the machine in its own language (via a translator).

Programs that translate assembly into its machine code counter-part are called assemblers and are available for various target CPUs and platforms. The target CPU is what the assembler needs to output machine code for. The platform is the CPU/OS that a programmer will use to write the assembly and translate/assemble the code. Assembling code for a target that differs from the working platform called cross platform development.

Hacking assembly is just the opposite; a hacker will translate machine code into human-readable assembly to understand the code and make changes as necessary. A program which does this kind of translation is called a disassembler, which are just as widely available as assemblers. The trouble is, few disassemblers output assembly that can be assembled back into machine code by an assembler. For the purposes of this tutorial, doing so would be out of scope because it is not usually a requirement to rebuild an entire program just to hack it. [[EnHacklopedia:Tools|Renegade64]] contains a code assembler which is much closer to what a hacker will use when patching assembly.

===Rundown of Assembly Languages===
Assembly languages define a set of instructions specific to one family of CPUs. Depending on the CPU or assembly language, there may be only a small handful of instructions, or there may be a vast library of instructions available to the CPU. There are two common terms for CPUs which define the type of instruction set a CPU will use. The CISC machines generally have many different forms of the same instruction, while RISC machines typically have only one (rarely two or more) form of the same instruction. The names "Complex" and "Reduced" do not refer to the size of the instruction set, but to the ratio of instruction forms to single instructions (the smaller the number of instruction forms, the more "reduced" the instruction set). Some RISC machines have a far greater instruction set than CISC machines. For example: PowerPC(RISC) compared to 6502(CISC).

Regardless of the type of instruction set, an instruction is typically comprised of two parts: The opcode and the operands. The opcode defines the command which the CPU will use. The operands define how the CPU will execute the instruction. The number of operands can vary, depending on the language and the opcode. Some opcodes have no operands at all; these are called "implied" operands, since the operand is implied to be non-existent.

The most basic example of such an opcode is NOP. NOP, also sometimes called NOOP, exists on every major CPU in use today (though the assembly instruction is the same across all instruction sets, the machine code is not; yet another example of making machine code easier to understand). Its function is simply wasting CPU cycles; it does nothing else. This seems impractical by today's standards, where timing is not as crucial as it once was, and in most cases it may be desired to use every last cycle to its greatest potential. However, the NOP instruction is important for many tasks. It can be used to help synchronize multiple CPUs by having both wait for a small time, for instance. For a hacker, the NOP instruction becomes an invaluable tool for manipulating programs. Any instruction can be overwritten with a NOP to disable it completely. Overwriting the instruction which changes a character's health in a game will disable the game from changing any health at all.

To Do: Explain operands.

==Breaking Limits==
To Do

==Infinite Ammo For All Guns/Levels==
To Do

==Changing Starting Items/Stats==
To Do

==Killing Timers==
Timers can be stopped with assembly the same as anything else, but caution should be taken in doing so. Setting a breakpoint on write of the timer address and making disabling the instruction which write to the timer address. Now here's where the caution comes in. Some assembly routines aren't just used for that single timer. There are times when stopping a simple timer can freeze half the stuff in the game, so be careful.

There are also times when the real timer can't be found normally, but a fake (on-screen) one can. These are more difficult to disable, but the real timer can sometimes be traced by doing a write breakpoint on the fake timer. Sometimes, it's as easy as looking as the instructions nearby. The game may be converting the timer to a different format to show on-screen immediately after it decrements and stores it. If the answer isn't obvious, the only thing to do is to backtrace the assembly to figure out where the value for the fake timer came from. It has to get it based on the real one, somehow. This is difficult to explain in real detail because games vary so much.

==Rapid Fire==
To Do

==Mega Jump==
To Do

==Invincibility==
To Do

==Debug Menus==
To Do

==Walk Through Walls==
Hacking a walk through walls code involves locating the game's clipping routines, which can often be very spread-out and embedded deep in the physics engine. This theory will focus on 3D games, but much of it can also be applied to many 2D games. 2D games simply lack a Z axis.

Locating the clipping routines may take a few different steps, depending upon the game and how it was programmed. Locating the main character's coordinates is the best place to start. Coordinates can be found with a simple 32-bit unknown search. With 3D games, there are always three coordinates named "X", "Y", and "Z". The Y coordinate is the usually easiest to find because no matter which way the character or "camera" are facing, the Y axis is always up-and-down. Reference [[#Position_Modifier|Position Modifiers]] for more information on locating coordinates.

Coordinates are almost always placed in memory in order; the Y coordinate will appear between the X and Z coordinates. This idea can be exploited to locate all three coordinates after finding just one of them. Once the X and Z coordinates have been pin-pointed, these can be used to locate the clipping routines.

The second step requires a write watchpoint on either the X or Z coordinate. Choosing which coordinate to use is entirely up to the hacker, as they will typically both lead to the same routines. Setting a breakpoint on one of the coordinates will usually cause a break right away, even with the main character standing completely still. If the break-causing store instruction is disabled, sometimes additional breaks will occur. It is wise to keep a list of all addresses which cause breaks without moving, and the instruction data they contain. This makes it easy to re-enable the instruction later. As soon as there are no other breaks occurring while the main character is standing still, this step is complete.

The next step requires checking if any breaks occur while walking in an open area, without touching any walls. Most of the character control routines have already been disabled, by this point, and in most cases the main character should be "stuck" walking along only one axis. However, in a few other cases, a break will occur as soon as the main character begins to move. If this happens, the instructions causing these breaks must also be disabled. When the main character is able to glide peacefully along a single axis, the only breaks occurring should be when the main character hits a wall.

With all of the character controlling routines disabled, walking into any wall should cause a break as the physics engine is attempting to clip the character's forward movement against the wall while retaining lateral movement (to "slide" against the wall when hit at an angle). This works because most physics engines want to adjust the coordinate for clipping (the one which was disabled for standard control) separately from the standard control routines. (Note that not all games will exhibit this behavior. For such games, the clipping will be done before the standard control routines write to the coordinates.)

At this point, the first clipping routine has been located. Disabling it (either by disabling the single instruction with a NOP instruction, or by branching over the write or the entire routine if it can be done safely) should result in one of two possibilities: The character will either move through the wall, or yet another break will occur. In the case of the former, the code has been found (or at least one part for one of the two axes). For the latter, these clipping routines can be consecutively disabled, with each new routine found becoming another part of the completed code; all clipping routines must be disabled for both the X and Z axes.

That concludes the basic rundown for walk through walls codes. To recap: Locate the clipping routines by disabling the standard controlling routines. Then disable those clipping routines. Test the game with the clipping routines disabled by re-enabling all of the standard controlling routines, or simply by resetting the console with the clipping-disabling codes enabled.

==Jesus Mode==
A Jesus Mode code allows the player to walk on water just like Jesus in the bible did. One of the most complex hacks to make, it requires great skills with a debugger and a real familiarity with assembly language. The first Jesus Mode code made was for Super Mario 64 by Parayste.

The idea behind Jesus Mode is to figure out how the game determines when the player hits the water, and then edit the code so that the water routine acts the same way the routine for solid ground does.

[[Image:Mario64_jesus_mode.png|center|Mario walks on water (N64)]]

[[Category:EnHacklopedia]]

File:Mario64 jesus mode.png

2010-10-10T07:21:23Z

Raing3: Mario walks on water (N64)

Mario walks on water (N64)

File:Renegade code search.png

2010-10-10T07:10:57Z

Raing3: Renegade: Code Search Window

Renegade: Code Search Window

EnHacklopedia:Number and Data Encoding Formats

2010-10-09T00:29:15Z

Raing3: New page: ==Modulus== The modulus instruction (represented by % in C-style languages and MOD in other places) is a fundamental operation that is not used very often outside of computer science and a...

==Modulus==
The modulus instruction (represented by % in C-style languages and MOD in other places) is a fundamental operation that is not used very often outside of computer science and advance math. All it does is returned the remainder of a division. For example, 3 % 2 = 1, while 3 % 3 = 0. Modulus is often used to determine divisibility, as if one number modulus a second is zero, then the first number is evenly divisible by the second. The modulus is also used in hashing algorithms.

==Decimal==
The decimal method of representing numbers is the most common method used in mathematics. 10 digits (0 - 9) exist each of which occupies one decimal place. Decimal is also known as base-10, due to the fact that is both consists of 10 different digits and because each decimal place has its value based on a power of ten. In a multiple digit number, each successive digit to the left has an increased value by a factor of ten, while each successive digit to the right has a decreased value by a factor of ten. For instance, the number 873 is equivalent to 8 * 102 + 7 * 101 + 3 * 100. This is an important concept as all other base-n representations of numbers work in a similar fashion. Decimal numbers sometimes have a trailing "d" on them to make the base being used explicit. In this document, if there are no other base markers (trailing "b" or preceding "0x"), then the number is in base-10.

==Binary==
At the lowest level, a computer is just a series of switches with two settings - high voltage and low voltage. By convention, the number 1 represents the high (or on) setting and 0 represents the low (or off) setting. Just as decimal places are based on powers of ten, binary (or base-2) places are based on powers of two. For instance, the number 110 is equal to 1 * 102 + 1 * 101 + 0 * 100 in decimal and 1 * 22 + 1 * 21 + 0 * 20 in binary. While the binary representation does allow one to easily perform [[#AND|bitwise operations]], it has a drawback. The length of the representation becomes massive quite quickly. A three digit decimal number requires a minimum of seven binary digits and a four digit decimal number requires a minimum of ten binary digits. By the number one million, twenty binary digits are required. Binary numbers are represented by a trailing b: 110 is a decimal number; 110b is binary. 1 binary digit is referred to as a "bit".

==Hexadecimal==
Hexadecimal (also called base-16 or hex) is used as a substitute for binary. Hexadecimal has many of the advantages that binary has, but removes binary's largest disadvantage: the massive size. Each hexadecimal digit takes the value of one of 16 different values, 0-15. Values 10 and up are represented as the letters A through F. Because each hexadecimal place is based on a power of 16 and because 16 is equal to 24, hexadecimal numbers are four times shorter than their binary equivalents. Hexadecimal numbers are represented by a preceding "0x" or "$" or a succeeding "h"; For instance, 10d is also 0xA, $A, or Ah. In this document, all hexadecimal numbers are represented with the preceding "0x". 1 hexadecimal digit is known as a nybble or half-byte, while 2 digits is called a byte (8 bits). Larger units are left somewhat ambiguous. A "word" is used to referred to the fundamental data type of a microprocessor. However, this can be 16, 32, or 64 bits, as well as some rather odd sizes on archaic processors, such as 39 bits. For the purposes of this document, a word is 32 bits with a halfword (or short) being 16 and a doubleword (or dword) being 64. A quadword (or qword) will be 128 bits.

==Conversions==
Converting between bases is not that difficult a task, but can require a bit of practice. The easiest conversions to do are being base-16 and base-2. For a base-16 number, all you have to do is convert each digit into its corresponding binary form and keep the order intact. The representations are as follows:

0x0 - 0000b
0x1 - 0001b
0x2 - 0010b
0x3 - 0011b
0x4 - 0100b
0x5 - 0101b
0x6 - 0110b
0x7 - 0111b
0x8 - 1000b
0x9 - 1001b
0xA - 1010b
0xB - 1011b
0xC - 1100b
0xD - 1101b
0xE - 1110b
0xF - 1111b

For instance, to convert 0xDEA2 to binary, you would expand "D" to "1101", "E" to "1110", "A" to "1010", and "2" to "0010", giving you 1101111010100010b.

Converting binary to hexadecimal is similar. Each four bit number is converted into its hexadecimal version. While one can start working from the right when converting hexadecimal to binary, it's important to start on the left when doing the opposite, as starting from the right will give a wrong result unless the binary number has a number of bits that is a multiple of four. For this example, the number 1111010010b will be used. The lowest four bits are 0010b which corresponds to 0x2. Then, 1101b which is 0xD. Finally 0011b, which is 0x3. The base-16 representation is 0x3D2.

Converting binary and hexadecimal into decimal is easy as well, but a much different task. It is good practice to know the first few powers of 2 (1, 2, 4, 8, 16) and 16 (1, 16, 256, 4096, 65536). The so-called one's place in the number has a value of 1 (20 or 160) and as one moves to the left, the value of the place increases by a factor of 2 or 16 respectively. The convert these values to decimal, multiply the value of the digit in a specific binary or hexadecimal place by that place's value. Do the same for each digit, then add all the products up.

Sample binary to decimal conversion: 110101011101b = 1 * 20 + 0 * 21 + 1 * 22 + 1 * 23 + 1 * 24 + 0 * 25 + 1 * 26 + 0 * 27 + 1 * 28 + 0 * 29 + 1 * 211 + 1 * 212 = 1 + 4 + 8 + 16 + 64 + 256 + 1024 + 2048 = 3,421.

Sample hexadecimal to decimal conversion: 0xBEEF = 0xF * 160 + 0xE * 161 + 0xE * 162 + 0xB * 163 = 15 * 1 + 14 * 16 + 14 * 256 + 11 * 4,096 = 15 + 224 + 3,584 + 45,056 = 48,879.

Converting numbers from decimal to binary or hexadecimal is slightly more problematic. The best way to do this is to find the largest power of 2 (or 16) that is not greater than the decimal number. Divide the number by that power and the result is the highest digit in the converted number. Divide the power by 2 (or 16) and repeat the process with that power and the remainder of the division.

Sample decimal to binary conversion: 132. 128 is 27. 132 / 128 gives 1 with a remainder of 4. Dividing 128 by 2 gives 64. 4 / 64 is 0 with a remainder of 4. Dividing 64 by 2 gives 32. 4 / 32 is 0 with a remainder of 4. Dividing 32 by 2 gives 16. 4 / 16 is 0 with a remainder of 4. Dividing 16 by 2 gives 8. 4 / 8 is 0 with a remainder of 4. Dividing 8 by 2 gives 4. 4 / 4 is 1 with a remainder of 0. At this point we can stop the math. However, we still need to 0-fill the remaining bits. The 2's-place and 1's place still haven't been taken care of, which means two more zeros need to be appended. Our final result is 10000100b.

Sample decimal to hexadecimal conversion: 327. 256 is 162 327 / 256 is 1 with a remainder of 71. 256 / 16 is 16. 71 / 16 is 4 with a remainder of 7. 16 / 16 is 1. 7 / 1 is 7. The converted number is 0x147.

==AND==
One of the fundamental logical and bitwise operations is known as the AND. AND takes in two inputs and produces one output. At its most fundamental level true is returned if both inputs are true and false otherwise. Bitwise AND (represented by &) ANDs each individual bit of a number together and the corresponding bit of the output is the result of ANDing the two input bits. For instance, take 11011111b & 10101101b. Bit n of the output is equal to Bit n of input 1 & Bit n of input 2. Bit 7 of the output will be 1 &s 1, or 1. Bit 6 will be 1 & 0 or 0. Bit 5 will be 0 & 1 or 0. Bit 4 will be 1 & 0 or 0. Bit 3 will be 1 & 1 or 1. Bit 2 will be 1 & 1 or 1. Bit 1 will be 1 & 0 or 0. And bit 0 will be 1 & 1 or 1. The final result is 10001101.

==OR==
OR (represented by |) is another fundamental bitwise operation. On the one-bit level, OR returns 1 if either input is 1 and 0 if both inputs are 0. For multiple bit numbers, the same bit-by-bit process used to AND numbers and be used to OR them. Example: 10011001b | 11001010b = 11011011b.

==XOR==
XOR (represented by ^) is a slightly more advanced bitwise operation. It is similar to OR and takes two inputs. However on the one-bit level, the output is 1 when either input is 1 '''but not both'''. If both inputs are 0 or 1, the output is 0. Example: 10011001b ^ 11001010b = 01010011b.

==NOT==
NOT (represented by ~) is a fundamental bitwise operation. However, unlike AND, OR, and XOR, it only takes in one input. NOT inverts a bit. That is, if the input is 0, the output is 1, and if the input is 1, the output is 0. When performing a NOT, it is important to keep in mind implicit zeros. ~1101b will not be 10b. It will be 11110010b, 1111111111110010b, or 11111111111111111111111111110010b depending on whether the data size is 8-, 16-, or 32-bits.

==Shifts==
A shift does what it implies: it shifts data to the left or to the right; that is, each bit is moved one place over per shift. There are left shifts and right shifts and two varieties of each.

The logical shift (represented by << for left and >> for right) shifts every bit to the left or the right a specified amount. Vacant bit positions are filled with zeros while the high bits (for left shift; low for right) are discarded. For example: 01001101b << 2 = 00110100b.

The arithmetic shift is similar to the logical shift. In fact, the left arithmetic shift is identical to the left logical shift. The difference is what occurs in the right shift. An arithmetic right shift performs the corresponding right logical shift first. Then, the MSB is replaced with what it originally was prior to the shift. Because there is no difference between left logical and arithmetic shifts, << is used to represent both. The right arithmetic shift is represented by >>>. Example: 10111000 >>> 3 = 10010111.

==Rotate==
A rotate is identical to a shift except that instead of the edge bit being thrown away, it is moved to the other end of the number. On a left rotate, the MSB becomes the LSB and on a right rotate the LSB becomes the MSB.

==Two's Complement==
A major problem in the early years of computer science was how to represent negative numbers. After a lot of other formats were tried, the method eventually settled upon was Two's Complement. To turn a negative number into its two's complement representation, you invert the binary representation of that number's positive representation and then add 1. For instance, (assuming an 8-bit data size), -12 would be calculated as follows:

12 = 00001100
~12 = 11110011
-12 = ~12 + 1 = 11110100

Determining what a particular binary representation means is not difficult. If the highest bit is 0, the number is positive and can be calculated as normal. If the highest is 1, then the number is negative. To determine the negative number's magnitude, subtract one and then invert the number. Then convert to decimal like normal. The only exception is when the sign bit is set and every other bit is not.

To determine the value of this representation, set the LSB and determine what this number is. Then subtract one.
Example: 11111110b

The sign bit is set, so the number is negative. Subtracting gives 11111101b. Inverting gives 10b, which is 2. The number is -2.
Example: 00000110b

The sign bit is not set, so the number is positive. Conversion can performed normal. The number is 6.
Example: 10000000b

The sign bit is set and all other bits are not. Adding one gives 10000001b. This number represents -127. Subtracting one from that gives -128.

==Zero- and Sign-Extensions==
Zero- and Sign-Extensions are the two different methods used to extend a value to a larger size, for example an 8-bit value to 16-bits. Zero-extension simply involves adding the appropriate number of zeros to the beginning of the number. For instance, zero-extending 10011111b to 16-bits would result in 0000000010011111b. Sign-extension is slightly different. If the MSB is zero, then the conversion is the same as in zero-extension. However, if the MSB is one, then the appropriate number of ones are added to the beginning of the number instead of zeros. Using the same example, sign-extending 10011111b to 16-bits would result in 1111111110011111b. Sign-extension is used because it allows two's complement numbers to keep their value when extended, whereas zero-extending the number would not.

==IEEE-754==
IEEE-754 is the nearly-universal standard used for representing floating point values. Nearly any computer that contains an FPU will be using this format, and this includes consoles. The small floating point size is 32 bits; floating point values of this size are called single-precision floating point numbers (keyword '''float''' in C-like languages). Of these 32 bits, 1 is set aside for the sign, 8 bits are for the exponent, and 23 bits are for the mantissa. When the sign bit is 1, the number is negative; when it is 0, it is positive. The exponent bits actually store the exponent with 127 added to it, so when the exponent bits are 00000000b, the exponent is -127. The mantissa stores the normalized version of the number. This means that the decimal value is stored without the decimal point; the exponent keeps track of where the decimal point belongs. Normalized numbers have a MSB of one in the mantissa; there are also denormalized numbers, which have a MSB of zero in the mantissa. When using denormalized numbers, the exponent is stored with 126 added to it instead of 127.

Example: -118.625
The number is negative so the sign bit is set.
118.625 in binary is 1110110.101b.

Normalized, the number is 1.110110101 * 26.
The exponent is 6. Adding 127, the exponent is 133 or 10000101b.
The floating point value is 1100001011110110101000000000000b.

Double-precision floating point values also exist (keyword '''double''' in C-like languages). The size is doubled to 64-bits. The exponent is expanded to 11 bits with a bias of 1,023, and the mantissa size is more than double to 52 bits. Finally, the quadruple-precision floating point values (keyword '''long double''' in C-like languages) expands the size to 128 bits, with a 112-bit mantissa and a 15-bit exponent (with a 16,383 bias).

IEEE-754 also allows for signed infinities and NaNs. An infinity is represented by the maximum possible exponent with a mantissa of zero, while an NaN is represented by the maximum possible exponent with a non-zero mantissa.

[[EnHacklopedia:Tools|Float Convert]] is a tool that allows one to convert between decimal floating point numbers and IEEE-754 formatted floating point numbers. However, it only works with single-precision values.

Some basic C code can be used to convert between decimal and IEEE-754 double-precision values. This code is portable and is guaranteed to work on any platform. To convert a double to hex:

#include <stdio.h>

int main()
{
double val = 1.0; //Substitute your value here.
printf("%016I64X\n", *(long long *)&val);
return 0;
}

Converting from hex to double is easy as well:

#include <stdio.h>

int main()
{
long long val = 0x3FF0000000000000LL; //Substitute your value here.
printf("%G", *(double *)&val);
return 0;
}

==BCD==
BCD is an archaic method of representing decimal values. It was used on system without an FPU, such as the SNES. Each nybble in a BCD represents a specific decimal place; because of this, only values 0-9 are legal. The size of a BCD is arbitrary, as is the location where the decimal point exists.

Example: 0x9837. Assuming that the decimal point exists in-between the bytes, this halfword represents the BCD value of 98.37.

==Byte Order==
===Big Endian===
Big endian is a method of storing data. The "big end" of a word is stored first. For instance, the word 0x0A0B0C0D stored at 0x08000000 would have 0x0A stored at 0x08000000, 0x0B at 0x08000001, 0x0C at 0x08000002, and 0x0D at 0x08000003.

===Little Endian===
Little endian is the most common method of storing data. The "little end" of a word is stored first. For instance, the word 0x0A0B0C0D stored at 0x08000000 would have 0x0D stored at 0x08000000, 0x0C stored at 0x08000001, 0x0B stored at 0x08000002, and 0x0A stored at 0x08000003. Many systems, including Nintendo's handhelds, store data this way.

==ASCII==
ASCII is the most commonly used format for encoding characters. Originally a 7-bit encoding, it later expanded to 8-bits to double the number of characters. In ASCII, the letters 'A' through 'Z' are represented by 0x41 through 0x5A and 'a' through 'z' are 0x61 through 0x7A. '0' through '9' are 0x30 through 0x39, and a space is 0x20. While many games encode their text into ASCII, a lot of games use a modified ASCII, where the letters, while still together, start at a different point. For instance, the capital letters may begin a 0x00 instead of their standard ASCII location. A relative search can help search for text in games that use this. A relative searcher searches based on differences between bytes instead of looking for a specific series of bytes. For instance, if one were to search for "ABD", the relative searcher would search for three consecutive bytes where the difference between the first and second was one and the difference between the second and third was two. [[EnHacklopedia:Tools|SearchR3]] is a program that automates this process. Below is an abridged ASCII table, which contains some of the more common characters used. Full ASCII tables are available on other websites, such as [http://www.asciitable.com asciitable.com].

{|cellspacing="0" border="1" width="100%"
!align="center"|Character
!align="center"|Hex
!align="center"|Dec
|-
|align="center"|NULL
|0
|align="center"|0x00
|-
|align="center"|LF (Newline)
|10
|align="center"|0x0A
|-
|align="center"|Space
|32
|align="center"|0x20
|-
|align="center"|!
|33
|align="center"|0x21
|-
|align="center"|"
|35
|align="center"|0x22
|-
|align="center"|#
|35
|align="center"|0x23
|-
|align="center"|$
|36
|align="center"|0x24
|-
|align="center"|'(' - ')'
|40 - 41
|align="center"|0x28 - 0x29
|-
|align="center"|.
|46
|align="center"|0x2B
|-
|align="center"|'0' - '9'
|48 - 57
|align="center"|0x30 - 0x39
|-
|align="center"|'A' - 'Z'
|65 - 90
|align="center"|0x41 - 0x5A
|-
|align="center"|'a' - 'z'
|97 - 122
|align="center"|0x61 - 0x7A
|}

[[Category:EnHacklopedia]]

EnHacklopedia:Tools

2010-10-08T23:45:49Z

Raing3: New page: {|cellspacing="0" border="1" !align="center"|Program !align="center"|Description !align="center"|Author |- !align="center" colspan="3"|NES Tools |- |align="center"|[http://cheats.gbatemp.n...

{|cellspacing="0" border="1"
!align="center"|Program
!align="center"|Description
!align="center"|Author
|-
!align="center" colspan="3"|NES Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nes/fceuxd_sp.rar FCEUXD SP v1.07] [http://cheats.gbatemp.net/hack/tools/nes/fceuxd_sp_source.rar Source code]
|NES Emulator with multiple code hacking features including a RAM searcher and debugger with breakpoint support.
|align="center"|Parasyte BbitMaster Xodnizel Sebastian Porst
|-
!align="center" colspan="3"|SNES Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/snes/snes9x_debug.7z Geiger's SNES9x Debugger Mark 9]
|Modified SNES9x with debugger.
|align="center"|Michael Springer
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/snes/snes9x.zip SNES9x v1.43]
|SNES Emulator with RAM searcher.
|align="center"|Gary Henderson
|-
!align="center" colspan="3"|Genesis Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gen/gens_hacking_version.zip Gens Hacking Version]
|Modified Gens with cheat search.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gen/gens_hacking_version.zip Gens KMod v0.4]
|Modified Gens with debugger.
|Kaneda
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gen/gens_hacking_version.zip Gens Tracer]
|Slightly outdated version of Gens with a nice tracer.
|
|-
!align="center" colspan="3"|N64 Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/1964.exe 1964 v0.99]
|N64 emulator. Compatible with Renegade.
|Joel Middendorf
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/gs_n64_crypt.zip GS Pro N64 Crypt]
|Tool for encrypting/decrypting the GS/AR rom for flashing with the official utils.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/lemasm.zip LemAsm v0.1]
|R4300i Assembler/Disassembler.
|Lemmy
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/mupen64.exe Mupen64 v0.5.1]
|N64 emulator. Compatible with Renegade.
|Hacktarux
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/gs_pro_utils.zip N64 Version 3 Utilities]
|Datel's official software for use with GS/AR Pro.
|Datel
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/patch_n64_utils.zip N64 Version 3 Utilities Hi-Res Patch]
|Patched utils to allow searching the hi-res memory. Also adds support for Windows NT/2K/XP (UserPort required).
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/nemu08.zip Nemu v0.8]
|N64 emulator with debugger. Compatible with Renegade.
|Lemmy LaC
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/niew.zip Niew]
|R4300i Assembler/Disassembler (No COP1 support).
|Titanik
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/pcs_01.rar Parasytic Cheat Search V0.01] [http://cheats.gbatemp.net/hack/tools/n64/pcs_02.rar Parasytic Cheat Search V0.02]
|PJ64 Plugin for RAM searching.
|Parasyte
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/perfect_trainer.rar Perfect Trainer v1.0b]
|An edited GS Pro rom for hacking Perfect Dark and a few other hi-res games.
|IceMario
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/project64.exe Project 64 v1.6]
|N64 emulator. Compatible with Renegade.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/project64_debug.zip Project 64 Build 52 (Debug Version)]
|Debug version of Project64. Tons of nice features, but it lacks the most important one: BREAKPOINTS!
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/n64/xploder64_utils.exe Official Xploder 64 Utilities]
|The official software for use with Xploder64.
|Fire International
|-
!align="center" colspan="3"|PSX Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/caetla.zip Caetla 0.34 With Utilities] [http://cheats.gbatemp.net/hack/tools/psx/caetla128b.zip Caetla 1.28b]
|Homebrew PSX cheat device ROM for flashing to old PC Comms link devices. v1.28b is a hacked version.
|xianaix CMX
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/psx_pro_modded.zip GSProModded]
|Official utilities for the cartridge based GS/AR Pro with the ar3stop ROM included. This allows playing backups (but not imports) without a mod-chip.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/pcsx_debug.zip PCSX with Debugger]
|PSX emulator, compatible with Renegade. Also has a debugger.
|Linuzappz
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/cdx_utils.zip Playstation Utitlies for CDX Version]
|Official utilities for the CDX based GS/AR.
|Datel
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/psx_hack_utils.exe Playstation Version 3 Utitlies]
|Official utilities for the CDX based GS/AR.
|Datel
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/psx_emulator.rar pSX (emulator) v1.11]
|PSX emulator, compatible with Renegade. Has a debugger, but it's not nearly as useful as PCSX.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/ssspsx.zip SSSPSX]
|PSX emulator, compatible with Renegade.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/psx/undatel.zip Undatel]
|Utility for encrypting/decrypting the PSX GS/AR Pro ROM.
|
|-
!align="center" colspan="3"|DC Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/dc/dccrypt.zip DCcrypt]
|Dreamcast GS/AR code encryptor/decryptor.
|Parasyte
|-
!align="center" colspan="3"|GCN Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/gcn_asm_gui.rar GCN ASM GUI]
|GCN assembler/disassembler.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/gcncrypt.zip GCNcrypt v1.5]
|GCN AR code encryptor/decryptor.
|Parasyte
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/gcnrd.rar GCNrd v1.10b]
|Gamecube memory searcher and debugger.
|Parasyte
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/gcnrd_gui.rar GCNrd GUI]
|GUI frontend for GCNrd.
|Kenobi
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/psoload.zip PSOload v2.0a]
|PSO-based loader.
|costis
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gcn/sdload.zip SDLoad]
|SD card-based loader.
|costis
|-
!align="center" colspan="3"|PS2 Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/cb2crypt.rar CB2crypt]
|CodeBreaker PS2 code encryptor/decryptor. Works with versions up to v9.x.
|misfire
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/cb2util.rar CodeBreaker PS2 File Utility v1.0]
|Utitility for converting/encrypting/decrypting files for CodeBreaker PS2.
|misfire
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/maxconvert.zip MAXConvert v0.6]
|Utitility for encrypting/decrypting and converting PS2 codes between formats.
|Parasyte Pyriel
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/maxcrypt.zip MAXcrypt v1.5]
|AR MAX code encryptor/decryptor.
|Parasyte
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/ps2_code_decoder.zip PS2 Doce Decoder]
|Converts PS2 code between several different formats.
|iN tHE mIND
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/ps2/ps2dis.zip PS2DIS]
|Assembler/Disassembler for use with PS2 SLUS/SLES/etc files.
|hanimar
|-
!align="center" colspan="3"|GB Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gb/bgb.zip BGB v1.12]
|Gameboy and Gameboy Color emulator with Debugger.
|bgb
|-
!align="center" colspan="3"|GBA Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gba/arcrypt.rar AR Crypt v3.12 beta]
|GS/AR code encryptor/decryptor; Code converter.
|Kenobi
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gba/cbacrypt.exe CBAcrypt]
|Codebreaker code encryptor/decryptor.
|Parasyte
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gba/gbatool.exe GBAtool v1.20]
|CBA Master code finder, slide code expander and button code generator.
|CMX
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gba/visual_advance_h.zip VisualBoy Advance: Hacker's Edition]
|GBA emulator. Modified version of VBA 1.7.2 with additional searching options.
|Forgotten Kenobi Labmaster
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/gba/visualboy_advance_sdl_h.zip VBA-SDL: Hackers Edition]
|Modified version of VBA-SDL 1.7.2. GBA emulator with debugger.
|Forgotten Kenobi Labmaster
|-
!align="center" colspan="3"|NDS Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/ards_pointer_tool.rar ARDS Pointer codes Tool]
|Helps create ARDS Pointer codes.
|kenobi
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/cbdscrypt.rar CBDSCrypt v1.02]
|Encrypts and decrypts codes for the CBDS. Also creates master codes.
|kenobi
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/kode_garage.rar Kode Garage]
|Slide code and button code generator, code analyzer, code porter.
|KicKenchicKen57
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/nds_convert.rar NDS Convert v2.12]
|Converts codes between AR, CB, and Dipstar formats.
|Dlong
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/ndstool.exe NDS Tool v1.31]
|NDS ROM manipulator.
|Darkfader
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/nds/no_dollar_gba.rar No$GBA v2.4b]
|NDS Emulator; Renegade compatible.
|Martin Korth
|-
!align="center" colspan="3"|Miscellaneous Tools
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/float_convert.exe FloatConvert]
|Converts floating pointer numbers between decimal and IEEE-754.
|
|-
|align="center"|'''Game Genie Encoder:''' [http://cheats.gbatemp.net/hack/tools/misc/gg_encoder_linux.tar.bz2 Linux] [http://cheats.gbatemp.net/hack/tools/misc/gg_encoder_osc.dmg Mac OSX] [http://cheats.gbatemp.net/hack/tools/misc/gg_encoder_win32.zip Windows]
|Encodes and Decodes Game Genie codes for NES, SNES, Genesis, Game Boy, and Game Gear.
|
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/gscc2k2.zip Game Software Code Creator 2K2]
|N64 and PSX code searchers and debugger.
|CMX
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/gscc2k2_fix.zip Game Software Code Creator 2K2 VRAM Fix]
|GSCC2K2 patched to fix the 16-Bit/24-Bit radio button problem with VRAM dumping.
|CMX
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/renegade64.rar Renegade v1.68]
|Multipurpose tool: Hooks emulators for several systems to search for codes among other things.
|Viper187
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/searchr3.exe SearchR3 V1.0]
|Performs relative searches for strings.
|Antiriad DeJap^Raine
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/tsearch.zip TSearch v1.6]
|Tool for searching the memory of PC games. Includes a somewhat simple x86 debugger as well.
|Corsica Production
|-
|align="center"|[http://cheats.gbatemp.net/hack/tools/misc/userport.zip UserPort]
|Driver for Windows XP/2000 to allow older programs full access of the parallel port.
|Thomas Franzon
|}

[[Category:EnHacklopedia]]

EnHacklopedia:Documents

2010-10-08T23:44:29Z

Raing3:

{|cellspacing="0" border="1"
!align="center"|Document
!align="center"|Description
|-
|[http://cheats.gbatemp.net/hack/documents/6502.txt 6502 Reference]
|Contains information on every opcode for the 6502, as well as the status flags and addressing modes. 6502 is the processor used in the NES.
|-
|[http://cheats.gbatemp.net/hack/documents/65816.txt 65816 Reference]
|Contains information on every opcode for the 65816, as well as the status flags and addressing modes. 65816 is the processor used in the SNES.
|-
|[http://cheats.gbatemp.net/hack/documents/arm.pdf ARM Reference]
|Official ARM Reference Manual. The GBA contains an ARM7 processor and the NDS has both an ARM7 as well as an ARM9.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_arm.pdf ARM Quick Reference Card]
|A three page quick reference for the ARM instruction set.
|-
|[http://cheats.gbatemp.net/hack/documents/gbatek.html GBA Tek]
|Unofficial GBA and NDS reference.
|-
|[http://cheats.gbatemp.net/hack/documents/gekko_user_manual.pdf Gekko User Manual]
|Official Gekko (Gamecube) reference manual.
|-
|[http://cheats.gbatemp.net/hack/documents/hitachi_sh7750.pdf Hitachi SH7750 User's Manual]
|Official reference manual for the SH7750 processor. Could be useful assembly reference for Dreamcast.
|-
|[http://cheats.gbatemp.net/hack/documents/m68000prm.pdf m68k Programmer's Reference Manual]
|Official reference manual for the m68k processor. The m68k is used in the Sega Genesis.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol1.pdf MIPS32 Architecture For Programmers: Volume I]
|"Introduction to the MIPS32 Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol2.pdf MIPS32 Architecture For Programmers: Volume II]
|"The MIPS32 Instruction Set" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol3.pdf MIPS32 Architecture For Programmers: Volume III]
|"The MIPS32 Privileged Resource Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/n64ops.zip Nintendo 64 Toolkit]
|Contains information on the R4300i processor which the N64 uses as well as other miscellaneous features of the N64.
|-
|[http://cheats.gbatemp.net/hack/documents/psx_documentation_project.pdf PSX Documentation Project]
|Everything you ever wanted to know about the PSX but were afraid to ask.
|-
|[http://cheats.gbatemp.net/hack/documents/r4300i_datasheet.pdf R4300i Datasheet]
|The official info on the r4300i processor from MIPS.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_thumb.pdf THUMB Quick Reference Card]
|A three page quick reference for the THUMB instructions set. THUMB is a special state of ARM that contains different instructions.
|-
|[http://cheats.gbatemp.net/hack/documents/z80080.pdf Z80 CPU Family User's Manual]
|Official reference manual for the Z80 processor. The Z80 is used in the Sega Master System and Game Gear, as well as all Game Boy models prior to the GBA.
|}

[[Category:EnHacklopedia]]

EnHacklopedia:Documents

2010-10-08T23:43:10Z

Raing3:

==Documents==
{|cellspacing="0" border="1"
!align="center"|Document
!align="center"|Description
|-
|[http://cheats.gbatemp.net/hack/documents/6502.txt 6502 Reference]
|Contains information on every opcode for the 6502, as well as the status flags and addressing modes. 6502 is the processor used in the NES.
|-
|[http://cheats.gbatemp.net/hack/documents/65816.txt 65816 Reference]
|Contains information on every opcode for the 65816, as well as the status flags and addressing modes. 65816 is the processor used in the SNES.
|-
|[http://cheats.gbatemp.net/hack/documents/arm.pdf ARM Reference]
|Official ARM Reference Manual. The GBA contains an ARM7 processor and the NDS has both an ARM7 as well as an ARM9.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_arm.pdf ARM Quick Reference Card]
|A three page quick reference for the ARM instruction set.
|-
|[http://cheats.gbatemp.net/hack/documents/gbatek.html GBA Tek]
|Unofficial GBA and NDS reference.
|-
|[http://cheats.gbatemp.net/hack/documents/gekko_user_manual.pdf Gekko User Manual]
|Official Gekko (Gamecube) reference manual.
|-
|[http://cheats.gbatemp.net/hack/documents/hitachi_sh7750.pdf Hitachi SH7750 User's Manual]
|Official reference manual for the SH7750 processor. Could be useful assembly reference for Dreamcast.
|-
|[http://cheats.gbatemp.net/hack/documents/m68000prm.pdf m68k Programmer's Reference Manual]
|Official reference manual for the m68k processor. The m68k is used in the Sega Genesis.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol1.pdf MIPS32 Architecture For Programmers: Volume I]
|"Introduction to the MIPS32 Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol2.pdf MIPS32 Architecture For Programmers: Volume II]
|"The MIPS32 Instruction Set" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol3.pdf MIPS32 Architecture For Programmers: Volume III]
|"The MIPS32 Privileged Resource Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/n64ops.zip Nintendo 64 Toolkit]
|Contains information on the R4300i processor which the N64 uses as well as other miscellaneous features of the N64.
|-
|[http://cheats.gbatemp.net/hack/documents/psx_documentation_project.pdf PSX Documentation Project]
|Everything you ever wanted to know about the PSX but were afraid to ask.
|-
|[http://cheats.gbatemp.net/hack/documents/r4300i_datasheet.pdf R4300i Datasheet]
|The official info on the r4300i processor from MIPS.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_thumb.pdf THUMB Quick Reference Card]
|A three page quick reference for the THUMB instructions set. THUMB is a special state of ARM that contains different instructions.
|-
|[http://cheats.gbatemp.net/hack/documents/z80080.pdf Z80 CPU Family User's Manual]
|Official reference manual for the Z80 processor. The Z80 is used in the Sega Master System and Game Gear, as well as all Game Boy models prior to the GBA.
|}

[[Category:EnHacklopedia]]

EnHacklopedia:Documents

2010-10-08T14:24:10Z

Raing3: New page: ==Documents== {|border="1" !align="center"|Document !align="center"|Description |- |[http://cheats.gbatemp.net/hack/documents/6502.txt 6502 Reference] |Contains information on every opcode...

==Documents==
{|border="1"
!align="center"|Document
!align="center"|Description
|-
|[http://cheats.gbatemp.net/hack/documents/6502.txt 6502 Reference]
|Contains information on every opcode for the 6502, as well as the status flags and addressing modes. 6502 is the processor used in the NES.
|-
|[http://cheats.gbatemp.net/hack/documents/65816.txt 65816 Reference]
|Contains information on every opcode for the 65816, as well as the status flags and addressing modes. 65816 is the processor used in the SNES.
|-
|[http://cheats.gbatemp.net/hack/documents/arm.pdf ARM Reference]
|Official ARM Reference Manual. The GBA contains an ARM7 processor and the NDS has both an ARM7 as well as an ARM9.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_arm.pdf ARM Quick Reference Card]
|A three page quick reference for the ARM instruction set.
|-
|[http://cheats.gbatemp.net/hack/documents/gbatek.html GBA Tek]
|Unofficial GBA and NDS reference.
|-
|[http://cheats.gbatemp.net/hack/documents/gekko_user_manual.pdf Gekko User Manual]
|Official Gekko (Gamecube) reference manual.
|-
|[http://cheats.gbatemp.net/hack/documents/hitachi_sh7750.pdf Hitachi SH7750 User's Manual]
|Official reference manual for the SH7750 processor. Could be useful assembly reference for Dreamcast.
|-
|[http://cheats.gbatemp.net/hack/documents/m68000prm.pdf m68k Programmer's Reference Manual]
|Official reference manual for the m68k processor. The m68k is used in the Sega Genesis.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol1.pdf MIPS32 Architecture For Programmers: Volume I]
|"Introduction to the MIPS32 Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol2.pdf MIPS32 Architecture For Programmers: Volume II]
|"The MIPS32 Instruction Set" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/mips32_vol3.pdf MIPS32 Architecture For Programmers: Volume III]
|"The MIPS32 Privileged Resource Architecture" Official reference manual for MIPS32 architectures. Covers the CPU used in PSX and N64.
|-
|[http://cheats.gbatemp.net/hack/documents/n64ops.zip Nintendo 64 Toolkit]
|Contains information on the R4300i processor which the N64 uses as well as other miscellaneous features of the N64.
|-
|[http://cheats.gbatemp.net/hack/documents/psx_documentation_project.pdf PSX Documentation Project]
|Everything you ever wanted to know about the PSX but were afraid to ask.
|-
|[http://cheats.gbatemp.net/hack/documents/r4300i_datasheet.pdf R4300i Datasheet]
|The official info on the r4300i processor from MIPS.
|-
|[http://cheats.gbatemp.net/hack/documents/qrc_thumb.pdf THUMB Quick Reference Card]
|A three page quick reference for the THUMB instructions set. THUMB is a special state of ARM that contains different instructions.
|-
|[http://cheats.gbatemp.net/hack/documents/z80080.pdf Z80 CPU Family User's Manual]
|Official reference manual for the Z80 processor. The Z80 is used in the Sega Master System and Game Gear, as well as all Game Boy models prior to the GBA.
|}

3 in 1 Expansion Pack for EZ-Flash V

2009-04-02T10:23:41Z

Raing3: The download link to NDS Backup Tools 3in1 was broken so I changed it to a GBAtemp link.

AKA: 3-in-1, 3 in 1, EZ Expansion Pack, EZ-Flash 3-in-1, EZ-Flash 3 in 1, Expansion Pack 
Manufactured by: [http://www.ezflash.cn EZ-Flash]
[[Image:3in1-1.jpg|350px|3 in 1 Expansion Pack (Only for DS Lite)|right]]
[[Image:EZ-Flash_3in1_gba_sized.jpg|350px|3 in 1 Expansion Pack (GBA Cartridge Sized)|right]]

== Variants ==
*3 in 1 Expansion Pack for EZ-Flash V for DS Lite (White or Black)
*3 in 1 Expansion Pack for EZ-Flash V for DS (AKA DS "Phat" Version or GBA Size)

Note: There are two chip set variations, where one chip set has succeeded the first. This has resulted in changes in source code provided to third-party developers. According to the EZ Team, this change was due to a shortage of a specific flash chip.

== General ==
The 3 in 1 Expansion Pack is a [[:Category:NDS Slot-2 Carts|NDS Slot-2 Cart]] that works in conjunction with [[:Category:NDS Slot-1 Carts|NDS Slot-1 Carts]]. The device officially attempts to integrate three distinct solutions. First, the device is capable of loading GBA games stored in slot-1 devices in a manner similar to previous slot-2 solutions created by the EZ-flash team. Secondly, the 3 in 1 is a memory expansion pack. Finally, the device is a competing rumble pak expansion for games that support official DS rumble pack. Furthermore, open third-party access to the hardware features have expanded the capability of the Expansion Pack.

The 3 in 1 Expansion Pack for EZ-Flash V can be officially purchased as a bundle with the EZ-Flash V or separately. The product was specifically designed for [[EZ-Flash V]], but users of other slot-1 cards are able to utilize the Expansion Pack.

== Hardware Features ==

* 256 Mb (32 MB) of NOR Flash Memory. This type of memory is able to retain data without requiring uninterrupted power. Depending on data size, writing may take up to several minutes. One typical use includes copying over a GBA ROM, thereby allowing the 3-in-1 to act like a real GBA cartridge.
* 128 Mb (16 MB) of PSRAM. This memory does not retain data when the power is turned off. However it can be written at speeds much faster than NOR memory.
* 4 Mb (512 KB) of battery backed SRAM for save data. The battery is necessary to retain data.
* Programmable embedded "rumble pak" (haptic feedback) device

== Software ==

=== Official ===
# GBA Loader:
#* GBA ROMs and save data are stored long-term in the Slot-1 device memory
# 128 Mb (16 MB) PSRAM Expansion:
#* Extra RAM necessary for programs like DS Opera Web Browser loaded from Slot-1 device.
# Rumble function:
#* Works with all official rumble enabled NDS games and homebrew loaded from Slot-1 device.
#* Rumble can be set to three levels of intensity.

=== Third-Party ===
The source code necessary to utilize the key hardware features of the expansion pack is readily available to developers. There have already been many successful solutions for third-party slot-1 carts. There are many practical and creative projects openly available in the homebrew scene.
{| class="wikitable"
|-
! Name & Link
! Author
! Program Type
! Brief Summary
|-
| [http://ezflash.sosuke.com/viewtopic.php?t=4262 Standalone Browser Patch]
| Triforce, Cory1492
| Patcher
| Patches the DS Browser allowing automatic detection of the 3 in 1 PSRAM
|-
| [http://ezflash.sosuke.com/viewtopic.php?t=4767 Standalone Rumble Patch]
| anonYmous
| Patcher
| Patching tool for DS ROMS that support rumble. This allows automatic detection of the rumble hardware, therefore not requiring any tool to turn on the rumble feature. This is a manual version of the automated patching done by the EZ-Flash V.
|-
| [http://ezflash.sosuke.com/viewtopic.php?t=4749 GBALdr]
| Cory1492
| GBA ROM Loader
| A homebrew application run from the DS that will load games directly to NOR memory, load/save .sav files, and can auto-backup the save data currently on the cart when loading a new game. Due to the fact that it only loads games into NOR memory, it can be painfully slow, taking up to 5 minutes in some cases. Cory1492 has recently updated the GBALdr program to fix the problems detecting and running GBA games with newer 3in1 cards which have different hardware components to earlier versions. Full details of the updated GBALdr can be found [http://nds.cmamod.com/2008/01/27/gbaldr-3in1-01-final-hw-abstraction-update/ here].
|-
| [http://ezflash.sosuke.com/about5006.html 3in1 ExpPack Tool] (Succeeded by GBA ExpLoader)
| Rudolph
| GBA ROM Loader / Hardware Enabling
| Another homebrew application that runs from the DS. This is by far one of the best loaders available. Just as with GBALdr, it can load games to the 3 in 1. What makes it different than GBALdr is the fact that it can load all ROMS under 16MB directly to the PSRAM on the 3 in 1, making copy time less than a minute in nearly all cases. Additionally, it can load games to NOR memory if they exceed 16MB. Two other features that I find to be unique to this tool is the ability to turn the Rumble Pack on and off (for supported DS games) and the ability to switch the cart over to an Expansion Pack for use with the Opera Browser. Rudolph recently updated the 3in1 ExpPack software and renamed it to GBA ExpLoader. Compatible with the first chip set. The latest version can be downloaded from [http://blog.so-net.ne.jp/Rudolph/ here]
|-
| [http://kotei.blog.so-net.ne.jp/ GBA ExpLoader] (Successor to 3in1 ExpPack Tool by Rudolph)
| Rudolph
| GBA ROM Loader and Patcher / Hardware Enabling
| Rewrite of the 3in1 ExpPack Tool allowing expanded compatibility with not only the succeeding 3in1 chip set, but also other [[:Category:NDS Slot-2 Carts|slot-2 carts]]. Differences from 3in1 ExpPack Tool: automatic GBA ROM file patching, multiple save mechanism, and extended compatibility with specific save types (for example, ROM 1386 - Famicom Mini Vol 5 Zelda no Densetsu, save type EEPROM_124).
|-
| [http://gbatemp.net/index.php?download=2775 NDS Backup Tool 3in1]
| Rudolph
| Backup Tool
| Utilizes the NOR Flash Memory and SRAM. This homebrew application can send or backup save information stored an original DS game cartridge. Furthermore, NDS Backup Tool 3in1 can backup original carts as ROMs. DS cartridges that contain more than 256 Mb (32MB) of data are compatible with this tool. The software is sophisticated enough to copy data in 256 Mb chunks and then rejoin them later in the slot-1 cartridge memory. Compatible with both chip sets.
|-
| [http://ezflash.sosuke.com/about6317.html NDStation]
| Chuckstudios
| Patcher
| A very interesting approach to loading ROMs on the 3 in 1. Rather than having a homebrew running on the DS transfer the ROM to the 3 in 1, chuckstudios developed a Windows program (later ported to Linux by dg10050) that packaged the GBA ROM in an .NDS file. This packaged file, when launched from a Slot 1 card, would backup any existing save on the 3 in 1 and load the ROM onto it. The aim of the project is to give things a more integrated and unified feel with your Slot 1 cart. Additionally, one can customize the icon of the .nds file, alternatively load the game into the PSRAM, compress the ROM, and include a custom GBA border.
|-
| [http://www.cyclopsds.com/cgi-bin/cyclods/engine.pl?page=support CycloDS Evolution Firmware v1.2 and up]
| Team Cyclops
| Firmware
| The [[CycloDS Evolution]] officially integrates rumble for Nintendo DS games, memory expansion for Opera Browser without any additional ROM patching, and GBA-NDS linking.
|-
| [http://ezflash.sosuke.com/viewtopic.php?t=5342&start=0 Pokepatch for EZ3in1]
| Cory1492
| Patcher
| Patches Pokémon DS versions Diamond and Pearl allowing DS-GBA linkage. The GBA game must be loaded into the NOR. Please read the linked discussion thoroughly.
|-
| [http://www.dslinux.org DSLinux]
| [http://dslinux.org/cgi-bin/moin.cgi/ContactingDevelopers DSLinux Dev Team]
| Operating System
| Provides the Linux operating system more available RAM
|-
| [http://www.snemul.com/ds/ SNEmulDS]
| Archeide
| SNES Emulator
| Provides additional RAM to emulator in order to improve large SNES ROM emulation
|-
| [http://lazyone.drunkencoders.com/wordpress/index.php Mini vMac Port]
| Lazyone
| Legacy Mac OS Emulator
| Provides additional RAM
|-
| [http://lameboy.nutki.com Lameboy]
| Nutki
| Game Boy / Game Boy Color Emulator
| Rumble is supported GB/GBC games
|-
| [http://quake.drunkencoders.com/ Quake 1 and Quake 2 for Nintendo DS]
| Simon Hall
| Quake 1 and Quake 2 Ports for the DS
| Quake 1 uses the additional RAM as an optional enhancement. Quake 2 requires additional RAM from slot-2.
|}

== Compatibility ==
The current compatibility of the 3 in 1 with official games is practically complete. The official EZ-Flash V kernel software is capable of integrating all hardware featured in the 3 in 1 Expansion Pack. The EZ-Flash team does not ensure hardware compatibility with other slot-1 devices. Compatibility with third-party slot-1 carts appear to be just as good.

The 3 in 1 is compatible with GBA ROMs [[#When do I need to patch a GBA ROM in regards to the saving function?|properly patched]]. Optional ROM trimming is also available. GBA ROMs can be written to the PSRAM unless the ROM is larger than the 128 Mbit capacity and/or has a save type of 1 Mbit or larger. All GBA ROMs can be written into the 256 Mbit NOR flash memory. The NDS Browser requires additional patching and/or tools for unofficial slot-1 carts in order to recognize the PSRAM. The rumble feature is for NDS games and can be easily coded into homebrew. [[Lameboy]], a slot-1 Game Boy / Game Boy Color emulator, is an example of homebrew that is compatible with 3 in 1 rumble when properly enabled by either official or third-party software.

Homebrew applications can use the Expansion Pack as a memory expansion. For example, DSLinux-DLDI uses it to provide extra RAM for their linux port. SNEmulDS utilizes the extra RAM to improve large Nintendo SNES ROM emulation.

== Review ==

=== Official GBAtemp Review ===
[http://gbatemp.net/index.php?showtopic=42399 EZ-Flash V GBAtemp Review]

:'''Overall:''' ''"The build quality is great, it feels very sturdy and the black brushed finish was a good choice. The cart is held together with a single screw on the back. It fits firmly in the GBA slot however it does seem to stick out ever so slightly, so slight it’s hardly worth mentioning. You’ll notice it if you brush your finger over it though."''

:'''GBA:''' ''"You can start a GBA game by either hitting the ‘Start GBA game’ button on the DS firmware menu or by pressing R+A when selecting the game in the EZ-V menu. There is no EZ-V GBA loader menu meaning that you can only have one game on the cart at one time. It would be nice if in the future you were allowed to write multiple games to the 256mbit of space. But as it stands it's a simple and effective GBA solution for a slot-1 flash card. The EZTeam come highly recommended with all their GBA ventures and the Expansion Pack is no exception, GBA games run fine and are easy to write and use."''

:'''RAM:''' ''"When the Opera DS Browser was released it came with a separate RAM pack which gave the DS that little extra boost to run the application. The Expansion Pack simulates this RAM pack when you use the DS Browser ROM. There is no patching required, just simple drag & drop and the Opera Browser will work fine. Strangely though the Expansion Pack will not work if you use the original DS Browser DS card with it, only the ROM version will work. That being the case there shouldn’t be many people out there that would want to use the original card with the Expansion Pack if they have an EZ-V."''

:'''Rumble:''' ''"Rumble is loud, very loud. On full rumble the Expansion Pack is frighteningly loud and completely distracts from the gaming experience. This is in line with the official rumble pack. However you have the ability to select between three different strengths of rumble. Pressing R+L on the EZ-V loader will take you to the menu where you can select between low, medium or high. On low the rumble emits hardly any noise and still has a pleasant sensation when playing games like Elite Beat Agents. Games do not have to be patched for rumble support, that information is stored in the updated savelist file. Only official rumble supported games will use the Expansion Pack as it works just like the official pack."''

=== Images ===
<gallery>
Image:3-in-1.jpg
Image:Back.jpg
Image:Bottom.jpg
Image:Expansion-open2.jpg
Image:Expansion-open.jpg
Image:Ezv-plus.jpg
Image:Ez3n1package.jpg|Standalone Packaging
Image:Ez3n1openpackage.jpg|Contents
Image:Ez3n1compare.jpg|Comparison to Original
</gallery>

==Initial Setup==
'''Simply put, the most popular unified third-party program for GBA ROM Loading, RAM Expansion, and Rumble at this time is [http://kotei.blog.so-net.ne.jp/ GBA ExpLoader]. GBA ExpLoader automatically patches GBA ROMs during the ROM loading process.''' The following are fairly generalized instructions.
=== GBA ===
EZ-Flash V owners may follow the [http://ezflash.sosuke.com/wiki/index.php?title=EZFlash_V_quickstart_guide Official EZ-Flash V Quickstart Guide]. Other Slot-1 Carts will require a third-party solution.
==== Automatic Patching Method ====
Third-party applications have become more sophisticated allowing a more streamlined process of initial setup. This method of initial setup does not require manual patching of GBA ROMs.
#One will need a [[#Third-Party|Third-Party Loader]] that supports automatic GBA ROM patching in order to load a GBA ROM from a DLDI compatible Slot 1 cart.
#GBA ROMs can be [[GBAtemp_Glossary#T|trimmed]].
#Once the GBA ROMs and the necessary files for the Third-Party Loader are copied over to the slot-1 memory card, follow the instructions of the homebrew loader accordingly. One typical step is [[DLDI]] patching of the loader, which is usually a file with a .nds extension.

==== Original Method ====
The original method requires manual ROM patching. This can be used as a historical reference as third-party applications with automatic ROM patching become more mature.
#One will need a [[#Third-Party|Third-Party Loader]] in order to load a GBA ROM from a DLDI compatible Slot 1 cart.
#GBA ROMs can be [[GBAtemp_Glossary#T|trimmed]].
#GBA ROMs must be properly patched in order for the 3 in 1 to save to SRAM. Two popular tools are known to do this:
#*[http://gbatemp.net/index.php?download=224 GBATA] - GBATA is the most widely accepted tool to use when SRAM patching GBA ROMs. All you need to do is load up the ROM (click the [...] button), click on the SRAM Patch tab, and click the Patch button. If the button is grayed out, then the ROM does not need to be patched.
#*[http://www.sosuke.com/ezflash/viewtopic.php?t=719 EZ4 Client] - EZ4 Client is an alternative to GBATA. While it performs a similar function as GBATA, several users have reported lost save files with roms patched with this program. If you have a GBA ROM that uses a 1mbit save, you must use this program to patch it.
#Once the the GBA roms and the necessary files for the Third-Party Loader are copied over to the slot-1 memory card, follow the instructions of the homebrew loader accordingly. One typical step is [[DLDI]] patching of the loader, which is usually a file with a .nds extension.

=== Nintendo DS Browser ===
The EZ-Flash V can open a clean Nintendo DS Browser ROM without any additional setup. Other Slot-1 Carts will require a third-party solution in order for the ROM to recognize the 3 in 1 PSRAM.

*One working third-party solution that enables other slot-1 carts to use the 3 in 1 with the Nintendo DS Browser ROM would be the GBA ExpLoader by Rudolph.
#Patch the program [[DLDI]] accordingly.
#Switch to the Rumble selection menu.
#Select 'Expansion RAM'.
#Start-up the DS Browser.

=== Rumble ===
According to the Quickstart Guide and Official GBAtemp review, an updated save list is necessary in order to identify NDS ROMs that support rumble when used in conjunction with the EZ-Flash V. Other Slot-1 Carts will require a third-party solution. Rumble is compatible with any NDS game or homebrew program that supports it.

*One working third-party solution that enables rumble in other slot-1 carts would be the GBA ExpLoader by Rudolph.
#Patch the program [[DLDI]] accordingly.
#Switch to the Rumble selection menu.
#Select the intensity of rumble, and the tool will soft-reset.
#Start-up a DS game or homebrew program.

*Due to the recent 3 in 1 expansion pack hardware revision, automatic rumble enabling for slot-1 carts, like EDGE and CycloDS, is broken. This is one workaround:
#Patch one of the games with Standalone 3in1 rumble patcher, for example Metroid Prime Pinball (preferable US version)
#Load the patched game once
#Trigger soft-reset
#Load a different game

==Frequently asked questions==

===Where do I put my ROMs?===
Unlike a lot of Slot 2 solutions out there, the 3 in 1 does not have its own removable storage. This is due to the fact that it was initially designed for use with the EZ-Flash V. ROMs are stored in a permanent fashion on the removable media or internal storage of your Slot 1 device. Where they are put is determined by which solution you choose from the [[#Third-Party|third-party solutions]] list. A cool feature of the 3 in 1 is treating a GBA ROM loaded in the NOR like a GBA cartridge.

===Can the 3 in 1 only hold 1 GBA ROM at a time?===
The 3 in 1 can only hold one ROM in its NOR, unless you are running an EZFlash V or V Plus with the 1.8x b2 loader. Any time you want to play a game 16MB or less, you copy it over to the PSRAM on the cartridge using your loader of choice. This is standard with all slot 2 cartridges. Most slot 2s that have firmware (the ones with removable or internal storage have the loader built-in). The only reason people think otherwise is because most Slot 2s have either removable or internal storage for ROMs, homebrew, etc, which the 3 in 1 does not. Please read the [[#Initial Setup|initial setup]] section, it will give a more in-depth explanation.

===Whenever I load up a game, my save is gone! What do I do?===
This kind of issue can only be resolved through troubleshooting. Does the GBA ROM require SRAM patching beforehand? If so, make sure you are SRAM patching your games using one of the two tools listed in the [[#Initial Setup|initial setup]] section. If you are already doing this, make sure you are loading games in either PSRAM or NOR, not both. From what I have seen, most loaders want you to use one or the other for it to work correctly. Check the help files of your loader for more information (such as known bugs, proper ROM loading procedure, etc.).

===When do I need to patch a GBA ROM in regards to the saving function?===
You will need to patch the ROM if your loader does not feature automatic patching. Furthermore, patching is only necessary if the ROM does not use SRAM for saving. Anything already using up to 512kbit (64KiB) SRAM to begin with shouldn't need to be patched at all. GBA games that originally used EEPROM or FLASH, and/or has over 512Kbit, will need to be patched. 1024Kbit save types have to be patched with EZ4 client since GBATA has not implemented the concept of SRAM bankswitching. GBATA, for example, will not allow the file to be patched if unnecessary.

== See Also ==
* [[CycloDS Evolution]]
* [[EZ-Flash II]]
* [[EZ-Flash III]]
* [[EZ-Flash IV]]
* [[EZ-Flash V]]
* [[R4 DS]]
* [[M3 DS Simply]]

== Useful links ==

=== Support ===
*[http://www.ezflash.cn Official EZ-Flash website]
*[http://ezflash.sosuke.com Official English speaking EZ-Flash community/resource]
*[http://www.monroeworld.com/myfaq/index.php?action=show&cat=8 Monroeworld FAQ on EZ 3-in-1]

=== Homebrew Development (Read thoroughly) ===
*[http://ezflash.sosuke.com/viewtopic.php?t=4171 3 in 1 Sample Code in Action - PSRAM, NOR, Rumble]
*[http://ezflash.sosuke.com/viewtopic.php?f=16&t=11939 New Source Code Notice by EZ Team in Regards to New Chipset]
*[http://forum.gbadev.org/viewtopic.php?t=13023 RAM Unlocking API for Slot-2 Devices]

[[Category:NDS Slot-2 Carts]]
[[Category:GBA Flash Carts]]