Primary Zelda Hacking

A huge issue with Zelda Oracles hacking and using ZOSE is the crashes and unknown opcode errors an emulator will come across. Well, I figured out, or proved my guess, that they were the fault of the new loading and executing of the scripts. So when I get out of school, which should be the 26th of May, I'm going to begin recoding the assembly and redo a big chunk of the scripting engine. This will result in no bugs and hopefully we won't be limited to bank C for primary headers. If we are, well we are, but my main goal is to get rid of the errors.

~Lin

Sorry but the lead developer of ZOxx is a liar. Development has already started and is nearly complete, with new and way improved features such as:

-No more crashes
-Multiple scripts in a room
-No need for using bank C (See new skeleton)
-Possible underwater use (Has yet to be tested)

New skeleton:

Interactions with the ID of 72 load the specified address at the back of the ROM, and when a jump is used, the new address is stored in the interaction's memory (Dx7D-Dx7F) and recalled to load data in C300 every time its script is executed.

Sounds pretty good.  So this basically works for interaction 72 only, and nothing else is being changed, right?

Yep. The only code I've added is used ONLY for interaction 72. I'm not sure whether or not I want to mess with the script code to add an FF opcode because I don't want to mess with the original code at all. I think what I'll do is make the original code peek at the byte, and if it's FF, resume the script based off the next byte. I also had to hardcode Dx46 (Delay) handling because for some reason they broke with my calling code, but they work fine now.