Home Page Forums Other Emulator Message Boards Nestopia Internal Database and Headerless Rom Support

As long as the database would be still compatible with headered images, I'd be willing to support it.

Although I like some of the ideas here, I personally still want to give iNES 2.0 a chance. iNES 2.0 has the advantage of being able to work on older emulators, while the database idea does not.

Plus, having headers will give the emulator something to fall back on. If info for a particular ROM in the database is missing or incorrect, it would have the header to rely on. But if the ROM was headerless, the ROM wouldn't run.

So basically, I support a compromise between the two.

Older emulators can use headered ROMs. If there's really a demand, they'll be kept available (just as you can still get MAME 0.36final sets). I see no need to retard current ones just so morons can keep using NESticle though.

I love this world because is large enough for both the approaches.

You can continue with your plan to rule the world of emulation, and I can continue to trust bootgod and the pages he puts up showing how he opened ten different copies of the same cart just to check the layout and the contents of the chips.

You can continue your holy war against homebrew and test roms and I can continue to rename them for TOSEC (even if for test rom is a shame not to catalogue sources and readmes... I will find a solution...)

Of course efforts by other guys are welcome (and bragalad and polarz and others already contributed to bootgod database), but I continue to trust single person more than "projects" (for the same reason I would criticize single dats from TOSEC rather than the project as a whole, single changes to MAME rather than its value as a whole etc.)

anyway, I'm leaving for a week, so keep up the discussion: I'll try to check the thread when I can

If a rom didn't run because of an entry error or because it was too new, it would probably get noticed and fixed fairly quickly. Such a fix wouldn't require any action on the part of the user other than staying up to date with the emulator. Header errors are less practical for the typical user to fix.

As for what should be included in the database, I think that the emulator db should stick only to licensed material which was commercially available. Third party dbs could extend this by providing a db with betas, test carts, and pirates. Hacks/translations are infinitely creatable and are modifications of already databased material. Is there a patch format so that the patch stays separate of the rom? That would solve some things... like, you want to play a translation, you name the patch the same as the other roms, put it in the patch directory, and turn on an option, and nestopia detects it and soft-patches the original rom(s)? Nobody actually needs the thousand separate mario hacks just because GoodTools collects them. I think the soft-patch functionality would be sufficient for actual users, even if it means manually renaming and moving some things to get it working (as described in patch readme).

Are 16 bytes really that scary? Is the desire to force headerless ROM images on the world just driven by a few individuals' concept of what's "right", regardless of pragmatism?

Also, I think identifying file types by file extension only is...dirty, but maybe that's the same type of idealism the anti-header people express.

definitely

That's basically the same as what we have now: decentralized metadata. I mean, there's no difference between this and the UNIF format with its sections (info, PRG, CHR) in separate files.

Mednafen: depends on your view of the purpose of emulation. There's nothing wrong with the status quo if your only desire for it is to play free games. If you actually want your grandchildren to be able to see and understand NES games, then we need a better archival format. (Similarly, it's important that the GNU Radio guys get NTSC decoding working so there's some way to show the output of real hardware then). The fact that emulators have to second-guess the header info currently to achieve max compatibility is just silly.

hap: I personally like the UNIF format, and I'm OK with it even for archival purposes, but it doesn't seem to have taken off despite fairly wide support in emulators. I'm not sure if it's just inertia, or that nobody knows about NEStopia yet, or that nobody powerful on NESdev is pushing it the way they are iNES 2.0.

There is a difference. In UNIF, you're still dealing with a header-like format that works on a per-ROM basis separate of the emulator. Once again, to effectuate changes is far less practical than a single database file included with the emulator. I think that UNIF could serve a nice secondary purpose in the presence of a database because it could become a requirement for infinitely creatable material not in the database (hacks, homebrews, etc). If Marty and other emulator authors got together and defined a database format that they could all use and that users could edit, we will have simplified emulation and removed a dependency and complexity that really doesn't serve much of a current purpose other than to annoy verifiers and make people dependent on GoodTools.



What's most interesting about this statement is that you make it appear as though the world is against removing headers while a few nutjobs are supporting it. In reality, the vast majority of users just want their games to work, a small group of people support (retaining) headers and a seemingly larger group of people support getting rid of them to some extent.

I'm one of those people that believes that emulation is "not" just about the masses who want nothing more than for their games to work. The people who have a passion for the systems and take the time to learn about how they work, write emulators, or dump games and record their checksums, are probably mostly in agreement with a change in the way roms are stored and emulated. In that regard, yes, I think it's scary that complacence could affect the outcome of this.

EDIT: Somehow, I forgot a "not" which really helps with what I was meaning to say...

Have you considered the fact that some game revisions are equal when it comes to ROM contents, but have a different hardware configuration? It's impossible to include that in a universal database using ROM checksums as private key.

No, Belmont suggested a "per-ROM" solution, but stored in a much cleaner way than say, iNES. I think I have to agree with him that iNES 2.0 is not a good solution for accurate archival purposes (even though it would make every game playable).

prg+chr+xml would probably be the way to go for me - you could put that easily in a container format.
The XML would work as description how to access the game: Storing information that would otherwise to be guessed:
board name, mapper info, wram, prg size, chr size, developer, publisher, release... well any information you could probably want in there. That is up to those who actually have the info

Of course this information has to come from a trusted source. If everyone could mash half-way working info together, it is nothing better than iNES - just more "modern".
BootGods webpage is a very good example how things can work - every information is backed up by pcb scans. Its only drawback is that the information is not in an "easy to use" format for emulators.

In the current no-intro set there are like 150 unrecognized games. But without the actual pcb info there is no way to tell which mapper they should have. (In the past it was trial and error - try all mapper numbers until one works and use that)

Btw - what speaks against a MAME-like approach with verifying the roms? Nestopia does already warn you if you have a bad dump...