mzxrules' notes on Ocarina of Time

[mzxrules]

So I was poking through different variables within the Global_Context on NTSC 1.0 when I noticed that a section that manages controller input was reacting whenever I "plugged in" a controller into the 3rd slot, but not slots 2 or 4.

 

So I booted up Nemu to see what (if anything) was reading input from controller 3.

 

It turns out that ovl_En_Mag (Actor 0171) contains code that checks for a sequence of button presses that when pressed completely wipes out all save data. This code is useful for clearing out corrupt save data that would otherwise be impossible to delete without opening up the cartridge.

 

I call it "Resetti no Forgetti"

 

To activate the code, press D-Up, D-Down, D-Left, D-Right, Start, B, C-Down, L, C-Right, C-Left, A, C-Up, R, Z in sequence on controller 3. After each correct input you have 16 frames to press the next input in the sequence, or else the code will not work.

[mzxrules]

Some months ago, someone created a modified version of mupen64plus that printed out the output text written to the IS64 system. Since I couldn't find the program anymore, I made one myself, but worse!

 

http://www.mediafire.com/download/oe37gcrh8o7mbu5/release-light.zip

 

Reason for this is because Cen mentioned a set of addresses he found that results in the game dumping the entire frame:

 

MQ debug: 80166D28 0000

MMdebug 800A5A20 0000

[PwnzLPs]

...but worse!

oh boy... XD just kidding. Good job, mzx

[mzxrules]

my laptop died a few days ago. Still want to try one more thing to see if I can get it to boot. Don't know if the hard drive is still good. 

 

Fortunately, I have a "full" back-up of everything I felt was important to me from around October, while I have a partial back-up of a subset of my files that dates back to late February. I don't remember but I don't think I've done a whole lot of important coding recently so that's a plus.

 

Assuming the worst (hard drive failure), the biggest loss is probably a bunch of notes I started taking of different routines observed in Nemu. I had also began pushing toward updating my xml actor documentation the days up until the crash, primarily adding more consistency to things, finding more things I overlooked, adding more metadata notes. Guess the mupen hack source is gone, but much of that was spent understanding the layout of mupen's source and getting hung up on beginner C stuff.

[mzxrules]

Poking into transition actors (specifically 0x0023, the room changing plane), and found some interesting things

 

There appears to be an upper limit of 64 transition actors per scene. The reason for this is that when a transition actor is initialized, it stores an index that references back to the transition actor list within the upper 6 bits of the variable located at 0x1C within the instance (where the "variable" part of an actor's initialization params are stored). 6 bits = 64 different values. 

 

When a scene is loaded in memory, the actor number component of a transition actor record is negated whenever that actor is in memory.

 

Actor 0023 has a variation that is bound to a switch flag. If the switch flag is not set, the actor won't swap rooms when Link walks through. You can use this to (for example) make it so that one hallway leads to one of two or more different rooms.

[mzxrules]

Spent a bit of time backtracing through oot routines, and found a bunch of important game-related stuff for NTSC 1.0 (though some applies to other versions as well).
 
http://wiki.cloudmodding.com/oot/RAM_Map_(NTSC_1.0)
 
In addition to the above, the function at 80051B50 (which is located within code) initializes a block of memory that is 15D4 bytes long (rounded up to 15E0 when allocated). I have little idea of what's in this block, but from what testing I've done it seems that this block remains loaded in memory for the duration of the game, meaning that if you increase the space allocated, you'll be able to use it for creating your own static variables. The specific instruction that sets the size of this space is located at 80051B5C (ADDIU A0, R0, 0x15D4). 
 
 
http://wiki.cloudmodding.com/oot/Overlay_Table
 
 
I've known of the existence of the above table for some time, but I just recently took a closer look at things. It turns out, that this table defines the so called Global Context in one of it's records, and as such means that you can also add variables to the tail end of that as well.

[mzxrules]

been working on a fun new mod (something I didn't think would take this long but eh), called "Beta Quest" for NTSC 1.0. Basically it's a mod with randomized entrances, and unlike the real "Beta Quest", it crashes a lot less often.

 

However there is one problem, and it seems to be some sort of phantom bug I encountered when working on Dungeon Rush. For some reason, decompressing the NTSC 1.0 rom results in glitches with the RCP when the Game Over screen is being drawn. In some instances it can actually hang the emulator (PJ 64 1.6 at least), which is really odd. The most consistent way that I've gotten a fatal hangup is by going from Link's House (entrance 00BB) -> Inside Jabu Jabu (0028), die, don't save, continue. NTSC 1.0 compressed does not seem to be affected by this issue at all

[haddockd]

I assume that means that if you recompress it after modding it that it doesnt crash...correct?

[mzxrules]

I hope so. I'm still working on it so I haven't gotten to the point where I want to re-compress it

[haddockd]

Ah. Would it be worth your time to compress it and test just to see? If it works after recompression then you may have an answer. Also have you tried other emus (Nemu, 1964, etc)?

[PwnzLPs]

Just an FYI, Nemu doesn't give a fuck about what you do to it so long as it doesn't throw any crashes, and everything in the ROM that's getting pointed to is where it's pointed to. And even then, the second one doesn't always cause crashes. Most of my results from those errors (stuff not being where its pointed at) just skewed the HUD and caused whatever was pointed to to turn invisible. Just fair warning.

[mzxrules]

created a compressed build, and like i expected it works fine. I'm far more interested in knowing what is killing the game off, and why its not consistent

[mzxrules]

Intended to work on cutting down some cutscenes in my mod, got sidetracked and started looking at the code for the game's cs parser

 

Valid commands range from 0x01 to 0x90, 0x03E8, and -1. A jump table is used to parse commands 0x01 to 0x90, and is located at 8010757C NTSC 1.0

 

I've only traced through the routine used to parse the cutscene command that handle's Rauru's actor, but I now realize why nobody has built a "master" list of actor ids yet. From what I can tell, the purpose of this set of routines is to simply set a pointer to the active command for an actor. The actor then listens for it when it's being processed.

 

What's more important though is that a number of ids reference the same function. For example, Rauru's cutscene id (0x27) uses the same routine as 17 other different ids, meaning that these ids should be are equivalent to one another 

 

This is also means that some ids can't be used with one another, since you'll end up overriding the pointer before the actors can act on it