nesdev.org

I have a NES game that has two variants, MMC1 and a UNROM variant. How will these be listed in the database? That will cause some clutter and confusion. two separate entries, of course. I'm thinking, what if we distribute a bad ROM and it's not until later it's discovered when it's been spread arou...

Agreed. So if the primary goal is verifiability/preservation, then how about a zip container containing (only) prg and chr, with a simple database mapping mechanism. No match, no go. Homebrew, etc. stick with iNES (or iNES2 or UNIF). That's what MESS currently does. Except that I'd like to add home...

Granted I don't use MESS, but I haven't seen MAME pack XML with ROM sets. Even if it has been done for a year, that's pretty much a blink of the eye; I, like a lot of other people probably, don't really follow either project. we don't pack xml with roms, and I have said that, but you can get an xml...

The ZapFC checksum is a hash of two hashes, so you still have the same problem. that's why in my opinion it would be smarter to keep the two files separated and zipped up in a single archive Anyway (and I'm reluctant to even post in this thread, considering FitzRoy's reaction to any criticism), I j...

@etabeta: Yes, I'm aware that this approach is very much like how MESS works without the overhead of XML. I use tab-separated files at work because XML is so bloated. as I said, there is always space for new approaches, and better info can only improve the overall quality of all the databases (as l...

The format is now flexible enough to not only suit every NES game but it can suit every console and coin-operated game, all through a single auditing and management tool only understanding one format. Theoretically all platforms could use a consolidated database as well, but the DB's flatness would...

FWIW, info about game pcbs has been collected by various sources. e.g. in the MESS xml list I advertised here last summer [1] http://nesdev.com/bbs/viewtopic.php?t=6558 (xml file can be found here: http://git.redump.net/cgit.cgi/mess/tree/hash/nes.xml ) and fwiw split files (PRG+CHR) are floating ar...

concerning the original topic, I plan to try some more work on the xml thing around the end of the months, if my real work permits it. I'd like to discuss a bit more with bootgod before, though... too many things to do and no time to do them all :( From discussions with MAME people I have had it see...

After searching a little bit, I do have the first one. But I need to re-read the thread to see exactly what needs to be tested the current emulation problem is that text in the ending sequence is screwed. I guess pictures of the ending sequence on the real hardware could at least confirm how the ga...

Anyhow, my personal belief is these files should not contain only ROM data. It should contain information allowing complete emulation, including things that would be known about the game if you owned it. Such as whether it's 2 player, coop, etc, because these things affect the actual playing or sel...

this is exactly the kind of discussion I was hoping for, so don't worry about sidetracking (only the nss talk was a bit off ;) ) about jumpers and registers, there is basically no example that I could use when I started with this xml thing [1], so I looked for the solution with less impact over the ...

In that comment on my site you are quoting, I am advocating for storing layout information in the XML file. The XML file can specify boundaries within the file (via offset= and size=) to map data anywhere. You can even give each section a "chipid=" field to store what you would have in th...

No offense man it's just that all this stuff could be figured out with a internal database inside the emulator which IIRC, One emulator does that. no offense taken. still, if you go to the route of the internal database, then iNES headers really becomes useless and info can directly go in the db it...

Back to splitting files apart again. All I can say is you better stay away from the SNES scene with that nonsense, you've already ruined NSS :P if you would look closely, you would notice that we already ship a snes.xml list, but no split files have been added... wonder why? because it's not strict...

In other words, this is research/an experiment in another way of representing NES cartridges digitally. The results of this will help anyone in the future considering a similar approach. Maybe it won't pan out for some/all uses, but it will provide actual experience. exactly. + the fact that it's n...