N64 Isles Troff 'n' Scoff Crash Explained

During the process of a frame, the game tries to go through the Object Model 2 list (A set of objects that are loaded as soon as a map loads) and executes some code that is stored inside the object. This code tends to be specific to each instance of the object, for example, the coconut switches in Jungle Japes would tell the game to free diddy if all 3 are activated. The code in question which first causes the crash is the pad underneath Scoff (The blue hippo)

The game tries to calculate how high Scoff's pad should be off the ground. The way the game does this is to multiply a constant by the ratio of the amount of coloured bananas turned in vs. the amount of coloured bananas required to open the door. For example, in Jungle Japes, if you have 15 Coloured Bananas turned into Troff & Scoff, where the game wants 60 to grant access to Army Dillo, that would mean that the game would reduce the height of the pad to 1/4 of it's maximum (1/4 being derived by 15 / 60)

So the game grabs the world of the parent map (Eg. If you entered the T&S in the Crypt in Castle, it grabs the overall world as "Castle"). For Isles T&S, this world is grabbed as Isles (world index 7). When you look in the array for the total CBs required, it indicates 0 CBs needed to open the door. As such, when performing this arithmetic, the game tries to do 0 / 0. Anything divided by 0 is a problem, but the game initially is okay with this as it has a failsafe to prevent some divide by 0 crashes.

However, shortly after this division, the game converts the outcome of that division into a different format (Specifically a single-precision float into a double-precision float). There is no failsafe for this, which is what causes the crash.

Now, some may be asking why Helm T&S doesn't crash since the boss door says that 0 CBs are needed to open it. Well, stored right after the CB requirement array is the B. Locker requirement array. Helm is level index 8, so it reads the first entry in the B.; Locker Requirement array (1 GB for Jungle Japes), and so references this as the denominator for the division (eg. 0 / 1). Therefore, this results in the operation being 0 and doesn't crash.

As to why VC doesn't crash, it's assumed that it's something to do with the compiler used in the Wii U Virtual console. However, at this point.... who knows.
(It's unknown whether this is the cause of the corrupt geometry in VC Isles T&S)

Since all this happens before you have control, and the arrays are constants that are never overwritten, and the code for each of the Objects in the subset are run regardless of what is loaded and what is not, there is no way to bypass this crash