NES Headers

[BezPowell]

I've extracted some Nes ROMs from various game packs on Steam, but have been unable to verify any of them using the no-intro dats. Some searching across the web suggests that there can be a problem verifying Nes ROMS due to varying headers.

Has anyone managed to get Nes roms working, and if so could you give me some pointers on how?

Thank you.

P.S. Mainly interested in verifying the ROMs that come with the Namco Museum set, but would also like to get some of the Castlevania sets eventually.

[optyfr]

There is currently no header check in jrommanager, this was planned but never done, this would slow down checking : we can't take into account the CRC from zip file entries and need to unzip each file to verify if there is an header and if yes, read the remaining data to get the real non headered CRC). I can't guaranty it'll be done one day... anyway, some information about your case :

• no intro dats crc values are always for rom without the header
• there is fortunately only one header type for NES, it's iNES format, which is always 16 bytes long
• the header start with the ASCII word "NES"

So to check if your roms are valid ones, just open some rom files with notepad and see if the NES value appear at start of file. If yes, then remove the first 16 bytes (can be easily done using tail or dd commands on linux) to new files and check against the non headered files copy

[BezPowell]

I'll give that a go, thank you.

[jumafuse]

The thing with the headers with some systems is a problem with all rom managers.

Al alternative is to not assume zip crcs are correct and build a cache with crc, this allows to keep the crcs with and without headers on the cache but also means a slower initial scan.

Thankfully systems with these issues are so small that take seconds to scan anyway.

[optyfr]

JRomManager indeed uses a scan cache, except that it's not for extra headers on single files, but for SHA1 and MD5 checksum on archives entries (even on CRC it's faster since we don't open archives at all)

[jumafuse]

Maybe with a database of well known dats would be easier to annotate additional information on them, maybe just a json file next to them indicating: { system : "NES", headers : false } So when building the cache the scanner knows is a NES dat and if finds that the file starts with a NES header strips it to do the hash instead of taking the one found on the zip.

The alternative would be to add these features as options, what means more views and JRomManager already have too many,.

So I would suggest convention over configuration to reduce the amount of views.