ROM Hacking Guide

• pokered

  43 3,774 8.3 Assembly

  Disassembly of Pokémon Red/Blue

  

IMHO, in the modern era, ROMhacking is kind of a ridiclous, constraining pursuit: you're effectively working within the constraints of an arbitrary static-linked memory-map generated by a linker decades ago to suit the precise needs of the particular assembler source fed in at the time (and the needs of the ROM chip that said source would be burned onto.)

IMHO, it makes much more sense today, with the tools we have available, to not directly hack on ROM images themselves, but rather to first disassemble the ROM; to then factor the produced assembly into modules; to reverse the assembler data constant sections into separate named resource files, with a Makefile that converts them back; and so forth, at each step ensuring that typing `make` reproduces the original ROM image.

Once you have that — e.g. https://github.com/pret/pokered — you can then fork the codebase you now have, and develop further on it with regular programming tools. At this level, you don't have to worry about overrunning allocated strings-sections, rewriting pointers, etc. And there's nothing† stopping you from just bumping up your target ROM image size if you run out of headroom.

† Well, okay, maybe you'll be limited by the fact that the system architecture only has an address-space so large, and the original game as written was small enough that it didn't use banking, but upon expanding it you now need to use banking. That's a hurdle, but not an insurmountable one.

• mgbdis

  6 225 4.5 Python

  Game Boy ROM disassembler with RGBDS compatible output

You make it sound like there's a machine you can put a Game Boy ROM into and get out a disassembly, which is kinda true (https://github.com/mattcurrie/mgbdis) but it doesn't automatically split out data blocks or anything like that - it just tries to crawl the ROM and disassemble any code it can find. It's certainly not "effectively no additional work" than making targeted alterations to the binary and documenting your work.

And that's before you get to platforms where most if not all games are written in C - I question whether a mere disassembly of a game like Pokemon Emerald would even be useful to anyone, whereas the pokeemerald decompilation (https://github.com/pret/pokeemerald) is clearly useful but was a heck of a lot more work to produce.

> That's a hurdle, but not an insurmountable one... unless the system didn't even support banking. (Are there any systems that didn't?)

Depends what you mean by "support". I don't think any system has a built-in mapper - they just assign a chunk of memory space to the cartridge bus, and if your game is larger than that chunk of memory space you include a mapper on the cartridge. Nintendo provided standard mappers for machines like the NES and Game Boy because it's very hard to include a substantial game in the wedge of memory space you get on the processors in those machines, whereas only one game on the Genesis/Megadrive needed one.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project