The most interesting part to me is how often emulator development turns into discovering that the original games were doing something deeply strange but completely intentional
I’ve been decompiling for the past (almost) two years, and it’s fun to see the bugs, compiler quirks, programmer superstitions, things that coincidentally work because of compiler behavior not because of correctness, as well as the things modern tooling would have caught that 30-year old versions of GCC hadn’t gotten around to yet.
There were even things I thought I had to manually optimize in the early 2000s that the GCC optimizer was already taking care of in the mid-90s.
There's not really an exact science to it, but manually-optimised code is usually more structured/systematic to make it easier for the human author to manage the dependencies and state across the board, while automatically-optimised code is free to arrange things however it would like.
As an example of the kinds of optimisations that the best human programmers were doing before compilers took over, see Michael Abrash's Black Book: https://www.phatcode.net/res/224/files/html/index.html - you can intuit how a human might organise their code to make the most of these while still keeping it maintainable.
Heh. Today I found thanks to the 9front people that some GB games used carts' sram as 'swap'.
games/gb didn't save the sram in the emulator save files, so upon restoring the snapshot and saving in the cartridge memory you got a mismatch. It got fixed really fast, the emulators are really simple plan9 C compared to anything else.
> All of this just to let Dolphin play online with real Wii consoles in a game whose official servers are since long dead and whose replacement servers have a peak of only 15 concurrent online players.
Knowing there's people out that who have such absurd levels of dedication makes me so happy.
I always love reading the dolphin progress reports. They do a good job of explaining how things work and parsing it out into something easy to understand
Agreed. They've been consistently high quality for the 12 years they've been put out at this point. I'm glad they stopped trying to force them into the "monthly update" mold because so many ended up being like "April/May/June/July Update!"
On the topic of Dolphin progress reports, one of the people who author them has written an interesting blog post on the state of open source emulators and the kind of community problems they deal with: https://emucross.com/rethinking-open-source/
TL;DR if you open source a project prone to hype before you are established with a community, identity, and results to speak for, you risk entitled and uninformed users demanding more than you can deliver. Others may take your half-baked feature branches and release them (to fanfare from users who were able to use it with the exact one game it worked with), taking your credit.
Running these projects ain't easy and the Dolphin team deserves a lot of credit for doing it with a level of professionalism I'm sure many in here don't even see at work. The social work involved in this kind of project should not be taken for granted either.
It's got to be a major struggle maintaining motivation in the face of aggressive and ungrateful users. It's bad enough when they're giving you money, it must be much worse when they're not.
As far as I know it is mostly more immature emulators that struggle with straight out "stolen work" - something tells me the triforce branch is more a matter of "let's get triforce to work and then we can get it working well with the main branch again afterwards"
In the discussion of the Triforce arcade compatibility, there's some discussion of "IC Card" support needing to be implemented, and doing so unlocking a lot of missing functionality.
I think this is referring to the Japanese rail payment cards? I know you can use them on things like vending machines, but from the article it seems like the Triforce cabinets let you save game progress on them too, which would be a great feature I've never seen in US arcades.
> Triforce games can support two types of cards for saving: Magnetic Cards (magcards) and Integrated Circuit (IC) cards. Magcards are cheaper, fragile, and can only survive so many writes before failing. They have the added bonus of having a printable side, where the game can print a player's achievements and more. IC cards are more like old credit cards with a thicker plastic. They weren't printable, but were much sturdier.
It's referring to memory cards. This is the Triforce feature, almost every game on it uses cards for savegames. The arcades you're thinking of almost certainly had a version of Mario Kart Arcade GP - you may just not have played it.
It exists in US arcades. It's a similar concept as an AIME card which you use to authenticate when playing maimai, chunithm, dance dance revolution, dance around, beat mania, etc. Triforce IC cards store data instead of just being for authentication.
I suspect you would quickly attract a lot of the wrong kind of “developers” the moment a financial reward appeared. Especially now that it’s so easy to use AI to make something that looks slightly plausible.
Although I suspect the other sibling comment is the real reason.
Nintendo's lawsuits they won against emulator projects in the past had donation systems as one of, if not the sole main point they drove to win the case.
Dolphin is bringing back support for the Triforce arcade cabinet that was jointly developed by Nintendo, Sega and Namco that was dropped by Dolphin in 2016.
Notably games includes F-Zero AX (not to be confused with F-Zero GX on Gamecube) and Mario Kart Arcade GP 1 and 2.
Though I don't know if you can count it as a "buried lede" if the first paragraph of the article is dedicated to it, with a big clickable banner, haha!
What is the most reliable place for ROMs these days? Is there any sort of checksum that can accompany them to ensure safety? While I trust Dolphin, I don't trust most ROMs.
In all my years of emulation, I've never come across a malicious ROM for a major console.
Dolphin runs its own VM. Obviously anything is possible, but developing some kind of breakout-ROM which would infect the host machine is just way more engineering than I could imagine ever being worth it. The vector is just too complex, and the target (nerds downloading retro games) just isn't worth the squeeze.
Archive.org actually hosts a good chunk of the major Gamecube ROMs. Good luck!
There's tons of options, no-intro, redump, tosec, mame are all doing DAT files with file checksums.
That said, ROMs are basically never a malware vector as they have to exploit an issue in the emulators themselves and historically that hasn't really been seen. Typically malware related to roms happens with files included in the zip archives or by sites offering "downloaders" with embedded malware.
I've had pretty good success with CleanRip https://wiibrew.org/wiki/CleanRip#Wii_DAT_download for acquiring ROM files. With it, I was able to backup my entire personal collection with minimal fuss, and can now enjoy that collection in HD with Dolphin's various enhancements.
For verification you generally want the Redump database, which has checksums for most disc-based console releases. Unfortunately they seem to be offline at the moment, or I'd share a canonical link. Look around for that.
It's been done, the ZSNES and Project64 emulators have both had exploits which allowed a malicious ROM to run arbitrary code on the host. ZSNES is written mostly in assembly so that was kinda asking for trouble though.
The most interesting part to me is how often emulator development turns into discovering that the original games were doing something deeply strange but completely intentional
I’ve been decompiling for the past (almost) two years, and it’s fun to see the bugs, compiler quirks, programmer superstitions, things that coincidentally work because of compiler behavior not because of correctness, as well as the things modern tooling would have caught that 30-year old versions of GCC hadn’t gotten around to yet.
There were even things I thought I had to manually optimize in the early 2000s that the GCC optimizer was already taking care of in the mid-90s.
Have you written about your discoveries anywhere? They sound pretty interesting.
How can you tell the difference between something manually optimized and something automatically optimized?
There's not really an exact science to it, but manually-optimised code is usually more structured/systematic to make it easier for the human author to manage the dependencies and state across the board, while automatically-optimised code is free to arrange things however it would like.
As an example of the kinds of optimisations that the best human programmers were doing before compilers took over, see Michael Abrash's Black Book: https://www.phatcode.net/res/224/files/html/index.html - you can intuit how a human might organise their code to make the most of these while still keeping it maintainable.
Heh. Today I found thanks to the 9front people that some GB games used carts' sram as 'swap'.
games/gb didn't save the sram in the emulator save files, so upon restoring the snapshot and saving in the cartridge memory you got a mismatch. It got fixed really fast, the emulators are really simple plan9 C compared to anything else.
> All of this just to let Dolphin play online with real Wii consoles in a game whose official servers are since long dead and whose replacement servers have a peak of only 15 concurrent online players.
Knowing there's people out that who have such absurd levels of dedication makes me so happy.
I always love reading the dolphin progress reports. They do a good job of explaining how things work and parsing it out into something easy to understand
Right? I started reading them before I became a programmer. I think they helped me learn how to think about the inner workings of programs
I think they're the best status reports I've seen anywhere.
Agreed. They've been consistently high quality for the 12 years they've been put out at this point. I'm glad they stopped trying to force them into the "monthly update" mold because so many ended up being like "April/May/June/July Update!"
What stands out to me is that they explain not just what changed, but why it was hard in the first place
I really thought this was talking about the year 2603 at a glance.
On the topic of Dolphin progress reports, one of the people who author them has written an interesting blog post on the state of open source emulators and the kind of community problems they deal with: https://emucross.com/rethinking-open-source/
TL;DR if you open source a project prone to hype before you are established with a community, identity, and results to speak for, you risk entitled and uninformed users demanding more than you can deliver. Others may take your half-baked feature branches and release them (to fanfare from users who were able to use it with the exact one game it worked with), taking your credit.
Running these projects ain't easy and the Dolphin team deserves a lot of credit for doing it with a level of professionalism I'm sure many in here don't even see at work. The social work involved in this kind of project should not be taken for granted either.
It's got to be a major struggle maintaining motivation in the face of aggressive and ungrateful users. It's bad enough when they're giving you money, it must be much worse when they're not.
I was going to say that I'm glad it sounds like trifoce support is in mainline now.
Because some time ago I had multiple incompatible branches of Dolphin to support the games I played.
I'm not sure it was a half baked triforce fork but it was definitely not as polished as the main branch
As far as I know it is mostly more immature emulators that struggle with straight out "stolen work" - something tells me the triforce branch is more a matter of "let's get triforce to work and then we can get it working well with the main branch again afterwards"
I really enjoy how clearly excited the author is about what they wrote here.
JMC is the goat, I had the pleasure of reporting melee netplay bugs with him and he is just so Inquisitive and interested in everything.
In the discussion of the Triforce arcade compatibility, there's some discussion of "IC Card" support needing to be implemented, and doing so unlocking a lot of missing functionality.
I think this is referring to the Japanese rail payment cards? I know you can use them on things like vending machines, but from the article it seems like the Triforce cabinets let you save game progress on them too, which would be a great feature I've never seen in US arcades.
> Triforce games can support two types of cards for saving: Magnetic Cards (magcards) and Integrated Circuit (IC) cards. Magcards are cheaper, fragile, and can only survive so many writes before failing. They have the added bonus of having a printable side, where the game can print a player's achievements and more. IC cards are more like old credit cards with a thicker plastic. They weren't printable, but were much sturdier.
Source with photos: https://dolphin-emu.org/blog/2026/02/16/rise-of-the-triforce...
Cool! Thanks for the clarification.
It's referring to memory cards. This is the Triforce feature, almost every game on it uses cards for savegames. The arcades you're thinking of almost certainly had a version of Mario Kart Arcade GP - you may just not have played it.
It exists in US arcades. It's a similar concept as an AIME card which you use to authenticate when playing maimai, chunithm, dance dance revolution, dance around, beat mania, etc. Triforce IC cards store data instead of just being for authentication.
Do they accept donations? I couldn’t find anything on the website.
They don't: https://forums.dolphin-emu.org/Thread-dolphin-donations?pid=...
Wise.
I've seen many a fine volonteer project become enshittified because they started optimizing for financial income rather than for having fun.
I suspect you would quickly attract a lot of the wrong kind of “developers” the moment a financial reward appeared. Especially now that it’s so easy to use AI to make something that looks slightly plausible.
Although I suspect the other sibling comment is the real reason.
It's also a smart legal strategy.
Nintendo's lawsuits they won against emulator projects in the past had donation systems as one of, if not the sole main point they drove to win the case.
I think the lede is somewhat being buried here.
Dolphin is bringing back support for the Triforce arcade cabinet that was jointly developed by Nintendo, Sega and Namco that was dropped by Dolphin in 2016.
Notably games includes F-Zero AX (not to be confused with F-Zero GX on Gamecube) and Mario Kart Arcade GP 1 and 2.
This is pretty big!
https://dolphin-emu.org/blog/2026/02/16/rise-of-the-triforce...
There was a thread on it a few weeks ago: https://news.ycombinator.com/item?id=47040524
Though I don't know if you can count it as a "buried lede" if the first paragraph of the article is dedicated to it, with a big clickable banner, haha!
Fantastic! I always wonder if the original console devs would be able to provide bonus insight.
I imagine some of the original devs would be surprised anyone is still digging into their work at this level of detail 20+ years later
If they're still working for the same employer (quite possible with Nintendo), they may still be under NDA.
What is the most reliable place for ROMs these days? Is there any sort of checksum that can accompany them to ensure safety? While I trust Dolphin, I don't trust most ROMs.
In all my years of emulation, I've never come across a malicious ROM for a major console.
Dolphin runs its own VM. Obviously anything is possible, but developing some kind of breakout-ROM which would infect the host machine is just way more engineering than I could imagine ever being worth it. The vector is just too complex, and the target (nerds downloading retro games) just isn't worth the squeeze.
Archive.org actually hosts a good chunk of the major Gamecube ROMs. Good luck!
The breakout engineering to exploit Dolphin has already happened, see for example:
* https://dougallj.wordpress.com/2016/11/13/exploiting-dolphin...
* https://gist.github.com/hthh/502ae16db55612f64d3966769a154c3...
* https://github.com/dolphin-emu/dolphin/pull/4447
Woah! This I was not aware of - that's really cool actually. Hats off to u/dougall.
There's tons of options, no-intro, redump, tosec, mame are all doing DAT files with file checksums.
That said, ROMs are basically never a malware vector as they have to exploit an issue in the emulators themselves and historically that hasn't really been seen. Typically malware related to roms happens with files included in the zip archives or by sites offering "downloaders" with embedded malware.
gstreamer, 6502 code from a NES music decoder, and maybe c64 SIDs would exploit it too.
I've had pretty good success with CleanRip https://wiibrew.org/wiki/CleanRip#Wii_DAT_download for acquiring ROM files. With it, I was able to backup my entire personal collection with minimal fuss, and can now enjoy that collection in HD with Dolphin's various enhancements.
For verification you generally want the Redump database, which has checksums for most disc-based console releases. Unfortunately they seem to be offline at the moment, or I'd share a canonical link. Look around for that.
Now there's an interesting challenge. A ROM that does a VM breakout and runs a command on the host.
It's been done, the ZSNES and Project64 emulators have both had exploits which allowed a malicious ROM to run arbitrary code on the host. ZSNES is written mostly in assembly so that was kinda asking for trouble though.
"... we've identified the touchscreen protocol as being similar to Elo's SmartSet Data Protocol..."
Chuckled out loud at that one. Figures they went for an ol' reliable when they built the arcade cabinets for The Key of Avalon.