News: 11 March 2016 - Forum Rules

Author Topic: GBA Assembly Tool Help  (Read 771 times)

SNEAKYTING

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
GBA Assembly Tool Help
« on: October 23, 2021, 08:08:19 am »
I've been told that I needed a GBA Assembly Tool to look deep into the scripts for any GBA Roms, in this case "Megaman Zero 1-4" for the coding of the element scripts, weapon scripts movement + jumping/mobility/velocity physics, cyber elf system and the animation states of when the playable character, Zero attacks with all 4 of his weapons plus projectile state along with the hitboxes. But I cannot find the right tool that can open up the sprites and coding/scripts from the GBA ROM. IF Anyone know the actual name of that GBA tool program and can tell me where to find it, I'd appreciate your help. I also apologize if this is in the wrong Forum category and the inconvenience.

FAST6191

  • Hero Member
  • *****
  • Posts: 3358
    • View Profile
Re: GBA Assembly Tool Help
« Reply #1 on: October 23, 2021, 10:06:20 am »
Not entirely sure who told you what there as there are several different things you go between in that, some of which would not require assembly but or some crazy in depth changes (not examination, changes).

Equally "that can open up the sprites and coding/scripts from the GBA ROM". If you have previously dealt with PC games, DS games and newer, things that came on floppy disc or things that came on CD/DVD then you don't have the option to explode a GBA game, outside of some homebrew, into files with nice names, sizes, directories and extensions to poke at.


On "scripts" then you might want to go into what you mean here. For 99% of the GBA library and ROM hacking hacking purposes most will assume by script you mean the text in the game itself. The main deviation being pokemon hacking wherein scripting refers to the actions the NPCs take in the overworld. I have not dealt the most with GBA Rockman/Megaman hacking (some good people there actually -- the battle network 4.5 project would not have been easy) but they had not adopted such terminology. In this case you might be looking towards the latter, and "scripted AI" or similar is not going to be a unknown term.


Anyway most of those things seem reasonable to look at.

Graphics. Most will start by getting a tile editor, opening up the ROM in it, setting one of the GBA modes and pressing down until they have gone through the ROM, and as the GBA has two main modes (technically 4 + different sizes, though one is never really used and another one will not be used by 99.99% of sprites on the GBA) which are typically known as GBA 4bpp and GBA 8bpp but some editors will do differently.
For tile editors/viewers I like crystaltile2, tiled2002 and tiledggd.

There is also compression to consider (the GBA makes extensive use of it). Two main options for this before you break out the fun tools. That being compression search tools (not the greatest fan but they do work) and SWI log tools (you play the game and when it uses the compression feature of the BIOS, assuming it is one of the games that does it, then you get a nice log of SoftWare Interrupts aka BIOS calls to feed the compression tool with the added bonus of them telling you exactly where, what type and how much is needed).
Several tools should be available on the site here under compression tools unlz gba nlz gba and have a look at http://www.romhacking.net/?page=utilities&category=&platform=10&game=&author=&os=&level=&perpage=20&title=&desc=compression&utilsearch=Go in general.

I have a larger guide covering GBA and DS ROM hacking
http://www.romhacking.net/smf/index.php/topic,14708.0.html


Everything else there. This is where assembly starts to appear.
You will want to learn to make cheats as most things there will change memory in some way, and do so repeatability and predictably.
I usually recommend https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial for learning to make cheats.
This will allow you to find memory related things which you will want to use in further steps. For instance equipping a weapon might change stats, being hit loses health which in turn will have resulted somewhere not very far back from a hitbox check.
Alternatively if the action results in a graphical change (new sprite say) then the thing what governs the on screen display and behaviour of sprites is the Object Area Memory aka OAM (objects/objs being an alternative name for sprites).


For tracing I have some stuff in the guide above but also suggest https://www.romhacking.net/documents/361/
Mind you rather than old vba-sdl-h then no$gba debug is what will form the gold standard for many
https://problemkaputt.github.io/gba-dev.htm https://problemkaputt.github.io/gba.htm
The specifications made to go with the emulator (usually referred to as gbatek) are also the main reference for any GBA hardware question save for some of the audio stuff
https://problemkaputt.github.io/gbatek.htm

Though I do like to flank it with
http://www.coranac.com/tonc/text/asm.htm
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
maybe also https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html
https://imrannazar.com/ARM-Opcode-Map

no$gba is not the only modern offering though for there is also https://wrongbaud.github.io/posts/ghidra-debugger/ and some of the stuff done for mgba (granted https://mgba.io/tag/debugging/ is what most tend to look at which is more for game specific faults and emulator quirks).

Tracing in general is easy enough in concept. Computers/CPU can do three main things with memory.
1) Read something
2) Write something
3) Execute a line of code there.

Consequently you have three main types of breakpoint (break as in stop program, if you ever wondered what the pause-break button on your keyboard was related to then yeah), or log point if you want to log things for later examination (useful if you don't know when something more unique will happen to a commonly accessed area).
Break on read aka BPR
Break on write aka BPW
Break on execute aka BPE but sometimes in some emulators BOE.
You can also log new functions executed if you want with the general flow there being to do everything but what you want to do (move, idle...) such that the game sees timers tick down, music play, idle animations, animation upkeep and whatnot and then you do the thing you want, that being both a new function and last thing done before you stop and have a look.

If you are unfamiliar with assembly then it is a type of programming. It is unique to every style of CPU, and every class of system you use it on -- the GBA and Wii might both have ARM processors in them but their memory, hardware hanging off it and more besides will be arranged very differently.
You also necessarily have to micromanage things as CPUs are very basic devices when all is said and done, ARM stuff even more than many others (though this is by design and not necessarily a bad one).
If you are not familiar with the basic ideas of loops then probably want to get familiar there. Any programming tutorial will cover these https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm
It will look a bit different in assembly (compare/cmp followed by a branch/b/bne for IF ELSE type setups) but still be the same thing underneath it all.
Anyway I usually figure there are three types of instruction
1) Maths
2) Housekeeping
3) Program flow

1) Maths is obvious. Computers are very good at simple maths instructions (see "everything is adding" that they get newer computer science and electrical engineering types to consider -- adding it adding, subtracting is just a different type of adding, multiplication is adding...)
2) Housekeeping.
When the hardware docs say you have 16 registers (arguably a few less as a few of those are normally used for specific tasks) and each of those are 32 bits (which is a luxury compared to earlier devices -- NES is 8 bit, and has 3 general use registers) it means it.
This means copying data around (mov command), push and pop (frees up and returns the old data when you are done), resetting states and whatever else needs to be done often.
3) Program flow. Adding things up is wonderful but ultimately boring. This is why I told you to get familiar with loops as this is that.

Oh and the GBA has two instruction sets. One called ARM, the other called THUMB which is 16 bit instructions (faster, less space needed) with a few limitations though still using the 32 bit registers.

That should be enough to get started with. Some of this is jumping in at the deep end compared to what a lot of hackers start out with but you can get some real stuff done here.


Also
"jumping/mobility/velocity physics,"
Do have a read of https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub
https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm

Whipon

  • Jr. Member
  • **
  • Posts: 33
    • View Profile
Re: GBA Assembly Tool Help
« Reply #2 on: October 23, 2021, 01:49:20 pm »
Not entirely sure who told you what there as there are several different things you go between in that, some of which would not require assembly but or some crazy in depth changes (not examination, changes).

Equally "that can open up the sprites and coding/scripts from the GBA ROM". If you have previously dealt with PC games, DS games and newer, things that came on floppy disc or things that came on CD/DVD then you don't have the option to explode a GBA game, outside of some homebrew, into files with nice names, sizes, directories and extensions to poke at.


On "scripts" then you might want to go into what you mean here. For 99% of the GBA library and ROM hacking hacking purposes most will assume by script you mean the text in the game itself. The main deviation being pokemon hacking wherein scripting refers to the actions the NPCs take in the overworld. I have not dealt the most with GBA Rockman/Megaman hacking (some good people there actually -- the battle network 4.5 project would not have been easy) but they had not adopted such terminology. In this case you might be looking towards the latter, and "scripted AI" or similar is not going to be a unknown term.


Anyway most of those things seem reasonable to look at.

Graphics. Most will start by getting a tile editor, opening up the ROM in it, setting one of the GBA modes and pressing down until they have gone through the ROM, and as the GBA has two main modes (technically 4 + different sizes, though one is never really used and another one will not be used by 99.99% of sprites on the GBA) which are typically known as GBA 4bpp and GBA 8bpp but some editors will do differently.
For tile editors/viewers I like crystaltile2, tiled2002 and tiledggd.

There is also compression to consider (the GBA makes extensive use of it). Two main options for this before you break out the fun tools. That being compression search tools (not the greatest fan but they do work) and SWI log tools (you play the game and when it uses the compression feature of the BIOS, assuming it is one of the games that does it, then you get a nice log of SoftWare Interrupts aka BIOS calls to feed the compression tool with the added bonus of them telling you exactly where, what type and how much is needed).
Several tools should be available on the site here under compression tools unlz gba nlz gba and have a look at http://www.romhacking.net/?page=utilities&category=&platform=10&game=&author=&os=&level=&perpage=20&title=&desc=compression&utilsearch=Go in general.

I have a larger guide covering GBA and DS ROM hacking
http://www.romhacking.net/smf/index.php/topic,14708.0.html


Everything else there. This is where assembly starts to appear.
You will want to learn to make cheats as most things there will change memory in some way, and do so repeatability and predictably.
I usually recommend https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial for learning to make cheats.
This will allow you to find memory related things which you will want to use in further steps. For instance equipping a weapon might change stats, being hit loses health which in turn will have resulted somewhere not very far back from a hitbox check.
Alternatively if the action results in a graphical change (new sprite say) then the thing what governs the on screen display and behaviour of sprites is the Object Area Memory aka OAM (objects/objs being an alternative name for sprites).


For tracing I have some stuff in the guide above but also suggest https://www.romhacking.net/documents/361/
Mind you rather than old vba-sdl-h then no$gba debug is what will form the gold standard for many
https://problemkaputt.github.io/gba-dev.htm https://problemkaputt.github.io/gba.htm
The specifications made to go with the emulator (usually referred to as gbatek) are also the main reference for any GBA hardware question save for some of the audio stuff
https://problemkaputt.github.io/gbatek.htm

Though I do like to flank it with
http://www.coranac.com/tonc/text/asm.htm
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
maybe also https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html
https://imrannazar.com/ARM-Opcode-Map

no$gba is not the only modern offering though for there is also https://wrongbaud.github.io/posts/ghidra-debugger/ and some of the stuff done for mgba (granted https://mgba.io/tag/debugging/ is what most tend to look at which is more for game specific faults and emulator quirks).

Tracing in general is easy enough in concept. Computers/CPU can do three main things with memory.
1) Read something
2) Write something
3) Execute a line of code there.

Consequently you have three main types of breakpoint (break as in stop program, if you ever wondered what the pause-break button on your keyboard was related to then yeah), or log point if you want to log things for later examination (useful if you don't know when something more unique will happen to a commonly accessed area).
Break on read aka BPR
Break on write aka BPW
Break on execute aka BPE but sometimes in some emulators BOE.
You can also log new functions executed if you want with the general flow there being to do everything but what you want to do (move, idle...) such that the game sees timers tick down, music play, idle animations, animation upkeep and whatnot and then you do the thing you want, that being both a new function and last thing done before you stop and have a look.

If you are unfamiliar with assembly then it is a type of programming. It is unique to every style of CPU, and every class of system you use it on -- the GBA and Wii might both have ARM processors in them but their memory, hardware hanging off it and more besides will be arranged very differently.
You also necessarily have to micromanage things as CPUs are very basic devices when all is said and done, ARM stuff even more than many others (though this is by design and not necessarily a bad one).
If you are not familiar with the basic ideas of loops then probably want to get familiar there. Any programming tutorial will cover these https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm
It will look a bit different in assembly (compare/cmp followed by a branch/b/bne for IF ELSE type setups) but still be the same thing underneath it all.
Anyway I usually figure there are three types of instruction
1) Maths
2) Housekeeping
3) Program flow

1) Maths is obvious. Computers are very good at simple maths instructions (see "everything is adding" that they get newer computer science and electrical engineering types to consider -- adding it adding, subtracting is just a different type of adding, multiplication is adding...)
2) Housekeeping.
When the hardware docs say you have 16 registers (arguably a few less as a few of those are normally used for specific tasks) and each of those are 32 bits (which is a luxury compared to earlier devices -- NES is 8 bit, and has 3 general use registers) it means it.
This means copying data around (mov command), push and pop (frees up and returns the old data when you are done), resetting states and whatever else needs to be done often.
3) Program flow. Adding things up is wonderful but ultimately boring. This is why I told you to get familiar with loops as this is that.

Oh and the GBA has two instruction sets. One called ARM, the other called THUMB which is 16 bit instructions (faster, less space needed) with a few limitations though still using the 32 bit registers.

That should be enough to get started with. Some of this is jumping in at the deep end compared to what a lot of hackers start out with but you can get some real stuff done here.


Also
"jumping/mobility/velocity physics,"
Do have a read of https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub
https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm

Sorry for the off topic.

I have been in this wonderful site for years, just wanted to thank you for your excellent responses.
I check the forums everyday and I see you take your time to assist other members with long and detailed explanations.

Regards and congratulations ;).

SNEAKYTING

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
Re: GBA Assembly Tool Help
« Reply #3 on: October 31, 2021, 08:28:41 am »
Not entirely sure who told you what there as there are several different things you go between in that, some of which would not require assembly but or some crazy in depth changes (not examination, changes).

Equally "that can open up the sprites and coding/scripts from the GBA ROM". If you have previously dealt with PC games, DS games and newer, things that came on floppy disc or things that came on CD/DVD then you don't have the option to explode a GBA game, outside of some homebrew, into files with nice names, sizes, directories and extensions to poke at.


On "scripts" then you might want to go into what you mean here. For 99% of the GBA library and ROM hacking hacking purposes most will assume by script you mean the text in the game itself. The main deviation being pokemon hacking wherein scripting refers to the actions the NPCs take in the overworld. I have not dealt the most with GBA Rockman/Megaman hacking (some good people there actually -- the battle network 4.5 project would not have been easy) but they had not adopted such terminology. In this case you might be looking towards the latter, and "scripted AI" or similar is not going to be a unknown term.


Anyway most of those things seem reasonable to look at.

Graphics. Most will start by getting a tile editor, opening up the ROM in it, setting one of the GBA modes and pressing down until they have gone through the ROM, and as the GBA has two main modes (technically 4 + different sizes, though one is never really used and another one will not be used by 99.99% of sprites on the GBA) which are typically known as GBA 4bpp and GBA 8bpp but some editors will do differently.
For tile editors/viewers I like crystaltile2, tiled2002 and tiledggd.

There is also compression to consider (the GBA makes extensive use of it). Two main options for this before you break out the fun tools. That being compression search tools (not the greatest fan but they do work) and SWI log tools (you play the game and when it uses the compression feature of the BIOS, assuming it is one of the games that does it, then you get a nice log of SoftWare Interrupts aka BIOS calls to feed the compression tool with the added bonus of them telling you exactly where, what type and how much is needed).
Several tools should be available on the site here under compression tools unlz gba nlz gba and have a look at http://www.romhacking.net/?page=utilities&category=&platform=10&game=&author=&os=&level=&perpage=20&title=&desc=compression&utilsearch=Go in general.

I have a larger guide covering GBA and DS ROM hacking
http://www.romhacking.net/smf/index.php/topic,14708.0.html


Everything else there. This is where assembly starts to appear.
You will want to learn to make cheats as most things there will change memory in some way, and do so repeatability and predictably.
I usually recommend https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial for learning to make cheats.
This will allow you to find memory related things which you will want to use in further steps. For instance equipping a weapon might change stats, being hit loses health which in turn will have resulted somewhere not very far back from a hitbox check.
Alternatively if the action results in a graphical change (new sprite say) then the thing what governs the on screen display and behaviour of sprites is the Object Area Memory aka OAM (objects/objs being an alternative name for sprites).


For tracing I have some stuff in the guide above but also suggest https://www.romhacking.net/documents/361/
Mind you rather than old vba-sdl-h then no$gba debug is what will form the gold standard for many
https://problemkaputt.github.io/gba-dev.htm https://problemkaputt.github.io/gba.htm
The specifications made to go with the emulator (usually referred to as gbatek) are also the main reference for any GBA hardware question save for some of the audio stuff
https://problemkaputt.github.io/gbatek.htm

Though I do like to flank it with
http://www.coranac.com/tonc/text/asm.htm
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
maybe also https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html
https://imrannazar.com/ARM-Opcode-Map

no$gba is not the only modern offering though for there is also https://wrongbaud.github.io/posts/ghidra-debugger/ and some of the stuff done for mgba (granted https://mgba.io/tag/debugging/ is what most tend to look at which is more for game specific faults and emulator quirks).

Tracing in general is easy enough in concept. Computers/CPU can do three main things with memory.
1) Read something
2) Write something
3) Execute a line of code there.

Consequently you have three main types of breakpoint (break as in stop program, if you ever wondered what the pause-break button on your keyboard was related to then yeah), or log point if you want to log things for later examination (useful if you don't know when something more unique will happen to a commonly accessed area).
Break on read aka BPR
Break on write aka BPW
Break on execute aka BPE but sometimes in some emulators BOE.
You can also log new functions executed if you want with the general flow there being to do everything but what you want to do (move, idle...) such that the game sees timers tick down, music play, idle animations, animation upkeep and whatnot and then you do the thing you want, that being both a new function and last thing done before you stop and have a look.

If you are unfamiliar with assembly then it is a type of programming. It is unique to every style of CPU, and every class of system you use it on -- the GBA and Wii might both have ARM processors in them but their memory, hardware hanging off it and more besides will be arranged very differently.
You also necessarily have to micromanage things as CPUs are very basic devices when all is said and done, ARM stuff even more than many others (though this is by design and not necessarily a bad one).
If you are not familiar with the basic ideas of loops then probably want to get familiar there. Any programming tutorial will cover these https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm
It will look a bit different in assembly (compare/cmp followed by a branch/b/bne for IF ELSE type setups) but still be the same thing underneath it all.
Anyway I usually figure there are three types of instruction
1) Maths
2) Housekeeping
3) Program flow

1) Maths is obvious. Computers are very good at simple maths instructions (see "everything is adding" that they get newer computer science and electrical engineering types to consider -- adding it adding, subtracting is just a different type of adding, multiplication is adding...)
2) Housekeeping.
When the hardware docs say you have 16 registers (arguably a few less as a few of those are normally used for specific tasks) and each of those are 32 bits (which is a luxury compared to earlier devices -- NES is 8 bit, and has 3 general use registers) it means it.
This means copying data around (mov command), push and pop (frees up and returns the old data when you are done), resetting states and whatever else needs to be done often.
3) Program flow. Adding things up is wonderful but ultimately boring. This is why I told you to get familiar with loops as this is that.

Oh and the GBA has two instruction sets. One called ARM, the other called THUMB which is 16 bit instructions (faster, less space needed) with a few limitations though still using the 32 bit registers.

That should be enough to get started with. Some of this is jumping in at the deep end compared to what a lot of hackers start out with but you can get some real stuff done here.


Also
"jumping/mobility/velocity physics,"
Do have a read of https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub
https://www.tutorialspoint.com/computer_programming/computer_programming_loops.htm
But what program is it and how am I suppose to use it so I can recreate or convert the existing MMZ GBA script/coding into LOVE2D coding for a fan game that I'm going to work on soon?

FAST6191

  • Hero Member
  • *****
  • Posts: 3358
    • View Profile
Re: GBA Assembly Tool Help
« Reply #4 on: October 31, 2021, 04:46:11 pm »
But what program is it and how am I suppose to use it so I can recreate or convert the existing MMZ GBA script/coding into LOVE2D coding for a fan game that I'm going to work on soon?

This side of some kind of mega AI then there is no such tool. Porting efforts like that take either a long time and a lot of patience watching an emulator and game memory, or a skilled programmer that knows the original system and the new one (though the new one is apparently Lua so that is not so bad) and still a long time (but less than the watching an emulator type), you might get lucky and find this game is a C programmed game and be able to use a decompiler to speed the second one up a bit (or maybe not but make a more accurate game).

The text you can possibly find more easily if that is what you wanted. Plenty of tutorials on finding text in games, and you can learn most of what you need to tackle most games in hours there.