Slashdot

This mod certainly allows you access to free games, however it does not make it easy to run commercial games for free. It merely allows access to home brew games without a modchip. Modchips do not make Nintendo any additional money over the cost of the console anyway.

Except Nintendo actually (gasp) sells the Wii at a profit: [wikipedia.org]

Unsigned software != pirated commercial software.

While, of course, this ability implies that you *can* run pirated software, with the right modifications, in practice I have yet to see a plausible black-hat group with the expertise needed to develop such a hack. And we're sure as heck not going to do it ourselves. All that people have been doing is Virtual Console piracy, which is quite easy once a few details got released / leaked, due to nintendo's multiple mistakes on their DRM. But patching commercial games to read their data from SD or USB is not at all trivial.

I would hate as much as the next guy to see pirates (yeah, yeah, I know there are folks out there who just want to code 2D Tetris to work on your Wii... and there are about 10,000 pirates for every one of you, who want to play first-party Nintendo games for free) take down an IP producer I liked.

That being said, it isn't going to happen to Nintendo: they are largely pitching the console at folks who both don't pirate games and wouldn't know how to if they did (targetting customers who enjoy paying money for your product -- a novel concept!). They've sold a bazillion units -- and every one at a profit, thank you very much. They can update the firmware to remove this channel and the exploit any time you put in a first-party disk, and with the Nintendo model they can be reasonably certain that any console which is turned on in 2008 will play one of the next three Big Series releases from Nintendo. They have caused a resurgence in interest in alternate peripherals (credit also to Guitar Hero), which means that just stealing the game itself doesn't get you all of the fun. They have a very friendly online purchasing experience for many old games, which makes it less appealing to use the system as an SNES emulator (a very popular "homebrew" application in my experience).

So I'm not worried about Nintendo. Good thing, too, as I own stock in them.

Dreamcast wasn't the only console designed to be able boot 3rd party disc out-of-the-box (although the feature was designed with karaoke discs in mind. Not homebrewer nor pirates).

PS3 is also designed to be able to boot Linux out-of-the-box. But the PS3 doesn't seem to be tanking because of it.

The first Playstation was one of the most widely pirated console. Yet, it was also one of the most successful.

After the first couple of years, emulation of the Gameboy was widely available. During the life-time of GameBoy Pocket, Light and Color. Emulation has been available in parallel, with a flourishing underground traffic of roms, yet you can't call the GameBoy "not successful".

I disagree. First, few hardware maker actually sell consoles at a loss (even if they have smaller margins on the hardware compared to the software).
In the case of Dreamcast, how much of friend do you know how only bought the console (first hand from a shop) and never ran anything but burned CD-R on it ?
Everyone I know who had a Dreamcast had at least bought couple of games. Usually the same quantity as they also had cartridges for older less pirated game consoles.
It seems to me that DC piracy hasn't as much lowered games sales, as it has mainly allowed users to play that they wouldn't have bought in the first place.

What really caused the DC's downfall is a mix of not loud enough marketing (SEGA has often showed understated stats of its console, whereas most competitors used to inflate the specs), a silly price war later in the life cycle against its competitors, lots of 3rd party developers putting their project in the hold in expectation of the next playstation, and past financial disasters (the Saturn definitely tanked in the US, and only had limited success in Japan and even more limited in Europe).

The Wii is not sold at a loss. It has a lot of success in most market, out-sellling its main competitors. It's primary market is more geared toward casual and family players who aren't going to go through the hacking hassle to get the pirated software work anyway. (They usually buy on the spot the Wii and couple of fun multiplayer games Ã-la WiiSport. Then only occasionally buy additional games). It's not even in direct competition in its own market (whereas both of the competitor fight for the "hardcore player" segment).

I just can't see the Wii tanking because of this hack.
That hack will just enable creative use of the hardware by homebrewers.
And maybe enable some player to play games they weren't interested in buying in the first place.

Nonetheless, given Nintendo's past, they will probably go with great rage after all makers of such hacks, and sue them for piracy. With the net result being to so much raising sales, as mainly killing homebrew creativity.

This is simply rewriting history.

The Dreamcast was already close to death by the time these hacks came out. It was a combination of Sega's insufficient capital to continue advertising the Dreamcast past the 9/9/99 launch, and a steady drumbeat from Sony about how the PS2 would be a generation ahead. Sega was simply outmatched from the start.

The Dreamcast was a great console with perhaps the most interesting lineup of games, but it was always going to be a poor cousin to the PS2.

Besides, if piracy kills consoles, the PS2 would have faded about 18 months after it came out.

I'm speaking here as an amateur Nintendo DS developer with some experience with DevkitPro, the "toolchain" made by some guys to run stuff on Gameboy Advance, Nintendo DS, Gamecube and recently Wii, among others. I have no direct experience with Wii developing, but I think I can help you a little...

* Which programming language can I use? I am guessing C/C++ is supported?

The "toolchain" is called "DevkitPPC" (a part of DevkitPro, which is available here [devkitpro.org]) consists of GCC and some other utilities (many from GNU) and libraries to generate ELF executables that the Wii can run. So, basically, C and C++ are supported.

I don't know about the last version, but they're working daily on the CVS mainly with Wii updates, so expect the next version (r15) to be very nice. All this is available as a Windows installer, or you can get binaries (or the source) for Linux. I remember seeing something for OSX, but I don't know how it is nowadays.

* Which UI library exist? Is there support for input devices, can I also output text and images?

* Which network library exist? Can I use internet/WLAN connection, can I use Berkeley sockets API?

* Are there existing example applications? Not only "hello world"... maybe something more complex?

The libraries for the NDS are very low-level stuff, with very recent additions towards higher-level stuff; so I'd imagine the Wii stuff is still very low-level.

There are some Wii examples to get you started. I don't know if the main packages include them, you can grab them here [sourceforge.net] if not.

Finally, if you start developing for the Wii, expect to visit forums, dig up information on IRC and generally learn *very* low-level stuff to do anything beyond a simple "hello world".

Yes, C/C++ is supported.

There are no decent UI libraries yet. What you do get is direct access to the GPU with libOGC (the main homebrew library). The API is similar in spirit to OpenGL, though not directly compatible, and there is some setup needed. There's are a few examples on the devkitpro CVS (download the module 'examples'). Most are for GameCube, but don't be fooled - they can be compiled for Wii with no modifications, most of the time, by adding -mrvl to your CFLAGS and LDFLAGS. Graphics support is probably the least user-friendly part of libogc.

Input devices are quite easy to use, both GC pads and the Wiimote, in the latest version of libOGC (which requires the latest CVS devkitPPC). Once r15 is out, you'll get all of this in easy to use precompiled packages. Things like inactivity timeouts and auto-connection work out of the box, and you pretty much just call one function to scan for pads, and one function to read the current state structure.

SD filesystem support is also trivial. One init call, and then it's just stdio, using URL-ish paths: fat:/file, etc. With the Homebrew Channel, you also get your current directory set to the directory of your executable on the SD card (via argv[0]), so you can just open relative paths and they'll go to the right place on the SD card.

Networking is supported (via wlan and USB adapter), through an API that is mostly Berkeley Sockets compatible. A few things are somewhat nonstandard, but we can't do much about them - in this case, the TCP/IP stack is implemented in the IO/Security coprocessor, so we're just wrapping that interface.

Also, getting a USB Gecko [usbgecko.com] is recommended. It's basically an interface that looks like a USB serial port on one end and plugs into your GC memory card slot on the other. While you can have a text console on-screen, the Gecko lets you have easy stdin/out directly from a PC, which is very useful for debugging. You can also call DEBUG_Init() and get a gdb stub listening over gecko when you get an exception, so you can easily get a backtrace and all of those goodies. We'll probably come up with something better in the future (via wifi?), but it's still a very nice, simple low-level peripheral to have.

Admittedly, the documentation now is very lacking, because most developers have been spending their time coding new features. Now that things are getting calmer and I have more time, I hope to start documenting things a lot better.