People tend not to go too console specific for that, or if they do they will probably say "but it applies to everything"... mainly because it does. Text is still likely to be encoded in something other than ASCII, something that you will have to make a table for. Text will still use pointers, still have all the things that we see on text engines from similar vintage consoles and the like. Graphics are still ultimately needed to be displayed on the, rather specific, hardware so things will play to that, give or take some compression and generation/modification. To that end you will probably want to get familiar with a tile viewer that supports GB/GBC decoding (should be basically all of them).
The hardware docs of note for the GB/GBC are probably still the pandocs (
http://problemkaputt.de/pandocs.htm ). They are old but it is not like the GB/GBC hardware has changed... well ever as far as programmers/hackers are concerned but since they were written works too.
Where the NES has mappers the GB/GBC has memory bank controllers (MBCs), they kind of work in similar ways. The idea is that addresses will probably not be direct locations in the ROM or the memory map where the ROM is found (the GBA will almost invariably be 08000000 through 09FFFFFF or similar mirrors, the megadrive/genesis does similarly for most games....) but reference the memory bank (a window in memory which changes) where it will eventually be visible. Not all games used MBCs though.
If you want to go a bit further then you will not be able to use the debuggers that others working on NES and SNES use for obvious reasons but BGB debugger and no$gmb (the same guy that wrote the version of the pandocs I linked also wrote that) do pretty well.
Topic: Gameboy/Color Hacking docs (Read 1821 times)