News: 11 March 2016 - Forum Rules

Author Topic: Lost in asm NDS  (Read 3246 times)


  • Hero Member
  • *****
  • Posts: 650
    • View Profile
Lost in asm NDS
« on: June 18, 2011, 09:09:52 am »
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... :'(
« Last Edit: June 23, 2011, 03:51:57 pm by Auryn »


  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Lost in asm NDS
« Reply #1 on: June 24, 2011, 01:32:10 pm »
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.