New Wii Hardware Revision to Drop GameCube Compatibility

[biolizard89]

http://www.qj.net/wii/events/brand-new-wiis-out-by-christmas-no-backwards-compatibility.html

We hackers know why that decision was made -- the major debugging tool for the Wii (USB Gecko) relies on GameCube hardware, meaning that removing GCN compatibility will prevent development of online cheats on those consoles.  Unfortunately, this impacts those of us who do legal mods using the GCN hardware, including both offline cheating (GeckoOS) and console synchronization (GeckoTunnel).

It's unclear how GCN support will be removed.  The Wii's processors can easily handle GCN games, so playing GameCube games might be as simple as copying BC/MIOS onto a new Wii.  Debugging Wii games can be done via WiFi on the IOS side, as megazig is currently working on.  I can't think of an easy way to debug games while in GameCube mode without GameCube ports, unless something like DIOS MIOS were used... linking the front SD slot to a SDIO/USB bridge sounds possibly feasible.  If debugging were done, GameCube controllers could be simulated using PadSim.

Speaking as a developer who uses the USB Gecko, this news does not change my plans.  The Wii U is on the way, and it has been known for months that it will not support GameCube hardware.  All USB Gecko developers have been aware of this fact.  When or if Wii or Wii U debugging solutions are released which do not rely on GameCube hardware (including Wi-Fi solutions like MegaIOS, or front-SD solutions), I will happily work with those solutions' developers to have GeckoTunnel use them (with interoperability with USB Gecko).  In the meantime, GeckoTunnel development will proceed as planned.

For those of you who are interested, the following products look useful in implementing a front-SD debugging interface:

Hardware:
http://www.actel.com/products/ip/search/detail.aspx?id=739

Linux driver to port to the Wii:
http://lxr.free-electrons.com/source/drivers/mmc/card/sdio_uart.c?a=blackfin

Any thoughts from the hardware hackers on whether an SDIO/USB bridge would be doable?

[WiiPower]

I think the 2 main reasons are:
1. Lower the costs
2. Get the people used to not having gamecube backwards compatiblity. We know that the WiiU won't be able to play them, but the majority will find out when it's in the shelves.

Anyways, this restricted Wii might be a good opportunity to create a front sd debugger. I would choose that instead of the wifi one, because i imagine that the Wii to WiiU differences related to the front sd slot are much smaller than the wifi differences. But this is pure speculation, maybe nintendo thinks of that and makes the front sd slot somehow secure against hacking.

[James0x57]

I read that it's an EU exclusive remodel and it's at the end of Wii's life... so I really don't think usb gecko is the reason for it. WiiPower's thoughts seem much more likely to me..

Also, it wouldn't stop people from using homebrew so it would be way too little way too late if that was their goal.. IMO

[dcx2]

Using the SD slot for remote debugger is certainly feasible.  I'm pretty sure it's attached to the EXI bus already, probably just would require changing which registers the code handler uses to write to the USB Gecko.

I went to Riivolution's forums and asked about whether they could add remote debugging via wifi.  The attitude I got there was pretty dismissive, so I haven't been back since.  They were all "there's too many PPC calls that you will need to emulate", which IMO isn't true; IOS can read and write to MEM1, so all you would need is a few bytes of memory and a semaphore to indicate who has ownership of the bytes.  Alas, I digress.

As far as "the last system with homebrew", I doubt it.  There hasn't been a console that hasn't been hacked yet.  Given that Nintendo's stock has been taking a hit because foolish investors are too concerned with short-term profits at the expense of long-term health of a company, it makes sense that they might try to cut costs a bit.

[Deathwolf]

WiFi?  There will be an Action Replay for sure (hope so  )

[dcx2]

Yeah, drive chips will probably come first, although I expect Nintendo to do crazy stuff to their new drives.  I believe the latest Wii drives can't even read DVD-R at all.

Nintendo isn't going to leave it open to hacking.  After all, they didn't leave the Wii open.  They just FUBARed when they used a string comparison function for a cryptographic hash.  Certainly they won't do that again.  But exploits will be discovered.  Keys will be found.

My guess is that Wii mode will be exploited first, and that will be used to learn about the rest of the device.  After all, GC mode was exploited to learn about the Wii.

Sure, it might take a year to find an exploit that the general public can easily use.  But, honestly, I don't buy stuff until it's been out for a year.  I wait for rev2 bugfixes at least.

[megazig]

I currently use riivolution as my base for megaios. So, it's very possible. Current issues are source and time and computer availability though

[dcx2]

There was never any doubt in my mind about being possible.  I just don't know ARM (yet) so I wouldn't know how to code it.  I also don't know much about IOS.

But I do a lot of hardware development in my profession.  I'm quite accustomed to ferrying data across hardware domains using semaphore flags.

Here's a basic run-down of what I envisioned.  There are four common buffers of memory which are reserved by an IOS Wifi debugger and the PowerPC's code handler; ToIOS, ToIOSFlag, FromIOS, FromIOSFlag.  These would probably exist in the 80001800-80003000 range.  exisendbyte would be replaced with a routine that writes the byte to the ToIOS buffer, and then it sets the ToIOSFlag to give ownership of the buffer to the ARM.  After IOS reads the byte, it will clear the ToIOSFlag, giving ownership back to the PPC.  exireceivebyte would use the FromIOS buffer in a similar manner.

It might not have the best performance at first, but it could be improved upon by increasing the buffer size.  The Flag buffer could contain the byte count, and the MSB would be the flag itself.  The nice part about this approach is that it would allow us to re-use the current Gecko OS code handler and Gecko.NET with minimal modifications to the existing hacking toolchain; Gecko.NET would just need some socket code to talk with the IOS Wifi debugger.

I am more than willing to lend my expertise to such an endeavor, as it would be a great opportunity to learn about IOS and ARM.