43512

Based upon the OOT Debug ROM scene and entrance table extension hack, I created a program to extend these two tables and fix the pointers to them automatically.  Additionally, due to a point brought up in the brief discussion regarding the limits on how many new files can be added due to ROM size limits after posting about the aforementioned hack, I wrote up a few code segments that would allow Yaz0-compressed files to be stored in the ROM and decompressed in real-time as needed, similarly to how MM operates.

The idea is that, when intending to start work on a mod, you would run the ROM through this program beforehand.  Any new files added to the ROM, of course, will have to be added to the look-up table that this program produces at the end of the ROM; I intend to write a small helper program for inserting new files, but that will have to be done manually.  Please consult the readme for more information, or ask a question here and I'll do my best to answer.

Download links:

Windows 64-bit binary:  https://mega.co.nz/#!llskDQ6D!9mZacQQ-u2XIMFW70yJ-y8hShMnJ0NNAvy_ASeE0AVE

Source code:  https://mega.co.nz/#!oh9zgYSA!UmWufyzsgRUIEGyCdo2Gh-vC66CXFS6gpo-7Fwudj9E

Something that people should be aware of when following your tutorial is signedness in assembly. Thankfully, when setting that scene/entrance table offsets, you used ORI for the lower 16 bits which interprets the value given as unsigned. However, the ADDIU to set the lengths of the scene/entrance table, if given values after 0x7FFF, will be a negative number and result in FFFF being placed in the upper 16 bits of the register. Perhaps an ORI should be used in place of the ADDIU.

 

Nonetheless, great job!

I agree with the ORI method, although it depends on if you want to go up to 8000 or higher, lol.

Ah, good point.  I made a point of using ORIs as much as I could, so I'm not really sure how those ended up as ADDIUs; perhaps I should've examined my code a little more thoroughly when I wasn't drowsy.  =P

I'll edit the tutorial to use ORI instructions for the lengths instead, although I can't imagine having so many areas and starting positions in a mod that someone would need to expand the scene or entrance tables to above 0x7FFF in length.  Come to think of it, would you even have enough space in ROM to store enough scenes to fill all of those entries with valid data?

Good job at finding it, saves people time to dig for it themselves. I archived this immediately.

Thank you!  I understand that the scene/entrance cap could become a serious limitation for someone trying to make a large-scale mod, especially due to how unobvious it is to resolve -- this solution, at the very least, isn't intuitive at all -- and how you need to be knowledgeable about assembly and such to fix it.  Using spinout's ztables hack is one solution, but I wanted to determine exactly what you'd need to do to overcome it, both out of my own curiosity and out of a desire to produce sufficiently detailed documentation that someone could design a program to automate the process.  Thus, I derived a solution and kept track of every last modification I had to do.  I hope it'll prove useful.

Nice one. Did you find that code by yourself or were you using spinout's hack as a reference?

Thank you!  By myself.  I was originally going to take a look at spinout's, but once I found one of the offsets referencing the scene table in RAM, I surmised it'd be easy to come up with the rest.  I was wrong, but, since I enjoy ROM hacking like this and figuring things out on my own, I went ahead and completed it without investigating spinout's work.

How to extend the Scene Table and Entrance Table arbitrarily (offsets are for the OOT Debug ROM):

1. Copy the code from 0x21CC - 0x2264 and put it in a separate file (we’ll call it codefile_loader.bin; pastebin of raw hex).
2. Make the following changes to codefile_loader.bin:
   • 0x90: 03E00008 -> 27BD0038   (JR RA               -> ADDIU SP, SP, $0038)
   • 0x94: 27BD0038 -> 8FBF0038   (ADDIU SP, SP, $0038 -> LW RA, $0038 (SP))
   • 0x98: insert bytes, 03E00008 (null -> JR RA)
   • 0x9C: insert bytes, 27BD0040 (null -> ADDIU SP, SP, $0040)
3. Insert the modified codefile_loader.bin into a sufficiently-large area of free space in the ROM (in an unmodified OOT Debug ROM, unused space starts at 0x35CE040).  Make a note of the starting offset.
4. Copy the code from 0x5050 - 0x50E8 and put it in a separate file (we’ll call it ram_clearer.bin; pastebin of raw hex).
5. Add the following lines to the top of ram_clearer.bin:
   • 3C088015  (LUI T0, $8015)
   • 35087D90  (ORI T0, T0, $7D90)
   • 10880026  (BEQ A0, T0, $000050E4)
   • 00000000  (NOP)
6. Insert the modified ram_clearer.bin at 0x5050.
7. Copy the scene table from 0xBA0BB0 - 0xBA1448 and put it in a separate file (pastebin of raw hex).
8. Add as many additional entries to the bottom of the table as you want or need (keep track of the new file length for later).
9. Insert the modified scene table into a block of free ROM space.  Again, remember the starting offset.
10. Copy the entrance table from 0xB9F360 - 0xBA0BB0 and put it in a separate file (pastebin of raw hex).
11. Add as many new entries onto the end of the table as you need or want (again, keep track of the new file length for later).
12. Insert the modified entrance table into another segment of free space.  Like with the others, record the starting offset.
13. Create a new file and add the following lines to it (pastebin of raw hex; XXXXs are still present):
    • 27BDFFC0 (ADDIU SP, SP, $FFC0)
    • AFBF0038 (SW RA, $0038 (SP))
    • 3C048001 (LUI A0, $8001)
    • 3484CE60 (ORI A0, A0, $CE60)
    • 3C08XXXX (LUI T0, $XXXX [1st half of scene table start])
    • 3508XXXX (ORI T0, T0, $XXXX [2nd half of scene table start])
    • 3C098015 (LUI T1, $8015)
    • 35298000 (ORI T1, T1, $8000)
    • 340AXXXX (ORI T2, R0, $XXXX [new length of scene table])
    • AC880000 (SW T0, $0000 (A0))
    • AC890004 (SW T1, $0004 (A0))
    • 0C0004FF (JAL $000013FC)
    • AC8A0008 (SW T2, $0008 (A0))
    • 3C048001 (LUI A0, $8001)
    • 3484CE60 (ORI A0, A0, $CE60)
    • 3C08XXXX (LUI T0, $XXXX [1st half of entrance table start])
    • 3508XXXX (ORI T0, T0, $XXXX [2nd half of entrance table start])
    • 3C098015 (LUI T1, $8015)
    • 35299000 (ORI T1, T1, $9000) [if scene table length > $1000, you’ll need to increase this from $9000]
    • 340AXXXX (ORI T2, R0, $XXXX [new length of entrance table])
    • AC880000 (SW T0, $0000 (A0))
    • AC890040 (SW T1, $0004 (A0))
    • 0C0004FF (JAL $000013FC)
    • AC8A0008 (SW T2, $0008 (A0))
    • 3C048001 (LUI A0, $8001)
    • 3484CE60 (ORI A0, A0, $CE60)
    • 3C08XXXX (LUI T0, $XXXX [1st half of codefile_loader.bin start])
    • 3508XXXX (ORI T0, T0, $XXXX [2nd half of codefile_loader.bin start])
    • 3C098015 (LUI T1, $8015)
    • 35297DC0 (ORI T1, T1, $7DC0)
    • 340A00A0 (ORI T2, R0, $00A0)
    • AC880000 (SW T0, $0000 (A0))
    • AC890004 (SW T1, $0004 (A0))
    • AC8A0008 (SW T2, $0008 (A0))
    • 080004FF (J $000013FC)
    • 0009F821 (ADDU RA, R0, T1)
14. Insert this new file at 0x21CC.
15. Change the values as shown below at the following offsets in ROM:

• 0xB371B4: 3C0F8013 -> 3C0F8015 (LUI T7, $8013       -> LUI T7, $8015)
• 0xB371BC: 25EF9A10 -> 35EF8000 (ADDIU T7, T7, $9A10 -> ORI T7, T7, $8000)
• 0xB33EC4: 3C088013 -> 3C088016 (LUI T0, $8013       -> LUI T0, $8016)
• 0xB33EC8: 250881C0 -> 25089000 (ADDIU T0, T0, $81C0 -> ADDIU T0, T0, $9000)
• 0xB33FE4: 3C098013 -> 3C098016 (LUI T1, $8013       -> LUI T1, $8016)
• 0xB33FF4: 812981C0 -> 81299000 (LB T1, $81C0 (T1)   -> LB T1, $9000 (T1))
• 0xB341E0: 3C0B8013 -> 3C0B8016 (LUI T3, $8013       -> LUI T3, $8016)
• 0xB341F4: 956B81C2 -> 956B9002 (LHU T3, $81C2 (T3)  -> LHU T3, $9002 (T3))
• 0xC15E74: 3C098013 -> 3C098016 (LUI T1, $8013       -> LUI T1, $8016)
• 0xC15E84: 952981C2 -> 95299002 (LHU T1, $81C2 (T1)  -> LHU T1, $9002 (T1))
• 0xB1064C: 3C088013 -> 3C088016 (LUI T0, $8013       -> LUI T0, $8016)
• 0xB106D8: 950881C2 -> 9C089002 (LHU T0, $81C2 (T0)  -> LHU T0, $9002 (T0))
• 0xB347A0: 3C0C8013 -> 3C0C8016 (LUI T4, $8013       -> LUI T4, $8016)
• 0xB347B0: 958C81C2 -> 958C9002 (LHU T4, $81C2 (T4)  -> LHU T4, $9002 (T4))
• 0xAE0530: 3C098013 -> 3C098016 (LHU T1, $8013       -> LHU T1, $8016)
• 0xAE0540: 812981C0 -> 81299000 (LB T1, $81C0 (T1)   -> LB T1, $9000 (T1))

If you want the ROM to be playable with Project64, be sure to use a tool like RN64CRC to correct the ROM CRCs, as the old CRCs will be invalidated by these changes.

Porting a level from MM into OOT

What you’ll need:

• A hex editor, such as HxD
• A decompressed OOT ROM, such as the Debug ROM
• The scene file for the area you’re porting (.zscene file type)
• The room files corresponding to the above scene (.zmap file type)

As an example, I’ll port the Deku Scrub Playground (024D6000 – 024DEE90.zscene and 024DF000 – 024E3360.zmap when extracted from the MM Debug ROM) into the OOT Debug ROM.  Note that this is a “quick and dirty†porting tutorial in the sense that it omits quite a lot of fine-tuning and more technical adjustments; the goal is simply to port the level and get it to load properly.

First, open up each of the .zmap files in the hex editor and locate the actor list header command, which will be an 8-byte string near the top of the file with the following format:

01 xx 00 00 yy zz zz zz

Second, change the second byte of the command – the “xx†– to 00.  This tells the game engine not to load any actors when loading the room; the index values representing the actors in MM don’t correspond to those in OOT, so attempting to bring them into memory could cause the game to freeze.

Third, locate the object list header command, which is also an 8-byte string at the top of the file, though its format is slightly different:

0B xx 00 00 yy zz zz zz

Fourth, as with the actor list command, change the second byte – again, the “xx†– to 00.  Like before, this instructs the game engine not to load any objects, as the object numbers in MM don’t match the object numbers in OOT and thus could potentially cause a crash.

After repeating the above steps for each .zmap file, save the changes, then open up the .zscene file.  Locate the start position list header command, which, like the others, is around the top of the file and has the following format:

00 xx 00 00 yy zz zz zz

Now, go to the position in the file specified by the three rightmost bytes – the “zzâ€.  At that location will be a number of 16-byte strings (specifically, there will be a number of these entries equal to the “xx†field of the header command) with the following format:

ww ww xx xx yy yy zz zz pp pp rr rr ss ss vv vv

Don’t worry about the majority of it; simply change the last two bytes – the “vv†– of each entry to either 0x0FFF or 0x0DFF.  The former makes Link run forward slightly when the area is loaded, and can cause him to step through walls out of bounds and into the void; I recommend the latter, as using it makes Link merely stand still in the specified position when the area is loaded.

Next, go back to the top of the file and find the map list command, which is formatted as follows:

04 xx 00 00 yy zz zz zz

As with the start positions, go to the file offset specified by the “zz†bytes.  At that offset, there will be several 8-byte strings (as before, an equal number of entries to the “xx†of the command), which have this format:

xx xx xx xx yy yy yy yy

More specifically, the “xx†bytes represent the start of a map file in the full ROM, and the “yy†bytes represent the end of the same map file in the full ROM.  At this point, you’ll have to calculate these offsets.  In the OOT Debug ROM, there is unused space from 0x035CE040 to the end of the ROM; thus, you can calculate offsets by finding the size of each file, adding that value to the free space offset, and recording the old free space offset as the start and the new free space offset as the end.  Here are the new offsets for the Deku Scrub Playground port:

Scene size: 0x8E90

Scene start offset: 0x03600000

Scene end offset:   0x03608E90

Room size:  0x4360

Room start offset:  0x03610000

Room end offset:    0x03614360

Once you’ve calculated the offsets for your files, put the ones for the .zmap (NOT the .zscene) in the scene's map list entry.  Specifically, put the start offset in the “xx†field and the end offset in the “yy†field, and repeat that process for each of the maps.

After doing so, save all changes and then insert the files into the ROM at the positions you calculated.  Inserting the files can be accomplished in HxD by selecting the entire file in the hex editor, copying it with Ctrl+C, navigating to the respective offset in the ROM, and pressing Ctrl+B (NOT Ctrl+V, as that will add new bytes into the ROM and change the size of the file).

Now that you’ve inserted your files into the ROM, only one step remains:  You must make your level accessible in-game.  To do that, you must add your scene file into the ROM’s scene table, which is basically a list of all of the scene files in the game.  The location of the scene table varies for different versions of OOT; find version-specific offsets here.

Since we’re working with the OOT Debug ROM, the scene table is at offset 0xBA0BB0.  Go to that position in the full ROM, then search for the start offset of the existing scene that you wish to replace; find scene starting offsets and table indicies here.

In the case of the Deku Scrub Playground, we’ll be replacing the Depth Test scene.  Note that each scene table entry is 20 bytes long and has the following format:

xx xx xx xx yy yy yy yy ww ww ww ww zz zz zz zz qq qq qq qq

The only portions on which to focus here are the “xx†bytes and “yy†bytes, which represent the start offset and end offset of the scene file in question.  Replace these values with the start and end positions that you calculated earlier for your ported scene file.

With all of that done, save the changes and boot up the ROM in your emulator of choice.  Select the scene you replaced in the Map Select; with any luck, it’ll load successfully:

===============

Expect a OOT -> MM porting tutorial soon-ish?

With the reliable HxD hex editor (I can't believe I used XVI32 over this for so long) and the handy-dandy Yaz0 encoding program, I've been working at deciphering the apparently undocumented -- I couldn't find anything about them on the wiki, at least -- scene header commands for Majora's Mask.  I apologize ahead of time if any of the below turns out to be inaccurate; I did my best to be meticulous with everything.

0x1B command:

This header command controls the behavior of small cutscenes, such as when hitting the bell in the Laundry Pool, drinking a potion, or warping somewhere with the Song of Soaring.  From what I could gather, all of the scenes in MM have at least the same nine entries, which involve universal actions (i.e. actions that Link can perform in any area); they seem to be required, as the level won't load if those entries aren't present.  These data are typically listed at the top of the segment pointed to by the command offset, and usually occur in the following order:

Although these are by default the same from area to area, they can be set to different configurations for different levels and it'll still work perfectly fine.

0x02 command:

The 0x02 header command specifies the position of, rotation of, and effects applied to the camera for 0x1B-defined cutscenes.  The entries control whether the camera teleports to the given position or visibly moves there and how zoomed-in or zoomed-out the view is.

Those two are the only ones I've figured out thus far.  I'll update this post with any other information I can find.  Also, by all means double-check this documentation and make sure that it's correct, and please do what you can fill the holes I left in it if you feel motivated to do so.

The reason that the entire hillside to west clocktown is missing is probably because that part of town is actually an object. I'm not 100% certain, but I think I recall coming across it once while I was browsing objects with UoT. Aside from that, excellent work!

I'm not sure if it's a separate object, or an external texture file, or some command in the display list that MM and OOT interpreted differently, or what.  It didn't look like any of the other Clock Town maps used external texture files, though; or, at least, they all rendered the majority of their textures properly despite me not porting anything other than the scenes and maps alone.

Also, thank you!  ^^  It's really not very impressive, though, considering the texture bugs and so forth.

@43512

 

the ztables hack has most of that done it seems, it relocates those tables to the end of the ROM. I'd like to import all of MM and TP into OOT, that's why I'm messing around with it myself. Just trying to figure out how to add more entries to those now-used tables.

Ah, is that so?  I may have to investigate this ztables hack as well.  If you figure anything out about adding more entries to those tables, please let us know how you did it.  I for one would appreciate it.

At 0xC58BA0 in a decompressed (U) [!] Majora's Mask ROM is a table for external texture files.

 

Look at the second byte of the header command beginning with 0x11 in a scene file. If it's greater than 00, multiply it by 8 and add it to 0xC58BA0. That offset will show you to the start and end offset (XXXXXXXX YYYYYYYY) of the external texture file that the map uses.

 

Look in the display lists for G_SETTIMG (0xFD) commands with pointers that don't use bank 02 or 03. They will point to within the external texture file.

Thank you for the concise and informative reply.  I looked at the scene file for West Clock Town, however, and the second byte in the 0x11 header command was 00.  Does that mean it doesn't use an external file for its textures?

Also, I'm curious as to why the second byte of the header command for the skybox settings would indicate if external texture files are in use.  Is there a known reason why that's the case?

Porting actors between games would be pretty difficult - someone claimed to have done it once but it was quite obviously fake, which they didn't admit at the time probably because this community has been awful for people wanting to say "I'm better than you" in the past. Anyway, that's kind of irrelevant.

To port actors between the games, you would basically have to find all the function calls made in the actor's code and change their target addresses to be the same function in the other game, if it even exists. That's actually not too hard in itself but becomes a huge pain when most of these functions are not documented at all and you've got to check whether they are taking the same arguments and whatever. You'd also have to find and change any fixed addresses the actor reads from such as the current save file, loaded actor list, etc. and data at these addresses are not structured the same way in both games. Even then, the actor's RAM structure is treated differently in OoT and MM from what I remember so that would probably have an effect too. It's not impossible, but for anything other than a very basic actor it could be quite difficult to get this to work.

Ah, I see.  I may attempt it at some point, but probably not any time soon.

Have you thought of using z64_tables hack by spinout to expand the scene,actor and object tables to make this work a bit more comprehensively/extensively?

It didn't occur to me, though, admittedly, I'm not exactly working toward any major mod or project with all of this; it's more experimentation than anything else.

On a related note, I would like to figure out how to extend the tables in the code file myself, but I suspect I'd have to manipulate the game's assembly code to do that, and I have no clue how to go about doing that.

I’ve been experimenting with porting rooms and scenes from MM into OOT and vice versa.  I've gotten it to work successfully in both directions, though thus far it seems that MM->OOT ports are both simpler and less finicky than OOT->MM ports.

After much tinkering around in the scene files and entrance table, I managed not only to port most of Clock Town -- South, North, East, West, and the Laundry Pool -- into OOT, but also to connect the exits and entrances of the different scenes correctly (that is, in the same way as they are in MM).  I had to sacrifice the entrance entries of other maps in the process, but it was for the sake of science.

With any luck, I’ll be able to figure out what’s causing those texture glitches.  I’d also like to port more levels -- and connect them appropriately, if the entrance table will put up with more abuse -- and some actors on top of what I have here, although I’m unsure how feasible the latter would be.

One interesting thing I encountered was that the water in the Laundry Pool made the camera freeze in place once you jumped into it; it remained stuck even after exiting the water.  That went away after I changed the “water/camera properties†field in the water box data from 0101 to 0100.  I don’t know if that’s common knowledge or not, but I’m posting it anyway.

At some point, I intend to try something like that Clock Town port in the opposite direction (that is, from OOT into MM).  I also plan on drafting up a tutorial on manual level ports like this, if anyone’s interested.

I'm sad to hear that, although I definitely understand; having to hop between different forums due to drama or the forum fading away gets tiring.  For what it's worth, I always found your work staggeringly impressive.  I didn't have much in terms of constructive criticism or feedback because I never used your tools much myself -- I tend to do my work in hex editors -- and because I was away for such a long time and thus didn't know much of anything about them.

Is there any chance that you'll pick up OOT/MM hacking again later on, or are you finished for the foreseeable future?

Zelda in a futuristic setting.

Smooth peanut butter or crunchy/chunky?

When I was in elementary school, I fell and hit my chin squarely on the edge of a table in the lunch room.  I had to get several stitches, but it didn't leave a scar.

I've had my finger slammed in doors a couple of times.  Thankfully, I never lost my fingernails, but the skin underneath bruised nastily, turning black and brown for a while.

I had to get a tooth pulled not because of poor dental hygiene, but because it was so far out of alignment that not even braces could move it into place.  I don't miss it, since my teeth are all nice and straight now, but I didn't particularly like having to spit out mouthfuls of blood for a few days, nor did I appreciate a big, wet scab in my mouth keeping my tongue company for well over a week.

I don't have any particular preferences.  That is, I can enjoy any game that's well-made, engaging, and innovative in some way.  For instance, I loved the N64 Zeldas (big surprise there, right?), Pikmin, Catherine, Yume Nikki (and its assorted fangames), EarthBound, and Luigi's Mansion.  I suppose I end up playing more older games than newer ones, if only because there's been a dearth of games that interest me as of late, but I'd be more than willing to try something new if it seemed promising; that's how I got into Catherine, in fact.  I tried Touhou once, but it kicked my behind so soundly that I haven't touched it in months.

In terms of games that I don't like, I'm don't much care for FPS games.  Pikmin 2 disappointed me with how effortlessly easy it was in comparison to the original, but it wasn't bad overall.  This list would probably extend further if I actually played games more often.

I also read visual novels from time to time, although I wouldn't count those as video games.

Greetings, everyone!  I'm 43512, and I was a member of ZSO while it was around, although I went under a different name then.  I experimented with adding actors and objects, as well as map porting; I managed to hand-port a couple of different maps from MM into OOT, although I never could get the reverse to work.  I also attempted to hand-make a custom map and scene, as well as extend the scene table, but both of those were vastly more complicated than I could handle at the time.

Nonetheless, N64 modding and hacking and so forth still fascinates me, so, when I came across this community and saw all of the spectacular projects and advancements that have been made since I used to dabble in this field, I couldn't resist joining in.  Moreover, since I'm more technially-savvy than I was back then -- which isn't too big of a claim, to be sure -- I daresay I might actually be able to contribute to the community in some meaningful way for a change.

My old ZSO username was Master Hand, for those of you who are curious.  I'm quite ashamed of how ridiculously childish and annoying I was back then, so I'm trying to distance myself from that.  ^^;

Regardless, it's quite a nostalgia rush, seeing so many familiar users.