I'm wondering if a Wii debugger exists or could be made that could be active while a program is operational? It'd be nice to be able to freeze the CPU, look around memory, disassemble code, single step, but breakpoints, stuff like that.

It seems to me some sort of terminate but stay resident approach could work, maybe some sort of Wifi packet mechanism could be used for communication with a remote host. A packet could be sent to the Wii using the Wii's MAC address, and the TSR could pick it up and respond to debug style requests in the body of the packet.



Edited 1 time(s). Last edit at 09/16/2010 10:32PM by dashxdr.

I think USB Gecko is the only publicly available method for what you seek.

Quote
dashxdr
It seems to me some sort of terminate but stay resident approach could work, maybe some sort of Wifi packet mechanism could be used for communication with a remote host.

Just a pointer for this kind of thoughts. In the very same moment, using a WiFi or any other similar connection of the kind, that, as you say, "halt the CPU and browse around", the WiFi itself will stop working, because you see, to process the WiFi/Ether packets, you DO need the CPU.

As SifJar said, go with Gecko.

Quote
g_man
[Wiibrew.org]

It's buggy, slow, a pain the a$$ to set-up, and not compatible with SVN libogc for over a year. Its not a valid option.

oh, It worked for me, but that was a while ago.

Quote
Skizo
Just a pointer for this kind of thoughts. In the very same moment, using a WiFi or any other similar connection of the kind, that, as you say, "halt the CPU and browse around", the WiFi itself will stop working, because you see, to process the WiFi/Ether packets, you DO need the CPU.

As SifJar said, go with Gecko.

Gecko seems to have been discontinued.

Incidentally, the management of USB traffic requires the CPU as well. Your assertion that Wifi wouldn't work applies to USB as well... and yet magically USB must work if this Gecko thing works.

The debugger itself uses the CPU. It could call the Wifi stack to keep it working. Just as whatever mechanism that uses the USB keeps the USB communication going.

Are you really a programmer, or are you just talking theoretically, may I ask? There's always a way to make something work.

A USBGecko doesn't use the wii's USB ports (unless you're doing it wrong). It uses the EXI bus which doesn't really require any background management.

Quote
tueidj
A USBGecko doesn't use the wii's USB ports (unless you're doing it wrong). It uses the EXI bus which doesn't really require any background management.

In layman's terms, you plug one end into a GC memory card port on your Wii and the other end into a USB port on your pc.

Also, they are officially discontinued (for about a year), but there's still a ton of them out there for sale. I bought mine from [foundmy.com] just a few months ago for only $30 USD.



Edited 1 time(s). Last edit at 09/21/2010 04:36PM by Arikado.

Quote
tueidj
A USBGecko doesn't use the wii's USB ports (unless you're doing it wrong). It uses the EXI bus which doesn't really require any background management.

Ah! Good point. I was thinking USB meant plugging the USB end into the Wii, not the host computer one is developing on. Thanks for the correction.