News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: GBA ASM Basic Question  (Read 3137 times)

SogiTai

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
GBA ASM Basic Question
« on: August 28, 2013, 12:55:58 am »
So if you've noticed my previos topic, I do in fact come from a fire emblem community.  ASM is certainly something I want to get into.

However, I was wondering does ASM allow you to add your own graphics as well  Or does it simply mess with codes?

Basically would you need other programs to insert graphics into the rom?

Does ASM replace all other rom editing programs in the long run?

I want to get into ASM, and if I don't have to take the time to learn all of these editor's methods of being used, I'd like to get right into ASM. 

justin3009

  • Hero Member
  • *****
  • Posts: 1603
  • Welp
    • View Profile
Re: GBA ASM Basic Question
« Reply #1 on: August 28, 2013, 02:50:52 am »
ASM is pretty much the entire structure of ROMS, rather, their language when modifying it.  As long as you understand how the code works, you can pretty much do whatever you want within limitations of the system.
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

FAST6191

  • Hero Member
  • *****
  • Posts: 2490
    • View Profile
Re: GBA ASM Basic Question
« Reply #2 on: August 28, 2013, 04:58:08 am »
What justin3009 said though to add to it ASM is much like hex editing -- anything can be done within the limits of the system but it is often pointlessly long winded to do it that want and thus if someone has already made the tool then it is often better to use that instead.
Though the GBA is far from a complex and far from so oversimplified/weak you need to add your own complexity to do things learning the nuances of GBA assembly is likely to take far longer than learning a basic tool. Bonus is I see a lot of those tools for Fire Emblem are open source after a fashion and often using easier to learn languages like python.

SogiTai

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: GBA ASM Basic Question
« Reply #3 on: August 28, 2013, 08:48:00 am »
Alright Great!  :D  I appreciate such fast replies! 
With the info you guys have provided, I will continue my research and practice with ASM. 

I'm aware many people might think it's silly/pointless to do so given the user learnedly programs out there, but I'll give it a try nonetheless, and see where I can go, from there.  I'll still brush my skills with, said "replaced" programs too though, of course.

Quote
ASM is much like hex editing

I got a similar feeling to this when doing my research.  But with that said, other than the language what is the difference  between hex and assembly?
For example would I be limited on hex things that I would be able to do on asm?

If I understand correctly what I've been reading doing my research.  Binary code in Hex editing is the computer language, and ASM is more of a user friendly based language.  Therefore you do your programming in ASM and convert it to HEX?
Or
Is it that you find the information you're looking for with ASM via debuggers and disassembler, in order to edit the Hex?

Or something entirely different, I haven't grasped yet



Thanks again!
« Last Edit: August 28, 2013, 09:10:19 am by SogiTai »

STARWIN

  • Sr. Member
  • ****
  • Posts: 445
    • View Profile
Re: GBA ASM Basic Question
« Reply #4 on: August 28, 2013, 04:33:09 pm »
memory contains data. data that is supposed to be executed by a processor is called (machine) code. because code can be seen as data, you can open entire programs and their data as one big block of numbers that represent the contents of the memory.

data at a low level is bits in a known order. in many systems the bits are grouped as 8 bit units, called bytes. bits are either 0 or 1, and the most direct way to represent them is binary (base2 numbers). hex is just an another representation of those same numbers in base16. one hex symbol represents exactly four bits, ranging from 0 to (1111 base2) / (15 base10) / (F base16), which is 16 distinct symbols.

grouping bits to bytes means that you have an address for each byte in addressable memory, but not for each bit. a typical hex editor shows you two hex symbols (digits) near each other because they together form an addressable location. a better name for a "hex editor" would simply be data editor though. a typical text editor is not good for data editing because not all numbers have unique symbols (single letters) (assuming ASCII and so on.. just a basic example).

being able to read machine code is useful, as you can (slowly) understand exactly what the program does. people almost always disassemble machine code into some assembly language (there may be more than one asm language for one machine code) to make it easier to read and write.

as you specified GBA, there are a lot of GBA CPU details documented here: http://nocash.emubase.de/gbatek.htm#cpuoverview

there you can see what state the processor contains, which opcodes exist and how opcodes look like in the number form. i think it is a bit ambiguous how the term opcode (=operation code) is used. in any case the opcode format listings explain the relation between what you see in a hex editor and with assembly language (mnemonics): these MOV, CMP, INC and other almost readable things.

now, the parts of memory that are not machine code are not meant to be executed. for that reason, they can't really be disassembled. what all that data means depends on the (human, or human-made tool (format)) interpretation. the catch is that you can read the existing code (and use assembly tools of course - always use helpful tools) to figure out how the data is supposed to be interpreted. so no, "ASM" is not a good replacement for image viewing and editing, for example.. but when figuring out how to extract or insert images, knowledge of the code can help you to code a tool for that purpose. or you can just rewrite the code in the game to make it read images in any format you wish (not considering hardware limits) etc etc.

CPU and its assembly language is probably the easiest (and best documented) part of most of these systems. there is then the more annoying knowledge of how the CPU interacts with the rest of the system, and overall what the rest of the system does.

oh, and if there are tools for graphics that work for your needs, with high probability you should learn to use them instead. unless they are incomplete etc. though basic knowledge of low level stuff cannot do any harm.. at most it takes your time.

FAST6191

  • Hero Member
  • *****
  • Posts: 2490
    • View Profile
Re: GBA ASM Basic Question
« Reply #5 on: August 28, 2013, 04:37:40 pm »
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,14708
For 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.