Game Cube Memory Exploit
There are several methods available to successfully boot homebrew on unmodified and modified Gamecubes. These methods include using a special bootdisc and memory card device, a loophole within an official Gamecube game title, a traditional modchip or a drive replacement modchip.
Game cube memory exploit
These require a memory card to place the hacked save game and a boot.dol converted to .gci format. Swiss is distributed as a bootable GCI. Need the help of an already homebrew able Gamecube, or a Wii (while RVL-001 is the easiest, RVL-101 and RVL-201 can have their GameCube ports soldered back in), modded or unmodded to first put such files on memcard.
Castlemania Games is now selling a Gamecube memory card that also doubles as an exploit device. A SD reader is still required to boot homebrew, however the combination of this memory card, the reader and an original copy of Windwaker, Twilight Princess, or Paper Mario will allow you to launch Swiss on a completely unmodified Gamecube. And while yes, an Action Replay can do the same thing, the NTSC version is out of print and the PAL version is almost completely out of stock permanently as well, leaving game exploits as the only choice for many people. Prices start at $15 and an explanation of how this works is below:
After boot, GCMM will check which devices are available. If only one device is available, GCMM will use it as default. If more than a single device is available GCMM will boot into the device selector screen. You may skip device selector screen at boot using command line arguments (check cli files for gamecube mode).
You can load gcmm via sdload and an SD card in slot A, or by streaming it to your Gamecube, or by booting a bootable DVD with gcmm on it. You may also use any of the more recent game exploits.A good source for information on these topics is at -forever.com/wiki/index.php?title=Booting_Homebrew
The GameCube Memory Card is a propriety flash-based memory device used to save data for games on the Nintendo GameCube. The cards are compatible with the Wii, though they cannot be used to save data for its games. Up to two memory cards can be inserted into the GameCube or Wii at once.
The GameCube memory card is necessary in order to save data of any sort in Melee, including Records, unlockable characters, and other accomplishments, as well as snapshots taken with the game's Camera mode; as data is frequently saved throughout gameplay, Melee's manual recommends against removing cards or shutting down the console before returning to the title screen. If no memory card is present, the game will warn the player of the fact when the game is booted, though the player can still play the game; inserting a memory card at any point will let the game begin to save data, though it will overwrite any previous Melee data on the card.
In an unusual use of the memory card, players are rewarded the Captain Olimar trophy if they have save data from Pikmin on their memory card while loading up Melee. Pikmin's save data needs to be on the same card as the Melee save data. Pikmin itself was released after Melee in PAL regions, which made it impossible to collect all the trophies in the game's first month of release; in Japan and North America, Pikmin was released prior to Melee.
Metal Gear Solid: The Twin Snakes, an enhanced port of Metal Gear Solid for the GameCube, features further compatibility with Melee's save data. Released three years after Melee, one of the bosses in the game, Psycho Mantis, taunts Solid Snake by claiming to have the ability to read minds; among his ways of proving this is by reading data off the inserted memory card and asking Snake and, by extension, the player, about other save data found on the card. If Melee's save data is detected, Psycho Mantis has unique dialogue specifically referencing Melee.
The gameplay mod 20XX Tournament Edition is uniquely run by using hacked save data that exploits how Melee loads code. As such, uploading this data to any memory card will force the GameCube or Wii to load 20XX on top of Melee. As an added feature, this data is read like most other data saved to the memory card, allowing for players to copy the hack from one card to another using the built-in software on either the GameCube or Wii.
Before custom/homebrew software can be run on the Wii, it must first be hacked. This is accomplished by exploiting some weakness in either a game or in the Wii System Menu. The exploit is essentially used as a way to break out of the Wii's normally protected environment and install the Homebrew Channel which, once installed, can itself be used to run additional homebrew applications without the need for further exploits.
The MMU is a part of the GameCube's CPU. Credit: Wikimedia / CC by-SA 4.0The Memory Management Unit, or MMU, is responsible for quickly giving games access to data and code. Rather than directly accessing available RAM, games interface with virtual memory which is then translated to physical memory by the MMU. This can be done in two ways, with Block Address Translations (BATs) for huge portions of memory or the page tables for small fine-grained mappings.
The games are given access to virtual memory instead of real memory for several reasons. First of all, it gives the CPU an opportunity to cache accesses, greatly speeding up the efficiency of accessing often used values. Secondly, the GameCube only has 24MB (and some specialized areas) of RAM across a 4GB address space, meaning most memory addresses have no RAM backing them! If a game were to access a real memory address with no backing memory, it'd get garbage or even crash! By using virtual memory, the MMU can throw an exception giving the game a way to handle the situation or provide valuable feedback to developers on what went wrong.
As long as the games only write to valid memory, Dolphin doesn't have much work to do. Most games use the GameCube/Wii's default BAT mappings, and as long as they don't try to access memory outside of that, all that has to be done is making sure accesses end up in the right place.
Dolphin's way of handling this is to hardcode that Block Address Translation (BAT) from virtual memory and translate the address to physical memory. In layman's terms, the game is asking for one memory address, but the console (and thus Dolphin) gives it another from real memory.
There are also a few other major pieces mapped out that we'll be keeping out of the scope of this article. The big one is Memory-Mapped Input/Output (MMIO), which is how the CPU interacts with different devices, such as the disc drive, memory cards, etc. The other thing to note is the special boot sector, but since games can't access it there isn't much more to say about it for now.
MMU Off is as barebones as MMU emulation can get while still booting games. It just gives the game some memory to work with and assumes the game will play nice. And amazingly enough, most GameCube games and nearly all Wii games actually do.
Because the games are using these addresses as extra RAM, simply mapping them as valid memory works! But, you're probably wondering why these games are accessing invalid memory in the first place, right?
This is because Nintendo provided a library that allowed games to take advantage of the GameCube's 16MB of auxiliary RAM as extra RAM. Because this auxiliary RAM is linked to the DSP, it's more commonly used and referred to as audio ram, but it can technically be used for just about anything. Because the CPU can't directly map the auxiliary RAM to the address space due to a missing hardware feature, the game has to read or write to an invalid memory address to invoke an exception handler. This exception handler would then use Direct Memory Access (DMA) to move data from the auxiliary RAM into a game designated cache in physical memory. It then sets a page table to say that this previously invalid memory address now points to this cache location, allowing the game to continue without crashing!
While the MMU Speedhack is great for performance, it only really works when a game is following typical memory usage behaviors that have been seen so many times they have been integrated into Dolphin. These hardcoded assumptions allow Dolphin to assume where games are going to read and prevent the need for making sure memory access is actually valid. MMU Speedhack games are so standardized that very simple rules encompass them, but, those rules have limitations.
Several games used their own custom exception handlers and use memory addresses in non-standard ways, breaking the MMU Speedhack. In these cases, Dolphin now has to check and make sure that a memory address is valid before feeding instructions or data to the emulated CPU, which is much slower than simply assuming things are valid.
MMU Enabled - Assuming you're using a version from before this article, things get slightly further with MMU Enabled. Dolphin does emulate the exception and loads the error handler, but Dolphin simply isn't capable of handling what it does next. Clone Wars takes advantage of the BATs being disabled during exception handling to get finer control over memory management. And then proceeds to say that the default BATs and page tables aren't good enough and tries to create its own. Dolphin hardcodes the BATs. They aren't changeable. So, when the error handler returns control to the game... it promptly crashes. But at least Dolphin itself is still running so you can close the game and play something else!
Proper BAT emulation means that Dolphin needs to be able to enable and disable BATs based on what the game is actually doing instead of assuming what the game wants. The problem with this is that the foundation of Dolphin's efficient MMU emulation hinges on the fact that it knows where valid virtual memory is going to be, and breaking that assumption broke Dolphin to the core.