Finding a Debug Menu

Discussion in 'NDS - ROM Hacking and Translations' started by Wellington2k, Apr 20, 2013.

Apr 20, 2013

Finding a Debug Menu by Wellington2k at 2:55 PM (1,055 Views / 0 Likes) 5 replies

  1. Wellington2k
    OP

    Member Wellington2k DO YOU HAS?

    Joined:
    Nov 1, 2010
    Messages:
    751
    Location:
    Somewhere in this world of ours
    Country:
    United States
    Hello!

    I've looked at this one game for DS and it appears to have a debug menu. In fact, the button press in order to reach the debug menu during development was L+R+X. I've also found the address where the text is shown in the debug menu.

    Where do I go from here?

    I have the No$GBA debugger.
     
  2. ccdeal51
    This message by ccdeal51 has been removed from public view by tj_cool, Apr 20, 2013.
    Apr 20, 2013
  3. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,698
    Country:
    United Kingdom
    What options you have could vary a lot-
    It might just be that the text stuff was left in and the entire debug code was ripped out. Unlike older systems with lots of assembly when it comes to the DS you are probably just recompiling it so such a thing is not so problematic.

    Still the address of the text may or may not be useful, I assume this is in the binary as in the ROM is really not going to do much good (DS tracing is in its infancy still really and it is not like the GBA where you could realistically look for copy from/BIOS compression read/DMA read to 08??????). If the menu is still there and the text is in RAM then search through the binary for an instruction that plays with that area. Going backwards from there you can hopefully find what starts that code and then you just need to either trigger it manually or hope somewhere the debug was something but got NOPped out (I assume it is interrupt driven or every vblank for the controls to be parsed so if the "if L+R+X" then debug arrangement reads "if L+R+X then NOP" you are good, otherwise you are going to have to make a command to jump or otherwise tell it to jump to the debug menu location).
     
  4. Wellington2k
    OP

    Member Wellington2k DO YOU HAS?

    Joined:
    Nov 1, 2010
    Messages:
    751
    Location:
    Somewhere in this world of ours
    Country:
    United States
    OK. Would I have to search in the ARM7.bin or ARM9.bin or both?

    I also found that there is an IN-GAME Build Notes menu (Unknown activation) and a Fly Cheat (L+R+B and Move With The Control Pad).
     
  5. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,698
    Country:
    United Kingdom
    Theoretically it could be anywhere. In practice I doubt it will be in an overlay (or if it is then it will be one stuck in a unique or nearly unique address) and probably not the ARM7 either as it is not typically something the developer really touches (though there might be a debug version of the ARM7).
     
  6. Wellington2k
    OP

    Member Wellington2k DO YOU HAS?

    Joined:
    Nov 1, 2010
    Messages:
    751
    Location:
    Somewhere in this world of ours
    Country:
    United States
    Luckily there are no files in the overlay folder. So that narrows it down to ARM9.

    Would I just search for the text of the debug menu I found in a hex editor or No$GBA debugger?
     
  7. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,698
    Country:
    United Kingdom
    In almost all programming languages there are many ways to skin a cat and ASM is probably the worst of all.

    Still there is a general order of operations

    You have two binaries (the ARM9 and ARM7) running on their respective processors. Overlays (though are none here) can be dropped into memory and jumped to allowing the game to swap out functionality at points.

    Generally operations will be run all the time though it can be lessened for power reasons. One of the big points for stuff happens during the vblank period and though it is technically an interrupt phase most consider it separately to more general interrupts. Interrupts are the other big concept and they allow you to say "if this happens then stop everything and run this" rather than checking every few cycles though that is still an option used by some people.

    As far as button presses are concerned though... they are visible in memory at all times but at every vblank or some other set point the values of buttons are copied into memory and those are used for all "if ? button is pressed" operations (it stops issues with buttons maybe not being the same state from one microsecond to the next and is still faster than any human can press buttons), for that reason be aware of this if you are looking for code that speaks directly to those memory locations as it probably does not work that way.

    At some point those three ideas would have merged together to generate something that in higher level languages would have read
    IF (L+R+X = pressed) THEN GOTO DEBUG
    ELSE carry on with main program.
    ASM even compared to C is quite different in the arrangement it will end up with (you will get all sorts of compares and branches rather than IF and ELSE) but the logic is the same.

    In older games that were largely written in ASM with a set memory structure the "THEN GOTO DEBUG" phase would probably have been commented (NOPped) out to do nothing which is why earlier consoles can sometimes have them added back in quite easily. The DS has no such qualms though as most things are written in C family languages or something even higher level (at these points I usually note lua exists and was used in several commercial games) and commenting out the debug stuff at source level and recompiling is a simple task. It is not a certainty though and the old arrangement or something akin to it might still have existed; in general use you can not press up and down at the same time so they might have changed the L+R+X to be UP+DOWN+X* or they could have just left all the functions in but changed the IF L+R+X to do nothing.

    *this is not such a bad idea for depending upon your developer quality some fragment might still half rely on debug code and stripping it out might then have your final debug build work flawlessly but the non debug stuff might fail. In this case the flight option might be quite useful for a cutscene or something.

    On top of this the DS is also noted for not having the whole ROM visible in memory or even visible in memory as pages/banks and this means in general the binaries are catapulted into memory at boot where they run from (this is why you can port assembly hacks or hacks to binaries and overlays to cheat form on the DS) and everything else is copied and uses an odd command structure. Coupled with the high level languages stuff this is why things might be odd compared to older consoles and methodologies. I already mentioned that the text might just be a developer leftover and nothing of the actual code could still exist in the final game, if it was buried in the ARM9.bin though things look up a tiny bit and doubly so because that commands and copy arrangement is very annoying to work backwards though for data you know is used and is being used at the point you are trying to trace from.
    However where you could have some logic to working through to hidden sections on the older consoles; say on the GBA even if the IF L+R+X stuff is broken following it or at some other place there will be calls to the text you mentioned and that tends to lead to the debug functionality at which point you just get to rebuild the IF L+R+X arrangement into something that works.
    If the text is just in a file then most bets are off as developers do not have to worry so much here (DS ROM space is quite large so things are not that tight), for example I was pulling part a Castlevania game for the hacking docs and in the sound file was a bunch of stuff from their E3 presentation before the game was released and loads of other nice things have been fished out of DS ROMs over the years. Being in memory the binary is a bit more limited and developers are bit more inclined to keep it tidy.

    I am not quite sure I have something good to say so as to tie it all together at this point but hopefully I have said something that you can use as a jumping off point.
     

Share This Page