I would like to propose that CNES (and the assembler) NOT support the iNES file format. We are getting a chance here to start with a clean slate, and I would like to take advantage of that opportunity.

I *fully* concur.

-- Theodore Reed (rizen/bancus)

Me too.

I wouldn't really mind supporting the original iNES format, the format the way it was created by Marat Fayzullin. It's the horrible derivative of iNES, made popular by various, mildly insane, emulator authors that needs to be defeated.

UNIF exclusivity is fine by me, though!

Well, we definitately need to include the option to open iNES files, but warn the user that they will automatically be converted to UNIF.

I'm a little weary of auto-conversion to UNIF.

-- Theodore Reed (rizen/bancus)

Perhaps we could create a class of boards INES-### for ROMs auto-converted from iNES format. For instance, a generic MMC3 board (not known if TSROM, TLROM, etc.) could be INES-004.

Um. No. That's contrary to the whole spirit of UNIF. My suggestion is that we use *solely* UNIF, but make a program for conversion, that way people can convert things over and we don't have to worry about allowing iNES in everything else. (It also means that there'll be less iNES ROMs in the end.)

-- Theodore Reed (rizen/bancus)

This project needs to contain some easy automatic conversion, because what about the guy who knows nothing about computers and wants to play (a legally obtained) iNES file? He should have the option to just automatically convert the file, otherwise hes going to end up saying "CNES sucks, it wouldnt play my file, but _nesticle_...now that program rules!". We don't want that.

A legally obtained iNES file is a homebrewn program, and those usually use simple (if any) mappers. Conversion shouldn't be a problem. Or we could just support the original iNES format. Either way, problem solved!(?)

The problem with automatic conversion is that there's nothing keeping them from autoconverting everytime they want to play, keeping the ines file around.

-- Theodore Reed (rizen/bancus)

Additionally, having conversion code in every CNES program would certainly bloat the hell out of it.

-- Theodore Reed (rizen/bancus)

Without having read the UNIF specs (beyond skimming through it many months ago), I don't see the point in it. You have an iNES-format ROM: it will play in any emulator supporting the mapper in question. You don't really *need* any information for the ROM beyond the mapper type, the size of the PRG-ROM and CHR-ROM, and flags indicating mirroring, presence of Save-RAM, etc.

My point: iNES gets the job done. Plus, it's an established standard. You get a ROM: it is in iNES format. No confusion. You download a ROM hack: it's for an iNES format ROM. No confusion. You write a demo: your NES assembler assembles to an iNES format ROM. No confusion, plus no having to bloat it to support UNIF, or worrying that your favourite assembler doesn't support UNIF.

Enter: UNIF. You download a ROM... OK, file extension tells which format it is easily enough. If it's iNES, play it in your time-tested iNES-format emulator. If it's UNIF, play it in a relatively new one. If you're a complete newbie to the whole thing, just getting the ROM is hard enough. Now figure out which emulator you need. You download a ROM hack... oh, it's for a UNIF ROM. *Goes swimming up shit creek (ie., ROM sites) to pick up a copy of the UNIF-format ROM*. My point: introducing a new proposed standard, when there already is a working standard established, creates confusion in a once unified scene. Until one standard eliminates the other, everyone involved has to either accomodate both standards, or focus on one and thereby leave out the other.

However, UNIF can get the job done too. If you guys are so jacked up for it, I suggest that the emulator support both iNES and UNIF. That way, assuming the emulator catches on, it eliminates much of the confusion. You download a ROM: it doesn't matter which format it's in, because your shiny new emulator will play it just fine either way.

As for converting images from iNES to UNIF, I suggest that a separate program be created that deals with this exclusively. It should be a DOS program, although a Windows port wouldn't hurt (and wouldn't block out anyone using WinXP or other non-DOS operating system); for one thing, DOS is better-suited for file-conversion-style operations; plus, for NES developers, you don't need a new assembler with a strange syntax: write up a .bat file that assembles and auto-converts to UNIF in one shot. Voilà!

</rant> Anyhow, that's my two cents on the matter at hand.

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

"Thank you for an excellently reasoned post."
Heh... I figured it'd start a big "debate" or something. Thanks :)

"(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)"

Good comparison. However, GIF had some clear shortcomings (legality issues, 8-bit-only colour, binary-only transparency, outdated compression scheme, etc) that PNG addressed; it was a clear and necessary issue that needed to be addressed. UNIF, from what I can see, only has a clear and necessary improvement over iNES in terms of being more specific with exotic mapper types. I'm not saying that's something that doesn't need to be addressed, but I don't think replacing an established standard just to accomodate a minority of games (most of which are still covered under iNES) is really such a good thing.
Besides, PNG can do more than GIF can. UNIF is basically just a different format for the same thing.

"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."

If you're speaking of a general 6502 assembler, then yes. But, like Assembly itself, some assemblers assemble for one specific platform, and thus aren't "general" 6502 assemblers. For instance, I use NESASM for my NES development. It cannot produce output for UNIF, C64, Apple II, etc., but I think it's a damn good NES assembler. (it could be better, of course, but it does me just fine).

"UNIF has a few features (like checksums)..."

I'm a ROM hacker, and I don't like hearing about Checksums. Unless a program exists / will be written that can look at a UNIF ROM and auto-fix the checksums, ROM hacking (which includes translations, such as japanese-to-english) will be severely hindered were UNIF to succeed in replacing iNES as the established standard.
Of course, it depends on how The Emulator will respond to UNIF ROMs that have bad checksums... if it does like ZSNES does for SNES ROMs (ie., merely mentions it), then no problem, but if it prompts you, or flat-out refuses to play it, that could be a problem. Unless, as I said, there's a tool for ROM hackers to auto-fix checksums.
To avoid defeating the whole point to checksums, I think that that checksum-fixing tool should be created, and that The Emulator should probably give a "This ROM has a bad checksum. Do you want to play it anyway?" prompt when it encounters a bad checksum, so that in the cases of a corrupted file, it won't just brush it off and end up doing something ungood.

"...just random memory transforms that happened to make that game work"

I think the saying "the ends justify the means" is appropriate here. (that is, it works, doesn't it? I'm not saying it was the "right" way to do it- it most certainly wasn't- but it got the job done... more or less).


... anyhow, I'm not opposed to UNIF, I just don't feel that a new format was necessary enough to replace iNES when iNES works well enough. If UNIF were to overtake iNES as the de-facto standard for ROMs, that'd be just fine by me; after all, iNES gets the job done, but UNIF gets it done right. I'm just not looking forward to the transition period. As long as there's gonna be one, it should be made as short and smooth as possible... for a proposed "ultimate emulator" to support both formats will definetely help with that. Most people will probably download this emulator to play their iNES ROMs.. having the emulator also support UNIF will allow the new format to be introduced to them (when otherwise they wouldn't have bothered), so they can judge for themselves whether "the switch" from iNES to UNIF is a switch worth making.

... but if it were UNIF-only, most people who (currenly) only play/have iNES ROMs wouldn't bother with just another emulator for "that strange, different ROM format", and thus neither The Emulator nor UNIF would get the exposure they both need.

I think some of UNIF's useful features could be supported in existing games in a kinda hacky way by getting it's CRC and looking it up in a database that says which games are NTSC/PAL, what controller it uses for input, whether or not WRAM is battery-backed, etc. I think nester does something like this. Didn't RVU or someone make a list like that, or was that just for game genie codes?

I like the extras that UNIF format could allow, like label/box artwork and instruction manuals. That would be kinda cool to see. It's far from necessary, but I think it would entice quite a few people to give UNIF a shot.

I like the extras that UNIF format could allow, like label/box artwork and instruction manuals. That would be kinda cool to see. It's far from necessary, but I think it would entice quite a few people to give UNIF a shot.

Let's not forget line number info for source-level debugging. Mmmmm.

Those extra features are nice - though a emu would need a header info box for them to make any difference to someone using the rom, inaddition unif would be a huge difference over .nes format in my oppinion because of the fact that it reduces excessive mapper numbers cause by more than ines mapper, mapping to real mapper (should also stop wrongly labled mapper roms)(unless its a lazy ines traslation i.e not checked in first place).
Also it should be relatively easy for demo rom authors to translate their own roms as they just sandwich their prg rom + chr rom in a unif header - unless I misunderstand the unif spec.

"I like the extras that UNIF format could allow, like label/box artwork and instruction manuals."

yeah, that sounds pretty cool. if there were some way to compress it all (raster graphics would take up a bit of space, for instance), that'd be hella cool. for instance, do something like what PNG does and ZLIB-compress the PRG-/CHR-ROM and the extra stuff (eg., box art, manuals, etc). that would be worthwhile, in my opinion.

OK, now you're making me like UNIF more. Before, I was like "it's just another format for the same thing", now I see that it expands on the bottom-line format to allow extra stuff. If UNIF were compressed somehow, that would be damn near perfect.

Yeah, UNIF's real win, as near as I can tell, is that it's intrinsically extensible without breaking earlier implementations. I still have some issues with it (using fixed-length strings in something that encodes its own length kind of rankles, but enh).

As for compression, why not just take a bunch of ROM files (of arbitrary format) and run them through a tar/gz library, and let the emulator treat the results as directories? We could call it NEStar and get pun points as well as utility!

actually, I was thinking that PRG/CHR compression would be a major pain in the ass for ROM hacking... besides hacking compressed data, distributing a hack in .ips (or a similar format) would be a pain. A possible solution *could* be to allow either compressed or uncompressed ROMs, and let the emulator (or a separate program) apply the patch itself, by decompressing the ROM, applying the patch, and then re-compressing it.

however, that's a lot of hoops to jump through. Games aren't all that big anyway, so I retract my suggestion to compress the PRG/CHR.

"...it's intrinsically extensible without breaking earlier implementations..."

yeah, that's a good idea.