This is a follow up to the previous post about the leaked official GB/GBA Switch Emulators. Click here to read it if you haven’t.
By any means, as far as my knowledge goes, Nintendo using an EZ-Flash is the least of my concern as an “evidence” of the GBA emulator being fake. That just needs to be said.
Nintendo has used standards made by outsiders like unofficial emulator developers, pirates and homebrewers for literal decades, some of it can even be dated back to the the Nintendo 64, when the original japanese version of Animal Crossing was released, with a NES emulator included inside.
What the developers are doing VS what the lawyers are saying, there tends to be hypocrisy from the company, and I feel it’s safe to say this is pretty much the entire industry in a nutshell.
I’ll try to explain, pretty much everything emulation and retro that Nintendo used from outside that I know of.
iNES Header
I’ll take this time to debunk this once and for all:
No, Nintendo did not sell downloaded ROMs back to you on Virtual Console.
You have probably heard the story that Nintendo uses iNES headers, from a GDC conference about emulation and using this as evidence that Nintendo uses downloaded ROMs to sell back to you.
Nowadays, especially after the gigaleaks of 2020, we can safely say this is not really true. However, Nintendo DID use a standard made by outside emulator developers, but you’ll see there’s quite the logical explanation about it.
But I need to explain what a iNES header is, and I’ll try to simplify terms.
A NES cartridge is basically comprised of two seperate parts:
- Program ROM: Contains the game’s code
- Character ROM: Contains the game’s graphics
The NES accesses both of these seperately and simultaneously, and then, to make bigger NES games, a chip that we call a “mapper” handles access of both seperately in a way that the NES understands, while providing a way to handle bigger sized ROMs. This is really oversimplified, but for the sake of this post, think that for different needs, there are different mapper chips that aren’t necessarily compatible.
The problem is that if you just dump the ROMs from the cartridge, there is genuinely no way to tell what the cartridge is made of from the data you got.
This is where iNES comes into play. iNES is a NES emulator released in 1996, developed by Marat Fayzullin, it is still receiving updates to this very day. This developer had to solve the problem of knowing what kind of NES cartridge information we can get from ROM files, and so he devised what we call the “iNES header”, which acts as a description of the cartridge, and to include both the Program and Character ROMs in one single ROM file for convenience.
The header acts as what we could call metadata, which includes specific cartridge information, including the type of mapper chip used. This is really important information because else, emulators don’t know what kind of NES cartridge it is supposed to emulate.
Yet, you could find ROMs in this exact format inside Animal Crossing, Virtual Console, even the NES Mini and Nintendo Switch Online! What gives?
Well it all harkens back to the N64 era. At one point, Nintendo hired a japanese developer who contributed to iNES’s code, specifically the sound emulation. This person is called Tomohiro Kawase, and you may hear about this person a lot when you dig into the retro side of Nintendo.
Tomohiro Kawase, with help from Hideaki Shimizu, developed the official NES emulator for the Nintendo 64 and many other systems as well. He also used the iNES ROM format while developing it. Why? Couldn’t they just make their own standard?
Honestly, it might just be because it was handy to use, the standard was considered good enough already. You shouldn’t necessarily expect developers to be as strict as lawyers are.
Think of it that way, there’s a double standard: The developer standard and the lawyer standard. They don’t necessarily mesh.
You’d be also surprised how developers can also be very lazy and do things without much thought just because it works fine.
The person has also proven to be familiar with dumping ROMs, which the gigaleak has showed very well, but the gigaleak also got us seperated Program and Character ROM files for pretty much every single NES and Famicom titles, no iNES header to be seen.
A common argument that I saw was that the file is identical to what you find online, which is not really evidence because I could just dump the game myself, and if I do my diligent work, I would most likely input the exact same cartridge information in the iNES header by hand, resulting in an identical file. You can have an identical file from two completely different sources, or more, even.
But what the evidence brings is that, yes, Nintendo has used a standard made by unofficial emulator developers, possibly because of hiring someone who worked on iNES in the past.
The gigaleak also brought the source code of the NES emulator for Nintendo 64, as well as the full source code of the 3DS NES and Game Boy Virtual Console emulators. It also provided a tool specifically made to automate the build of NES ROMs with iNES header from the PRG and CHR ROM files.
For some reason, the 3DS Virtual Console emulator actually comes with a different header standard (and honestly better, even?), it is called “TNES”, which was literally never used again, the Wii U, NES Mini and NES Switch Online still relies on the iNES header format to this day.
So I just want to repeat again: I am confident Nintendo did not sell downloaded pirate ROMs to you in the slightest, there is zero evidence pointing towards that, and clearly Nintendo is one of the kings of archival. However…
Did they download ROMs anyway?
The same may not be said if they didn’t download pirate ROMs at all, however.
That one might get people talking, but please read the entire thing first, because this is very nuanced.
One of the final leaks (so far, that is) of the gigaleaks was brought in 2021, were basically a huge backup of emails from around 2005 and 2006. A lot of them are about the planning of the Wii, but also the development and planning of Virtual Console, in pretty big detail, even.
This is where we learned that the SNES Wii Virtual Console emulator was originally developed by a single person at Nintendo in Japan, Paul Donnelly, who then (forcibly by an unexpected event) passed the torch to Intelligent Systems, who was already making the new NES emulator at the time.
He also trained them to handle SNES ROM hacking for the sound emulation, which at the time, was bypassing Sony’s SNES Audio system for patent reasons, and needed every SNES ROM to be hacked for this.
Anyone can check this if they want, but when you check the executable of the SNES Wii VC emulator, you might find a list of SNES games that are seemingly supported, a lot can have Wii VC Title IDs even, but a lot can also come with lotcheck SNES ROM filenames as well.
The email attachments also include E3 builds of the Virtual Console emulators. So I checked the E3 SNES Virtual Console build… imagine my surprise when I found a bunch of filenames that are definitely lotcheck, but mixed with a lot of filenames really reminiscent of GoodSNES ROM filenames you can find in a lot of ROM sites…
It looks like a lot of downloaded SNES ROMs were used during development of the SNES Virtual Console emulator, especially before the E3 showcase. Does this mean Nintendo could have sold SNES ROMs on Virtual Console?
Well… all evidence in the emails still points to No, they didn’t. We can clearly notice a lot of emails asking for specific lotcheck ROMs, including for games that were downloaded, which suggests that when it’s about the public use, they’re genuinely hellbent on using ROMs sourced from themselves.
But I did notice a lot of paperwork involved just for getting one archived ROM from Nintendo, EVEN from within Nintendo, so I can imagine developers not really wanting to wait and skip parts to be efficient.
But this doesn’t really explain how official emulator developers still have a complete lotcheck ROM fullset if I judge from the gigaleak… it’s a bit hard to have a complete answer, but all evidence still points to Nintendo caring to use officially sourced ROMs on the public side even when the files are literally identical anyway…
Famicom Disk System Disk Format
Nintendo is a bit weirder when it comes to Famicom Disk System emulation, their FDS disk file format is actually different from what we use on unofficial emulators. So why do I even mention this?
Well you can use this as evidence that formats used are really just whatever developers feel like using; but I do want to mention some things about the gigaleak that still shows us that Nintendo is well aware of the outside FDS disk format.
In late 2020, the gigaleak brought us a complete set of master disk dumps originating from Nintendo themselves done in early 2007, including photos of every single master disk. We know they are new dumps they made themselves, because the original master disk of The Legend of Zelda is actually corrupted. This has resulted in every japanese Zelda 1 rerelease to not have the final revision of the game.
In 2016, they actually took the time to use a Famicom Disk Writer Soft Pak, a cartridge containing the final version of The Legend of Zelda, meant for use for the rewritable kiosk, because if you didn’t know, you could buy Famicom Disk System disks, and actually rewrite them with different games. This is kinda ecological, and this wouldn’t be the only service that does this.
Take a guess who dumped the Soft Pak? Tomohiro Kawase, who was tasked by his higher ups to do it.
Now that was just a bit of trivia for y'all, but there’s something else in the leaked contents: A converter called “rdafds.exe”.
This effectively converts between Nintendo’s FDS File format and the unofficial FDS file format recognized by unofficial emulators and viceversa. This is honestly pretty practical even. The readme even suggests the use of PC emulators for testing.
And in fact… we have caught them in the act for using PC emulators before…
WarioWare: Smooth Moves shenanigans
If you don’t know, then I assume you’re a bit confused why I’m talking about this game.
I’ll cut to the chase, WarioWare: Smooth Moves is co-developed by Intelligent Systems and Nintendo, and is pretty known for referencing a lot of Nintendo’s history, more than Nintendo themselves sometimes.
One of the microgames we’ll talk about is the Punch-Out!! microgame.
It’s seemingly just Punch-Out, right? Well when we take the background image on its own, there’s a little bit of a surprise…
Well that looks like an emulator on PC to me, not only that but we can actually tell which emulator it is! It seems to be VirtuaNES emulating Punch-Out, edited to remove sprites in the foreground. Well that’s kinda interesting, isn’t it?
Did they look at other N64 emulators..?
The Wii U Nintendo 64 Virtual Console emulator was developed by iQue from scratch, using the same framework they made for the 3DS Virtual Console. For Super Mario 3D All-Stars on the Switch, all evidence seems to point towards iQue pursuing development of the same emulator, itself supporting even more features especially for real-time hacking.
To my assumption, the emulator was passed to NERD and then became what’s known as Hovercraft for the Nintendo 64 Nintendo Switch Online service, as a lot of code from iQue’s framework has definitely disappeared. (This may be inaccurate according to NERD’s own post on their website.)
Here’s a bit of off-topic trivia for you about the emulator’s features:
Ever since the Wii U, the emulator supported the Controller Pak save emulation but never used it, has unfinished 64DD emulation code, and also contains skeleton code for Transfer Pak support (nothing that would work beyond turning the thing on and off).
A lot of this code stayed on the Switch pretty much as is. But what took my attention was a little bit of completely useless code inside the N64 emulator in Super Mario 3D All-Stars.
Inside, there’s a function about recognizing the N64 game’s CIC chip protection bootcode (you don’t need to know more), and it recognizes quite a few more than necessary. It recognizes the CIC 8303 chip which is the japanese retail 64DD CIC chip.
But then it recognizes the CIC 5167 (0x142F in hexadecimal) chip. Wait… That’s not an official bootcode. That’s the 64DD Cartridge Port bootcode! For more context, these are completely fanmade ports of 64DD titles into a cartridge ROM format by Zoinkity, compatible with flashcarts, how come this is recognized by an official emulator?!
Not to mention but the 5167 identification number is technically useless, and actually a sort of info that’s kinda left relatively obscure, you’d really need to look far to find it… except inside open source N64 emulator code.
The thing about this, is that I feel personally involved. I am the one who added support for this specific bootcode in Project64 and mupen64plus, and included the 5167 information too. So I kinda feel humbled a little bit that iQue may have possibly looked at code that I wrote in other emulators.
Now, the emulator only recognized the bootcode, but actually doesn’t have anything programmed to actually make use of it, so it would recognize and then do not much of anything beyond that.
Eventually, possibly after I talked about it on Twitter, all of the 64DD related code were removed including the 5167 CIC reference, in an update of the N64 Nintendo Switch Online application.
Hagi, the GameCube Emulator
The final very quick blow. Hagi is the GameCube emulator written by NERD and was used for the emulation of Super Mario Sunshine and the port of Super Mario Galaxy in Super Mario 3D All-Stars.
This one is very quick to talk about, because I’ll just mention that the emulator makes mention of unofficial features inside it: The USB Gecko, and Gecko Patches.
The USB Gecko is a device used for debugging code and code hacking on the GameCube and the Wii, it plugs into the GameCard Memory Card slot and plugs into the PC via USB.
Gecko Patches are nothing more than the equivalent of Action Replay & GameShark codes by homebrewers.
Both things are completely unofficial, and yet, Nintendo developers doesn’t have problems using those. Ain’t that interesting?
So obviously, things are always more complicated than just “Nintendo is against the use of flashcarts and unofficial applications” but yet it is fine when their own developers use it, and I’d like to say, it has always been like this. Call it hypocrisy if you prefer, but for me the use of flashcarts inside Nintendo to help emulator development is nothing new.
There’s your post about Nintendo using unofficial stuff ever since the moment they started emulating things.
Addendum Edit: I actually don’t care that much that Nintendo uses unofficial stuff for development, it’s not a big deal to me; but for other people, it is. And chances are, for those who think it is a big deal, they’re not developers.
