Sorry that was intended as more of an analogy than a direct point of comparison.
Hex editing.
Computers understand binary and only binary. There may come a time where that is not the case (see quantum computing) and depending upon how you look at it some of the earlier stuff did the same (see analogue computers and some aspects of valves). For the most part though everything is binary all the way down.
As 1 and 0 can only really be used to represent two different things they get stacked to form hexadecimal which is four of them in a row. This need not be four directly related things either but cross that bridge when you come to it.
Sidelining that for a moment though.
Assembly
In a computer you tend to have a CPU, it does nothing more than take instructions, decode them and do the operation they say to do. With this you can build basic functions and from there you can have programs.
http://imrannazar.com/ARM-Opcode-Map is a setup for the ARM7 and ARM9 (the GBA uses an ARM7TDMI where the DS uses that and an ARM9).
http://nocash.emubase.de/gbatek.htm#armconditionfield has actually what they encode as if you scroll up (and generally read that whole section). By the way basically everybody working on the GBA or DS owes GBAtek a massive debt of thanks and frankly most of ROM hacking on said systems could be reconstructed tomorrow if it was all lost save for GBAtek. Short version is bookmark it and refer to it regularly.
However the CPU is not the only thing that does processing or effects a change somewhere in the hardware so if you have a value and stash it at certain points in memory (this is one of the things that makes assembly harder -- you could know all there was about the ARM7 but if you move to a new device with a new memory layout, new BIOS/coprocessor and more you have a whole bunch more learning to do, with C and other high level languages you will tend not to have this as they deliberately wrest memory control out of your hands).
Likewise if you have a value for say strength of a character and of an enemy (we have a very simple game here) and you load both into the registers (fast memory internal to the CPU) then if it tried to decode them as instructions* it would do very odd things but if it compared those two values you can figure out which entity one the strength contest. As having simple strength values makes for a boring game and one you can not expand easily you then usually have a function to find where the data is held, to read the data into memory for that instance, how to modify the data (levels, handicaps....) and more. Working your way back through all those functions to get to where it was found in the ROM is known as tracing and is one of the earlier to gain skills when attempting to become an assembly hacker and one that never loses its potency. Guide to it on the GBA
http://www.romhacking.net/documents/361/*though it might not know what to do normally if you managed to get this into memory (say by fiddling with the save in a game) and managed to get it to jump to it... well I am sure you can see why I would say this forms the basis for an awful lot of hacks.
The GBA then has things for music, to handle the sound engine, for graphics, to handle the graphics engine, for game decisions, to handle the things that dictate what goes into the graphics engine and so on and so on including things for the processor to run, for the BIOS instructions to take as input for their functions (which can be quite extensive and can also be things you might have expected the CPU to have instead*).
*there is no divide instruction on the ARM7TDMI. The GBA BIOS and DS kind of coprocessor thing have it though, even if it is relatively slow compared to the rest of the instructions.
In conclusion then hex is everything but assembly controls what is read into where* and what is used for calculations it in the end. Somewhere** in the long lines of hex will be assembly code in binary form which, assuming there is no compression/encryption which there tends not to be on the GBA (the DS and many later consoles is a different matter), is easily converted back into more readable forms. You certainly can edit assembly code in a hex editor but it is more of a party trick than a useful skill, I do suggest being able to pull it off if you have something like those two links earlier in front of you and can take 10 minutes to make each change but being able to just think about it and do it is just a party trick and far from essential.
Technically I am supposed to mention that even though assembly is pretty raw there are still niceties afforded by using a proper assembler (if you are hacking the GBA in this day and age you will be unless you have been led horribly astray). Do a search for pseudoinstruction if you are really concerned there.
Also the people that coded the ROM in the first place might not have been brilliant programmers so some obvious fault might well be a fault in the game and similarly just because it is obvious to you it might not have been obvious to the compiler the original programmer used to make the game.
*I should note that not all data has to pass through the CPU on the way to the memory and there is a technique called direct memory access aka DMA that will take things from one location in memory (like the ROM image part of the memory map) and put it in the memory somewhere, but as it will be the CPU that puts the value into memory that the DMA controller responds to....
**it is really easy to find on the GBA. I cover it in my little GBA and DS docs as you will want a bit more grounding in assembly before I cover it really
http://www.romhacking.net/forum/index.php/topic,14708For others reading the first bytes of the ROM are the first instruction, it is almost always a jump to the end of the header. After this it is a bit of IO and then the first reference to anything in the 08?????? region is the binary proper with all the juicy stuff.
It is quite literally some two or three games that differ here, enhacklopedia wherever it happens to be this month covers the main ones in the Phantasy Star collection game which kind of half resets into the game in question. Also when it comes to homebrew all bets are off though it is still a good technique.
Finally/as I am seeing an increasingly large amount of asterisks and having to extend the reply box "I'm aware many people might think it's silly/pointless to do so given the user learnedly programs out there".
Most around here would quite happily welcome another person with assembly skills into their ranks, however it would be a bit cruel to get them to go that far if the games in question had nice tools and they only wanted to make a few changes within the limits of the program so protocol dictates you at least make the person aware of what they are asking.
Topic: GBA ASM Basic Question (Read 3895 times)