I want to play a game from my usb device(32GB) but usb loader gx wont find my usb stick. I have formatted it to wbfs and tried both usb ports, but it won't work. I know that I have to patch my ios, but I don't know how, and what to patch. I have tried to installed something, but it won't work. I ran a syscheck and here's the results: sysCheck v2.1.0b13 by DoubleA and R2-D2199.runs on IOS58.

If you followed my previous post on attaching a USB hard drive to your Wii, you now should have the convenience of loading games directly from your hard drive without ever having to worry about swapping discs. Yet having to load the Homebrew channel, then going through to your USB loader can feel cumbersome sometimes. Getting channels to go directly to the games, or the USB Loader is easier than you would think.

1. Wii Backup Manager is a program to copy Wii games from your computer to a USB drive so you can play the games on your Wii. It also can download game covers from GameTDB and can be used to list what games you have. This tutorial will tell you how to copy over games from your computer to your USB drive.
2. Select “USB Mass Storage Device”. Insert any game disc, and press “+” to install it. This may take some time depending on the size of the game. Repeat last step for each and every game you want to install.
3. Plug your USB hard drive back into your Wii, load up WAD manager via homebrew, find the wad you just created and install it. If at any time you need to uninstall this channel, simply load up the WAD manager, find your wad, and select “uninstall” instead of install.

You obviously need to have the Homebrew Channel plus a USB loader installed before you can do any of this. If you don’t, follow these steps then come back here once you’re done. Please note that the steps here can and might damage your Wii! I very highly recommend you install BootMii into boot2 and back up your NAND before attempting any of the following steps. Should anything go wrong, you have a backup you can fall back on, otherwise you are continuing at your own risk!

Prerequisite Steps

• Download and install WAD Manager.
• Create a “/wad” folder on your SD card (must be on the root of the card!) Any channels that you want to install must be placed here or else the WAD Manager will be unable to find them.

There’s two options from here on out, and you’re welcome to do both. You can just install a usb forwarder channel that will allow you to access your USB Loader from the main menu, or install channels for individual games so that they show up on the main menu.

Installing USB Loader Forwarder Channel

There’s quite a few USB forwarder channels out there, but they all do pretty much the same thing. A USB forwarder channel looks in specific directories for an installed USB loader and tries to run it. The advantage of this is that it makes it simple to upgrade your USB loader without ever having to mess with the forwarder channel, since you can just swap the boot.dol to a newer version.

To make things easier, you can download the one I use: Universal Forwarder Channel by Narolez. This forwarder looks in the following locations for a USB Loader boot.dol:

• sd:/apps/usbloader_cfg/boot.dol
• sd:/apps/usbloader/boot.dol
• usb:/apps/usbloader_cfg/boot.dol
• usb:/apps/usbloader/boot.dol

Forwarder Installation

• Copy the .wad file to “sd:/wad”.
• Load up WAD Manager in homebrew, find your wad, and choose to install.

You should now have the channel correctly installed, and should be able to access your USB loader directly from the main menu! If at any time you need to uninstall the channel from your Wii, you can follow the installation steps above, choose the same wad file, then choose to uninstall and the channel will be removed from your system.

Installing Channels for Individual Games

Installing games already on your USB hard drive is pretty simple, just be sure you already have the games loaded onto you hard drive via USB Loader. You also need to download CRAP in order to assist with the channel creation.

Channel Installation Steps

• Plug in your usb hard drive to your computer.
• Launch CRAP.
• Select the drive letter of your USB hard drive, i.e. J:.
• Choose the game which you wish to create a channel for.
• Select a loader. Most of the time you should be fine with using USB Loader 1.6, but you may need to use a different loader depending on what options you want to apply to the channel.
• Click on “create channel”
• Your wad will be saved in the WAD directory of your CRAP folder, so you will need to copy/move this wad to your USB hard drive.
• Plug your USB hard drive back into your Wii, load up WAD manager via homebrew, find the wad you just created and install it.
• If at any time you need to uninstall this channel, simply load up the WAD manager, find your wad, and select “uninstall” instead of install.

You should now have a channel listed on your main menu for your game, and you can repeat the above steps for any additional games you wish to install.

There may be an occasional issue with a couple of games depending on what version of cIOS38 your are currently running. cIOS38 rev. 14 unfortunately breaks dual-layed disc compatibility, so games such as Smash Bros. Brawl or Metroid Prime Trilogy will not work in USB Loader. Wii Sports Resort will not work via the channel method if you >13 installed, so you may want to pick and choose what cIOS38 you are running based on what games you want to install as channels.

Set-up on your SD Card

1. Goto the downloads page and download the latest featured release.
   Download file: DeSmuME Wii r185.zip
   (DeSmuME Wii Revision 185) Jun 28, 2010 file size: 637.88KB
   
2. Extract it into your apps folder. Make sure the path is along the lines of root:/apps/namethisfolderanything/boot.dol
   
3. Place your DS ROMs in sd:/DSROM/ to make your life easier
   You can select any ROM to play that is stored anywhere on your SD Card.
   The default directory is sd:/DSROM/

Nintendo DS ROMs Working on Wii?

• Right now, most NDS ROMs work.
  If anyone knows of a good compatibility chart, let us know please :)

Known Issues with GX

Now that Desmume can run on native GX (translation: hardware acceleration baby!), let's look at some of the pitfalls and problems that plague us.

Wii To Usb Cable

Problems and Roadblocks

1. The GPU renders things in lines. I do not know where the sprites are stored. Speaking with the 'Vanilla' Desmume developers, it seems that they are taken directly from the DS game. What does this mean? It means (unless there IS a big storage place that houses all the sprite layers, which would be awesome) that it may be very difficult to convert the individual lines into 4x4 texels, since each line would not comprise all the information that a 4x4 texel would need. Again, I am not 100% sure about this, so maybe there is hope.

2. This may involve significant rewriting of the Desmume GPU code in order to get native GX to run at full efficiency. This may affect the software renderer. This is just a possibility, however. Someone more familiar with the software renderer should be able to address this better than I.

What's wrong with GX?

There is actually very little wrong with GX, it is actually Desmume, and how it does its work, that is causing the trouble when we move to native GX code.

Problems: **Sprites** Textures

I will be using Super Mario 64 DS as an example. If you load up the game, you will see something very, very odd: What looks like four blue buttons on the top screen and blue gibberish on the bottom screen. What? It's broken! Not so. Here is why it does this:

I direct your gaze to the Draw() function in main.cpp. When we use the software renderer, everything ends up coming out in the wrong format, so we need to convert it to be 4x4 texels (what the Wii likes) in order to render it to the screen. Notice the line:

if(current3Dcore 1)

If current3Dcore is one, then we want to use GX, (if it is two, we use the software renderer). Notice that within that if statement we are not 'converting' the image before we render it to the screen. If you comment this out, you will see that the text is fine, but woe! The 3D has become gibberish! This is because GX will, obviously, render 3D in the correct format! But, the sprites (text) are not in the correct format, since these are generated via the Desmume software.

This also leads into the discussion of textures. You may still call the 3D star at the start of SM64DS a failure since it is clearly the wrong color, but in actuality I believe this is due to the same problem that we have rendering sprites: incorrect format. I am not 100% certain that this is the case, however. I could be wrong.

Possible Solutions

So what's the solution? Thankfully, I think I have managed to track down what is needed to be done, and I have a few possible alternatives.

1. Convert the Sprites, but not the 3D.

This would involve finding the source of the sprite generation. What we could do is apply the 'texel conversion' normally done in the Draw() function to the sprite upon its creation.

2. Render in layers.

Desmume uses a layered structure for its rendering engine. It will loop through every line and apply the background, sprites, 3D, and more sprites on top of that.

• The start of line 2087 does the background layer
• Line 2133 renders sprites with the function: 'gpu->spriteRender'
• 3D is rendered on line 2180: 'gpu->setFinalColor3d'
• And the final sprites are done on line 2212: 'gpu->setFinalColorSpr'

There's some more in there but this is a good example. The software will compare alpha combine pixels for each layer in the line. This is (I believe) accomplished in the function: GPU_RenderLine_layer in GPU.cpp.

It is possible to render each layer as a separate entity, convert the sprite layers, and combine them with the rendered 3D image (it's a texture) as a multi-layered texture using the GX hardware.

How To Load Games From Usb On Wii

3. 'Unconvert' the 3D.

I do not like this one, but I thought that I should suggest it nonetheless. This would involve doing the exact opposite of the 4x4 texel conversion to the rendered 3D image. That way, when we convert it later, it will look correct. This, obviously, would involve more rather than less CPU cycles; the entire reason to use GX in the first place. This could be a quick-fix until a more permanent solution is found.

Conclusion

I would vote for the 'Render in Layers' approach. I believe the tradeoffs (having to hold space for each layer) would be offset by the fact that the hardware could combine them at a FAR greater efficiency than the software ever could. Look in the function '