I tried doing this but it still didn't help. I'm not sure if I'm doing this right, but I pressed Ctrl-B and entered this: [0843fad4]? (The question mark is part of the string, not my sentence) and then ran the game and entered 1-1. I can see in the memory viewer that this offset is the one I want - but nothing happens. Changing that value in the memory viewer does affect the game, but obviously I can't get anything useful out of it..
I tried setting it to an invalid value (which usually freezes the game) to see what happened. But in the debugger all I can see is it getting stuck in an infinite loop with a bunch of crap I can't understand at all. Understanding uncommented ASM is not my strong point at all; even less so with ARM (which I have no idea about).

____________________

Originally posted by Hectamatatortron

---

That doesn't look like a valid address to me.

Are you sure it's not a mirror?

When it comes to mirrors, the debugger only breaks if you specify the exact address being used to access the memory location.

This is why it's hard to get breakpoints on addresses like 0x023FFXXX - lots of games access that area with the mirror, 0x027FFXXX.

Also, I have No$GBA 2.6a debugger. No need to worry about explaining to me how breakpoints work on it.

Keep in mind that if the address you're thinking of is in the .NDS file, there's no way to set a breakpoint on reads of that data directly. The card's memory is not mapped to the hardware, it is accessed serially through I/O registers.

In other words, if you're going about this the way people would when hacking a GBA game, where you can simply add 0x08000000 to the address of a byte in the ROM to get the address you want a breakpoint of, then it's not going to work. Since the address you have looks to be in that range, I'm guessing that was your mistake.

---

Yeah, it's part of the ROM. No wonder it doesn't work that way.. but otherwise, what can I do? I don't know where the level data is loaded into memory.
I thought it would be possible to do this, since the ROM shows up in the memory viewer at 0x08000000 - but it still doesn't work. Is there anything else I can do?

____________________

I managed to find the data by creating a hexdump of the memory, using an old app I had to parse No$GBA hexdumps (I made it when I wanted to extract the decompressed ARM9 binary from memory) and searching through the result.

I have the offset of the value I need now: 0x0235fde8. But I can't figure out what to do with it.
I set a read breakpoint on that value and it stopped here:



If I run it again, that value is read several times before it finally finishes and the level loads.

I have no idea what to do - I've been trying to trace through it, but I can't figure out what the code does, or if I'm looking at it from the wrong point. This is really frustrating.

____________________

I didn't know you could change the registers actually; I'll try that and see if it helps.

I guess understanding ARM isn't that hard; but it looks daunting to me, considering the only ASM I know is 6502 (with basic instructions etc). I couldn't find a good doc for it; I didn't know the GBATek doc listed the ARM instructions. That will probably be helpful.

What seems to make it harder is that apparently, the level data isn't always loaded into the same location in memory. The byte I mentioned (the 70) isn't the tileset value - it's the first byte in the level file. (Or maybe I just calculated wrong originally.. since the same byte works over several level loads.)

I ended up looking for the correct byte in the memory viewer and modified the register as you suggested. I had it break 4 times on the same byte, so I tried changing each one at a time and figured out the 3rd break changes it (r0 though, not r2)

[Note this post seems rather illogical since I wrote the first paragraph before I tried anything, at this point I'm trying to translate the code]

I tried using the GBATek document to figure out the instructions, but it's rather confusing.
I remember I learned 6502 ASM with this, which describes all the instructions and addressing modes: http://www.romhacking.net/docs/%5B110%5D6502asm.htm - is there anything similar I can use for ARM?

I'm trying to figure it out by stepping through the code and seeing what each instruction does, but not everything is obvious, and I'm just taking guesswork on some parts.
Like this:

---

ldr r1,=20CACBCh

strh r0,[r1]

bx r14



[At 0x20BB970]

ldr r1,=208B168h

mov r0,r4

ldr r2,[r1]

add r1,r4,400h

---

which I'm assuming means this:

---

r1 = 0x20CACBC;

memory[r1] = r0;  // r0 is 0x08, which is the tileset value I'm using

goto r14;  // r14 is 0x20BB970; assuming that's an address, since it's nearby



offset_20BB970:

r1 = 0x208B168;

r0 = r4;

r2 = memory[r1];

r1 = r4 + 0x400; // the part for ADD on the GBATek doc was the only part I could understand

---

Is there anywhere I've gone wrong in that? Some other things also confuse me - why use bx instead of b, for example? The GBATek doc doesn't help much as so much of it is just abbreviations and confusing expressions which might make more sense to an experienced ARM programmer; but not to me.

____________________

I've managed to find out where the tileset code is loaded, I think.
I've also managed to understand pretty much everything, but I don't get this, what does it mean?

---

ldr r0,[r0,r2,lsl 2h]

---

Also, just to clarify: I'm assuming that [r#] means "the value of the address in r#", and =###h means "the direct value 0x###" (forgot what it's called, but it uses that value directly, instead of doing any memory or register lookups).

This also confuses me:

---

ldr r1,[r13,4h]

---

I'm assuming it means "set r1 to the value of the address (r13 + 4)" but I wanted to double check. Thanks for all your help with this, btw.

____________________

I've managed to disassemble what is pretty much an entire routine, and translate it into pseudocode. (A bunch of the comments don't make much sense since I wrote them while working through the code in the debugger.)
However I have no idea what it's supposed to do. I can figure out one thing - the jump table which runs a different function depending on the tileset number (some tilesets use the same function, or have none). But the rest doesn't make much sense.

This is my pseudocode:

---

offset_20B54F4: // tileset routine; called many times while loading a level, untouched otherwise

  push r4,r5,r14

  r13 = r13 - 4

  r4 = r1

  r1 = r4 + 0xC00

  r1 = memory[r1 + 0x10]

  r5 = r0

  if (r1 < 1) goto offset_20B5520

  if (r1 <= 6) {

    r13 = r13 + 4

    pop r4,r5,r15 // return from sub

  }

offset_20B5520:

  r1 = 0x20CACBC

  r0 = 0xFFFF

  r3 = memory[r1] // tileset value chosen here

  if (r3 == r0) goto offset_20B5570 // possible error checking? tileset 0xFFFF does not crash the game, just loads no tileset

  r1 = 0x20CB640 // Looks like a jump table of some sort is here

  r2 = r3 << 3 // Indexing?

  r0 = memory[r1 + (r3 << 3)] // Why not just do memory[r1 + r2]...

  if (r0 == 0) goto offset_20B5570

  r3 = r1 + r2

  r1 = memory[r3 + 4]

  r0 = r5 + (r1 asr 1) // sets flag which is used later I assume

  if (r1 == 0) zero_flag = true

  r1 = r1 & 1 // Does not set flag seeing as the instruction was "ands"

  if (!zero_flag) {

    r2 = memory[r0]

    r1 = memory[r3]

    r2 = memory[r2 + r1]

  }

  r1 = r4

  zero_flag = (r1 == 0)

  if (zero_flag) r2 = memory[r3]

  call_sub r2 // Process the jump table

offset_20B5570: // If the jump table lists 0 for a specific tileset, it skips directly here

  r0 = 0x2085A84 // Seems to be another jump table, how nice..

  r0 = memory[r0] // wtf?

  r0 = (r0 == 0) ? 0 : 1

  if (r0 != 0) goto offset_20B55F4

  r3 = 0x20C7818

  r2 = 0

  r0 = memory[r3]

  r1 = 0xFFFF

  r14 = r2

  if (r0 == r1) goto offset_20B55E0 // Oh look! More error checking? Except I don't think 24 is the tileset

  r0 = r4 + 0xC00

  r12 = memory[r0 + 0x10]

offset_20B55B0:

  r0 = r2 + 1

  r0 = r0 << 0x10

  r2 = r0 >> 0x10

  r0 = r2 << 1 // ??

  r0 = memory[r3 + r0]

  if (r12 == r0) {

    r0 = r14 + 1

    r0 = r0 << 0x10

    r14 = r0 >> 0x10

    goto offset_20B55E0

  }

  if (r0 != r1) goto offset_20B55B0 // nonsensical loop

offset_20B55E0:

  if (r14 == 0) goto offset_20B55F4

  r0 = r5

  r1 = r4

  call_sub offset_20B566C

offset_20B55F4:

  r0 = r4 + 0xC00

  r3 = memory[r0 + 0x0A]

  r1 = memory[r0 + 0x1E]

  r2 = 0x20CAFE0

  r4 = memory[r0 + 0x10]

  r2 = memory[r2 + (r3 << 2)]

  r0 = r1 << 1

  memory[r4] = memory[r2 + r0]

  r13 += 4

  pop r4,r5,r15 // return from sub

---

edit:
I've solved my problem yay. I didn't figure out the code, but with the help of some other code, I found the reason I couldn't find any tables in the memory - the game was indexing files differently to my filesystem viewer. I managed to find tables for pretty much everything graphics related so now I have almost-perfect graphics support in my editor. (Well, once I fix my object rendering, that is)

____________________

Anyway, now I have another problem. I've been trying to figure out the overworld map format.
I managed to find a table which corresponds level area IDs to the files they use and confirmed it works. But now I've been trying to find out how the map format works.

With a lot of debugging I figured out that it loads the area ID from 0x2085A94. I traced it down using breakpoints and found out it was just copied from 0x21C839E. But for some reason, breakpoints on it won't work.

It's weird because I can set a read breakpoint and it will work fine. I can set a read/write breakpoint (with !!? at the end) and it will trigger on the read - but it never triggers for writing. The level just loads by itself. I can see the value changing in the memory viewer throughout various stages in the level loading. Am I doing anything wrong or just being stupid as usual, or have I somehow found an obscure bug in the emulator?

____________________

Originally posted by Hectamatatortron

---

Did I mention that if a mirror address is used for the accessing instruction that the break won't hit?

Oh, wait...yes, I did.

That's probably your problem. It could take a while to try all the mirrors. Maybe try backtracing from the read until you get to the write? That could take a while too, but you've got to do one or the other, it seems.

Pick your poison.

---

How many mirrors would exist for that address? Time isn't really an issue.
Assuming that each mirrored area is 0x400000 (4mb; the GBATek document says this is the size of the main memory) it would make sense that these work: 0x21C839E, 0x25C839E, 0x29C839E, 0x2DC839E - but none of those trigger a read breakpoint either. Unless there are more mirrors I'm missing..

____________________