search

0ldsk00l / nestopia

Cross-platform Nestopia emulator core with a GUI
http://0ldsk00l.ca/nestopia
GNU General Public License v2.0
684 stars 167 forks source link

Using an External XML File Creates an Error? #397

Closed P0W3 closed 1 year ago

P0W3 commented 1 year ago

When I used the XML file in the "Image DataBase" section Nestopia, it creates an error. How can that be an error? image image

Nestopia UE (v1.51.1_win32). image

rdanbrook commented 1 year ago

Can you post a diff of that XML file and the original one from this repo? There might be some syntax error, but I can't really tell from the details here. Or maybe it's not even derived from the one in this repo. Either way I am gonna need more details to point you in the right direction.

P0W3 commented 1 year ago

So, the NstDatabase.xml file worked, but the other two XML files are what creates the error. NstDatabase.xml_2022_11_02.zip Nintendo - Nintendo Entertainment System (Headered) (Parent-Clone) (20221220-104001).zip Nintendo - Nintendo Entertainment System (Headerless) (Parent-Clone) (20221220-104001).zip

rdanbrook commented 1 year ago

Ok, now everything makes sense. Those XML files are not meant to be used with Nestopia, they are for something else, maybe some ROM manager. There is no info about mappers, input devices, or what have you, just checksums, titles, and filenames. If you look at the contents of NstDatabase.xml you'll see a lot more details in there. The XML database is there to cover cases where the mapper and other header information is not enough to emulate the game properly, or is just plain wrong. The database allows things to be overridden to make a user's life easier, and can also be used to give hints about what input device to use.

By the way, I made this program to view and modify headers: https://github.com/0ldsk00l/cirugia

P0W3 commented 1 year ago

Ok, now everything makes sense. Those XML files are not meant to be used with Nestopia, they are for something else, maybe some ROM manager. There is no info about mappers, input devices, or what have you, just checksums, titles, and filenames. If you look at the contents of NstDatabase.xml you'll see a lot more details in there. The XML database is there to cover cases where the mapper and other header information is not enough to emulate the game properly, or is just plain wrong. The database allows things to be overridden to make a user's life easier, and can also be used to give hints about what input device to use.

By the way, I made this program to view and modify headers: https://github.com/0ldsk00l/cirugia

Here is another issue that I have experienced.

When I inserted the NstDatabase.xml file in Nestopia UE (v1.51.1_win32), and I put an unheadered ROM in Nestopia, this error message popped up.

image

rdanbrook commented 1 year ago

Yeah, headerless ROMs are unsupported. It is also a terrible idea. I have been very vocal in the community about this issue, because it just creates headaches for emudevs and users alike. The rationale behind distributing concatenated PRG and CHR ROMs as a single file with no header to make them "cleaner" is flawed, and the better way to go about this is how MAME did things, which is to separate PRG and CHR ROMs into separate files and require a database or manifest (and this same method was done with bsnes/higan). The drawback to this method is that hacks and homebrew become a pain, because a database entry will need to be modified every time a change is made if you use checksums, or the user will be forced to specify mappers and PRG/CHR sizes before loading. Manifests are arguably better here because you don't have to deal with a checksum changing necessarily, but what is certainly not good is mashing together PRG and CHR ROMs with no further information.

To make a long story short, iNES and NES 2.0 headers are the way to go, and I don't support a misguided attempt to make NES ROMs "clean". If you want them "clean", go with the MAME solution.

P0W3 commented 1 year ago

This is the unheadered ROM that I was referring to.

CRC32: FB98D46E

The same CRC32 checksum is in the NstDatabase.xml file.

But, okay, I already get what you are saying. Even though, loading an unheadered NES ROM (not to mention the unheadered FDS ROM) is a pain-in-the-buttocks.

rdanbrook commented 1 year ago

Yeah, if the emulator doesn't recognize the file type based on the existence of some kind of header, it doesn't even look at the database, just flat out rejects the file. With all the above being said, I am open to the idea of supporting MAME style ROMs if someone else wants to write that code :). It would involve being able to read the MAME database file and handling the ZIP file extension differently, but probably doable.