WAD Manager v1.0 by Waninkoko |
+-------------------------------+
| www.teknoconsolas.info |
+-------------------------------+


+--------------+
| DESCRIPTION: |
+--------------+

WAD Manager is an application for (un)install WAD packages.

It lists all the available WAD packages in a SD card so you can
select which ones to (un)install.

Includes Wiimote support.


+-------------+
| HOW TO USE: |
+-------------+

1. Create a folder called "wad" in the root of a SD card.
2. Copy all the WAD packages in the folder created in the step 1.
3. Run the application with any method to load homebrew.


+--------+
| KUDOS: |
+--------+

- bushing and marcan (the homebrew channel is great)
- all my testers (pistu, SoraK05, danny.ml...)

New Features Implemented in R-14beta:
- Dynarec Stack Optimisation = small speedup (located in the Rom Preferences)
- Highlight Inexact Blend Modes = replaces inexact blend modes with a placeholder texture (located in Global Settings)
- VFPU TnL = acceleration of vertex transform and lighting / small speedup (located in Global Settings)
- Clear Fragment Cache = clears the contents of the dynarec fragment cache / do this before loading a new game to avoid freezes and such (located after pausing a rom, works great too)
- Font in GUI has been altered (view pictures below)

The ME work on it is only partially done so the sound doesn't lag quite as much as R13 and it's slightly less gargled.

Okay, since FCEU v1.0.9 was set out in the wild, I've resolved some bugs, added some features, etc. You know, all the usual stuff to make it better and betterer.

First, was a bit of a show stopper, as the emulator didn't even load the files you attempted to load. It went through the motions, but didn't quite finish. So, that was the first thing I had to fix (r8).
Then I found that ZIP reading files from the DVD (in Gamecube mode) wasn't quite working. So I had to quash that bug (r9). To round out the first round of fixes, I borrowed the memory card mounting routine from Crunchy2's Snes9xGx v2.0.1b8 (r10). Hopefully that will help many people that had trouble using their memory cards. If not, remove and reinsert your card and try again.

After a bit of a break to solve Zelda again, I continued to port some of the changes I made to Snes9xGX to this emulator. The list of changes include WiiSD support (r12, r13, r14, r16), a potential fix for those EU folks who need the video to be set to 60Hz (r15), work on easing translation to other languages (r19, r20, r21, volunteer translators needed, by the way), and bringing the VFAT library to the WiiSD card for long filenames.

The last thing I have worked on has been an effort to save and load the various settings in the emulator to any of the devices. For now, when the emulator first starts, it will attempt to load the settings from SD Gecko in Slot A for Gamecube mode or the WiiSD in Wii mode.

That catches me up with the present. The DevkitPro folks have been working towards a newer release of the devkit and libOGC with better Wiimote and WiiSD support. I hope to have one more release of these two emulators before that so I can dedicate more time to added these new features.

I wanted to post an update to my work on the Snes9x and FCEU emulators for the Wii/Gamecube. First, I'll go over what's been changed in Snes9xGx.

Since Snes9xGx v0.1.1 was released, I fixed some simple oversights in my code. For instance, when you choose to save SRAM or save states to to a GC Memory Card, you shouldn't really be able to choose the WiiSD as your slot (r38).

Then I implemented some crude work to make translating various phrases in the emulator into languages besides English (r41 and r49). I have some documentation on it at the project's main page. With help from other users, we can provide the emulator in Spanish, German, and Dutch. Speaking of documentation, if anyone out there want to lend a hand, just drop me a line. Any help is much appreciated.

The last big update I did was importing the VFAT library from eke-eke's GenPlus project to Snes9x (r62). So, now you can view the long filenames for ROMs in the WiiSD slot. This library only supports reading, so writing (ie SRAM or save states) are still limited to the 8.3 filename format.

Askot has been working a few things for the emulator as well. He finished up the code to automatically save and load the SRAM (r64). The way it works now is it will load the SRAM after you load a ROM image. Then it will save the SRAM (if the game uses it) when you exit the emulator and return to the main menu. It uses the currently chosen device and slot from the save manager menus. You may want to go into those menus and assign the proper device, then hit B (or select "Return to Previous"), before loading the ROM.

That wraps up this update. There is a lot more work to do, of course. A number of people have coded in some support for the Wiimote and Classic Controller. I need to review some of them, and come up with the best way to implement them. I want a better controller configuration screen for selecting what device and buttons you want to use, which will take quite a bit of work. Hopefully I'll get to it one day soon...

I've (finally) been able to create a patch for libogc today which just got accepted and adds my usb-storage code to it - just wait for the next release or get the CVS version if you know what you are doing. Thanks again to shagkur for some miscellaneous fixes and hints to my code.
Since my last posts even more devices are working now and only a few ones are not working which I'm unable to fix because the owners either didn't give me a usb log or because that device is just stupid and doesn't confirm to the usb storage protocol in a *really* bad way. If you want these devices to work get me a full usb transfer log while you're connecting your device to you computer. Just reporting that device $whatever is not working with the output of my old test applications will not help me to fix this drive, sorry.
However, I'll first talk in this post about why someone screwed up the IOS USB driver and what evil hack fixes this and then about how to use my usb-storage code.

Let's start with the IOS USB driver: It provides functions to get a device list, setup callbacks for device insertion/removal, open/close devices and send/read bulk, control and interrupt messages from/to them. At the first sight this looks just like libusb which should be enough for all kind of devices you want to connect. However, once you take a closer look to the functions you'll notice that there in fact is one difference: The IOS functions do not support timeouts and block until the device sends or receives the requested amount of data. So what happens now when you want to receive data from a USB device that doesn't want to send data to you? Your function will block forever because the device doesn't send data to the IOS and you can't handle that error case by - for example - resetting the device. I talked with marcan about this and he suggested me to use asynchronous IOS functions and just close the device handle when I don't want to wait anymore for the request to complete. This should be working in most cases but isobel - who is the main author of the wii-linux kernel patch set - said that you'll sometimes need to reboot(!) IOS, which will screw up all currently opened handles in your application and clean large parts of MEM2, in order to make such calls return. This is definitely not possible to do for a support library and I didn't encounter such an issue while writing my usb-storage code so I hope that such things will not happen when it is used. This IOS_IoctlvAsync hack is not really nice but it's currently the only solution to fix functions blocking forever and making the whole application unusable. We can just hope that those problems will be fixed in an upcoming IOS update.
I'm currently returning the error code USBSTORAGE_ETIMEDOUT in such cases which will mean that the device handle is no longer usable and you'll need to redo the whole initialization process and hope that this will not happen again. Get me some usb logs or debug my usb-storage code with a USB gecko and tell me where it fails and I might be able to fix this.

But let's talk about the usage of my code which is still missing some documentation in the header files - I'll add this when I'm really bored the next time
Before starting to use the usb-storage code you'll need to initialize the USB subsystems and my storage code by calling the following two functions. This is needed because the usb-storage code is obviously based on the USB subsystems which needs a IOS heap just like my code:


USB_Initialize();
USBStorage_Initialize();

You should probably also check return values here as both might fail when no more memory/no new heap id is currently available.
Afterwards you should use USBStorage_GetMaxLUN() to get number of logical units your device supports. On most USB sticks and hard discs there will only be one but card readers will most likely report multiple LUN. The next step is to prepare each unit you want to access by calling USBStorage_MountLUN(lun);. It will basically check the device for any errors and prepare it for reading and writing which is the next step: You just use USBStorage_Read() or *_Write() in order to read or write to your drive's sectors. That's it
There are some more functions but those are mostly self-explaining and probably won't even be needed by most applications.

Oh, and just in case you didn't get it yet: The "1.1" in the topic does mean that only USB 1.1 is supported.
I'll also destroy some conspiracy theories here that were mainly created on some spanish board and some other one which has the name of a last-generation handheld in its title:
I have done some tests with the IOS on USB2 support and I'm pretty sure that it's not supported. I cannot do anything against this and I didn't intentionally limit my code to USB 1.1. However, you still wouldn't get your ISO loader even if hi-speed USB 2 data transfers would be possible because it requires an immense amount of work on either patching game