WiiPower

As far as i can see, there are 3 conditions that must be met in order to play the game:
1. Have a WM+. Without WM+ the game won't work, and if you would hack it to boot without it, you wouldn't be able to control Link properly.

2. Watch the WM+ video once. If you watched it for another game, like Wii Sports Resort, you are good to go. If not, use d2xv6+ and a recent loader with the block IOS Reload option enabled. If the game keeps resetting to the wii menu, this is most likely the reason.

3. According to Crediar the game does not have the MetaFortress protection like many other recent games. So patching the game with video mode patches, language patches, country string patching, Ocarina etc. should work, but it might be a good idea to turn everything off until the game works.

How to watch the WM+ video:
There are 2 ways to watch the video, one dirty hotfix and the correct way to do it, which also gets some other games to work.

Method 1(good one, use d2x + IOS Reload block):
1. Get ModMii:
http://gbatemp.net/t...ii-for-windows/
2. Install it on your PC and run it.
3. Create a WAD file for the d2x v6 cIOS with base IOS56, slot 249
4. Copy the WAD to your sd card to the wad or wads folder(i always forget which one it is)
5. Start WAD Manager on your Wii
6. Select to use IOS236 for the install process. If you don't have IOS236, select IOS249
7. Install it

The rest is different for each loader, but all major loaders support it, CFG, GX, NeoGamma and WiiFlow(maybe uloader does not support it).
- Get the latest version of the loader you prefer.
- Make sure it uses IOS249 for all games, or just IOS249 for this game, it does not matter.
- Enable the "Block IOS Reload" option, either as global option or per game option.

Now the WM+ video should work. As well as all IOS Reloading games.

Method 2(dirty one, alt .dol loading):
1. Start your favorite loader
2. Select alternative.dol loading from disc. This is named differently in all loaders, but all loaders should have an alt. .dol disc option or similar.
3. Boot the game
4. Select player.dol when prompted
5. Continue booting the game and watch the video completely. It should reset your Wii afterwards.
6. Start your loader again.
7. Disable the alt dol option

I to want collect usable error reports for issues with VC/WiiWare nand emulation and try to arrange them into the right group. Basically if it's a loader issue, a cIOS issue, a nand emu issue, a hardware issue or user fault.

Known issues:
Nand emulation and Nintendo Wi-Fi Connection:
In TriiForce R86 using d2x v6, it works with both boot methods on real and doesn't on emulated nand. So it seems to not be a loader or cIOS issue, it could be a nand emu issue or be related to the used device.

This needs confirmation for sd, sdhc and usb nand separately.

The Legend of Zelda: Majora's Mask (VirtualConsole):


This needs to be tested with the latest TriiForce with both boot methods(normal + apploader), as one the latest updates might fix this.

LostWinds series (WiiWare):
Freezes randomly when entering a new area with a buzzing noise. Seems to happen more often, the slower the device is[Or it could be that the number of installed titles is relevant on TriiForce up to R87]. 2 reports that TriiForce r88+ reduces the freezes to happen much less often.

Swords and Soldiers (WiiWare):
...

Liight (WiiWare):
...

Bonsai Barber (WiiWare):


Might get different results on sd, sdhc and usb.

Various games:
- Some games are reported to require the apploader boot method. One of the recent updates to TriiForce might fix this.
"WAL", //ArtSyle: light trax
"WDH", //ArtSyle: Rotohex
"WOB", //ArtSyle: ORBIENT
"WPR", //ArtSyle: CUBELLO
"WA8", //ArtSyle: Penta Tentacles
"WB7", //Midnight Pool
"WSP" //Pokemon Rumble

- Some games are reported to only be able to save if there's a savegame on the nand already. In theory booting the game once with the apploader method might fix this.
Bit Trip Beat
Bit Trip Core
Bit Trip Void
Bit Trip Runner


When posting, please state what you are using and please always try to test with both boot methods(normal + apploader), on real and on emulated nand. Example:
TriiForce R86, d2x base IOS56 v6 final, 1 TB usb HDD, normal boot: DOESN'T WORK
TriiForce R86, d2x base IOS56 v6 final, 1 TB usb HDD, apploader: DOESN'T WORK
TriiForce R86, d2x base IOS56 v6 final, real nand, normal boot: WORKS
TriiForce R86, d2x base IOS56 v6 final, real nand, apploader: WORKS
MC v11.1, d2x base IOS56 v6 final, 1 TB usb HDD, normal boot: DOESN'T WORK
MC v11.1, d2x base IOS56 v6 final, 1 TB usb HDD, apploader: DOESN'T WORK
MC v11.1, d2x base IOS56 v6 final, real nand, normal boot: DOESN'T WORK
MC v11.1, d2x base IOS56 v6 final, real nand, apploader: WORKS

(that's the expected result for the online stuff btw)

Note that testing with TriiForce R91 is mandatory, because it received some updates recently which Mighty Channels does not have yet:
http://code.google.com/p/triiforce/source/...n%2Ftrunk%2FHBC

Credit for finding this goes to Oggzee and airline38. Oggzee created lots of test versions of CFG, and airline tried about 20 test versions.

The game We Dare uses some good protection that works against all current loaders. But it is defeated by a single nop...

All loaders that support the "new" Ocarina code handler include the following source code:


and adding one nop makes it:


Which is the required change to get the game working. Apparently the game looks for the byte pattern:
3C608000 606318A8 7C6903A6
and it doesn't find it when it looks like this:
3C608000 606318A8 60000000 7C6903A6

It doesn't matter if the code is executed or just part of the code somewhere. The actual pattern might be bigger, but only with the code after it, adding a nop before the code in question still triggers the protection. It's quite a good idea, as it blocks all recent loaders, including Gecko OS, but as it wasn't combined with some other protection, so it was not good enough. A mixed protection would have required to disassemble the game, not just some simple testing.

Clipper, Oggzee and me were thinking about the future of "the" cIOS installer. Well, we have different intentions and opinions about it, so we thought it might be a good idea to discuss it in public. Also none of us has one at the moment. Let's see where we get with it.

Some of the questions:

Should the installer be final somewhen?
If it was final, it would mean: When a new cIOS is released, the installer could be used directly by anybody to install the latest cIOS. This would be handy on alpha/beta releases. But it would also mean more work for whoever writes the installer.

(Only if installer would be final somewhen:)Should the installer use a .zip to get the modules or take them from a folder, or both?
- Reading from a .zip files would be the most user friendly, just download the latest cIOS, put in the root of the sd card, run the installer, select the wanted .zip and go.
- Reading from a folder would be better for people who want to change stuff in the cIOS themselves. The .zip method would allow it as well, just 1 step more. And the .zip method would be less prone to user error.
- Reading from both would have its advantages, but would make the installer more complicated.

Should the installer save downloaded IOS files to sd card?

How should the .txt/.xml file look like that will be used for the cIOS identification?
The current plan is that CFG and NeoGamma(and later most likely the others too) will be able to identify cIOS with info directly saved in the cIOS. Instead of the crappy method that is used right now, but by keeping the identification for all older cIOSes of course. ModMii will have its own way to put this info into the cIOS, which is currently not the best way for an installer that runs on a wii(inside a .bat file). The info which base IOS was used, should be added by the installer automatically as well as the magic. The info what the name of the cIOS is, its version and one additional string can be put in manually. It could be a simple ciosinfo.txt with the content:


The format how this data looks like in the cIOS is decided already:
typedef struct _iosinfo_t {
u32 magicword; //0x1ee7c105
u32 magicversion; // 1
u32 version; // Example: 5
u32 baseios; // Example: 56
char name[0x10]; // Example: d2x
char versionstring[0x10]; // Example: beta2
} __attribute__((packed)) iosinfo_t;

And it's located in the .app file that is used for this already by Waninkoko. It should be the .app file that is found in the tmd at offset 0x1E7

Or GC 1:1 backups with audio streaming + modchip?

I found a bug in the latest d2x cIOS. If it was there already in Waninkoko's cIOS, i expect GC retail discs with audio streaming, maybe even those without too, to cause some kind of error before they are booted.