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

While this is an important subject and people are strongly opinionated around here, my personal main objective as an emulator author is foremost to know what the hell I'm supposed to emulate. A CNROM cart? A TKSROM cart? Or maybe a bootlegged multi-cart with "happy new year" labeled on the board? Obviously, NES cart information is absolutely necessary and where it should go is what's being debated here.

A database taking care of pure ROM files certainly has its uses. It keeps the implementation details away from the user and places the burden on someone else, i.e the db maintainers and emu authors. If something needs to be changed or updated, you do it once and in one place only. The one I personally maintain has surely been handy at times, especially as I can use it to store additional information about a cartridge which the iNES file doesn't have a clue about. Things like exact board used (SAROM/SJROM/SKROM/SXROM), chip revision (MMC1A/MMC1B2) and other things that helps bring up emulation accuracy.

However, as convenient for the user it may be, it's a hefty amount of work and not the most fun thing an emulator author can do - constantly having to keep track of new dumps and whatnot. The reason the database was put to use in the first place was so I could get around the limited design of the iNES file format and deal with some of the common widespread broken ROMs. I never really intended to have the database work as a full-fledged replacement for headered ROMs.

That being said, if an image shouldn't contain anything but pure ROM data it might as well be split into separate files so that PRG-ROM and CHR-ROM data can be distinguished. The full database proposal brings up a few interesting questions. Who will maintain it? What should go in there? Anything under the sun, including homebrews and hacks, or just games that was commercially released when the console was still being actively sold? Anything not in the database would be useless to an emulator since the emulator wouldn't know how to run it. Is that really ok?

Assuming the database thing went forward, here's how I'd answer:

As far as maintainers, the database itself should be GPL or a similar F/OSS license and maintained as a separate project.

What should go in there? I would suggest having separate databases for e.g. Japan official, US official, Europe official, Chinese hacks, homebrew, and so on. Bad dumps should never be added - that's my major beef with the Good* sets.

Is that OK? I'm guessing that anyone still creating NES homebrew is probably closely associated with NESdev and will be able to communicate their needs appropriately.

That all said, I prefer a more distributed approach.

You'd have separate PRG-ROM and CHR-ROM files in a zip (ideally separate per physical chip, but not strictly necessary) and a config file (ini or xml format) which would give the name of the board, the mapper chip details, and so on. IMO that would combine a lot of the advantages of the database and headered approaches.

- It's pretty easy for emulator authors, especially if the board descriptions are compatible with UNIF's
- Anyone can be the maintainer. Someone could pretty easily throw together a utility that used NEStopia's database file to split up current iNES ROMs into the "new" format
- Homebrew authors could easily write their own config file

If I might, I'd just like to throw my two cents on the whole matter.

As stated earlier in this thread, almost all gamers don't really care about the format used for their games, so long as it runs. For now, iNES "works" and they are probably completely unaware of what iNES even is, much less why it causes some trouble with emulation authors, NES developers, and other such people.

If a new format is to be made for better accuracy and technical merit, it should probably get supported in the popular and actively maintained emulators first. To cause as little confusion as possible, this should be done before split ROMs get widely distributed. Some old tools/emulators might not ever support the new format, and when they're needed, there probably would be a relatively simple way of converting to the old iNES format.

Personally, there shouldn't be any intermediate "phase" change by going headerless first. If the goal is to have an accurate way for preserving NES cartridges, there shouldn't be any need for this step. (Especially when the intermediate step might be worse than the final goal, if the new format has an information file containing various information.)

i would go for the .ini/.xml version too

not to mention that, if at a certain point we find out new properties of a board revision (if ever), we should simply spread out a new .xml file (hardly to be considered a copyright infringiment adn clrmame + a dat file could put it in the right place infew seconds) without touching the .prg / .chr

I don't know if that was sarcasm, but I totally support this idea.

I think NES roms sets should be like MAME roms sets.
And the emulator (Nestopia or MESS) should provide a driver.
Then we would no longer need headers.
I am sure the No-Intro Project would support those split sets as soon as Nestopia and/or MESS implement such drivers so we can finally get rid of those headers. We would take care of the dump tracking and database part to ease the emulator authors burden.

http://forums.no.intro.free.fr/showthread.php?t=1418

a database of dumps already exists (look for bootgod)

EDIT: moreover, taking a look at the no-intro thread [1], it seems someone do not understand that you cannot simply remove headers and run images as they are: NES carts have very different layouts, with different connections, and different ways to be read by the console.

the emulator have to know which kind of emulation apply to the image. it's like emulating different arcade PCB, no more no less.

therefore, you have to put these informations somewhere: iNES images put those in the header, we should find another way (either in an external database, or in an additional file inside the set)

in both approaches, it would be anyway kind to let homebrew programs & tests a way in and not be too strictly focused on commercial games: tests often stress edge behaviour of the hardware and help to debug emulation issues. it would be stupid to simply throw them away from the emulation world

[1] I would post there but I had some problems with my password and I still cannot login...

I thought they were searching serious mainteners
And please take no offence but the No-Intro project may be the best choice, if compared to the poor competitors.

don't be offended, but I trust much more that single guy which has verified by itself each cart (dumping various carts just to confirm the validity of the dump), than you guys at nointro.

NES is a more serious problem than GB or FDS: you really have to open the carts and put your hands on the chips, so I would trust someone only after he gave me some technical proof (or if he's guru)

and also TOSEC is able to spread out dats if needed (being myself the maintainer of the NES part )

Take a closer look at what we are doing.
TOSEC is a huge joke.

I think "huge joke" is a bit unfair, but their standards for CD dumping are unintentionally hilarious for sure.