Thank you for an excellently reasoned post. I agree entirely (not supporting iNES in a proposed "ultimate emulator" because UNIF is superior is kind of like not supporting .GIF in a proposed "ultimate browser" because .PNG is superior).

That said:

Any assembler that *can't* produce iNES *and* basic UNIF outputs (and Apple II program images and C64 .PRGs and Atari 2600 binaries and...) is a pretty poor excuse for an assembler. UNIF has a few features (like checksums) that probably are better handled outside of the program source itself. Linking fully against UNIF takes a fair bit of work on the program's side, and I don't know of any linkers offhand that do it, so yeah, we should do that, and we might as well make it the default.

iNES is a simple enough format that there's no real need for special linker support for it.

The ideological force behind UNIF appears to be that it specifies the hardware itself - the iNES mappers, especially once you start getting in to the higher numbers, stop having 1-1 maps with the cartridge hardware. UNIF information can be acquired by studying the circuit board; later iNES mappers were just random memory transforms that happened to make that game work. (Mappers 0, 2, and 3 are examples of obvious 1-1 transforms; I'm told that mapper 1 is more of a hack.) Any purported "ultimate" emulator will have to read iNES and UNIF because otherwise it will be outperformed on an important compatibility point by FCE Ultra and NESten.

Furthermore, since both CNES *and* FCEU are open-source, *somebody* will get annoyed enough with a UNIF-only emulator that they'll write (or port FCEU's) iNES support in. Properly modularized loading code would let this be a moot point by the time the ROM image itself has been loaded.

--Michael