HI, I'm currently reading in the bytes of the NES rom, and I know how to do MD5, CRC32 and SHA1, but I'm not sure what part of the NES rom I need to grab for the data. Is it the PRG + CHR data that I get the checksum from? Can anyone point me in the right direction?
It depends on why you want these checksums and hashes. If you're comparing against some database of known-good ROMs, you'll probably want to match however the database does it: either separate hashes for PRG and CHR, or one hash that covers a combined PRG+CHR.
No matter how you do it, you want to include only the ROM data itself - no headers! (There are still a lot of .NES files floating around with garbage in the 16-byte header.)
Most checksums I've seen for NES ROMs are either (a) The entire file (including 16-byte NES header), or (b) The entire PRG+CHR region (i.e. same as (a) but without the header). I don't know of any which have separate hashes for the PRG vs. CHR -- I don't see how this would be useful when your source data is a single file.
koitsu wrote:
I don't see how this would be useful when your source data is a single file.
I guess it's useful if you dump/backup chips or make reproductions.
NesCartDB gives separate CRC32 values for each chip followed by one CRC32 value for all PRG ROM chips and all CHR ROM chips combined. For example,
After Burner has two CHR ROMs, and
Hokkaidou Rensa Satsujin: Okhotsu ni Shoyu,
Famicom Jump: Eiyuu Retsuden,
Family BASIC,
Action 52,
Nintendo World Championships,
Pinball and
Excitebike have more than one PRG ROM.
Separating them makes the most sense. If you care about the CRC, you care that there are multiple versions of a thing out there.
The header is irrelevant, as it should really always be the same if the PRG/CHR is the same (and commonly has errors or other data where it should have zero padding).
If you're making a patch, it may target a particular PRG or a particular CHR or both. By separating them you will better know which variants are valid for the patch.
Same deal for databases that are trying to discover variants. Knowing only the PRG or CHR is different is helpful.
I disagree about header being irrelevant with regards to the tool the OP is referring to, and can even cite an example where that would result in confusion: romhacked games which have been extended to other mappers, or utilising other features of the header (e.g. original didn't use SRAM, romhacked version does). Rephrased: all 3 things (PRG, CHR, header) must be "in sync" for this to work.
I do see the "overall" usefulness of separate checksum for PRG and CHR, but my overall opinion remains the same.
Hmm, yeah, headers have a lot of problems. It's probably prudent just to include all 16 bytes of the header in any romhack IPS.
Ideally, any romhack would be overriding all relevant parts of the header anyway, and the non-relevant ones should be the same. If the header is incorrect to begin with, though, it shouldn't run... but of course we have some emulators that ignore headers anyway, in which case your patch is boned if the starting header is bad.
For an iNES 2 header upgrade, you might end up with DISKDUDE in fields that you intended to leave as 0. Expecting your users to have an emulator that can correctly use iNES 2 in the first place, though, is yet another problem in the mix.
For example, iNES 2 cannot use the NES 2.0 format. I don't even think iNES 4.2 can use the NES 2.0 format.