[ASM & Hex] How to start in ASM hacking

[MegaMetapod]

Hi, I'm new to hacking, but I have been a programmer for some time now. I obviously had no issue applying patches, using some tools and modifying some hex options. However, I have had some issues starting with ASM.

I know the basics of ASM, and I know it has to be compiled and added to the rom, still I am not familiarized with some concepts and proceedings specific to rom hacking. I have seen plenty of tools and some tutorials, but they either go directly to the code or try to explain what is ASM from the scratch. Haven't found the right tutorial for me yet.

I want to know things such as the following:

- Are there any specific compiler or tools to develop ASM in rom hacking?

- Is there a Hello World ASM example to go all the way to the end with a simple example?

- What's up with the addressing?

I mean, other tutorials and examples say things such as "place this value in hex position x" or repoint this stuff (which I am just starting to get). Nevertheless, in ASM threads I always see references to hex addresses over 0x08000000 which really troubles me since the rom ends at 0x01FFFFFF. So maybe I need more background in pointers and addressing.

- What's up with the RAM usage?

I often see posts referring to RAM address 0x020000 are there any resources on RAM addressing and when/how to use? Are all of these posts implying that I have JPAN's save block hack (not entirely sure what that hack is about yet).

 

[mbcn10ww]

- Are there any specific compiler or tools to develop ASM in rom hacking?

Here is the compiler: https://www.dropbox.com/s/40h15zzgzunhzh1/thumb.zip?dl=0

- Is there a Hello World ASM example to go all the way to the end with a simple example?

You just need the routine, save it on notepad with the extension *.asm, don't forget to leave a blank line at the bottom of the routine, drag and drop it on the thumb.bat, then you will have a "routine".bin, open it in your Hex Editor then place in your rom the way the creator of the routine says.

- What's up with the addressing?

I mean, other tutorials and examples say things such as "place this value in hex position x" or repoint this stuff (which I am just starting to get). Nevertheless, in ASM threads I always see references to hex addresses over 0x08000000 which really troubles me since the rom ends at 0x01FFFFFF. So maybe I need more background in pointers and addressing.

The rom ends at 0x1FFFFFF, but the 0x08 before the address (0x09 after 0xFFFFFF) is just to say "it is your ROM offset not RAM offset", the prefix is used when you make pointers to routines, tables and scripts in your rom.

- What's up with the RAM usage?

I often see posts referring to RAM address 0x020000 are there any resources on RAM addressing and when/how to use? Are all of these posts implying that I have JPAN's save block hack (not entirely sure what that hack is about yet).

The RAM location isn't in your rom, it only shows up when you start the game on the emulator (with the prefix 0x02), if you're using VBA you can simply click on Tools>>>Memory Viewer and here you can view your RAM.

 

[BluRose]

hihi, just answering questions about things i'm viewing as incompletely answered

you might also want to look into totally legitimately getting a software copy of ida, usually v6.5 for fire red/emerald or v6.8 for an in-depth battle one for emerald

a "hello world" of pokémon rom applicable asm would be something like naming your character what you want. fbi also made like a workshop for that a while ago, and renaming the player character is covered in there. try those challenges out sometime, including the shiny pokémon one~

mbcn10ww basically put it the way it is, but the gba "loads" the rom into 32 mb so that it can access the data nicely. 0x08 prefix says within the first 16, 0x09 says within the second 16.
a basic guide from gbatek

Spoiler:

General Internal Memory
00000000-00003FFF BIOS - System ROM (16 KBytes)
00004000-01FFFFFF Not used
02000000-0203FFFF WRAM - On-board Work RAM (256 KBytes) 2 Wait
02040000-02FFFFFF Not used
03000000-03007FFF WRAM - On-chip Work RAM (32 KBytes)
03008000-03FFFFFF Not used
04000000-040003FE I/O Registers
04000400-04FFFFFF Not used

Internal Display Memory
05000000-050003FF BG/OBJ Palette RAM (1 Kbyte)
05000400-05FFFFFF Not used
06000000-06017FFF VRAM - Video RAM (96 KBytes)
06018000-06FFFFFF Not used
07000000-070003FF OAM - OBJ Attributes (1 Kbyte)
07000400-07FFFFFF Not used

External Memory (Game Pak)
08000000-09FFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 0
0A000000-0BFFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 1
0C000000-0DFFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 2
0E000000-0E00FFFF Game Pak SRAM (max 64 KBytes) - 8bit Bus width
0E010000-0FFFFFFF Not used

Unused Memory Area
10000000-FFFFFFFF Not used (upper 4bits of address bus unused)

and ida has a "ram map," it's really helpful in asm hacking~
the save block hack frees up some ram for free usage

 

[MegaMetapod]

Here is the compiler:

You just need the routine, save it on notepad with the extension *.asm, don't forget to leave a blank line at the bottom of the routine, drag and drop it on the thumb.bat, then you will have a "routine".bin, open it in your Hex Editor then place in your rom the way the creator of the routine says.

Thanks a lot, I have already done a couple of tests here and there. I even got one of kearnsey6's evolution methods working!

The rom ends at 0x1FFFFFF, but the 0x08 before the address (0x09 after 0xFFFFFF) is just to say "it is your ROM offset not RAM offset", the prefix is used when you make pointers to routines, tables and scripts in your rom.



The RAM location isn't in your rom, it only shows up when you start the game on the emulator (with the prefix 0x02), if you're using VBA you can simply click on Tools>>>Memory Viewer and here you can view your RAM.

Got it!

 

[MegaMetapod]

the save block hack frees up some ram for free usage

Thanks, I am finally feeling like I am making some progress. The only thing that escapes me is the RAM. I know about RAM and can understand that the save block patch frees space, however can't totally grasp why this is so important. Is the effectiveness in RAM handling such a big issue in ROM running? Or is it that the free space allows for more features?

 

[DizzyEgg]

Thanks, I am finally feeling like I am making some progress. The only thing that escapes me is the RAM. I know about RAM and can understand that the save block patch frees space, however can't totally grasp why this is so important. Is the effectiveness in RAM handling such a big issue in ROM running? Or is it that the free space allows for more features?

RAM space is finite. It's about 256 kilobytes IIRC. All pokemon games do not use it all, so there are a few kilobytes you can modify in-game and nothing bad happens. Now, all the save block patch does is alter the game saving structures and functions, so the bytes there get saved.

Also, since you're a programmer, I'll let you know that you can not only code in ASM but also in C(and even C++). Take a look at my signature and go to the Battle Engine Upgrade on Github to see how it looks like.

As for the 'Hello World' asm program, that would be hard since you can't just print text in Pokemon games.
Anyway, take a look at this thread https://www.pokecommunity.com/threads/343871
Should shed some light on asm.

 

[Touched]

Thanks, I am finally feeling like I am making some progress. The only thing that escapes me is the RAM. I know about RAM and can understand that the save block patch frees space, however can't totally grasp why this is so important. Is the effectiveness in RAM handling such a big issue in ROM running? Or is it that the free space allows for more features?

I don't know why no one has linked this yet, but here is a memory map for the GBA.

As you should know, RAM is volatile, meaning that it the data it stores is lost when the power is switched off. Obviously if you're going to save the player's progress you'll need some form of persistent storage. In the Pokemon games, this takes the form of a 1Mb (megabit) flash chip on the cartridge. Since all IO on the GBA is memory mapped, we must access the data on this chip via some memory address.

For flash this is done by using the SRAM region (0E000000-0E00FFFF). However, since 1Mb is larger than that address space, it cannot be directly mapped. So there is a special protocol used to read/write data from the chip. This protocol is handled by the Nintendo SDK and is documented on GBATEK.

Because we need to follow a special protocol to read data from the flash and SRAM memory is slow to read and write from, the game maintains a copy of the data on the chip in the saveblock structures (there are 3) in volatile EWRAM (02000000-0203FFFF). When you save the game these blocks are serialised and written to the flash chip, and when you load the game the structures are loaded from flash into memory. The original functions are inefficient in the way that they pack this data and leave gaps of unused space. All JPAN's hack does is rearrange the serialisation to be more tightly packed, allowing an additional saveblock. Therefore this hack is about expanding the amount of usable space for saving data - it doesn't in any way make more RAM available as that is impossible without special hardware (or in our case, a special emulator).