mzxrules

Some good notes, though I think most if not all is documented on the cloudmodding wiki. One thing that interests me is whether or not there's an easy way to generate a compatible overlay file with gcc. I've come really close to it through linker scripts, but my hang-up is that I either can't generate relocation data, or I end up generating an ELF object file. As relocation types, I believe the run-time relocation function only supports a handful of relocation types (the wiki lists four, but I haven't checked the code/data recently to confirm). On the topic of matrices, one thing to point out is that if you're doing some matrix manipulation in floats, care must be taken when downcasting from float -> int (and later a short), since such a cast will fail on real hardware if the value ends up being bigger than int_max/smaller than int min.

it amazes me how long it's taken to release this game. I remember reading about it in the same magazine covering Twilight Princess before it's original release.

That error usually pops up if you forgot to set the version to that of the Debug ROM, since by default I profile OoT NTSC 1.0. You swap versions by entering ver dbgmq

bumping up this thread because I recently updated a program I wrote called Spectrum that I created to map out how ram is being utilized in Ocarina of Time, and later Majora's Mask. The latest update makes it quite easy to trace most addresses from ram to a file in rom: http://forums.zeldaspeedruns.com/index.php?topic=2226.0

There are definitely a few features I'd like to add to the program myself, so I don't expect this to be the final version just yet. One thing I'd like to support is NTSC 1.0 since there are significant differences between PAL (Debug MQ), and NTSC.

do you know if i said/edited anything important here in the last few months? I don't think I have since I've been posting my stuff elsewhere

This falls within ovl_En_fHG, phantom ganon's horse. not too surprising. If mips can only work with 2 byte immediates, how does the 1 affect Spirit Arrows?

not real until I have the binary.

http://wiki.cloudmodding.com/oot/Actor_Overlay_Table

not sure what you're asking for exactly. Do you mean like where the actor file is loaded in memory (when it's loaded), or an actor instance? Where the common struct is located or something entirely different? I also don't see any logical reason for why anyone couldn't use the actor table.

You can use the same save since it's probably unlikely anyone will extend the space used for your save data, but if the layout of puzzle elements change in a future update you might encounter some weird quirks in some areas

nobody here remembers my mod

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

Spent about a day on this, trying everything to figure out why the mod was crashing on everything but nemu before finally isolating it to this snippet. For some reason, my mod throws an exception somewhere between 1DB0E4 and 1DB100 causing it to fatally halt, and I'm not sure why. Breaking up this section with no ops fixes it, though I still have issues on real hardware.

Maps look great, except for that one tree's textures

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

a friend of mine bought two of those super joystick things (though one was a different shaped controller and had different games). The D-Pad is quite crap, but it was amusing to play. Does that thing have Contra on it?

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

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

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.

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.

@@PwnzLPs I wrote some notes on boolean operators here for him, which every hacker should know: http://pastebin.com/aMGkS8en One thing I forgot to mention is the shift operators (bitwise and logical).

visibility

Thoughts: Not confident about the place where you're grabbing the D-Pad input (0x80166AF0). Assuming it's the same as NTSC 1.0, that bit of ram should be part of some stack. The title screen reset code grabbed input from the Global Context (it's not documented yet, but input for all 4 controllers should be in the 0x54 range). Is 801A0000 really a safe spot to inject your code? Your source code isn't preserving the state of your registers by pushing the register values on the stack/popping them off when you're done. Are you sure it's ok to re-assign their values within this context? You should be able to save an instruction by not assigning T0 to the same value later on in the source, two if you decide not to change the spot that you're reading input from

Speaking of delayed games...