Dolphin is an emulator for the Nintendo GameCube and Wii. It allows PC gamers to enjoy games from both consoles in full HD (1080p), along with a range of enhancements – including support for all PC controllers, turbo speed, networked multiplayer, and more.
To run the Windows version, the 64-bit Visual C++ redistributable for Visual Studio 2022 must be installed.
What games can you plan with Dolphin Emulator?
Dolphin lets you enjoy Nintendo GameCube and Wii games on PC. For a complete list of playable games, you can check out the list here.
What kind of CPU do I need to run Dolphin?
You'll need a quad-core CPU or better. With four cores, Dolphin has two cores for the main emulation threads, a third core for other tasks, and another core for the OS and background tasks.
Do I need a powerful GPU to run the Dolphin emulator?
A discrete graphics card that supports DirectX11.1 and OpenGL 4.4 is highly recommended. The more powerful the graphics card, the more pixels and enhancements you can throw at it.
- Nvidia: A GeForce GTX 1060 or better Nvidia GPU will be able to play Dolphin in HD resolutions with Ubershaders well.
- AMD: A Radeon RX 570 or better AMD GPU will perform well in Dolphin with Ubershaders. AMD generally favors D3D over OpenGL.
- Intel: Iris Pro iGPUs will handle Dolphin well in D3D in Windows. Integrated graphics older than HD 4000 are not supported.
How much RAM do I need to run Dolphin?
Dolphin requires at least 2GB of RAM. RAM speed generally has no effect on emulation performance.
Can I use two or more controllers for local multiplayer on Dolphin emulator?
Yes, if you have two or more friends connecting from the same computer, you can give a single computer multiple controllers. You only need to configure the first two ports of the Controller Configuration page.
What operating systems are supported?
Dolphin is a cross-platform emulator that runs on Windows 10 and Windows 11, Linux, macOS (10.15 Catalina and up), and Android (5.0 and above). Dolphin requires 64-bit operating systems to run properly.
What's New
All changes below are available in Release 2603.
2512-285 - Core: Create Fastmem Mappings for Page Table Addresses
"Fastmem" is one of Dolphin's biggest performance tricks. The GameCube and Wii's MMIO (Memory-Mapped Input and Output) memory mappings do not directly translate to the host system, and without a way to sort ordinary RAM accesses from MMIO accesses, Dolphin would need to manually translate every memory access at tremendous cost. Enter fastmem, where Dolphin exploits the host CPU's exception handler to sort accesses for us. If we map the entire GC/Wii address space to host memory, mappings for main memory will just work, no intervention needed. But attempting to access an address assigned to MMIO will trigger a CPU fault. When that happens, Dolphin can catch this fault and immediately backpatch the affected JIT code to manually translate the address instead. Just like that, Dolphin will only spend the effort translating memory accesses that it actually needs to translate, and the rest will be performed natively by the host CPU at incredible speeds.
However, fastmem didn't cover everything - it only supported memory mapped with Block Address Translation (BAT). Any time a game accessed memory mapped with a page table, the other way to map memory on the GameCube, Dolphin would always have to manually translate it.
This may sound problematic, but thanks to tricks like the MMU Speedhack, the vast majority of games see no performance penalty from page table accesses. In order for this lack of support to actually impact performance, a game would have to have a custom memory handler that resists our hacks and heavily relies on the page table. But what developer would be crazy enough to do all of that?
...Right. You.
Factor 5 is a recurring villain frenemy here on the Dolphin blog for a reason. If there's a trick to squeeze more power out of a GameCube, Factor 5 probably invented it. In this case, they went through all that trouble to get extra RAM.
The GameCube is a memory starved machine - its paltry 24MiB of RAM is tiny compared to its capabilities and storage media, which limited what developers could do with the machine. However, there is an additional 16MiB of RAM connected to the DSP, known as Audio RAM (ARAM). On a memory starved machine, an extra 66% of memory is extremely tempting.
There's a problem, though - the GameCube's CPU does not have direct access to ARAM. All the GameCube's CPU can do with ARAM is tell the DSP to use Direct Memory Access (DMA) to copy data from a range of main memory to ARAM, or vice versa. This is normally used for various DSP functions, such as loading audio samples.
For a game to use Audio RAM as general purpose RAM, some setup is required. If a game configures a range in the page table to point to invalid memory addresses, when it tries to access this memory, the invalid memory access triggers a CPU fault. That invokes the game's page fault handler, which uses DMA transfers to swap data between main memory and ARAM as needed. When the game resumes, the memory access will return data as if it were stored in valid memory all along. Through this process, data can be copied to/from ARAM in an automated fashion outside of the primary game logic, allowing games to more or less treat a range of invalid memory as if it were extra RAM. Audio RAM used this way is significantly slower than main memory due to its reliance on DMA transfers, but it's orders of magnitude faster than waiting for data from a spinning optical disc, so it's still a huge win.
Notably, the GameCube can only perform the above setup with the page table, as the hardware has too few BATs and their granularity is too large for this technique.
Halfway into the GameCube's life, Nintendo standardized this ARAM access process with a library provided in the GameCube developer support tools, so that developers didn't need to waste time creating their own solution. All games that utilize this library configure the page table in the exact same predictable way. Since we know exactly what they are going to do and we aren't bound to a GameCube's hardware limitations, Dolphin can just cheat for these games and set up a BAT pointing to extra memory that the GameCube doesn't have, bypassing all of that trouble while still getting the full benefits of fastmem. This trick is the aforementioned MMU Speedhack, and it has been enabled by default since 2014.
But years before Nintendo standardized this process, Factor 5 did it all themselves with their own custom memory handler in Rogue Squadron II. And, even though Nintendo's library existed by the time Rogue Squadron III came out, Factor 5 went above and beyond in that game with an even more optimized custom memory handler to squeeze as much as they possibly could out of ARAM. Tricks like this are what allowed Factor 5 to push the GameCube to such ridiculous levels.
