trying to load the unused debug menu in spongebob the yellow avenger

[joshiruxpi]

i am trying to load/hack in the unused debug menus in spongebob the yellow avenger for the nds but everything i have tried has not worked either resulting in crashes and other shit
i have a bit of know how in nds romhacking
and i have the tools to do so i think
does anyone know how i might be able to get it working

[KingMike]

Well, we don't know what you know about NDS ROM hacking, nor what you've tried nor trying to do.
It's hard to answer questions in that situation.

[FAST6191]

Are you sure the code is still in there?

The DS was firmly into the compiled code era of game making so commenting something out at compile time probably resulted in it not being anywhere in code, unlike the assembly era wherein something was more likely to have any vectors to access it in normal play (which themselves might be obtuse but that is potentially a different discussion*) removed/NOPed out as it makes life easier** and thus could be reintroduced again. If you then found some reference to it in a text file/set of strings then that might be all that remains and any debug menu is then one you created inspired by the things there, that or you hope someone finds something from whatever dev made it (old test carts containing a beta version, some dev finds a backup CD, and computers from bankrupt companies that somehow escaped the DBAN routine) and dumps it.

*or actually maybe not. One day hopefully soon I will get around to finishing the guide I am doing to finding hidden cheats, Easter eggs and debug menus. Short version of that though is watch the button presses to see if there is an odd combo looked for, watch to see if button sequences are stored in something unnecessary and maybe analyse code to see if there are unused sections. You can also try watching things the debug menu might influence (infinite health might be a flag in the calculation of damage kind of thing, and probably not an initially obvious one if it is normally concerned with obvious things like atk, def, evasion, randomness generator...).

**if you have fixed jumps and hardcoded locations then deleting a bunch of code makes life annoying for everything else that follows it or jumps to it. Compilers have no such qualms though.

[joshiruxpi]

yes i am sure it is still there there are three files called DebugMenu.pixml DebugMenuNICK.pixml and DebugMenuTHQ.pixml
i imagen that is the debug menu code but idk for sure

[joshiruxpi]

Well, we don't know what you know about NDS ROM hacking, nor what you've tried nor trying to do.
It's hard to answer questions in that situation.

well i have tried replacing code modifying code and etc etc idk i know a bit about editing text/code and textures/sprites

[FAST6191]

That does not mean the actual code that the game runs/ran is still there -- some assets that were part of it might well have been left behind but the code lost ("no little programmer don't touch my artwork"). At the same time it does not mean it did though. I have similarly also seen files named debug be final game very useful bits of normal play (no fix more permanent than a temporary fix and all that).

"replacing code modifying code and etc etc"
That tells us nothing.

I figure you have two main approaches.

So you have some files you are reasonably sure deal with the debug menu. Some have done more static approaches looking at the file handler for those files. Way more annoying on the DS than some of the cart in memory based systems but is what it is.

The other is as I described. Examine the code in the menus, start screens and whatever else for what would launch the debug menu. Could also be in game and it is the same technique.
If it is going to have to be done by a button press combo then something will be either looking for an odd combo (most menus are press A or press START, maybe B to cancel out, if you find something watching the controller state/debounced controller state for A+B+Y+START or something equally unusual and then jumping to a new area) then investigate that. Or if said menu is not something that has to memorise button presses (fine for in game move combos a la press A, then down and then up, less useful in sound test menus and things like that) or has a series of gated actions (if you have ever done a flow chart where only one thing advances down the path to the goal and everything else either stalls out or returns to start then that is what you are expecting, albeit in ARM assembly) it can take based on button presses or menu locations then that is probably something to look at.

Alternatively if buried in the menu code is some kind of area that is not normally taken then you can figure out how to jump to it or force a jump (if the execution methods were removed but the code itself left like it was often seen in 16 bit and older titles the compiler might not be smart enough to remove it, though they were pretty good by this point). Logging functionality on DS emulators is somewhat minimal compared to https://fceux.com/web/help/CodeDataLogger.html but you can achieve something like it with GDB and a fancy frontend for it https://wrongbaud.github.io/posts/ghidra-debugger/ .