11 March 2016 - Forum Rules

Main Menu

Lost in asm NDS

Started by Auryn, June 18, 2011, 09:09:52 AM

Previous topic - Next topic


Hi everybody,
i am not such a good debugger and things look a bit different from what I have learned back on the PSX times.
I am trying to move the text window up 8 pixel (see the right part of the emulation screen) to make it bigger.
Sadly I am a bit lost on how to continue.
I know how to make the tile map bigger and know that the tile map data is cut just outside the screen so i need to move the tile map up in memory to add the missing tile line at the bottom.
I know that know it's written @ x06003400 and I need to change it to be written @ x060033C0 but how to find the value to change in the ROM??
Here you have a screen when it's writing the tile map in memory (if i not mistake).

Thanks for the help and feel free to ask me if you need other parts of the debug screen.

June 23, 2011, 03:51:56 PM - (Auto Merged - Double Posts are not allowed before 7 days.)


Hit 100 views and nobody than can help me... :'(


It looks very much like you've found the target. One way you can test is, IIRC, changing the value stored in r1 - you can actually edit the registers at runtime, if I'm not mistaken.

Anyway. You need to find out when the address is loaded into r1. One way to do this is run through the subroutine until it returns, then find the original subroutine call, set a breakpoint to that, and then step through until you find the code you're looking for. If you still can't find it, repeat the process: see where the subroutine that called the subroutine breaks, step through, set a breakpoint to the call and whatnot. Keep tracing the matryoshka outward until you find the address being loaded.

Note that games have this wonderful habit of shuffling values around en route to their goal. It may not be initially loaded into r1: it may be loaded into another register and transferred to r1. You'll need to keep an eye out for that.

Also, an advanced trick that can save you some repetition is looking for the return address in the stack. When a subroutine call happens, the return address is pushed into the stack, so you can actually spot it if the push/pop balance is even or close to it (and the stack pointer hasn't been tweaked in any other way).
In the event of a firestorm, the salad bar will remain open.