Warning: terms may not be accurate. In fact, they almost definitely aren’t accurate, as you’ve probably figured out by now.

• A is the assembly window, it has all the codes and will update to whatever offset it is running if you play the game and then pause and check it out. More specifically, A is actually referencing the offsets here, but it’s in the assembly window, so yeah…

• B is the opcode column. Right now it’s set to arm, so… yeah…

• To the left of C is the column of parameters. Again, it’ll be more obvious once we go into Thumb mode, hopefully.

• D is no$GBA’s version of the memory viewer. It works practically the same—you can edit values as you like. If you right-click it you can switch between the “data window” (memory viewer) and the break/watch window (contains a list of breakpoints, which shall be explained later).

• E is the stack. If you remember the push/pop explanation, it like, stores stuff here… yeah, it’s another one of those things I really don't understand it all too well but it IS useful sometimes. Essentially, code sometimes pushes offsets while going through routines, so if you check the stack, you can sometimes find useful offsets of pointers, and thus "trace" the routine to find out where it loaded from (real hackers will probably say this is complete and utter bogus and nothing like true “tracing”.)

• F contains all the registers and their values. Sadly, I don’t know what cpsr and spsr are though, since I never had to learn… XP

• I don’t know what the flags do either, but they’re there, right next to the window. That’s g.

• H is the game window. The game can also pop-up on a separate window.

• For the buttons above I, the only ones I feel like explaining are Trace, Run Next, and Reload. The rest are either self-explanatory, not very useful, you can figre out on your own, or a combination of the above, AFAIK. Trace is very useful in that it lets you trace the routine. To me knowledge, it’s almost exactly like Run Next, except if you encounter a “sub-routine” (a bl opcode which branches elsewhere) it will actually follow to that code and keep going, whereas “run next” will just run through the entire sub-routine automatically and then keep going from there, without actually seeing what the sub-routine does. “Reload” just reloads the ROM, which is useful, and can also be done with Ctrl+R.

Next, for the main menus to the top:

• Files – you can open files via filename or a special list file that I don’t bother to use, and also reload recent ROMs. Snapshots are no$GBA’s versions of savestates, they’re slightly less convenient I think, but they work alright. There’s a couple other things near the bottom idk about and you can also quit (lulz).

• The search menu lets you search for strings, set bookmarks, find the next breakpoint, and some other stuff, but the only thing I use and thus the only thing I can really tell you about is the Goto option—click on the assembly window or memory viewer/data window and hit ctrl+G, then type in an offset in hex (remembering the “+0x08000000” if you’re trying to access the ROM!) and hit “Ok” (or enter) to go there.

• Run – it’ll let you run around the code. Seriously I don’t know much about it except that there are some shortcuts for the buttons. Maybe you can play around and update this tutorial once you figure out what everything does.

• The debug menu is pretty useful, it’ll let you make, clear, and toggle breakpoints, and some other stuff. I only ever really use it to clear all breakpoints though.

• The “window” menu has a lot of stuff like the VBA “tools” menu—it’s too much to go into but if you’re familiar with VBA you should be able to figure most of it out on your own.

• “Utility” has more things I don’t use though taking screenshots is useful. I’m sure it CAN be useful, I just don’t use it…

• “Options” menu has way too many options—fiddle around and get it to how you like. You may want to turn the brightness up and check out some other stuff like the controls to start with. Be sure to hit “Save Options” after your changes so that they save for the next time.

• “Help” menu just contains some basic help stuff, the typical stuff you’d expect from a help menu in a program like this. XP

Okay. Now, the basic idea behind debugging is that you say “this area is suspicious: let’s stop the game in this code and see what it does”. To stop it, you make a breakpoint: what I do is just click on the code I want to set a breakpoint on and it turns red. To get rid of it, click on it again or use the debug menu to clear all breakpoints.

As for where to set breakpoints—suspicious places, of course! I covered some tips on how to find routines before.

Now, once you stop the game, you need to figure out what the heck it’s doing. If there are notes on the routine already, it’s pretty helpful, but otherwise you need to use all your knowledge thus far on figuring out what the numbers might mean. Knowing offsets and other such values can be REALLY useful—just recognizing one byte can help you identify what one register holds, e.g. a character ID, and then you can be like “oh, it’s multiplying the character ID by this to get this offset, and… oh!!!” or something like that.

Yeah, it’s very… difficult to explain as a science. It takes intuition. Thought. Trial and error. Playing around. Research. Such skills are important to have and if you have them, you’ll get pretty far.

Anyhow, what you want to do once you find a routine is go through each code and see how each opcode affects the registers. See what the heck it’s doing to not only the registers, but also the values in the memory. If you see some offset in the memory that you don’t know about, try changing its values—it might break the game, but you might also find out something interesting.

Of course, don’t neglect to use this on your own codes. I taught you the hard way first, but now that you can debug your own code by going to the offset you put it at, you can check to see exactly what it’s doing—and when it does something you don’t expect, you know exactly what opcode to blame. Check it out, see how to fix it, fix it, re-insert it, and try again. Then you’ll really be using a “debugger” by, well, getting rid of the bugs in your codes. It’s a pretty fitting name to call this thing a debugger, huh?

…

Wooh.

This may be my longest section in the tutorial.

With that, the ASM hacking tutorial is done.

I’ve more or less taught you everything I know. Okay, I haven’t taught you every little offset, every little doc, or every little code. But that’s where YOUR work, YOUR effort comes in. If you’ve gotten this far, you have the potential to succeed and do great things. Surpass me, to start—it’s not hard. I am not very smart and I managed to get this far. Someone who IS smart can do much better. Hey, you can even write a better tutorial than this long, confusing, vague one when you’re done.

Lastly, I have a little special request of you. I can’t force you to do anything, but I’d appreciate if you shared the ASM hacks you made and any documentation you have. Sharing information and knowledge with others, including hacks, will help the community grow. It will help other people learn and prevent people from having to do the same work. Would you be able to make ASM hacks if others hadn’t shared their doc? I learned almost purely by looking at others’ works and trial & error, so I know I almost definitely wouldn’t. That’s why I took the time out to write this huge tutorial—so that the information is out there for people to take and make their own.

Again, it’s just a request—you don’t have to, but it’s nice. It’d be nice to have a chain of sharing, where I share my knowledge with some people, and they share their knowledge with some people, etc., because if nothing else, some day it might come back that someone shares something with you again. =)

You have learned the most obscure and feared aspect of ROM Hacking for many people—something many people wish they could learn, and something many others shudder to even think about or discuss. You have something to be proud of, if nothing else.

Congratulations and best of luck in all your hacking endeavors, especially ASM hacking!