Sup NesDev, iNES is dead, how do you feel?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Thu Feb 28, 2008 2:43 am

Most people here only talks from a romz0r perspective about the format and in that way I can see why iNES never will die..
But from preservation point of view iNES sucks big time and I'm guessing this is the reason why Marty made his proposal. I pesonally would like to see a more descriptive format intended for preservation of the games/box-art/manuals for future generations when all carts have bit-rots and all box-art/manuals are gone.
Sorry for misspellings, I'm from Sweden ^^

X-or
Posts: 44
Joined: Sun Dec 04, 2005 3:29 pm

Post by X-or » Thu Feb 28, 2008 2:50 am

OP here, sorry if OP post was a little exagerated, it was to get your attention :D

Why this new format with Marty and BootGod in command? Because many in the community want to get rid of that piece of junk called header embedded with the binaries. We wished emulators to be able to run raw binaries without any addition. Besides, this format allows to integrate a lot more infos that any header could, in human readable format.

FAQ:

Q:Which emulator will support that?
A:Nestopia, and hopefully more eventually

Q:Who will maintain the Database?
A:BootGod, so that you never run again a rom with a wrong mapper/herdaer

Q:Are the new roms going to be easy to find?
A:All you need to do is batch remove headers with uCON64. And yes, they will be available rather easily.

bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy » Thu Feb 28, 2008 3:19 am

dXtr wrote:Most people here only talks from a romz0r perspective about the format and in that way I can see why iNES never will die..
But from preservation point of view iNES sucks big time and I'm guessing this is the reason why Marty made his proposal. I pesonally would like to see a more descriptive format intended for preservation of the games/box-art/manuals for future generations when all carts have bit-rots and all box-art/manuals are gone.
But there is no reason the emulated rom cant still be ines (1 or 2), and then you add the exact same zip folder that contains the more detailed hardware description and artwork. ines is good enough for the emulator to play the game, so mapper info shouldn't be lumped in with other info when it just adds complexity. Keeping ines doesn't in any way restrict you from having and preserving those box/manual/label art files. Your new xml could even just say "use that ines rom" instead of "use that bin file" to keep everything backwards compatible.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Thu Feb 28, 2008 3:21 am

X-or wrote:Because many in the community want to get rid of that piece of junk called header embedded with the binaries.
People who consider there to be the One True Thing, with everything else being crap and bad, I want nothing to do with. These people cannot perceive the nuances of things, that everything has problems, and ignore the practical issues. That style of thinking just sucks.
bunnyboy wrote:Keeping ines doesn't in any way restrict you from having and preserving those box/manual/label art files. Your new xml could even just say "use that ines rom" instead of "use that bin file" to keep everything backwards compatible.
But iNES is EV1L!!!11!! We must be cleansed of it! But really, that'd be perfect, because then any emulators which can open iNES files embedded in a .zip would work already.

User avatar
Zepper
Formerly Fx3
Posts: 3220
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Thu Feb 28, 2008 8:15 am

Evil... but it's the format around for many years. :P Personally, UNIF looks fair enough to store the ROM and its properties.

dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth » Thu Feb 28, 2008 9:55 am

MottZilla wrote:What's wrong with iNES? I remember hearing some weird cartridges, which were probably pirate/unlicensed, didn't work with the iNES format cause of weird things they did or something like that. I agree that nothing will replace iNES headered NES roms unless it is backwards compatible. Even then you'll always have to support the old format.
The technical problem with INES is ambiguity. You cannot distinguish between MMC3 and MMC6 (both of which are mapper 4), nor can you disable WRAM explicitly (there's always 8K implied). Some mappers (such as 185) cannot be accurately emulated without additional info which isn't in the INES spec. You cannot declare WRAM sizes smaller than8K, nor can you declare battery-backed CHR-RAM. There's no room for VS system info, and there's no way to identify a ROM as being both NTSC and PAL. Most of these problems (if not all) can be resolved by adopting the kevtris' NES 2.0 specification, but without a reliable tool for performing the update in a database-guided manner, that spec will never go anywhere.

Further problems arise in the way actual ROMs are encoded. Many ROMs have simply bad headers, and those that have "good" headers almost never have the WRAM and PAL fields set properly. Even the battery RAM bit isn't reliable in my experience. These problems wouldn't be an issue if a reliable ROM fixer were available, but AFAIK there is none.
"Last version was better," says Floyd. "More bugs. Bugs make game fun."

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Thu Feb 28, 2008 10:48 am

X-or wrote:Because many in the community want to get rid of that piece of junk called header embedded with the binaries. We wished emulators to be able to run raw binaries without any addition.
Perhaps I'm misunderstanding, here... but from what I've been reading this new format does nothing for either of these. True the header may not be part of the binary file ... but it is part of the entire image package. And when you consider the image is likely to be zipped -- then it might as well be embedded... since, for all practical purposes... it is.

And you won't ever be able to run NES ROMs without additional information. Just as you can't run an iNES ROM without its header... you won't be able to run these ROMs without their descriptive XML files. (At least, not without doing a CRC or hash check or something of that sort)

So I fail to see how this format accomplishes what you were talking about here.
Besides, this format allows to integrate a lot more infos that any header could, in human readable format.
UNIF could be just as descriptive. Perhaps not as human readable -- but emulators aren't human, so that's not really a big selling point in my book. If you want a human-readable database -- make a webpage (like BootGod's). ROM binaries should be just that -- a binary.

I'm looking at this format from a practicality standpoint... and I keep asking myself these questions:

1) does this format make the emulator more functional?
2) Will end users really be looking at these XML files in a text editor?

I certainly don't see #1 being the case. And there might be a few people interested in the #2 feature -- but again those people would (or should) be just as satisfied with a seperate source (like BootGod's site). Either way -- the additional workload that's passed on the emulator here, and the complication involved overwhelmingly outweighs these benefits, IMO.
Q:Who will maintain the Database?
A:BootGod, so that you never run again a rom with a wrong mapper/herdaer
This is what gets me.

NEStopia has had a ROM database like forever... and it's worked well. I was planning on implimenting a database feature in my emu as well -- but stored externally so that it could be modified by others and updated without having to build a new binary.

Here, a text based, human readable format is understandable (and even a good idea). But is it really necessary to gut the ROM binaries, make a new format, and compromise backwards compatibility to do this? Of course it's not. NEStopia has been doing just fine for years -- I don't see why all of the sudden these databasing techniques aren't good enough any more.

KISS. XML is not simple or even easy to work with. Hell, it's not even the easiest text based format for a human to read. There's all this additional complication here... and really... how will anybody be better off?
Q:Are the new roms going to be easy to find?
A:All you need to do is batch remove headers with uCON64. And yes, they will be available rather easily.
More proof of my point.

If a conversion can be done with a tool -- then why can't this conversion be done internally by NEStopia? Why the new format? It just doesn't make sense to me.

Hundred bucks says NEStopia will still even do these kinds of conversions and database lookups even after this new format is supported (because of the large userbase still using iNES ROMs). So really... what's the point?

tepples
Posts: 22055
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Feb 28, 2008 11:15 am

Disch wrote:Perhaps I'm misunderstanding, here... but from what I've been reading this new format does nothing for either of these. True the header may not be part of the binary file ... but it is part of the entire image package. And when you consider the image is likely to be zipped -- then it might as well be embedded... since, for all practical purposes... it is.
Unlike with iNES[1] or UNIF, tools for hand-editing a zipfile and XML files are distributed with all computers that run the Windows XP or Windows Vista operating system.
UNIF could be just as descriptive.
Microsoft, Apple, and Canonical will probably never distribute UNIF tools with their operating system distributions.
1) does this format make the emulator more functional?
2) Will end users really be looking at these XML files in a text editor?

I certainly don't see #1 being the case. And there might be a few people interested in the #2 feature -- but again those people would (or should) be just as satisfied with a seperate source (like BootGod's site).
If the database updates come from a central source, then who updates this source when CaH4e3 posts a new dump or PDRoms posts a new homebrew?
NEStopia has been doing just fine for years -- I don't see why all of the sudden these databasing techniques aren't good enough any more.
If someone actually starts writing NES programming tutorials of the same caliber as the available Atari 2600 programming tutorials, as people are suggesting in a recent topic in the newbie forum, we might get more NES homebrew developers on board. These tutorials will need to specify how the emulator knows what board to emulate. If we want to rely on a database for board identification even more than we do now, what will newbie homebrew developers think?


[1] Sure, you could use MS-DOS Editor in its little-known binary mode to make an iNES header, and I've done that on several occasions. But isn't XML easier than that?

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Thu Feb 28, 2008 12:43 pm

tepples wrote:Unlike with iNES[1] or UNIF, tools for hand-editing a zipfile and XML files are distributed with all computers that run the Windows XP or Windows Vista operating system.
I never said XML would be harder to edit. But ROM Hackers and other people that edit ROMs and headers would (hopefully) be familiar enough with hex editors and other such tools so that on the off and somewhat rare occasion they'd need to actually edit a header in a way that existing tools don't already provide an interface for, they'd still be able to so with minimal difficulty.

Besides.. if you want to talk about editing efficiency... a new format that is completely incompatible with existing mainstream patching systems is riddled with problems. ROM hacking and translation sites (read: huge global communities -- more people care about hacks/translations than ROM databasing) are pretty much driven by IPS submissions -- and IPS simply will not work with this "slap a bunch of files in a .zip" approach.
Microsoft, Apple, and Canonical will probably never distribute UNIF tools with their operating system distributions.
Your point?

A UNIF editor would still be easier to write than an XML parser.
If the database updates come from a central source, then who updates this source when CaH4e3 posts a new dump or PDRoms posts a new homebrew?
Uhh... the site maintainer?

Regardless of what method you use ... any sort of ROM or image database is going to require some kind of central maintanance. Even if the database is a series of ROM images -- you'd still need someone to weed out improper hacks, typod/bad xml files, etc, etc. A flexible format doesn't somehow make the job of quality control and management disappear.

And in the case of a homebrew -- I fail to see why a UNIF or NES 2.0 header wouldn't suffice.

In fact -- for most homebrews, even a basic iNES header work suffice. People complain a lot about its ambiguities, but at the end of the day it really is good enough to get ROMs running. And unless some homebrewer is developing custom cartridges that function differently from existing boards, there's really nothing in a homebrew that needs to be databased in this detailed fashion.
These tutorials will need to specify how the emulator knows what board to emulate. If we want to rely on a database for board identification even more than we do now, what will newbie homebrew developers think?
Right...

Code: Select all

<game name="Shadowgate" system="nes.ntsc" crc="6A1F628A"> 
  <hardware board="nes-tkrom" mapper="4">
     <prg type="rom" size="128k" crc="591364C9" />
     <prg type="nvram" size="8k" />
     <chr type="rom" size="128k" crc="05414DD9" />
     <nmt mirroring="ctrl" />
     <mmc>mmc3b</mmc>
  </hardware>
</game>
It's soooo much easier explaining all of that in a tutorial than it is to explain what "mapper 4" signifies.

But at any rate... how would we be relying on databases more than we do now? I think we'd be relying on them just as much as we do now =P

Regardless... a database is only needed where iNES isn't sufficient. You may grill me for this... but for homebrewing... iNES is sufficient.

The lynchpin of UNIF and this XML format is that it's about preserving the original hardware. In fact, from what I'm reading in that thread, that seems to be the critical selling point here: databasing. In fact, one of the quotes in that thread:
iNES, any version, only cares about giving the people games to play. The goal of the XML-based format is about preserving how the hardware actually works.
This is the key distinction. Preserving hardware information is what a database is for. Getting the game to run in an emulator is what ROM image binaries are for. You're talking about two very different functions, here, and while they aren't necessarily mutually exclusive... combining them doesn't make the database portion of it any easier to maintain... nor does it offer the end user any benefit.

Databasing in a file format isn't really an advantage to homebrewers, ROM hackers, and translators unless they're producing their own custom boards. When you're talking about preserving the hardware aspect of things -- software produced after the fact which piggybacks existing boards doesn't factor in. What good does saying which specific MMC3 version X homebrew game runs on when it never had cartridges produced and would function equally well on any generic MMC3 setup? What's the point of databasing theoretical hardware that never actually existed?

This is one time where the beauty of iNES shines. Strength in simplicity. iNES may be completely lousy for databasing -- I'll agree there. But when you start talking about homebrewing and PD ROMs, you're starting to lose me. I don't see how this new format is of any greater value to that audience.

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Thu Feb 28, 2008 1:48 pm

"Preserving hardware" is a gate/symbol-level schematic diagram or edge-accurate HDL file of ICs accompanied by PCB schematics and high resolution scans, not a useless XML file.

X-or
Posts: 44
Joined: Sun Dec 04, 2005 3:29 pm

Post by X-or » Thu Feb 28, 2008 2:18 pm

kyuusaku wrote:"Preserving hardware" is a gate/symbol-level schematic diagram or edge-accurate HDL file of ICs accompanied by PCB schematics and high resolution scans, not a useless XML file.
Awesome speech!
And where are your "gate/symbol-level schematic diagram or edge-accurate HDL file of ICs accompanied by PCB schematics and high resolution scans" ?

BootGod is the xml author, his name alone justifies it's all but useless.
Last edited by X-or on Thu Feb 28, 2008 2:20 pm, edited 1 time in total.

bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy » Thu Feb 28, 2008 2:19 pm

Disch wrote: you'd still need someone to weed out improper hacks, typod/bad xml files, etc, etc. A flexible format doesn't somehow make the job of quality control and management disappear.
Which should happen with ines, but nobody wants to be the maintainer. Nestopia and other emulators could have fixed roms using their databases long ago.

Disch wrote: In fact -- for most homebrews, even a basic iNES header work suffice. People complain a lot about its ambiguities, but at the end of the day it really is good enough to get ROMs running. And unless some homebrewer is developing custom cartridges that function differently from existing boards, there's really nothing in a homebrew that needs to be databased in this detailed fashion.
Which again could be solved with a maintainer (and probably ines 2). A new board would get a new official number instead of something picked randomly. This new format will already need a maintainer to set what options are allowed in the xml, so nothing is any different.

Until there is a netlist mapper format any custom mapper will be just as ambiguous when described in text or a number. How would the emulator be able to add support by itself using the xml description of a board that does chrram banking and unrom type prg banking with different data bits? If you require a person to add that to the emulator its no different than calling those specs mapper #x.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Thu Feb 28, 2008 2:49 pm

bunnyboy wrote:Until there is a netlist mapper format any custom mapper will be just as ambiguous when described in text or a number. How would the emulator be able to add support by itself using the xml description of a board that does chrram banking and unrom type prg banking with different data bits? If you require a person to add that to the emulator its no different than calling those specs mapper #x.
Agreed completely. I actually often debate this very same topic with a friend on IRC. The format in which the data is interpretted by the emulator, be it in text or binary form, is ultimately arbitrary.

And if it's all arbitrary -- you might as well go with a format that's easy to work with.

User avatar
Zepper
Formerly Fx3
Posts: 3220
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Thu Feb 28, 2008 3:29 pm

Disch wrote:
bunnyboy wrote:Until there is a netlist mapper format any custom mapper will be just as ambiguous when described in text or a number. How would the emulator be able to add support by itself using the xml description of a board that does chrram banking and unrom type prg banking with different data bits? If you require a person to add that to the emulator its no different than calling those specs mapper #x.
Agreed completely. I actually often debate this very same topic with a friend on IRC. The format in which the data is interpretted by the emulator, be it in text or binary form, is ultimately arbitrary.

And if it's all arbitrary -- you might as well go with a format that's easy to work with.
Agreed++. My opinion is to accept new ideas, even if this one (XML) looks controversial. I still believe that UNIF is the best choice, though it needs to be more popular between emulator authors and the community (read: players). So, the users will make the choice.

At any rate, I'm not a player. I'm interested to develop my emulator for accuracy, by analyzing the CPU, PPU, APU... and making it as closer as possible of the NES.

The emulator database is a good idea, but why can't be shared between emulation authors, like a .dat file much like MAME?

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Thu Feb 28, 2008 3:45 pm

X-or wrote:And where are your "gate/symbol-level schematic diagram or edge-accurate HDL file of ICs accompanied by PCB schematics and high resolution scans" ?
My mapper logic is in a folder on my desktop. Where is your emulator that can interpret my Verilog?

Just because bootgod is behind this format doesn't make it smart.

Post Reply