In Dolphin 5.0, you could at least download any game from the GameCube. Except one. The difficult way to use a memory management unit in PowerPC Star Wars: The Clone Wars until recently did not allow playing it through Dolphin. But in Dolphin version 5.0-540, this problem is finally solved: the emulator has learned how to download all the GameCube games from the official console library.


Star Wars: The Clone Wars launched in Dolphin

Why did Star Wars: The Clone Wars become so special? To really understand what's the matter, you need to know a little about how the PowerPC processor performs memory management and how this process is emulated in Dolphin.

Memory control unit emulation

The Memory Management Unit (MMU) is responsible for providing games with quick access to data and code. Instead of directly accessing the available RAM, the games access virtual memory, which is then translated by the MMU into physical memory. This process can be performed in two ways: by translating Block Address Translations (BAT) in the case of large blocks of memory or by page tables in the case of displaying small volumes.
')
Games gain access to virtual memory rather than real memory for several reasons. First, it gives the processor the ability to cache access operations, greatly increasing the efficiency of accessing frequently used values. Secondly, the GameCube has a total of 24MB (and several specialized areas) of RAM in the 4GB address space; This means that most of the memory addresses do not have the corresponding RAM! If a game tries to access a real memory address that does not actually have physical memory, it will receive garbage data or simply cause a crash! Through the use of virtual memory, the MMU can generate an exception, giving the game the opportunity to handle this situation or provide developers with important feedback with useful information about the error that occurred.

Dolphin can emulate the MMU with a certain degree of accuracy based on theories about how the game should behave.


The MMU is part of the GameCube processor. Photo from Wikimedia

Theory 1: Software only writes to real memory

If games can record only in real memory, then Dolphin has no difficulty with this. Most games use the standard GameCube / Wii BAT mapping, and while they are not trying to gain access to memory beyond its limits, all that needs to be done is to provide access operations to the right places.


Standard mapping has one block address translation (BAT) that broadcasts all physical memory. Since BAT is faster than page tables, most games only use them.

Dolphin's approach is to hard-code this block address translation (BAT) from virtual memory and translate the address into physical memory. Simply put, the game asks for one address in memory, but the console (and therefore Dolphin) sends it another from real memory.

There are also other important display parts that are not covered in this article. One of the most important is the memory mapped input / output (Memory-Mapped Input / Output, MMIO), with which the processor interacts with various devices (disk drive, memory cards, etc.). You also need to mention a special boot sector, but since games can not access it, while there is no need to talk about it.

The MMU Off mode in the emulator is such a truncated MMU functionality to only allow the MMU emulation to allow games to load. It simply provides the game with a memory area for work and assumes that the game will not break the rules. Surprisingly, most GameCube games and almost all Wii games actually work with memory correctly.

Most GameCube rules-breaking games should have required full MMU emulation, but ingenious emulator developers managed to trick these games without performance degradation using MMU Speedhack.

Theory 2: The use of unacceptable memory games can be predicted

MMU Speedhack can be called "MMU Off +", because it still does not perform a serious MMU emulation. It displays more RAM than the GameCube has to make games think that everything works, not caring what the games really do.


Since games use these addresses as extended RAM, simply displaying them as real memory works! But you probably do not understand why these games generally try to gain access to invalid memory, right?

This is because Nintendo has created a library that allows games to use 16 MB of additional GameCube RAM as extended RAM. Since this additional RAM is connected to the digital signal processor (DSP), it is more often used as audio memory, but technically it can be used for almost everything. The processor cannot directly display additional RAM in the address space due to the missing hardware function, so the game has to read and write to the invalid memory address in order to trigger an exception handler. This exception handler uses direct memory access (DMA) to move data from additional RAM to the game-allocated cache in physical memory. Then he gives the command to the page table to report that the address of the previously invalid memory now indicates the location of this cache, which allows the game to work without “departures”!

Somehow, the Dolphin emulator hack manages to work for almost all games that use additional RAM as extended memory. Despite its curvature, this hack is surprisingly effective and works quickly.

Theory 3: Invalid Memory Access Unpredictable

MMU Speedhack has high performance, but it works only in games, memory usage algorithms of which are typical and are so common that they were integrated into Dolphin. Such a hard-coded behavior allows the Dolphin emulator to assume from where the game will read and not to worry about ensuring the validity of the memory being accessed. MMU Speedhack games are so standardized that they follow very simple rules, but these rules have limitations.

Some games used their own exception handlers and used memory addresses in a non-standard way, disrupting the operation of MMU Speedhack. In these cases, Dolphin should verify and ensure the validity of the memory address, and only then transmit instructions or data to the emulated processor; this is much slower than simply considering all addresses as valid.

Before attempts by Fiora and other developers to optimize JIT and MMU emulation, the MMU Enabled mode was the death sentence for the game process.




There are 21 known games that require more than just MMU Speedhack to work.

Processing memory checks (memcheck) is slower because it interferes with fastmem performance optimization. Fastmem displays the GameCube / Wii address space in the computer's memory, and then marks all the emulated invalid memory for the computer as allocated. This allows the Dolphin emulator to use the processor's processor exception handler to do the dirty work when intercepting exceptions. When it intercepts an exception, the emulator has to move from fastmem (fast) to slowmem (slow memory) to handle the address, which can be a very big performance problem.


Memory checks are the basic MMU Enabled function, and this is the main reason why games with MMU turned on were so slow in Dolphin. Some situations required a return to an interpreter that does not work with fastmem; at the same time, memory access was even slower than normal console access!

Despite the frequent inability to use, always try to use fastmem for almost any access; The fastmem download area stores only two instructions, and the same access using slowmem can take up to 1000 instructions! Since we don’t know if the pointer is in real memory or not, we just always try to use fastmem because of the huge difference in performance it gives us if it works.

As mentioned above, in fact, slowmem has become a little faster, which allowed it to be used in practice. This is mainly due to the transfer of memory checks to the Fiora's Far Code Cache code cache . By optimizing the processing of memory checks and the constant availability of all instructions and data in games with MMU, performance has increased significantly. The greatest effect is noticeable Rogue Squadron 3, the speed of which jumped from a measly 4 to almost 45 frames per second!

Usually, the Far Code Cache cache, along with other JIT optimizations, on average led to almost two-fold performance improvements in all games requiring MMU Enabled, with a pleasant exception in the form of Rogue Squadron 3. It is thanks to this that today powerful computer users can at least try playing games with enabled MMU.

Theory 3.5: Factor 5 - reptiles

Of course, the majority of users did not even know how much Star Wars Rogue Squadron 3 was slowing down before implementing Far Code Cache, because it simply did not load . At least that was the NTSC version. The PAL version was somehow loaded , and it was from it that the speed characteristics were taken before the appearance of Far Code Cache.


Even if you managed to start the game without breaking anything, things would suddenly become bad if an important piece of data was saved on several pages.

Rebel Strike became the penultimate NTSC-loaded game for one reason - it had a nasty little MMU trick that put off emulation by more than a decade. Rogue Squadron 3 could store data on several pages! With long-term reading or writing, the Rebel Strike could cause an exception, literally switching in the process from a valid to an invalid address! Previously, Dolphin mistakenly set an exception at the beginning of a reading, and had to set it where the exception actually occurred.

It would be nice if Factor 5 (from the translator: Star Wars Rogue Squadron III: Rebel Strike developers) became the last GameCube game loaded in Dolphin, but one more remained. And this time it was not a minor mistake.

Theory 4: the game determines its own real memory

Now we finally turn to Star Wars: The Clone Wars. After all the work done by Dolphin developers to handle BAT and page tables as efficiently as possible, this game decided to throw out one of Dolphin’s most basic assumptions: static BAT.

What does dolphin do?

Dolphin was completely unprepared for a situation in which real BAT emulation is required. Whatever settings you use, thanks to tightly defined assumptions, everything ended up very sour.

MMU Speedhack / MMU Off - in this combination, things went very badly. Since Dolphin does not actually emulate the MMU, he started the work and decided to transfer to the processor any garbage located at 0x00000000. The game naturally fell out, because it is extremely stupid behavior.

MMU Enabled - if you are using a version released before this article, then in MMU Enabled mode, the process moves a little further. Dolphin manages to emulate exceptions and load an error handler, but the emulator is simply not able to handle what happens next. Clone Wars uses BAT disabling during exception handling to gain more control over memory management. She then reports that standard BAT and page tables are not good enough and are trying to create their own. Dolphin hard sets BAT. They are not changeable. Therefore, when the error handler returns control to the game ... it certainly “falls”. But at least Dolphin itself continues to work, so you can close the game and play something else.

You can ask the question: "why not just create a special hard-coded BAT for this game?". But in fact, this will not work. The game changes BAT many times during missions and in multiplayer mode; this means that proper BAT emulation is required.

What Dolphin Should Do

Proper BAT emulation implies that Dolphin should be able to enable and disable BAT based on the actions of the game, and not on assumptions about what it wants. In this case, a problem arises: the effective MMU emulation in Dolphin is based on the fact that it knows where the virtual memory will be located, and the destruction of this foundation completely destroys Dolphin.

Star Wars: The Clone Wars is the only known game that uses four displayed BAT instructions and BAT data to create your own memory mapping. To emulate this game, the MMU emulation code in Dolphin must be completely rewritten. In this case, everything is very complicated: fastmem, memory checks, and the fact that between them.

Unlike other MMU Enabled's own exception handlers, the Clone Wars exception handler actually restructures memory. It disconnects the standard BAT from the address space and during the game many times creates its own. In previous images you saw that BAT became more and more complex, making the emulation more complete, but The Clone Wars throws all this work into the garbage!



This time Dolphin cannot make any assumptions. Only a complete remake of the BAT Dolphin emulation kernel is able to cope with this worst-case scenario. Dynamic BATs (Dynamic BAT) is a complete BAT emulation that allows you to do what the games ask for and display the information correctly. “Thanks to” this rewriting of a huge amount of code from most of the hard-coded assumptions in the MMU Dolphin emulation had to get rid of.

Flipping the page table

(from the translator: in the title, the authors beat the meme Flipping the Table , there is no talk of any “coup” of the page table)

For several years now, Dolphin developers have known what it takes to download Star Wars: The Clone Wars. In the distant past (in the era of version 3.0) there was a branch that could load The Clone Wars through the use of an interpreter. This was unnecessarily slow and affected the performance of non-MMU games; in that era, productivity was a very painful issue.

For more than a year, the current implementation (Dynamic BATs) even “hung” as a pull request , and at that time could already load The Clone Wars. She waited for her time for so long that even another developer started working on it!

The reason why the implementation of this function took such a long time is that it could not be implemented without destroying the work of the rest. Given all this, the implementation of the magumagu developer was brilliantly done.


As you can see, a lot of attention was paid to maintaining Dolphin speed despite the huge amount of rewritten MMU code. In games that do not use MMU Enabled and use MMU Speedhack, performance should decrease by less than 1%. This is a big difference with the original plans, in which for games that do not use MMU Enabled, the drop should have been more than 30% even with the MMU emulation disabled!

One of the important features of the implementation of Dynamic BATs is that it still works with fastmem, despite the obvious complication of the ability to move real memory! On the other hand, while MMU games run a little slower. A drop of 8% -15% is significant, but we can get rid of it with further optimizations. We felt that a huge increase in accuracy was worth some loss of performance.

Side effects of rewriting hard-coded BAT code

More accurate MMU emulation has led to the fact that the frequent strange behavior of games is now emulated much better. Of course, Dynamic BATs are really needed to run only one game, but other games also benefit from faster access to memory checks.

Users adore when games fall out, right? There are quite a few games for Wii that lead to crashes on the console when a player performs unintended actions. Sometimes doing these things even crashes Dolphin! Simplified access to memory checks means Dolphin can accurately emulate well-known glitches in games, without causing Dolphin crashes! The problems suffered by Super Mario Galaxy or Twilight Princess can now be emulated and cause the same crashes as on the console without affecting performance!


"Bug" with a road sign in Twilight Princess

Again, most players don’t like it when it’s crashing. From this point of view, Rayman Raving Rabbids TV Party (and Rabbids Party Collection ) no longer “fall out” when loading mini-games. Perhaps this happened because of small changes in cache management, or, more likely, in the hard-coded BAT / tables of the pages there were "bugs". A crash that no one could fix, just disappeared after rewriting the code - it was a pleasant surprise.

Improving the overall processor emulation also inexplicably allowed two more games to work. We Love Golf! , created by the developers of Mario Golf, “crashed” while trying to download the level. Summer Athletics 2009 simply did not load and showed some debug information on the screen.These games were not affected by the implementation of Dynamic BATs; inexplicably corrected the behavior of both games by itself clearing the code in the process of merging branches. According to information known about the problems of these games, it was most likely a matter of instruction and data cache errors.

Another pleasant surprise was the improvement in the work of the heap of romhaks in Dolphin. Wiimm’s Mario Kart romhaki Wii More Fun correctly (well, almost) load the route selection screen!

Very, very lucky that it all works at all. Hack does not clear icache; instead, it relies on the PowerPC processor in managing the release and reset of icache, so it was thought that it could not be emulated in Dolphin without significant performance degradation. But now Dolphin clears icache when changing BAT. Unfortunately, between tracks, players must return to the main menu. If you want this to be fixed ... then you do not need to inform us about it. Just keep in mind that with this Dolphin will have to emulate emulation of instructions and data cache, which generally will increase the requirements for resources for processor emulation 14 times! Hardcore or gamers seeking to emulate accuracy want to emulate everything, but everyone else does n’t really need full and accurate cache emulation.

If the romhackers still want their games to work in Dolphin, then we, unfortunately, will have to ask them not to rely on the processing of icache / dcache by the PowerPC processor. For example, the creators of Project M before the final release fixed the use of icache / dcache, so that it should work correctly in Dolphin. But if you do not want Dolphin users to run your romkhaks, then you know how to protect against this (at least for now).

Finally

After rewriting the code, Dolphin made another big jump in the engine's accuracy: several random crashes were eliminated (although most players would not notice the difference). This is a victory, albeit with a bitter aftertaste: we forced the last game to be launched from the GameCube, but there are still a lot of unsolved secrets. Of course, some games still fall out, there are many problems that need to be solved, but there are no completely non-working games left.

Currently, MMU emulation in Dolphin is capable of handling any known game. The only ones who can change this can be Factor 5, but they didn’t seem to have made any Wii games ...


Star Wars: Rogue Leaders on the Wii

However, it turned out that there is another Rogue Squadron game on the Wii . It was developed by Factor 5, so it must exploit the console as no game has ever done before. But the problem is that the game was not released, so we cannot open it in Dolphin. Although it does exist; Maybe someone can try to run it in Dolphin. Maybe at least look at the "departure", which it will inevitably cause. Or maybe it even starts, and you can make at least one screenshot? (Oh please!)

Anyway.At the very least, we have a Netflix channel developed by the core members of Factor 5 already in the new company. And, as you probably already guessed, it does not start in Dolphin.