Somebody contacted me on reddit in regards to some of my older comments on the platform, and it sort of got me thinking that I write a lot of crap on there and it’s really hard to find stuff I previously wrote on there after the fact, and it could be deleted going forward. If only I had some place on the Internet I could write stuff, and where I could be responsible for it… oh right, that is what this site is for.

I’ve done that previously when I write a big comment since it keeps this blog from becoming completely dead. I keep going to write stuff and finding that I already wrote about it 7 years ago.

In any case, one topic I haven’t algamated my thoughts/information on in that sense has been some considerations with Nintendo and Emulation. So, I thought I’d try to paraphrase what I’ve previously written on the subject here.

Nintendo, being one of the older giants of the Game Industry, is no stranger to not only having their hardware emulated through software, but using the approach themselves. Furthermore, while some argue that Nintendo “aims for quality” as a reason that they seem to drip feed emulated releases, their own emulators leave a lot to be desired in many cases and while arguably playable still give a strong “good enough” vibe.

Virtual Console

Over the years, Nintendo themselves has created and used Emulators. The Virtual Console, of course, is the most obvious example, but it was present before that. Animal Forest (Animal Crossing) used Emulation to allow you/your character to play NES games, for example. Additionally, things like the Ocarina of Time/Master  Quest and Zelda Collector’s Edition discs for the Gamecube used emulation. Some argue that the reason that Virtual Console releases were slow or why Switch Online isn’t adding  lots of games, isn’t just licensing, but because “Nintendo does it right”.

I don’t think that is the case, certainly not in regards to emulation, at any rate. None of Nintendo-developed Emulators are perfect and many of them are a bit hackey. Now, some of them, to their credit, were actually better than available community emulation of the time frame. For example, the Gamecube emulator may be missing things like graphical effects, and there are freezing and hanging issues with both Ocarina of Time and Majora’s Mask, but for 2001, it was pretty much the best you were going to get in terms of N64 emulation for the time. ”Virtual Console” titles sometimes suffer from a strange dark filter, unnecessary blur (some claim this is to mimic a CRT, presumably, those people have never actually seen a CRT before in their life so I can forgive the association), and often copious amounts of input latency. It seems to only be the Emulators that Nintendo outsources that actually work well, such as the GBA and SNES emulation on the Wii U Virtual Console. Unfortunately a lot of their releases that use emulation feel like they are doing “good enough” emulation. “Good enough” used to be an amazing achievement- getting a “good enough” N64 emulator running well on a Gamecube, for example, but nowadays, “good enough” just looks sloppy, when you compare it to community emulators, particularly since if anybody has access to internal documentation about the hardware, it’s going to be Nintendo.

iNES Headers

iNES Headers is a subject that will come up time and time again, and for good reason. iNES was a early NES Emulator which effectively set the standard for the informational format needed for extra data relating to a ROM, and how it should be dealt with to match how the original hardware would work with it (more or less). As well as stuff like if the game requires extra chips to be emulated as well. For that purpose, Marat Fayzullin created the iNES Header format and “.NES” File format for ROM data.

There have been some interesting controversies surrounding this subject. this NESDev Post had one user dump their Wii’s NAND Memory and discover that the Wii Virtual Console NES games used the iNES Header format.

For some reason, this information only sort of "stormed" the world relatively recently, as some youtubers started to pretend they discovered it, and claim that Nintendo illegally downloaded ROMs and sold them. There has been an equal number of silly claims that try to counter it. For the former, Nintendo owns the IP, so them downloading Nintendo ROM files is not copyright infringement nor is it illegal. The most likely explanation is that the ROM files were downloaded and used as-is, by whichever small teams were responsible for the VC. It was probably easier for them than trying to go through whatever process was needed to get the ROM internally. It’s possible they might have used a cartridge dumper too (those usually write headers). In either case, they obviously noticed the header but probably assumed it was actually part of the ROM data (many consoles do include header data in the ROM itself) and so just had the VC skip that header, not realizing it was actually something designed outside Nintendo.

The most interesting argument however is the claim that the reason the iNES Headers existed was because the Sound Engineer of iNES, Kawase Tomohiro, worked at Nintendo. This is not a very well supported claim and it’s still a pretty big stretch. For starters, the attribution that Kawase Tomohiro was the "Sound Engineer" of iNES comes from the iNES changelog. A single line: "Sound support completely rewritten, Thanks to Kawase Tomohiro". This doesn’t make them the Sound Engineer! iNES is a closed source product; Kawase may have offered advice, testing, or reported bugs, but being closed source, he never touched the code, to call him the "lead sound engineer" based on this single line is just silly. For all we know the asisstance wasn’t even related to emulation, but related to the OS implementation- eg he may very well have provided advice/suggestions regarding the best way to use the Macintosh sound libraries (iNES as suggested by it’s name was originally Macintosh-only). The way I see it, with that whole situation, there seems to be two possibilities.

The first is as I mentioned before, where the Wii VC ROMs contain the headers because the ROMs were downloaded from the internet, or dumped using the cartridge-dumper tools, which typically add a header, that Nintendo vilifies so strongly in their anti-emulation content. These headers went unused with the exception of an undocumented feature in the aforementioned Animal Forest that allowed loading a ROM file from a hacked memory card.

Or, The ROMs contain iNES Headers because Kawase Tomohiro, who, a few years prior, somehow single-handedly rewrote the sound code in a single release of the closed source emulator iNES, was hired by Nintendo. His intimate familiarity with all parts of iNES, somehow telegraphed by a single contributory sentence in a single changelog relating to sound support, meant he was now intimately familiar with the iNES header format. As a result, when he was later hired by Nintendo for the emulation work in Animal Crossing, he, despite being completely green to the company, somehow convinced Nintendo to use a pirate-format header for the ROM files, which was therefore slapped at the front of their existing ROM Data that they already had, and after spearheading the effort to use a community-defined header format first used in a community emulator and finally cutting through presumably weeks of corporate bureaucratic red tape to get it approved and in process, None of the games initially made available in the Animal Forest ROM actually use it and it was only used for an undocumented feature allowing you to load ROMs that were injected onto a Memory card. Later, as games were added to the VC, the resounding echo of his influence somehow convinced Nintendo to keep using the iNES header in their internal files even though their VC Emulators completely ignored them. Nintendo, presumably for completely arbitrary reasons, changed their header format recently to something that was similar but different. I’m sure that decision had nothing to do with recent news stories over the past few years about how Nintendo uses a community-defined header in their own files got a lot of media attention (Mind you, like… 15 years after it was first discovered on nesdev after somebody dumped their Wii’s NAND…)

Fact is that the “the headers were added because a staff member worked on iNES previously” has too many holes and raises too many questions and requires too many assumptions to be a reasonable stance.

Have something to say about this post? Comment!