Adding iNES headers to the NES dat

[Hiccup]

I think it might be a good idea if the NES dat had iNES headers included somehow. As you probably know, iNES headers are a way to describe some properties of a cart's hardware in a way that emulators (etc) recognize.

Some possible approaches to this (note these aren't necessarily mutually exclusive):

1. Having "Headered" as an alternate format (like Encrypted/Decrypted in the DS/3DS and BigEndian/LittleEndian in the N64 dat)
2. Having a file attribute called "iNES" that would contain the iNES header as hex values, which would appear in DoM and (optionally?) the datfile
3. Including the header as a separate file, a la the Switch "Initial Area" files

[Flashfire42]

I think an alternate DAT for iNES headers like we have the Byte Swapped stuff for N64. The way most ROM managers currently use DATs is they ignore the iNES header when sorting stuff. So an alternate DAT would be best. That way people can have their "Pure" NES roms and others can have their iNES headered ROMs to play on emulators.

[xuom2]

agree with alternate dat...

[Braintrash]

That way people can have their "Pure" NES roms and others can have their iNES headered ROMs to play on emulators.

Or have both, because I value "purity of ROMs" (grinning while typing this) and I also like to play ROMs using my flashcart.
That would be one less headache for me, honestly.

[Hiccup]

Sounds like option 1 (additional format) is most popular, which makes sense as it wouldn't require extra tools for combining the ROM and the header, unlike option 3 (seperate file).

But what do people think of doing option 2 (storing the iNES header in the database and/or datfile itself) in additon to having the additional format? Seeing as the iNES headers may be changing at lot (due to corrections), it might make sense to store those in the database. iNES headers almost certainly aren't copyrighted.

[baldjared]

1+2 is definitely my favourite choice.

1 is best from a usability standpoint
2 more info in dat-o-matic is always welcome with me.

[Flashfire42]

There is constant updates happening to the Dat-O-Matic as it is so I would say having 2 Dats, 1 for Unheadered and 1 for Headered is best. If the Headered Roms require updates or get new info then we add it as it comes in

[omonim2007]

Colleagues, I would like to ask: who, in fact, will be involved in promoting this dat and who will adding info there during it's lifetime?

It will be a very-very ambitious work, but what will be the result? What will this additional dat give you? Header is a very vague phenomenon, there are several variants of alternative files with different headers.

You can take the last GoodNES as a basis, but it is already morally outdated. You can take more modern files in iNES 2.0 format, but why we need to duplicate them in our database, when they already perfectly exist in their original form (in various original forums)?

From a practical point of view, creating such an additional dat makes little sense, but the work will need to be done enormous. It seems to me that you better make a corresponding request to the emulator developers. Let them write their software more correctly, that the definition of ROMs was made correctly without using headers. For Super Nintendo and Sega Mega Drive, a lot of emulators have been working without headers for a long time, everything works fine. Why is Famicom worse?

As for me, I will not devote my time to this dat at all since there is still a lot of other really useful work on DoM (in which you may also be involved ).

[Braintrash]

I believe headers are a crucial aspect of preservation when it comes to some systems.

When they are included in the original data contained in the cart's ROM (Super NES, Megadrive...), no big deal, as they are part of the data and as such will be included. I believe this is beyond any controversy (at least, I hope so).

But with some systems, like the NES, they are crucial. While the original system didn't use headers, instead relying on the game PCB to transparently feed it the right data in the right way at the right time, the emulators needs them to understand how to emulate what the game PCB did.

It is possible to integrate these headers in the emulators, but when something new is dumped, you need to wait until the emulator is updated before you can use the new dump, which is why it is considered more practical and universal to include the headers to the ROMs. Even Nintendo uses headers on the ROM they use on their own emulators.

Also, part of preservation is to be able to play the games. A good ROM dump that can't be playable is still a good ROM dump, but it also is halfway preservation.
(Note: I understand No-Intro is about data preservation, not emulation, but still: both work together in the case of preservation.)

As such, yes, having two DATs would be a very good compromise between the ones that want to only concentrate into pure data preservation (which is not a bad thing, as it is the basis that allows anything else) and the ones that want to also be able to use that preserved data in a full preservation perspective (ie. having perfect data and being able to use it).

Now, I also understand this is a large work that would need someone dedicated to it. If no one wants to do it, then I am willing to volunteer.
I am not a DATer, but I am willing to learn (I will eventually learn, so learning through a real world project would make better sense) and I like work to be properly done.

[Hiccup]

I think the first step would be to work out the the rules for creating iNES headers. Should they be taken from existing iNES header sets/databases, or from bootgod's NesCartDB, or maybe from the NES dat itself (from PCB serial transcriptions? I guess chip serial transcriptions may also be needed, but there are less of those in the database and I don't think they are necersarily standardised/machine-readable). Also, there's the question of if a single cart can be represented in more than one way in an iNES header - if so, then one way would need to be chosen over the other, and that decision should be written down as a "rule".

[KingMike]

From a practical point of view, creating such an additional dat makes little sense, but the work will need to be done enormous. It seems to me that you better make a corresponding request to the emulator developers. Let them write their software more correctly, that the definition of ROMs was made correctly without using headers. For Super Nintendo and Sega Mega Drive, a lot of emulators have been working without headers for a long time, everything works fine. Why is Famicom worse?

Because Famicom/NES has about a bajillion mappers. Something that didn't come up until a couple years into its lifespan, but after it did, nearly all games after that used them. Completely incompatible. Also has either vital info like screen memory mapping and ROM/RAM size. (ROM size being important because unlike other consoles NES ROMs can be split between two chips that can be mapped to two rather functionally independent processors. And it has been proven there's a few games which don't work due to the assumption it's safe to emulate having cart RAM for all games. That was another thing, it was common for NES games to put RAM in carts and NOT use a battery to save it.)
SUPPOSEDLY there was an internal header format Nintendo introduced somewhere in its lifespan, but both lack of adoption and lack of sufficient info made it useless. Like it would specify if a game contained "a MMC" but not WHICH.

So, in essence, the other two consoles had internal headers, with less vital information, in an often (but not always!) reliable format.

[xuom2]

adding data never hurts, even if "useless" data for some opinions. everything can be filtered at any time.
of course, a set of rules is needed as Hiccup said and, as always, a datter in zombie-mode is needed to add this huge set of info. I see that generally both elements are rare in the last times...