Expected unpatched ROM has outdated header

[SmashManiac]

The currently-expected SHA-1 hash of the unpatched ROM is: 77747840541BFC62A28A5957692A98C550BD6B2B

However, this hash does not match any known dumps for the original game: https://datomatic.no-intro.org/index.php?page=show_record&s=45&n=2282

After further investigation, it appears that the expected hash does match the correct base ROM (SHA-1 FD9079CB5E8479EB06D93C2AE5175BFCE871746A), but injected with an outdated header. This should be updated to the fixed header in both the documentation and the BPS patch.

Additional details here: https://nerdlypleasures.blogspot.com/2020/04/the-nes-and-famicom-accurate-cartridge.html https://nerdlypleasures.blogspot.com/2020/04/fixing-nes-headers-and-renaming-nes.html

[kirjavascript]

Every single Tetris romhack lists this as the hash to use; https://www.romhacking.net/games/940/

A different ROM and hash used to be used, but I changed it to this one after lots of people complained that I was using the wrong ROM and should be using the given hash that everyone else is using instead.

Additionally, https://www.romhacking.net/hash/ lists this is a known No-Intro dump, and iNES is not deprecated.

(The reference is No-Intro: Nintendo Entertainment System (v. 20210216-231042))

[SmashManiac]

The website in my original post is the official No-Intro database. They switched to NES 2.0 headers a while ago, which is backwards-compatible with iNES headers.

The reason why Hasher-js returns a match is because it only needs to find one with the base ROM hash.

[kirjavascript]

The community has been using this rom for decades, and in the past when other dumps have been provided instead it has caused problems with people complaining about the header mismatch. Every disassembly uses this hash, every romhack does. When people come across a NES Tetris ROM, it's this file.

What's the benefit for doing this? If I change this it will cause problems, for what reason?

It does not seem like it is worth it.

For people using NES 2.0 you could have a note about the conversion process or provide additional patches for the NES 2.0 header. I don't want to duplicate the number of patches I make though. Having multiple mappers is bad enough.

Maybe the right move is to move away from BPS entirely and just have a website that takes an ines 1 or 2.0 or pal or ntsc rom and does what it needs to with it. Then we no longer need to even specify headers.

[SmashManiac]

NES headers are not part of the ROM data, and do not generally affect ROM hacks or disassembly. A header is actually community data appended to a ROM to document the hardware inside of the NES cartridge. Without this data, emulators and flash carts won't properly simulate the hardware on which the ROM is supposed to run on, causing inaccuracies at runtime, unless they contain a separate database of such hardware data. The real ROM data is the headerless data, which contains the actual software. The only reason a ROM hack would patch header data would be to indicate a hardware change compared to the original cartridge.

As such, while I'm not familiar with the NES Tetris community, I would suggest them to switch to the more accurate header. unless a significant number of players must still rely on flash carts that don't properly emulate the NES Tetris hardware.

That said, I agree that additional patches are unnecessary anyway. In fact, the existing BPS patch seems to work just fine even with a mismatched header, except for a warning during the patching process about said mismatch. I'm not familiar enough with the file format to know if this is always guaranteed however.

There are lots of ways to resolve the patching issue, but at the very least I would document the expected base ROM/headerless hash, and what the expected header data is. Anything beyond that would be nice but unnecessary in my opinion.

Hope that helps! :)

[kirjavascript]

NES headers are not part of the ROM data, and do not generally affect ROM hacks or disassembly. A header is actually community data appended to a ROM to document the hardware inside of the NES cartridge. Without this data, emulators and flash carts won't properly simulate the hardware on which the ROM is supposed to run on, causing inaccuracies at runtime, unless they contain a separate database of such hardware data. The real ROM data is the headerless data, which contains the actual software. The only reason a ROM hack would patch header data would be to indicate a hardware change compared to the original cartridge.

TetrisGYM patches the header data to indicated the hardware change to enable SRAM. The CNROM version patches the header to indicate a change to mapper 3. I'm aware of how header differences have an effect on emulator and carts.

As such, while I'm not familiar with the NES Tetris community, I would suggest them to switch to the more accurate header. unless a significant number of players must still rely on flash carts that don't properly emulate the NES Tetris hardware.

When the community switches, I will start using different patches. I don't think they will though, and I'm not sure you could convince them.

There are lots of ways to resolve the patching issue, but at the very least I would document the expected base ROM/headerless hash, and what the expected header data is. Anything beyond that would be nice but unnecessary in my opinion.

I can document the headerless hash next release. Or make a web UI, I'll see how I feel.

[dailyskeptic]

However, this hash does not match any known dumps for the original game: https://datomatic.no-intro.org/index.php?page=show_record&s=45&n=2282

[SmashManiac]

@dailyskeptic : The data in your screenshot isn't from a database; it's data exclusively extracted from the file you uploaded.

@kirjavascript Sounds good! Speaking of the CNROM patch, it would be nice to document how it differs from the normal patch. I thought it was a Chinese version of the game based on its name, not a reference to the cartridge board. ^_^'

[kirjavascript]

updated readme to contain more info