Changes

ROM hacking resources

10,802 bytes added, 15:31, 17 March 2019

m

Reverted edits by 71.95.119.28 (talk) to last revision by Bot

The tile data uses indexed colors. Using Mario's shirt as an example, it isn't colored "red" but rather colored with "color 1". NES Mario games, like most NES games, happen to use the NES 2BPP mode (that is, two bits per pixel). A bit is either zero or one. With two bits, we can write <code>00</code>, <code>01</code>, <code>10</code> and <code>11</code>. This technically gives us four possible colors in total. However, there are actually three colors since "color 0" is transparency, used around Mario's sprite so that the backgrounds behind him are visible and unobstructed.

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 erroneous interpretations. That is, not to mention the numerous cases where the developers DON'T want you to look at their code: so it's either protected against disassembler tools during runtime (Denuvo on PC games), compressed then the game uncompresses just what it needs to the RAM and executes from there (Ys 5 for the Super Famicom), or most of the programming is written in another arbitrary programming language and the remaining 10% recognizable assembly code for that hardware is just the part which translates that arbitrary languages and not much else - this is also called bytecode and is used in many RPGs, with a quite infamously complicated variant being present in Earthbound (Mother 2) for example. 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 at 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 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 recognizable (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 Looking at the game's programming as it runs can also help you figure out tons of stuff, from how the game does the decompression for that insanely obscure compression scheme it uses, to how it loads level data, manages enemy stats and damage, display stuff and story events onscreen, and so on. Studying the game's programming, coupled with some corrupting (random hex editing of select memory areas) to confirm observations, has led to most of the game specific level editors and similar tools out there. So instead of lamenting why your favorite game doesn't have a dedicated tool, you can figure this out all on your own and create (in case you know some computer programming language) a good tool serving exactly your needs and which can be adjusted in whatever way you want.

==Emulators for ROM hacking==

* '''Cheats:''' You modified some text and graphics in the final stage but can't be bothered to replay the whole game legitimately. In case the emulator doesn't support this natively, you might want to consider using [http://www.cheatengine.org/ Cheat Engine].

* '''Save ~~States~~states, rewinding, fast forward, frame advance, pause:''' You modified something appearing in a very narrow timeframe, or you just want to take clean ~~screenshoots~~ screenshots of the game.

* '''Debuggers''' with the following features:

** '''Breakpoints:''' A breakpoint throws a fit and pauses the game if a specific address is tampered with. Of course, to know which address it is, you need to find it first with a cheat/RAM search.

** '''Conditional Breakpoints:''' Breakpoints that only trigger when another condition is also met. For example: Dragon Quest 1 keeps track of the monster ID (during battles) and the floor type (outside battles) in the same RAM variable. Which means every single step the hero makes will trigger the breakpoint, so if you're only interested in the monster ID code, you can weed out all other BPs by simply adding the condition "only trigger when the battle status RAM variable is on". Conditions can be about RAM or hardware register status.

** '''Disassembler:''' Translates the last few lines of programming executed from hex code to known opcodes telling which instruction is which (LDA/LDR/LD (load to accumulator/register), STA/STR/ST (store to accumulator/register), NOP (do nothing), and so on). After a breakpoint, it gives you the programming line (in assembly) directly responsible for altering the address the breakpoint was guarding against reading/writing/executing attempts. This is incredibly invaluable to understand the game's programming.

** '''Assembler:''' Allows the user to write their new lines of programming, which are then converted to the corresponding hex data. It's rare that emulators include this. Assemblers are often separate tools affecting the ROMs or to be inserted manually by users in ROMs.

===Emulators===

{| class="wikitable" style="text-align:center;"|+NES|-! scope="col"|Name! scope="col"|Operating System(s)! scope="col"|Version! scope="col"|[[Emulation Accuracy|Accuracy]]! scope="col"|Save states! scope="col"|Cheat support! scope="col"|Frame options! scope="col"|Breakpoint! scope="col"|Conditional Breakpoint! scope="col"|Disassembler! scope="col"|Assembler! scope="col"|Tracer! scope="col"|Memory view! scope="col"|Tile view! scope="col"|BG/OAM view! scope="col"|Useful?|-|[[FCEUX]]|Windows, Linux, macOS, Solaris, BSD|2.2.3|High|✓ |✓ |✓ |✓|✓ |✓ |✓ |✓ |✓ |✓ |✓ |✓✓|} * '''FCEUX''' is the golden standard for emulator debuggers, it's a fully featured one and very newbie friendly. So please check it out even if you're not interested in NES games as it's an excellent starting point for game modding. It's one of the few emulators, alongside PCSX2 and PPSSPP, to include conditional breakpoints. {| class="wikitable" style="text-align:center;"

|+SNES

|-

! scope="col"|Name

! scope="col"|OSOperating System(s)

! scope="col"|Version

! scope="col"|[[Emulation Accuracy|Accuracy]]

! scope="col"|Save states

! scope="col"|Cheat support

! scope="col"|Frame options

! scope="col"|Breakpoint

! scope="col"|Conditional BPBreakpoint

! scope="col"|Disassembler

! scope="col"|Assembler

! scope="col"|Useful?

|-

|-

|-

|}

* Older '''bsnes''' versions, and many of its forks - notably BizHawk and Marmelade, have an extensive VRAM viewer, some versions having ones topping NO$SNS, as well as a memory viewer. byuu says he wants to make a proper debugger himself called Loki (citing this as the reason for putting on hiatus the FEOE:Zero translation) but don't hold your breath for it.

* Geiger's custom build of an older version of Snes9x also is very useful. While the base emulator only has a background layer disabling hotkeys, cheat codes and frame advance features, this build adds a debugger, a tracer (to a log file), as well as a memory viewer/editor with the option to dump to external files to open with hex editors. There's also the very useful "What's Used" feature which colors areas in the memory viewer depending on what's onscreen (controllable with the BG layer hotkeys). However, it doesn't play nicely with nonstandard SNES cartridges. There's another custom Snes9x build by FuSoYa for Super FX2 games.

* As for '''NO$''' emulators, right off the bat when you start it, they have a fully editable debugger (upper-left), RAM memory viewer (lower-left), hardware register (upper-right) and stack (lower-right). You can set breakpoints on addresses or programming lines (opcodes). You can view I/O status (for stuff like sound and DMA) with the F10 hotkey.

And most importantly, you can view the contents of the VRAM in real-time. It's particularly useful in the case of the SNES (though there's no Mode-7 mode), as there's detailed info about tilemap tiles (the other alternative was to get a ZSNES save state and then load it in an external viewer tool to get that info). It also has sprite information. It's not ideal but far more rom modding oriented than other tools which don't even display 16 tiles per line thus often scrambling the view.

NO$PSX and NO$GBA's special debugger build (regular build doesn't have the debugger) also show 3D textures, and in the case of NO$GBA the 3D models too.

However, the main flaw these have is the lack of decent frame advancing, save state, and cheat options. You'll need CheatEngine, and importing SRAM files from other files most probably. Also, the base emulation isn't without its flaws (for example, NO$SNS crashes with Quintet games because sound isn't emulated).

* '''DeSmuME''' has some older builds on gbatemp with interesting modder-friendly options:

** Custom build allowing searching for unused RAM areas. If you want to change the game's programming you'll need to find an empty place in memory to put your new code, so this is extremely useful.

** Custom build allowing to select a DEBUG option under Slot-1. The console window will show every single file loaded off the cartridge in real time, and it's also logged to a text file. If you're, say, looking for the title screen to change it, you can this way narrow down which files you need to look for.

==General resources==

==Game-specific==

===EarthBound===

* Starmen.net's [~~http~~https://~~www~~forum.starmen.net ~~Starmen.net~~/forum/Community/PKHack PK Hack board] – Home of the hacking utility [~~http~~https://forum.starmen.net/~~pkhack~~forum/ ~~PK Hack~~Community/PKHack/CoilSnake-v1-0-Cool-Fish-Type-Edition/first CoilSnake], a tool that dumps data from the USA release of EarthBound into an ~~editor for modifying~~ editable format (mainly config files, plain text, and PNG spritesheets) and compiles everything back into the ~~EarthBound/Mother 2~~ ROM. ~~Has an active hacking community in~~ Threads for completed hacks are listed, as is the original PK Hack ~~section of its forums~~tool, ~~where links to completed~~ which was adequate for making hacks ~~can also be found~~when it first came out, but is now infamous for corrupting ROMs when pushed too far.

===Final Fantasy VI===

* [~~http~~https://www.ff6hacking.com/forums/portal.php ~~FF6 Hacking~~FF6Hacking] – Home to a large community of Final Fantasy VI hackers, complete with active forums, ~~links to~~ patches, ~~and~~ FAQs and guides for those looking to get into hacking the game.* [https://www.ff6hacking.com/wiki/doku.php FF6Hacking Wiki] – The most complete Final Fantasy VI hacking wiki with information on the SNES version but also on Final Fantasy VI Advance (GBA).

===Final Fantasy Tactics===

==Downloads==

* [https://mega~~.co~~.nz/#F!R8RCnZZY!Zxyqoynu9GVWIwFHCISK2Q!og53jJJL ROM Hacks]

[[Category:FAQs]]

Murrigan

Administrators

293

edits

Changes

ROM hacking resources

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Tools

Advertisements