Theory 3: Invalid Memory Access is not Predictable ¶ As ugly a hack as it is, it's painfully efficient and effective. Somehow, Dolphin's hack works for almost all games that use auxillary RAM for extra memory like this. 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! 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.
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. 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. This is because Nintendo provided a library that allowed games to take advantage of the GameCube's 16MB of auxiliary RAM as extra RAM. It maps more RAM than the GameCube has to trick games into thinking things are working without caring about what the games are actually trying to do.īecause 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? MMU Speedhack can be best described as "MMU Off+", as it still doesn't do any serious MMU emulation.
Theory 2: The Software is Predictable About Invalid Memory Usage ¶
Most of the GameCube games that failed with this should have required full MMU emulation, but devious emulator developers managed to outsmart them with no performance issues with the "MMU Speedhack." And amazingly enough, most GameCube games and nearly all Wii games actually do. It just gives the game some memory to work with and assumes the game will play nice. MMU Off is as barebones as MMU emulation can get while still booting games. 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. 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. There are also a few other major pieces mapped out that we'll be keeping out of the scope of this article. In layman's terms, the game is asking for one memory address, but the console (and thus Dolphin) gives it another from real memory. Because BATs are faster than page tables, most games simply stick to this.ĭolphin's way of handling this is to hardcode that Block Address Translation (BAT) from virtual memory and translate the address to physical memory. The default mappings have one Block Address Translation (BAT) that translates to all of physical memory. 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. Theory 1: The Software Only Writes to Valid Memory ¶Īs long as the games only write to valid memory, Dolphin doesn't have much work to do. 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.ĭolphin is able to emulate the MMU with several degrees of accuracy based on theories of how the game is going to behave. First of all, it gives the CPU an opportunity to cache accesses, greatly speeding up the efficiency of accessing often used values.
The games are given access to virtual memory instead of real memory for several reasons. 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. Rather than directly accessing available RAM, games interface with virtual memory which is then translated to physical memory by the MMU. The Memory Management Unit, or MMU, is responsible for quickly giving games access to data and code.