[andrea-i]

Hi All!

I'm a total neewb to hacking gb roms, but I'm an experienced programmer. I was wondering if anyone could give me pointers on how to accomplish this hack:
Disassembling one of the gb Wizardry english patched roms,
then trying to identify the piece of code that invokes the map spell,
then remove the portion of code that makes your character consume magic spell points.
Basically, free maps for all.

Is there any emulator that would help me with disassembling and inspecting code as it runs?

Thanks!

[FAST6191]

Most won't do a full disassembly as it won't assemble again without a lot of work.

Instead a more targeted approach will be opted for.

I don't know what the kids are suggesting for a GB/GBC debugger these days. I quite liked bgb's debugger
http://bgb.bircd.org/ but another may have snuck in during the meantime (many GBA emulators do GB/GBC as an afterthought and some of those have some very nice debugging options).

The approach is simple enough regardless.

Standard cheat search to find the mana. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial , or in this case hopefully it is just a matter of use spell, check for change, use spell, check for change, use spell, check for change, maybe do nothing and check for what remained the same... If by some craziness you have some kind of anti cheat or pointer on a GB game (would be super rare but not impossible) then you can try to cut through it if you want but as you are already going to be fiddling with code as part of this might as well use that (it might not be what you want but if it changes as a result the point is moot).
Set a break on write to the mana location you just found. Cast the spell, it should then say hold up something just wrote to the area. This will be the end result of the calculation but you get to follow it back up the line.

Whether it will be its own individual code for the spell (possible but who knows, makes it harder to NOP a subtract) or fetches spell cost from a table (change table to 0, or whatever, in that case). You may need to go one further and do a check on reading the area if the game does some kind of check to see if you have enough mana to cast it in the first place, in which case break on read. Some might go for a break on read first of all and it is a path you can take.

If you need a GB/GBC hardware listing most would point you at the pandocs, including its weird flavour of 8080/Z80 instructions.
https://gbdev.io/pandocs/

[andrea-i]

Hi thanks for taking the time to explain how this might work.

I'm not clear about one thing though, the solution you mention that doesn't require disassembling, I'm guessing is only good while playing the emulator? or does it offer some sort of patch generator?

Thanks!

[FAST6191]

There will still probably be some assembly involved, or at least understanding some if you are lucky enough to find a table used in this game rather than baked in at instruction level. It sounded however like you were thinking you disassemble something, poke it around a bit and assemble it as a shiny new ROM, much like you might download some open source code and poke that around before compiling it.

It is possible to do that for ROMs but usually the combination of data in the instructions, wasted space and junk, never mind a system using compression or with multiple instruction sets at play (be it something like the ARM-THUMB of the GBA, or coprocessors, neither of which really apply to the GB), mean you have to spend ages getting it to the point where you can assemble it, even more so if you want to take what are plain binary addresses and give them labels or comment on what the game is trying to do. Complete disassemblies capable of being assembled again do exist, several here and if you go looking around open source sites, but I doubt there is one for this right now.
To that end we tend to go a bit more targetted -- if you find the instructions doing things you want with a debugger (or maybe manually scanning a disassembly, be it static or take from an active emulator) it is not hard to either NOP things, change immediates or maybe jump/branch somewhere to do your extras. Assemble then what is either the changed instructions or a small fragment of code and overwrite what needs overwriting. Some assemblers will be able to have the output directed to the ROM location (have not played with the GB/GBC stuff for a while but such things exist for many devices as it is fairly desirable for ROM hackers), others will be a file you get to strip that from and overwrite, or overwrite and put the extra code where you found space.
If it is a few immediates you need to change then you don't necessarily have to be all story of mel ( https://prog.world/the-story-of-mel-a-real-programmer/ ) and the pandocs should list encodings for instructions, and NOPs (usually mov a register to the same register) are not that hard to sort either.

[vinheim3]

I would suggest using the Emulicious emulator if you're doing any REing: https://emulicious.net/

If you want an initial disassembly, use this tool: https://github.com/mattcurrie/mgbdis, this will give you something that will reassemble

Of the many features, Emulicious will allow you to debug the code as you've structured it in your project, so it's clearer what you're looking at

Other than that, it's understanding the architecture, and how to trace issues. Emulicious has a memory tracer that means you can set fewer breakpoints

[andrea-i]

thank you guys! will have a look at all that.