no$gba Debugger Help

[YoshiMoshi]

Hello. I would like some help using the no$gba debugger. I would like to run through the code one step at a time, watch the values in the registers get updated, and see what happens on the screen, one instruction at a time. So I downloaded no$gba debugger, and I go to the starting address of every GBA ROM in the GBA memory map, 08000000. I double click on this address location so that it's red. I then reset and run hoping that the debugger would get to 08000000 and stop, however the emulator seems to skip right past it as if it was never set and the game runs like normal.

Thanks for any help.

I tried looking online, for example youtube, and there aren't any tutorials on how to use the debugger to do what I'm looking to do.

 

[metroid maniac]

mGBA has a useful debugger. It's caused me fewer issues than NO$GBA in the past.

 

[FAST6191]

For the record most would probably not start with 08000000 -- bust out the disassembler and you will see in 99% of games that 08000000 is a jump to the end of the header, and a few instructions down from there (most of which is fairly essential IO initialisation) is another jump/branch to somewhere in the 08?????? region and there is where the real fun begins.
Even without that though then most use the breakpoints more as tools for areas they care about (think infinite HP cheat finding the memory area to in turn find the damage calculation), are read by what they care about (maybe you find some area in the ROM by corruption, pointer inference, some kind of fingerprinting, tile viewer... it does not matter but then want what loads that area to go have a look at that aspect) or are changed by what they care about (tweaking a jump might well see you look at the sprite location in OAM and work backwards).
Equally the 08000000 thing might be a quirk -- while reset might have done a hard reset and gone from scratch if it was closer to a soft reset then that might be the one address as it were. I have reasons to doubt it in this case (it is not the sort of oversight I expect him to make) but something I could imagine in some cases for some things.

Been a while since I used no$gba debugger and rarely did stepping with it (though execute next instruction/run to location selected, which could just as easily be the next line, is an option). Its syntax was slightly different to most things (not in a bad way, just slightly different) and it tended to not note poor entry of them as much as ignore them without so much as a popup to say "what is this?".

As far as tutorials then might have to do that one of these days (the debugger aspect being paid software for a lot of its life probably reduced that a bit, even if many had it), had some truly minor aspects in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ but not many compared to the others.
Its general help http://problemkaputt.de/gbatek-debugging.htm http://problemkaputt.de/gbatek-breakpoints.htm should be good stuff though for this and have enough examples to get it going on.

As above though some seem to be opting out of no$gba for this sort of thing. I will stand up for it still but it is also noted I am a freak that still has vba-sdl-h around ( https://www.romhacking.net/documents/361/ https://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ ). Others might go for mgba, others still are playing with GDB and linking it to ghidra https://wrongbaud.github.io/posts/ghidra-debugger/ or IDA.

 

[YoshiMoshi]

For the record most would probably not start with 08000000 -- bust out the disassembler and you will see in 99% of games that 08000000 is a jump to the end of the header, and a few instructions down from there (most of which is fairly essential IO initialisation) is another jump/branch to somewhere in the 08?????? region and there is where the real fun begins.
Even without that though then most use the breakpoints more as tools for areas they care about (think infinite HP cheat finding the memory area to in turn find the damage calculation), are read by what they care about (maybe you find some area in the ROM by corruption, pointer inference, some kind of fingerprinting, tile viewer... it does not matter but then want what loads that area to go have a look at that aspect) or are changed by what they care about (tweaking a jump might well see you look at the sprite location in OAM and work backwards).
Equally the 08000000 thing might be a quirk -- while reset might have done a hard reset and gone from scratch if it was closer to a soft reset then that might be the one address as it were. I have reasons to doubt it in this case (it is not the sort of oversight I expect him to make) but something I could imagine in some cases for some things.

Been a while since I used no$gba debugger and rarely did stepping with it (though execute next instruction/run to location selected, which could just as easily be the next line, is an option). Its syntax was slightly different to most things (not in a bad way, just slightly different) and it tended to not note poor entry of them as much as ignore them without so much as a popup to say "what is this?".

As far as tutorials then might have to do that one of these days (the debugger aspect being paid software for a lot of its life probably reduced that a bit, even if many had it), had some truly minor aspects in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ but not many compared to the others.
Its general help http://problemkaputt.de/gbatek-debugging.htm http://problemkaputt.de/gbatek-breakpoints.htm should be good stuff though for this and have enough examples to get it going on.

As above though some seem to be opting out of no$gba for this sort of thing. I will stand up for it still but it is also noted I am a freak that still has vba-sdl-h around ( https://www.romhacking.net/documents/361/ https://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ ). Others might go for mgba, others still are playing with GDB and linking it to ghidra https://wrongbaud.github.io/posts/ghidra-debugger/ or IDA.

Hey thanks! I really appreciate your help! You seem to be very knowledgeable of this stuff.

Yea I have seen that 08000000 is the "ROM_START_LOCATION" instruction which just a branch instruction to a certain address, past the header information. Still I was hoping to start at 08000000, because it's the start of the ROM and the first instruction, and just step through it one instruction at a time.

I'm not not trying to like do an infinite health cheat or anything like, just trying to understand how a ROM for the GBA works instruction by instruction, and hopefully identify some unused instructions that got leftover from development.

I agree completely no$gba debugger is not to intuitive, and the documentation on it is very poor. Even finding something written online with like pictures of the GUI and how to debug or a video, I can't find.

I've reviewed the GBA Tek documentation, and brake points don't seem to work. I'm sure it's just me not using the GUI correctly but I'm not sure what I'm doing wrong.

Another post mentioned the mGBA debugger. Unfortunately documentation on this also seems to be very rare.

I have been using Ghidra to go through the ROM and automatically tell me what the different instructions are. It's very helpful.

So are there any documentation or video tutorials on how to debug a ROM by going through it one instruction at a time? Watching the values update in the registers and memory, and viewing what is displayed on the screen? I can't find anything =(. If you know how to do it with no$gba, do you think you could create like a short YouTube video or something? The debugging documentation for GBA, doesn't seem to be to detailed.

I really appreciate your help!

 

[FAST6191]

Nobody does one instruction at a time unless they are already 90% of the way to where they want to be and are understanding a given subroutine or particular quirk thereof (which usually starts by a related value/something in the chain found on screen, via cheats, via some known hardware register like controls or sound, via something that reads a known location in ROM and all the rest I mentioned). You might get somewhere with a commodore 64 stepping through something and works reasonably well as a learning exercise or exam question but practical realities by the time of the GBA (or indeed even the NES really) mean that is largely untenable. Even those making disassemblies (and I guess some aspects of decompilation which has not yet come to the GBA, possibly some time soon though as C was the main thing) will tend to hone in on a mechanic, and then another, and then another... until a greater picture is formed, or maybe outline the possible jumps in some kind of main loop and fill that in mechanic/subroutine by mechanic/subroutine.

If you wanted to find leftover code (exists but not as common as older systems -- the GBA was a largely compiled code device and commenting something out in C will see the compiler never include it in the final outside of terribly bad luck on the part of the devs https://www.pagetable.com/?p=28 ) or perhaps the path not taken in hopes of finding a cheat/hidden option then there are other options.

Equally there are tools to note what code is run and thus what is not run, branches not taken and more besides. Basic logging as seen in the vba-sdl-h and more famously in the likes of https://fceux.com/web/help/CodeDataLogger.html would do it, though I have seen other hackers have their own tools to note things (also helpful for the ARM-THUMB split, said noting what mode something is in then being one of the niceties of emulators, though generally assume THUMB until proven otherwise or you are handling something serious). Do a playthrough of the game/game section, should then be easy enough to pick out branches/jumps, sections of code not taken and thus figure out their activators (if any are present).

Videos on hacking are limited. I, and the many others the many times videos have come up as a general idea or because the youth of the day demand it, have never figured out a format I would want to watch for a hacking tutorial that tells you much but also remains vaguely watchable -- me whizzing around in a hex editor for hours tells you nothing unless you already know, slowing down to explain what I am doing will make it 5x longer at least and put you to sleep even more, and most other things are artificial and thus miss out key info. Most things then are text and picture based and probably will be for the foreseeable, though certain things can be made more evident with video so whatever happens might spring from that. This is also from someone that really likes video ( https://gbatemp.net/threads/be-a-great-video-maker-and-replicate-this-video-effect.360509/ ), including long form (I have watched several hours of machining* and financial update content before 9am this morning and was fascinated throughout it all).

*I often pondered if this was to be the way but reckon it is actually inverted -- machining is all setup and if you are thinking while you are doing you went wrong somewhere, setup for most ROM hacking efforts is minimal and all thinking while you are doing save for maybe updating pointers manually (in which case stop being lazy and code something if you have enough time to zone out).

I have long promised a guide on finding hidden cheats now and basic debugging would be included as part of that (indeed the having to stop and make pictures/document examples is where a previous attempt to write that stalled out with everything else done) and have no reviews on my plate right now so might get around to it as part of that if you want. Just have to skip over the what is a breakpoint and why you care aspects.

 

[YoshiMoshi]

Nobody does one instruction at a time unless they are already 90% of the way to where they want to be and are understanding a given subroutine or particular quirk thereof (which usually starts by a related value/something in the chain found on screen, via cheats, via some known hardware register like controls or sound, via something that reads a known location in ROM and all the rest I mentioned). You might get somewhere with a commodore 64 stepping through something and works reasonably well as a learning exercise or exam question but practical realities by the time of the GBA (or indeed even the NES really) mean that is largely untenable. Even those making disassemblies (and I guess some aspects of decompilation which has not yet come to the GBA, possibly some time soon though as C was the main thing) will tend to hone in on a mechanic, and then another, and then another... until a greater picture is formed, or maybe outline the possible jumps in some kind of main loop and fill that in mechanic/subroutine by mechanic/subroutine.

If you wanted to find leftover code (exists but not as common as older systems -- the GBA was a largely compiled code device and commenting something out in C will see the compiler never include it in the final outside of terribly bad luck on the part of the devs https://www.pagetable.com/?p=28 ) or perhaps the path not taken in hopes of finding a cheat/hidden option then there are other options.

Equally there are tools to note what code is run and thus what is not run, branches not taken and more besides. Basic logging as seen in the vba-sdl-h and more famously in the likes of https://fceux.com/web/help/CodeDataLogger.html would do it, though I have seen other hackers have their own tools to note things (also helpful for the ARM-THUMB split, said noting what mode something is in then being one of the niceties of emulators, though generally assume THUMB until proven otherwise or you are handling something serious). Do a playthrough of the game/game section, should then be easy enough to pick out branches/jumps, sections of code not taken and thus figure out their activators (if any are present).

Videos on hacking are limited. I, and the many others the many times videos have come up as a general idea or because the youth of the day demand it, have never figured out a format I would want to watch for a hacking tutorial that tells you much but also remains vaguely watchable -- me whizzing around in a hex editor for hours tells you nothing unless you already know, slowing down to explain what I am doing will make it 5x longer at least and put you to sleep even more, and most other things are artificial and thus miss out key info. Most things then are text and picture based and probably will be for the foreseeable, though certain things can be made more evident with video so whatever happens might spring from that. This is also from someone that really likes video ( https://gbatemp.net/threads/be-a-great-video-maker-and-replicate-this-video-effect.360509/ ), including long form (I have watched several hours of machining* and financial update content before 9am this morning and was fascinated throughout it all).

*I often pondered if this was to be the way but reckon it is actually inverted -- machining is all setup and if you are thinking while you are doing you went wrong somewhere, setup for most ROM hacking efforts is minimal and all thinking while you are doing save for maybe updating pointers manually (in which case stop being lazy and code something if you have enough time to zone out).

I have long promised a guide on finding hidden cheats now and basic debugging would be included as part of that (indeed the having to stop and make pictures/document examples is where a previous attempt to write that stalled out with everything else done) and have no reviews on my plate right now so might get around to it as part of that if you want. Just have to skip over the what is a breakpoint and why you care aspects.

Yes please ! That would be great! Yea basic stuff like what is a breakpoint can be skipped.

 

[Keitaro]

Does anyone have an answer to this? I'm trying to do this exact same thing, mainly because I've written some code that isn't working correctly and I'm trying to trace the specific point it is malfunctioning at. It would be extremely valuable to be able to break at a specific function, step through it piece by piece, and watch the screen to pinpoint exactly where in the code this bug is happening. I, too, was unable to find any good documentation online for No$'s debugger, rather frustratingly so I'm so used to BGB's amazing, straightforward debugging features for the GBC and have been really frustrated with how complicated and convoluted the GBA solutions seem to be. I'm open to anything though, particularly if it supports symbols!