Wii VC Resets and Loads for Ocarina of Time

For a TL;DR, head to the bottom of the page

For years we have been aware that the reset duration for OoT on Wiis have varied. But we’ve always chalked it up to hardware differences with the Wii itself and have kind of ignored the problem.

Recently though, with the development of a lag counter gecko code and the VC practice ROM, it led some OoT community members to do some more in-depth research on Wii’s and their behaviour with Ocarina of Time.

Over the course of a few weeks, many OoT community members (mostly from the discord) came together to crowdsource a huge amount data for reset and load times. That sheet can be found here. This data made it pretty clear to us that there was no correlation between reset duration and Wii hardware. We recorded things like CPU model, year, color, model number.. and none of them had any direct effect on the reset.

Jbop reached out to FIX94 to see if he had any insight on what could be causing the problem.

He said:

“The wii is very simple as it is all bare metal, so as long as you load the game clean (using for example the system menu) to keep the original IOS, there should be no difference. If there was a modified IOS active, things may change, so be sure the IOS the game uses is the most up to date official one, you can check the IOS a wad uses using for example customizemii, see the startup ios in the options tab. Also note that only on a original wii that IOS may be different, the wiiu vwii mode uses its own set of special IOS that never got any updates.”

This made it clear that our problem with resets could very well be software related.

IOS is basically the small operating system used by the Wii. Numerous different branches of IOS have been released by Nintendo, and all Wiis actually have several different IOS versions installed simultaneously into any of 255 different "slots". The different branches of IOS are named by their slot -- IOS12 is installed into slot 12, IOS37 is installed into slot 37, and so on. Each of these different IOS have gotten occasional updates to fix bugs such as the Trucha bug, or in some cases to wipe their functionality so they cannot be used (making them IOS "stubs"). IOS50, for example, has two revisions: v4889 and v5120. Different branches of IOS can have different capabilities, such as providing access to the USB ports on the back of the Wii.

Virtual Console games (or any Wii channel, really) use a certain IOS to run, and each game does this by looking in the slot for the IOS number it needs. OoT uses IOS9, and thus boots using the IOS in "slot" 9. The fact that it boots from whatever is in slot 9, even if it isn’t the IOS intended to be installed in that slot, is significant.

We asked everyone who had previously given data about their Wii to now run an app called SysCheck on their console, which tests all IOS installed and outputs a report. After a large number of people had posted the resulting reports from their Wiis, we noticed a clear difference between the "slow" Wiis and the "fast" Wiis: All Wiis with resets faster than 13 seconds had an IOS9 that had an altered revision number and the Trucha bug, while all other Wiis had an unpatched IOS9 with a revision number that would be expected from an official IOS9. This seemed like a clear lead on the reset problem. Amateseru, Jbop, and Juwk tried both installing IOS9 with the Trucha bug patched in, and installing an early version of IOS9 that would have had the bug naturally. Neither test changed reset times on any of their three Wiis.

The next step in our testing was to take the IOS9 from someone with a fast Wii and analyze that/test it out on a slow Wii. Thanks to the help of Fenyan, Jbop was able to take the IOS9 from a NAND dump of his system and do some tests with it. The IOS was indeed not an official version, and when installed to slot 9 made Jbop's “slow” Wii have a fast reset. After looking at this unofficial IOS9 from Fenyan's Wii and comparing it with other IOS files, it was thought that it was likely a modified version of IOS60. Jbop then installed an unmodified, official version of IOS60 into slot 9 on his Wii, and it also sped up his Wii's reset time. His full test results can be seen here. Both patching an IOS and installing an IOS into an incorrect slot are impossible without softmodding/homebrew.

Now that we knew an incorrect or patched IOS installed into slot 9 could alter reset times, the question then became: What are all of the official versions of IOS9, and how fast are their resets?

There are 6 normal official versions of IOS9: v516, v518, v520, v521, v778, and v1034. The first two contained major security bugs and thus can only be found in IOS databases compiled online, while the last four versions can still be easily downloaded from Nintendo’s update server.

Jbop obtained all 6 versions of IOS9, the IOS that OoT uses, and gave it to Danny and myself to test.  All 6 official IOS9s have a 13 second reset, with IOS9v1034 being the fastest (data here). All IOSes with a faster reset have a non-IOS9 installed into slot 9 or possibly an official IOS9 that has been heavily tampered with. This is done by some homebrew apps to protect your Wii from getting bricked.

Just to be clear: No one knowingly installed unofficial software to speed up their game. This was done by homebrew apps most likely for brick protection, and just coincidentally affects OoT’s boot duration. This is all new information to us.

SO..

What does this mean for our leaderboards?

With the discovery of all this information, it is clear that all fast resets are caused by unofficial software that is not achievable otherwise without homebrew.  This alone is enough for the OoT moderators to ban any unofficial IOS.  Effective immediately, all Wiis must have an unmodified, official IOS9 installed.

All existing speedruns done with an unofficial IOS9 will remain on the leaderboards. From this point on, Wii reset times will be checked during the verification process of leaderboard submissions. Any runs with a reset faster than 13 seconds will be rejected.

Please follow this guide to install an official IOS. We recommend you do this even if you have a “slow” Wii.

Another topic of interest in our data collecting was load times.

A video by Baker here suggests that Wiis with different cpu models have varying load times:

However with more in depth research we found that may not actually be the case. Using the lag counter (which times loads), we were able to see that loading does vary slightly. But not enough to give one console or cpu model an advantage over the other.  Most loads vary by up to 3 frames (at 60fps) even on the same Wii.  This also happens on N64, so its a problem with the game not the Wii itself.

Also an important thing to note about loads is that some in game factors seem to affect loads as well. Potential things like time of day (which can lead to loading different scenes of the same map) and things of this nature. So if the conditions aren't exactly the same when timing loads, the data can be skewed.

Check out the two “JP Load Times” tab on the Wii Data Sheet for some numbers.

I made a tweet showing temple of time loads varying across everyone's Wii’s. This tweet was made before we had done any thorough research, and was just demonstrating OoTs general issue with inconsistent loads, NOT Wii’s being inconsistent.

______

TL;DR:

The OoT Community did a lot of research on Wii’s. Load times vary in the game itself, but Wii hardware/software has no effect.

Reset time variations are caused by differences in the IOS installed at slot 9. The people with “fast Wii’s” have an unofficial IOS9. These fast IOSes are now banned, and you must install an official one.

Runs with an unofficial IOS9 are being grandfathered in. They will not be removed.

______

Thank you to:

Danny for taking the initiative to start the Wii Data Spreadsheet

All 50 or so community members who participated in our data collection

Ama, Juwk, Danny, Fenyan and more for helping us with more in depth testing

And most of all to Jbop for taking a lot of time to do this in depth analysis to figure out the reset problem. Also thank you for providing the technical details in this write up for the IOS research.

-Fig