Gecko OS, WiiRD - how do they work?

[Dave Ubbin]

I have a few qeneral questions about Gecko OS and WiiRD. I've not found answers by searching the web. Apologies if some questions are a bit daft - I'm still at the stage where I don't know enough to know what's a daft question.


Gecko OS loading games

How does Gecko OS load games without getting itself overwritten? Does it know that there's an area of memory that games never access (and so always loads itself there)? If so is it a small area of memory (I've noticed that there are limits on number of code lines and so on).

I've seen that Gecko OS supports different hook types. Does this mean that Gecko loads the game and then patches the game to call back in to Gecko at certain points? I can see how that would work with interrupts but how about other things? Or are certain routines always at the same address no matter what game you are loading?


Breakpoints

I can see how you could overwrite code to make an exec breakpoint. But how does USB Gecko apply read or write breakpoints? Is there some hardware support for it?

Gecko.NET

I've seen the very neat feature in Gecko.NET to dump code for all frames on the call stack. Is there something equivalent that will dump the register-saves in each stack frame?

Code Overlays

I know you should expect that data will move, especially if you change levels / minigames / whatever. But what about code? I.e. is the pressure on memory so linited that a game will overwrite code (loading new stuff from DVD) when you move from one level to the next. I guess for a specific game I could test it but I'm after a general rule of thumb.

[dcx2]

These are all good questions.  I will provide short answers for now, but expect more complete answers later tonight when I have more free time.

Gecko OS and the code handler

I consider Gecko OS to be split into two parts.  The first part is the apploader.  It reads the main.dol from disc and writes it into memory, etc.  Once the apploader hands control over to the game, it does not run anymore.

The second part of Gecko OS is the code handler.  This is the code which is resident in memory while the game is running.  It is stored in the "unused exception vector", which is limited to 0x1800 bytes for the code handler, debugger, and cheat code list.  http://wiibrew.org/wiki/Memory_Map

The hooks ensure that the code handler is called frequently.  Generally once per frame.  Hooks are never in the same memory location across games, but they usually have a unique ASM signature that can be used to reliably find the address of the routine of interest.

Breakpoints

Data breakpoint support is provided by all PowerPC processors.  Instruction breakpoint support is optional, but it is implemented in the Gekko processor, and Broadway is practically identical to Gekko.

Gecko.NET

There is no way to dump the register saves automatically.  You will need to manually inspect the stack (r1 always points to the top).  Then you will need to carefully examine the stack and the result from Copy All Frames to deduce where a given non-volatile register was pushed.

Code Overlays

Since the Wii has 24+64 MB of RAM, overlays are usually unnecessary.  I have seen some games use them, in particular Resident Evil 4.  Fortunately, the F2 code is quite useful for conditionally hooking code overlays.

GC games are a different matter entirely.  GC mode only has 24MB of RAM available.  Most GC games I have seen have some code overlay, which would explain why Resident Evil 4 used them since it was a GC port.