Changes

How can we tell what actual color Mario's shirt is instead of just "color 1"? We do this through [[wikipedia:Palette_(computing)|palettes]]. Palettes are hex data consisting of three several bytes(3 for the NES 2BPP mode), and each byte is the ID for a specific color: "red", "blue", "yellow", "purple", "light blue", and so on. (There are just under 60 valid choices in the NES, but later systems have a much larger selection of colors.) We know Mario's clothes change color after eating various items, but the tile data drawings are stored just once in the ROM. There are separate palettes telling the game to colorize the same drawing differently for different situations. For more convenient tile editing, tile editors offer a custom palette option so that you can fix the colors individually and have the graphics show correctly. Some emulators can export palette data from runtime memory for use with the tile editor (for example VBA-M and Crystaltile), and some tile editors can import save states from some emulators and use the palettes found inside (like Tilemolester). ===Editing game programming===Game developers used to write directly in machine language which is, again, bytes. Technically you could memorize what each specific byte calls among the different programming instructions availabe in that hardware's processor, and write your code directly in the hex editor. But generally that would be madness. Let's consider one example, from 6502 assembly used in the NES processor: the instruction which loads a special memory register (called the "accumulator") with a value. We'll choose the value 0x00 here. If you encountered such an instruction in a NES program, it will be written as the two-byte sequence A9 00, where A9 is the opcode for this specific instruction, and 00 is the operand -- the value we chose for this instruction. What game developers did was to write in plain text documents their game's code using keywords that are more or less readable for humans.  So, in the (often commented) code they're writing when developing the game, they'd write LDA #00 -- conveniently, LDA stands for "LoaD Accumulator with memory", which is a far more helpful description of the instruction than its raw hex form. (The # means it's a value, otherwise if it's the byte at an address that's affected we'd use $) Game developers start from text files with human-readable opcodes and comments, which they then pass through tools called "assemblers" to get the binary form of the code. The inverse is possible, and is called disassembling:* In debugging emulators with breakpoint and disassembly support, you can cause the game to pause whenever some memory address is interacted with (read, write or execute). You can get the emulator to show you which programming instruction executed right now did said interaction, in binary form, then "disassembled" and translated to some English-sounding instruction.* Debugging emulators with trace features can disassemble all programming instructions executed between two instants if you so desire.* CheatEngine and IDA Pro can disassemble some programs at runtime, including games and emulators.* IDA Pro with some user-made plugins can also take a ROM file from the system covered in said plugin, and try to disassemble its binary to a text file. Some emulators offer the option to do this if you give them which address in the ROM (or RAM) you want to disassemble from. However, disassembly can easily fail, and you end up with garbage nonsensical code in the text file. Why? Just like hex editors with text display, or tile editors, when disassemblers try to interpret stuff that's not programming as such, it's a recipe for disaster. Another extra problem is that after reading garbage data, even if the disassembler stumbles upon some legit programming bits after that, it will no longer tell where instructions begin and end (remember they're all just bytes) and so there will be even more erronous interpretations. What you'll need to mod game programming, a.k.a. assembly hacking, is:* a documentation of the hardware you're working on (including the various registers, hardware registers for stuff like the VRAM, the memory addressing...)* an opcode list for that hardware, which includes all the instructions allowed on that hardware which you'll encounter (in the game's original code) and probably will use (in the code you'll write as a replacement)* an assembler tool, to transform the text file with your innovating hack's code to binary format to be inserted later with a hex editor in the game proper. If you're especially good in regular computer programming, you could write one yourself for your personal use.* a hex editor* optionally, knowing how to use a cheat engine, since the RAM addresses it finds can lead to the instructions we need to find and eventually mod, in case those instructions affect those RAM addresses.* any of the aforementioned disassembly solutions, as long as they can help you pinpoint which instructions in the original interest you and could be changed to achieve the effect you desire. Having the new code being too long can be troublesome since you wouldn't want to overwrite irrelevant parts of the rom and thus corrupt it. The popular solution is to insert a JUMP instruction (as always, which instruction it is depends on the hardware) pointing your code to some faraway empty place where you can comfortably put all the code you want -- of course, within the limitations of that specific system. You can see it's the same idea as text editing. If you're more interested, check SMWCentral's boards for tutorials introducing you to SNES hacking with Super Mario World. Then if you feel more comfortable tackling harder stuff, you could learn PS1/PS2 assembly and translate/mod/fix some games. By the way, more recent systems no longer have a big data blob with all data types mixed, but use neatly arranged file trees with recognizeable (yet proprietary) file formats. This goes for programming too: all systems now have the executable in a separate file, and it's often the one loaded first. Some people even claim they had success running those through third-party disassemblers like IDA Pro. Some examples:* PS1: SLUS_*** or some variation* PSP: EBOOT.BIN, BOOT.BIN* GC/Wii: .elf files* DS: ARM9.BIN, more rarely ARM7.BIN