I really find articles like this fascinating, and have a great respect for the pure engineering effort that goes into emulating these other devices.

Having been a web dev for 10 years and now Deep Learning / ML, I've never even dabbled in emulators or even read their code, and I find it inspiring that there's entire fields of programming that I know little about and can explore later.

Our field is truly amazing!

The dolphin devs have a ton of neat articles on their blog. Really fascinating.

> Having been a web dev for 10 years and now Deep Learning / ML

As a 15-year web dev- was that transition a natural one? Relatively easy? Profitable?

Finding a job or project that involves both web dev and another discipline and slowly sliding into the other discipline is a good way to transition, especially if you are older or with less free time.

I was able to transition from web dev to aerospace software while taking care of a family.

"Having been a plumber for 10 years and now a quantum physicist"

> Wii games don't have to do any of this - they have full access to the 64MB of MEM2. This means that Dolphin doesn't have to worry about MMU emulation in general. As with any great rule, there are some exceptions, such as games that are purposefully trying to break Dolphin. Those games will be covered in another article as they seem to particular target Dolphin's weaknesses and thus some of their behaviors doesn't actually make sense for the source hardware.

Boy I want to read that article

Those games were briefly covered in this older article: https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-rep...

> In basic terms, Disney Infinity and Cars 2 do a very specific amount of writes to lower MEM1, where a lot of really important data is stored. But, it writes just enough that the CPU doesn't flush it to MEM1; it remains in the CPU L1/L2 caches. It then tells the CPU, nevermind and invalidates the CPU cache. Thus, even on a hacked Wii this would do exactly nothing; it's specifically targeting a weakness in emulators.

> Emulating the CPU cache in Dolphin would likely slow-down Dolphin by a factor of ten or more. While we prefer not using hacks to "fix" games, we found it to be permissable in this case due to how specialized of an issue it is. Even if the L1/L2 caches are implemented in the future (which is definitely a possibility,) it will likely be something only used for testing, and thus this hack would remain so that people could actually play these two games. It's a compromise, one that no one is entirely happy with, but the game behavior necessitated it in this case.

Given that they know this, couldn't they patch the games themselves instead?

Where these games actually developed with this purpose? Did doplhin existed back during the game's dev cycle and the developers say "we don't want our game on the dolphin emulator"? Or it just happens that they use an approach that is problematic to begin with?

Since Dolphin emulates two generations of console, it definitely was around and well-known for the development cycle of later games. The first version of Dolphin was released in 2003, and the Wii was released in 2006.

it is worth noting that the three titles mentioned in the article are all Disney properties (Cars, Toy Story and Disney Infinity).

I'm a simple man, I see a new dolphin-emu.org article, I click it, read it, am fascinated by it and feel slightly smarter afterwards.

I would have thought that the GameCube would be the last Nintendo console to use a fixed-function GPU. I was very surprised to see that the Wii used one as well.

Not only were they both fixed function; they were in some very real ways the same GPU. Like bug for bug compatible. Like in a lot of the official Nintendo docs, they didn't even bother to sed s/Dolphin/Revolution.

Honestly a Wii really is an upclocked GC with a coprocessor stapled on the side handling new (and a lot of old) I/O.

They even included the same GPU again as the GameCube/Wii in the Wii U for backwards compatibility purposes. It's honestly a very nice GPU, and team that made it went to go on to dictate the architecture of the PC GPU for the next six years.

For a chip made in 1999, they certainly got their mileage out of it.

Quick clarification for anyone reading: they included the same GPU in the Wii U in addition to a more modern AMD GPU used for native Wii U games.

In many areas the Wii was just a GameCube with a clockspeed bump and weird controllers.

You could even run GabeCube games on the Wii, and it didn't require Nintendo to ship almost an entire GameCube on the board like Sony did with PS2 emulation on the PS3.

Although reading this article I wonder how Nintendo handled the ARAM situation and the like on the Wii when playing GameCube games?

> Although reading this article I wonder how Nintendo handled the ARAM situation and the like on the Wii when playing GameCube games?

The hardware could choose to use the bottom 16MB of MEM3 as an ARAM equivalent. That was actually the source of one of the first attacks. That is putting tweezers on that RAM chip, shorting the address lines and accessing the high part if that RAM while in GameCube mode.

Aha! Team Twiizers (early homebrew devs) makes even more sense now

For those interested: https://hackmii.com/ is still up and has a lot of interesting notes on the Wii.

Can we please fix the weird caps in the title? I spent way too much time wondering what a 'Wii More' was.

Great read. I wish I had the time to mess with this sort of stuff as a hobby.

I wonder why so many exclamations in the article. It's like they want to emphasize too! many! phrases!, a lot of them not really merited!

I guess it's just a byproduct of too much WhatsApp / IM in general, which introduces bad practices for long form writing, and also a lack of editing review.

That's a minor, minuscule annoyance in an otherwise very interesting article :)