rgbds VS mgbdis

This is a game jam where you make a Game Boy game in three months. If you don't know a lot of programming you can use GB Studio, you can learn the nitty gritty of how the Game Boy works by using assembly programming with RGBDS, or you can use C with GBDK or ZGB.

Game Boy disassembler: https://github.com/mattcurrie/mgbdis

You can compile the ROM's back with rgbds: https://github.com/gbdev/rgbds

Here you can see how bank switching works.

Probably not exactly what you want, but maybe worth checking out just in case: https://rgbds.gbdev.io/

Clone the specific version of rgbds we need (0.2.0 and 0.2.1 had segfaults on linking, but 0.2.2 seems to work just fine) git clone -b v0.2.2 https://github.com/gbdev/rgbds.git cd rgbds make cd ..

rgbfix is part of rgbds

Game Boy disassembler: https://github.com/mattcurrie/mgbdis

You can compile the ROM's back with rgbds: https://github.com/gbdev/rgbds

Here you can see how bank switching works.

You can get images out of it. Find the image locations in the ROM with a tool like YY-CHR, then annotate that location in the disassembler (like https://github.com/mattcurrie/mgbdis).

By a search on Google, I found this link: https://github.com/mattcurrie/mgbdis

I didn't use Ghidra, I only used mgbdis to create a disassembly. Patched it and then reassemble it.

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.