Jump to content
  • 0

Zelda OoT Debug Crash Debugger Combination


Airikita
 Share

Question

I have found a lead to the button combination for Zelda Debug on a console:

 

Note it may not work for an emulator (it doesn't for almost all of them, maybe all of them don't) but if you want to play it on console, here is the code for the Crash Debugger deciphered from the data in the Japanese text in the video:

  1. L + R + Z
  2. Up + C-down
  3. C-Up + Down
  4. Left + C-left
  5. C-right + Right
  6. B + A + START
  7. L + R + Left + C-right + START

HeavyZ will confirm this.

 

EDIT: We are under the impression KeyWaitB implies controller two.

 

xdaniel:

 

KeyWaitB (LRZ 上下 上下 左左 å³å³ B A START)
L + R + Z
Up + C-Down
C-Up + Down
Left + C-Left
C-Right + Right
B + A + Start

KeyWaitB'(ï¼¬ï¼²å·¦å³ +START)
L + R + Left + C-Right + Start
 

...is what I gather from the video.

Seems more accurate, but still testing.

 

EDIT: we're under the impression that Nintendo used the Konami code for this.

Link to comment
Share on other sites

Recommended Posts

  • 0

No I think someone just played a separate video to show what the crashed screen looks like, and an example of how to crash and activate the debugger. The guy who did the video really should have told how he done it. I'm having a hard time activating the debugger. If only someone could code it to activate on crash automatically...

Link to comment
Share on other sites

  • 0

KeyWaitB (LRZ 上下 上下 左左 å³å³ B A START)

L + R + Z

Up + C-Down

C-Up + Down

Left + C-Left

C-Right + Right

B + A + Start

 

KeyWaitB'(ï¼¬ï¼²å·¦å³ +START)

L + R + Left + C-Right + Start

 

...is what I gather from the video.

Yeah, it's possible... the + was yellow though, but you could be right.

 

But is it possible KeyWaitB' is controller 2? It's separate...

 

 

 

So this displays the debug messages side by side as you play the game itself?

It looks like he used a separate emulator that accesses the Debug text that the rom prints out... it doesn't look like it's part of the actual game, just an emulator that reads the Debug junk.

 

But in this case, it's a good find because now we have information on activating the debugger for Debug MQ.

Link to comment
Share on other sites

  • 0

I tried your combo too xdan, either I have to enter that code in RIDICULOUSLY fast, or it's not right. Idk, maybe I have to put this or that in on controller 2... I dunno. I might try to get some help on this from Zoinkity, he's a mad genius, and should be able to help.

 

Edited:

Until Zoinkity does offer some help, I'll keep trying your combination.

It looks the best out of all of them, so I could just be doing it wrong somehow...

Link to comment
Share on other sites

  • 0

[L R Z Up Down Down Left Right Left Right B A START]

 

is what i got from google translate

 

So i'm guessing it's what xdaniel said, on controller 2

 

EDIT:

Also, does that sound familiar to anyone?

 

Here's a hint

 

[up Down Down Left Right Left Right B A START]

[up Up Down Down Left Right Left Right B A START]

[up Up Down Down Left Right Left Right B A]

Link to comment
Share on other sites

  • 0

[L R Z Up Down Down Left Right Left Right B A START]

 

is what i got from google translate

 

So i'm guessing it's what xdaniel said, on controller 2

 

EDIT:

Also, does that sound familiar to anyone?

 

Here's a hint

 

[up Down Down Left Right Left Right B A START]

[up Up Down Down Left Right Left Right B A START]

[up Up Down Down Left Right Left Right B A]

Yes, me and HeavyZ were discussing the Konami code. I had a suspicion.

 

Your translation is also inaccurate, I already deciphered the code, and xdan is familiar with Japanese.

Link to comment
Share on other sites

  • 0

UPDATE:

With a closer look, I have determined the symbols are white for up, down, left, and right, which mean it's for the JOYSTICK and not the digital pad.

 

Also, KeyWaitB should definitely be controller 2 by analysis.

 

EDIT:

All seems to be white, so maybe they are digital pad? (is confused)

Link to comment
Share on other sites

  • 0

Actually, you know what I just realized? LRZ 上下 上下 左左 右右 B A START is just the bog-standard OoT button combination. Press and hold L, press and hold R, press and hold Z, let all go, press and hold D-pad up, and so on; just tried it on my JPN v1.2. I have the hand movements for it memorized, but not the actual buttons in combination, so it took me a while to realize.

 

So, either the code really is the same for the Debug ROM as well - which I figure it isn't, judging from this thread - or they never bothered to update that console message's text. And speaking of which, it's at 0xBBE398 in the ROM and at 0xB7F414 in a decompressed NTSC v1.0 ROM (which does not have the KeyWaitB' message, with the apostrophe).

Link to comment
Share on other sites

  • 0

Actually, you know what I just realized? LRZ 上下 上下 左左 å³å³ B A START is just the bog-standard OoT button combination. Press and hold L, press and hold R, press and hold Z, let all go, press and hold D-pad up, and so on; just tried it on my JPN v1.2. I have the hand movements for it memorized, but not the actual buttons in combination, so it took me a while to realize.

 

So, either the code really is the same for the Debug ROM as well - which I figure it isn't, judging from this thread - or they never bothered to update that console message's text. And speaking of which, it's at 0xBBE398 in the ROM and at 0xB7F414 in a decompressed NTSC v1.0 ROM (which does not have the KeyWaitB' message, with the apostrophe).

If you look closely, the combinations are different for Debug. Also, we noted that KeyWaitB is possibly controller 2.

Link to comment
Share on other sites

  • 0

The KeyWaitB debug messages in NTSC v1.0 and MQ Debug are byte for byte identical - the text "KeyWaitB" (so it doesn't mean controller 2, as it works on controller 1 in regular OoT even though that also says "KeyWaitB"), the buttons listed, etc. Check the ROMs at the offsets I mentioned.

 

Of course, the actual combination appears to differ in the Debug ROM, but the message printed to the console is identical.

Link to comment
Share on other sites

  • 0

The KeyWaitB debug messages in NTSC v1.0 and MQ Debug are byte for byte identical - the text "KeyWaitB" (so it doesn't mean controller 2, as it works on controller 1 in regular OoT even though that also says "KeyWaitB"), the buttons listed, etc. Check the ROMs at the offsets I mentioned.

 

Of course, the actual combination appears to differ in the Debug ROM, but the message printed to the console is identical.

Sadly there hasn't been any luck with either of the ports on HeavyZ's console... perhaps the Everdrive 64 has an issue with crash debuggers???

Link to comment
Share on other sites

  • 0

UPDATE:

 

OMG, I made a HUGE ERROR in the combination I entered... here's the real combination:

  1. L + R + Z
  2. Up + C-down
  3. C-Up + Down
  4. Left + C-left
  5. C-right + Right
  6. B + A + START
  7. L + R + Left + C-right + START

It's actually a combination of the OoT crash debugger code AND MM crash debugger code... with the exception that instead of "A + B + START" from OoT, it's "B + A + START" in Debug, and some other differences (2 and 3 are reversed).

 

This is regular OoT's combination: http://tcrf.net/The_Legend_of_Zelda:_Ocarina_of_Time#Crash_Debugger

 

I did translate it, but apparently I typed it in wrong... I've been having a lack of sleep lately.

Link to comment
Share on other sites

  • 0

I've tested this code and it also does not work, which seems odd. I may be wrong, but its possible the game has to have a certain flag enabled for the crash debugger to work, like how it has to have certain controllers plugged in for certain debug features to be enabled.

The other assumption is that the KeyWaitB' indicates another controller. Either it's Controller 1 for the first portion, then Controller 2 for the last combo, or vice-versa... It can also be a different set of controllers (like 2 and 3, 3 and 4, or 1 and 4...) in any regarding order... I would test any and all possibilities, including just testing a controller in one of the 4 ports on its own.

 

EDIT:

It could also be possible KeyWaitB' goes before, but that seems to be an oddity if so... I would test the first sequence to see.

 

I won't push anyone to test it, but I also know HeavyZ is trying his best.

Link to comment
Share on other sites

  • 0

Digging around the interbutts i was able to find this:

 

 

__osGetCurrFaultedThread

__osGetNextFaultedThread
 
Format
#include <ultra64.h>
#include <os_internal.h>
OSThread * __osGetCurrFaultedThread(void);
OSThread * __osGetNextFaultedThread(
   OSThread *last);
What These Functions Do
The __osGetCurrFaultedThread and __osGetNextFaultedThread functions are internal routines that the N64 operating system uses to gain access to the faulted thread. The Nintendo 64 operating system contains internal routines to gain access to threads that have faulted due to various exceptions such as TLB misses. These routines were designed for internal use only, so their names have a double-underscore (__) prefix notation. Internally, there exists a thread queue containing all the active threads created in the system. This queue is used mainly by the rmon debugging program for debugging purpose.
 
Currently, when a thread hits a CPU exception such as a TLB exception on an instruction fetch, the exception handler saves all the appropriate registers to the thread context, stops the thread from execution, marks it for the debugger, sends a message to any registered thread waiting for the OS_EVENT_FAULT event, and dispatches the next runnable thread from the run queue. If the rmon debugging program is running, it registers to receives the OS_EVENT_FAULT event, receives the faulted message, sends the faulted thread context to the gload tool running on the host, and causes the gload tool to print the thread context (mainly registers) to the screen. If necessary, developers can use the routines below in a thread that registers for the OS_EVENT_FAULT to handle CPU faults. Please see the fault sample application to learn how to use these routines.
 
The __osGetCurrFaultedThread routine returns the most recently faulted thread or NULL, if there is no faulted thread.
 
Based on the last thread, __osGetNextFaultedThread returns the next faulted thread from the active thread queue. If last is NULL, this routine performs a sequential search from the beginning of the queue. If last is not NULL, it starts the search from the last thread. If no faulted thread is found, NULL is returned. 
 
See Also
osInitialize
osCreateThread
osStartThread
osStopThread
osDestroyThread 

So it doesn't appear that it does anything we're interested in, so we really need to find out what KeyWaitB is doing.

Link to comment
Share on other sites

  • 0

Digging around the interbutts i was able to find this:

 

So it doesn't appear that it does anything we're interested in, so we really need to find out what KeyWaitB is doing.

I have the most amazing news! I found the portion of code that generates the KeyWaitB debug text! WHEEE!

 

I will trace it back if I can... (oh god I hope I can...)

 

 

EDIT:

 

YES!!!! I believe I have located the debugger, and I will force it to activate.

Link to comment
Share on other sites

  • 0

Terrible!

Looking closer at the code, I have some confusing news... KeyWaitB' is actually registered BEFORE KeyWaitB, yet the sequence is reversed... could it because of how it is read?

That just complicates the possibility of:

  • L + R + Z
  • Up + C-down
  • C-Up + Down
  • Left + C-left
  • C-right + Right
  • B + A + START
  • L + R + Left + C-right + START

-OR-

  • L + R + Left + C-right + START
  • L + R + Z
  • Up + C-down
  • C-Up + Down
  • Left + C-left
  • C-right + Right
  • B + A + START

EDIT:
Blah! Double post... meant to edit my last one, sorry...


EDIT2:
I might be confusing something though... might be irrelevant, it's only the printing for debug text.

It also appears the function to render the crash debugger is missing, but that may be false...


EDIT3:
FUCTIONS FOUND!!!
The functions for KeyWaitB and KeyWaitB' are at 0xB4D46C AND 0xB4D474 in the Debug ROM!!!

 

 

 

UPDATE:

If anyone wants to view my RAM documentation, you can download my [rough draft] text file:

http://www.mediafire.com/view/nqknrvffazlblml/CrashDebuggerTracing_byAirikita.txt

 

The location of the two functions are sandwiched between the debug text print calls for KeyWaitB and KeyWaitB' and where the first screen for the crash debugger is rendered. You can view the RAM to see for yourselves.

 

While you won't be able to SEE it in an emulator to test, with a little MIPS know-how, you can check everything that starts with a LUI XX, 8014 and with a ADDIU XX, XX, XXXX that follows, that will point you to the crash debugger's text.

 

Know that if LUI T5, 8014 is your start, then you must find an ADDIU T5, T5, XXXX to match.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.