Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I've discovered datomatic as resource for roms, and noticed that the hash values do not match

https://datomatic.no-intro.org/index.php?page=show_record&s=45&n=3375

https://datomatic.no-intro.org/index.php?page=show_record&s=45&n=4835

The root cause is that apparently, the nes 2.0 header is used when hashing the rom files instead of the original iNes header.

Is there any disadvantage making an official release with the never, better (and from what I've read) retrocompatible nes 2.0 header?


Also the vs version has a much nicer menu compared to the "normal" version, but unfortunately it is not possible to disable the hard drop :(


Otherwise great game!

Is there any disadvantage making an official release with the never, better (and from what I've read) retrocompatible nes 2.0 header?

I don't think the hash difference is related to the ines header. I think it's the filename that is "From Below (USA) (Aftermarket) (Unl).nes". When I changed the file name to match that, the hashes match.

but unfortunately it is not possible to disable the hard drop

It would be very easy to hack the game to disable harddrop, but yes, there is no in-game way to disable it. I can't remember the details, but I believe I had players test it extensively on authentic hardware, and unintentional UP presses on the joystick were non-existent (however, obviously that doesn't matter if you're playing in an emulator).

(1 edit)

Hi

Hash values are based on content alone, the filename does not have any importance. Thus renaming the file has no effect. On the contrary, any difference in content will produce a different hash (collision excluded)

The crc32 values I have after downloading the files are

from_below_2020_09_16_v_1_0_0.nes -> crc32: 8ce49adb from_below_vs_2021_01_13_v_0_10_0.nes -> crc32: d1616b88

After manually patching the header with the one described in the database, for example with

printf ‘\x4e\x45\x53\x1a\02\x01\x0a\x09\x00\x00\x50\x00\x00\x02\x00\x04’ | dd of=from_below_vs_2021_01_13_v_0_10_0.nes bs=1 seek=0 count=16 conv=notrunc

I get the values reported in the database

from_below_2020_09_16_v_1_0_0.nes -> crc32: 86e935b2 from_below_vs_2021_01_13_v_0_10_0.nes -> crc32: f0232955

Sorry about that, I think I had my files mixed up and was getting a false positive.


So looking at the header settings in that database, they did more than just set the rom to ines2. They also set 2 additional settings in the header (looking at the NES version, not VS):

NES Database:

4E 45 53 1A 02 01 00 08 00 00 00 00 02 00 00 01

ROM switched to ines 2:

4E 45 53 1A 02 01 00 08 00 00 00 00 00 00 00 00


The "08" means ines2 format. That is all that I would expect to change.

The "02" means "VS PPU Type = RP2C04-0001"

The "01" means "Default input type = Standard Controllers"

I'm not sure why the database has those changes. To me the correct thing to do is update the database to accurately reflect the actual released ROM. To me the actual ROM should be the source of truth. What do you think?

I would have also expected that the hashes would be of the original image, instead of the image with the newer header (https://forum.no-intro.org/viewtopic.php?t=6772).

Which is why I was asking if there where any drawbacks in using the newer format, which seem to be preferred in some environments.

From https://www.nesdev.org/wiki/NES_2.0 I see that the header is backward compatible and provides some new features.