If you aren't aware, a lot has been going on in the Wii homebrew world recently. It started with Bushing, segher, and tmbinc cracking open a Wii and doing what they called a 'tweezer attack' on it. The attack involved effectively shorting a circuit that allowed them to dump some memory (using GameCube homebrew code) that was normally locked out when entering GameCube mode (the Wii has 'Wii mode' and 'GameCube mode' for backwards compatibility reasons with GameCube games). There's a video of Bushing talking about it from the 24c3 a few months ago. With this memory dump, they extracted some system keys that can be used to encrypt, decrypt, and sign various system files.
They have an amazing understanding of reverse engineering and were able to find a couple of bugs (and probably a lot more that they haven't told anyone about). Two in particular were a buffer overflow with Zelda Twilight Princess, and a bug in the way Nintendos signing algorithm works. Using these newly found holes they were able to create an exploit titled the
Twilight Hack, a Zelda save game (the signing bug is not used on the save game file) that uses a stack smash to overflow the horses name and take control of the system. Homebrew was made possible with this exploit.
The Wii is a lot like a GameCube, and GameCube homebrew has been around for a while. Shagkur -- author, developer, and maintainer of the libogc project (which is available under
DevKitPro, a toolchain project managed by WinterMute) -- has been working recently on expanding libogc (the unofficial GameCube SDK) to include Wii support. Within the past few weeks he has added bluetooth support to libogc. As a proof of concept, and to test that the bluetooth stack functioned correctly, he ported wiiuse to the Wii. All went well and it seemed to spur a roar in the homebrew community, up until then no one had touched the wiimote in any homebrew applications.
Shagkur informed me of his work and I was obviously very excited. The bluetooth stack (lwbt) was added to the libogc CVS, and immediately a couple of other wiiuse ports popped up, most notably Rhys's (which was very clean and #ifdef'ed). I started with Rhys's since it was a pretty good base. I reworked most of what he did, and started fixing bugs where wiiuse didn't port over so well (not everything worked right off the bat).
Rhys gave his port to a couple of other people, and it leaked around to various developers in #wiidev. Now I have no problem with that at all, hell the code is freely available here at wiiuse.net, but as it turned out people began adding wiimote support to their applications without realizing it was unstable code -- wiiuse can (and very well may) crash at any given point. The reasons for this I won't get into, but the current state is no wiimote support for the Wii is considered stable yet.
At first everything appeared to have ported over very nicely to the Wii, except for IR. Enabling IR crashed (or froze) the Wii console. The bug turned out to be beyond my ability to find, much less fix. A crude work around was first introduced by NoNameNo, who wrote some nice looking code called
GRRLib. Now by looking at his code I can say he's a fine coder, but he didn't understand wiiuse to the point that he knew why his work around worked, much less what the actual problem was. He told me what his method was (which I had already known but had not released) and it was pretty much as I expected, it worked but it was extremely unstable. I should point out that by 'unstable' I mean that I could get the 'work around' to function properly almost 100%, but afterwards the state of the application could degrade suddenly and without warning.
Another problem NoNameNo ran into was that he couldn't get 2 IR sources to work with calculating the cursor position. So his demo releases (which he, IMO, incorrectly labeled as 'proof of concept') used just the first seen IR dot (dot[0].x and dot[0].y) for cursor position. I took a look at this and found the issue -- there were actually 3 problems which I was able to correct. IR calculations on the Wii can now correctly use 1 or 2 IR dots (just like the Linux and Windows versions).
Now the wiimote, and more specifically IR support, seems like a big deal with the homebrew developers. So NoNameNo released GRRLib (which is a set of a dozen or so frame buffer rendering functions) along with Rhys's wiiuse port. There was some confusion as to where the wiimote support actually came from, and many believed it was from GRRLib since it was the first to make a public release. Now I don't so much care about that, but what I was concerned with was NoNameNo did not say that the wiimote code was
unstable. Being a full release (GRRLib v2.0) it can be assumed the entire code base should not be experimental, but that is not the case. As I said before, any and all wiimote code currently in use on the Wii is not stable. This is one of the reasons I didn't release anything yet -- I don't want people to start using wiimote code only to have their applications crash and find themselves scratching their heads for hours trying to figure out why. I knew this would happen, so as soon as I saw NoNameNo had started releasing demos I asked him not to release any wiimote code until it was ready. He agreed, but a week later the code was released anyhow. Debugging on the Wii is hard enough (it's made easier with the USB Gecko) especially given the actual bug is very obscure, a back trace will just lead you in circles unless you are as familiar with the microkernel (libogc) as shagkur is. I have no doubt that there are people out there right now who are trying to debug problems with their programs and do not realize the actual issue has to do with wiimote support -- this is
exactly the type of thing I didn't want to see happen. It would have been better to wait until it was stable and make an official public release for everyone to use.
So, after having said all of that, the wiiuse port is still under way. Now that I have fixed the IR issue, I decided it was time to show a little (unstable) demo. I took the asteroids game, written by Andy Sommerville (aksommerville) and available
here, and added wiimote support to it. Rather than use the GameCube controller to turn and shoot the space ship, you can use point and click functionality with the wiimote
The download is on the same page as the original source.
edit: I should clarify a few things.
I am not saying not to use wiiuse (I want you do, that's why I wrote it), but just be aware it is not stable and could cause issues.
Secondly, I feel some thanks are in order.
- Thanks to Rhys for his work on the initial port I built off of, it saved me a good bit of work.
- Thanks to NoNameNo for his work effectively demonstrating wiiuse and showing the community how far we are with wiimote support.
- Thanks to Shagkur for his bluetooth work, libogc work, and his initial wiiuse proof of concept.
- Thanks to Marcan and everyone else who contributed to helping reverse engineer the wiimote, without which wiiuse would not be possible.
- Thanks to Bushing, Marcan, segher, tmbinc, and everyone else (too many to list) for IOS work, libogc work, tools work, and all that crazy stuff that's over my head
- Thanks to WinterMute for working with me on some issues that I won't get into here.
FAQ
Posted: Sun Apr 20, 2008 4:36 pm
