Earlier this month, an interesting development within the Wii reverse engineering scene was announced as Fullmetal5 revealed that they had hacked the Wii Mini via a Bluetooth exploit. This bookends a flurry of a Wii Mini hacking, including rigorous hardware modding by DeadlyFoez. You may be wondering, "Wait, wasn't the Wii hacked over a decade ago?". That's true, but the Wii Mini stubbornly remained unhacked all the way into 2019.

This resiliency came from the Wii Mini's cut down nature: it physically lacks the attack vectors that were used against the original Wii. In total, the Wii Mini was missing GameCube support, with no GameCube controller ports or Memory Card slots, lacked internet and browser support, and they completely removed the SD card slot. With so few attack surfaces, hackers have had to get inventive. DeadlyFoez created "FrankenWiis", mixing Wii Mini hardware and standard Wii hardware, to create exploit options and dump the Wii Mini firmware. This was as far as anyone could go, until Fullmetal5 found the holy grail: an exploit in the standard Wii Mini configuration, through the Bluetooth stack! This exploit completely opens the Wii Mini, allowing for arbitrary code execution to dump and/or load data over the Wii Mini's USB ports. The exploit is currently not public, but when it is released, users will be able to run homebrew on the Wii Mini just like any other Wii console, without any hardware mods. If you're interested at all in the Wii Mini and its many differences, feel free to checkout some of DeadlyFoez's videos of their efforts. It's a very strange little machine.

Update: During the writing of this article, the exploit was released!.

With the Wii Mini Menu dumped, the main question for us was... does it run in Dolphin?

The answer is yes! In addition to that, Fullmetal5 also adjusted Dolphin to correctly detect Mini Wii Menu versions. While there isn't much practical use for running this cut down Wii Menu in Dolphin, it was exciting to finally see one of the last unhacked pieces of Wii hardware fall. We'd like to wholeheartedly thank everyone involved for their efforts toward Wii hacking and preservation.

With that out of the way, we have a few changes of our own to go through. While the end of the summer was a bit slow, there are still some essential fixes for several popular games and finally EFB Access is working correctly on Adreno devices... at least in Vulkan. Let's jump into August and September's Notable Changes without further delay!

Notable Changes¶

5.0-10780 - Vulkan: Fix EFB Access on Adreno Drivers by Stenzek¶

Over the years, we've had our fair share of grievances with the Adreno drivers. And while the drivers still aren't perfect and there are a few things they they don't support on our wishlist, they have been steadily improving.

Unfortunately, the stigma of the drivers being buggy can often work against us even when they're doing nothing wrong, especially when there's no issue on the desktop version of Dolphin. In this case, Stenzek was investigating a way to do more accurate depth emulation on GLES. While he couldn't quite pull that off due to limitations within the mobile drivers, he did find a bug handling D24S8 textures in the GLES path. This format has a 24-bit depth component and an 8-bit stencil component. Dolphin was previously copying out both components, when really all we wanted was the depth. Once Stenzek corrected this, certain EFB Access effects that used this texture format started working in Vulkan on mobile drivers!

In The Legend of Zelda: The Wind Waker, it's easy to see how the game is malfunctioning. Because the depth test wasn't being handled correctly, the game couldn't tell if anything was blocking the sun or not. Thus, the lens flare would shine through objects as if you were staring straight into the sun. Other games with similar problems should be rectified as well. As far as we know, Vulkan + Adreno should have equivalent support for EFB Access effects to the desktop builds of Dolphin.

Unfortunately, this does not affect the broken EFB Access features in OpenGL on Adreno, and the cause of that issue is currently unknown.

5.0-10852 - JIT64: Fix MCRFS by flacs¶

Four years ago, flacs implemented the MCRFS instruction in JIT64. This instruction moves flags about the result of the last floating point calculation from the FPSCR (floating point status and control register) to CR (Condition Register) so that conditional jumps can be based on the results of floating point operations. Every game uses it to some degree, but it isn't a common instruction so Dolphin just used an interpreter fallback for years before flacs implemented it in our JIT. Unfortunately, we recently discovered that the Super Monkey Ball series was breaking whenever it used the MCRFS instruction.

The most commonly reported issue was that the Monkey Flight minigames present in several of the games would malfunction. As shown in the example above, players would magically collect bananas from across the map with no rhyme or reason. Worse yet, in Super Monkey Ball: Banana Blitz the game would outright crash on the final boss! In mid-August, flacs returned to the MCRFS instruction to see what was going wrong and realized that they made a small mistake when implementing the instruction in the JIT. They didn't set the MCRFS instructions's magic constant correctly, so data that the Super Monkey Ball games were looking for was being deleted instead of being transferred. Whoops. With this fixed, Monkey Flight minigames are working correctly, and maybe some small undiscovered bugs in other games are fixed too.

5.0-10872 - Disable Warning When Launching Unsigned WAD Files by JosJuice¶

WAD files are a format that Nintendo used to store updates for the Wii in the update partition in retail titles. While that may not seem like a big deal, homebrewers and dumpers have repurposed the format as a way to store WiiWare titles, Virtual Console games, and just about any other kind of channel on the Wii in a standardized format.

A couple of years ago while improving IOS-HLE and WAD file support, we added a warning to let users know when they were launching or installing unsigned WAD files. While WAD managers could dump and install these fine on console and they worked in emulator, they couldn't be verified as unmodified. Because there was no reason not to dump them signed, we thought that this popup would prevent users from potentially running improperly dumped software.

Unfortunately, this wasn't exactly how things worked out. By default, many of the older WAD dumpers would dump these titles with the console ID stripped, resulting in the WAD files being improperly signed. These stripped WADs are much more common and there's no real benefit to redumping them with the proper ID. Many users simply wanted the popup removed or disabled. While we did try to wait things out and see if the complaints subsided, the situation was not improving. Thus, as of 5.0-10872, this popup will no longer be enabled.

If you wish to see if your WAD file is properly signed or not, you can check this within Dolphin's extensive verification tab in the game properties page.

5.0-10925 - Generate Screenshot Name with Timestamps by CookiePLMonster¶

As an emulator, playing GameCube and Wii games detached from their original hardware is always the primary purpose for Dolphin, but divorcing these treasured games from their hardware chains opens up lots of other possibilities. Modding, screenshots, exploring their code, and much more! These other features often don't get as much attention, so we like to highlight them whenever we can.

This month, CookiePLMonster brings us a nice little change for anyone working with a lot of screenshots. Traditionally, Dolphin would label screenshots as just the GameID plus an incremental number. For example, the 5th Metroid Prime (GC) screenshot in the GM8E01 folder would be "GM8E01-5". Simple. Unfortunately this leaves a lot to be desired if one, say, has an small SSD as their boot drive and gigabytes of screenshots keep filling it up, so they keep dumping their bazillion screenshots into an archive on an HDD. Each dump has its own "GM8E01-5" and it gets very messy.

CookiePLMonster realized that this would not do, and changed Dolphin to affix the date and time to the end of each screenshot instead of an incremental number. Different screenshot runs are now all properly grouped together, finding out when a particular screenshot was taken is trivial, and no more naming conflicts when archiving! Screenshot collections have never been easier to manage!

All new screenshots will be far, far easier to organize. This doesn't help existing collections but, there isn't really anything we can do about that. Hm? What was that? Delete the old screenshots? No no no, that's crazy, there's still some good stuff in there! They'll be useful someday!

5.0-10941 and 5.0-10943 - Fix Stereoscopy and 3D Vision, and 5.0-10945 - Remove 3D Vision by Billiard and Stenzek¶

NVIDIA 3D Vision support and 3D output in general was an exciting feature. We had a lot of fun with initial support and Dolphin now supports a wide variety of 3D displays. Unfortunately, 3D output doesn't get tested much in Dolphin and the feature has been in a bit of disrepair. We've seen a few reports here and there of things getting broken and a few maintenance patches to fix major issues, but 3D output hasn't really been touched in quite a while. It doesn't help that monitor manufacturers dropped stereoscopy support ages ago, and even NVIDIA 3D Vision, once a flagship option for stereoscopic gaming, has been removed from the NVIDIA GeForce drivers as of version 419.

For our NVIDIA 3D Vision users, we're sad to announce that we have dropped 3D Vision support in 5.0-10945. As a silver lining, before 3D Vision was dropped, Billiard fully restored support and fixed the major problems preventing it from working correctly; 5.0-10943 has 3D Vision support restored to its former glory! Anyone hanging onto 3D Vision should use 5.0-10943 for the best possible 3D Vision experience in Dolphin.

That does not mean Dolphin is abandoning 3D output. All of the other remaining 3D modes have been updated with more fixes on the way. Turning 3D support on and off while a game is running has also been fixed. In general, despite the loss of NVIDIA 3D Vision, Dolphin's 3D support has been modernized to work with the new VideoCommon and should be working better than ever between all of our backends. And these updates help lay the foundation for what's to come.

Last Month's Contributors...¶

Special thanks to all of the contributors that incremented Dolphin from 5.0-10760 through to 5.0-10945!