CHKSUM = FAIL

[magitek369]

Okay, so long story short, I did a hard-patch of Live A Live, using the latest available translation, but no matter how many options I fool around with using NSRT, when I load up the game it still displays as a bad copy. Now, I know that this isn't uncommon among hacked ROMs, and the game plays perfectly fine, but I've applied patches before without the error, so this is really bugging me.

So anyway, my question is twofold. First, is it possible to fix this so ZSNES will recognize it as a good ROM? If not, then why is it that some hacks will display as good and some as bad? I've only recently gotten back into emulation so my active collection is still pretty small, but I've got Chou Mahou Tairiku Wozz patched and that reads as good. If I'm doing something wrong then it's probably something simple, but I followed the included patching instructions, so I wouldn't think I'd have a problem.

Thanks in advance. Peace.

[paulguy]

The reason different hacks show differently is that the hack author chose to fix the checksum in the header. It's nothing you did wrong, unless the game doesn't work or crashes or something. There are utilities for modifying headers, though nothing comes to mind right away. Back in the day I used some DOS program called SNES Tool or something, but it shouldn't matter.

Also, why are you using hard-patched ROMs and not using zsnes's soft patching? Are these multipart patches?

[magitek369]

Nope, everything works fine; just finished it in fact, great game.

I suppose that the reason that I'm choosing to hard-patch instead of soft-patch is more out of posterity than anything technical. I like keeping my ROM folders as neat and organized as possible, and so I choose to hard-patch in order to avoid unnecessary files junking up my folders.

I guess what I'm asking for then is a know method of fixing a ROM to display as good; like I said, it's not a serious problem, but it is bugging me. I've tried using NSRT but with no luck, so maybe someone could suggest another program. Thanks.

[Gil_Hamilton]

There's no simple way, because there's no good reason to.
All it results in is a lot of bad dumps with fixed checksums being passed around.

[creaothceann]

I guess what I'm asking for then is a know method of fixing a ROM to display as good; like I said, it's not a serious problem, but it is bugging me. I've tried using NSRT but with no luck, so maybe someone could suggest another program. Thanks.

RHDN has the official SNES dev manual, so you can read up on how the internal header is structured. Then it's just a matter of using NSRT (to get the ROM type and the correct checksum), the calculator (to get the inverse) and a hex editor (to enter these two 2-byte values).

[paulguy]

Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?

[Deathlike2]

Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?

I guess, but however...

"game name.sfc" and "game patch.ips" would consume less space, especially since many IPS patches (particularly SMW hacks) tend to expand the ROM.

[grinvader]

Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?

I assume magitek### here removes the clean dump from his romdir after hardpatching (which is fine if he never needs to update the patch, or to use a different combo of patches, and so on).

[magitek369]

There's no simple way, because there's no good reason to.
All it results in is a lot of bad dumps with fixed checksums being passed around.

I'm not asking how to fix a checksum on a bad dump, although I guess the same method of correction could be used. I was just asking why I could apply a patch to ROM X and have it display as good, while ROM Y would display as bad, which paulguy already answered for me. I always verify that a ROM is good before I patch it, and I'd never redistribute something that's already been patched. I keep my collection personal, but if I'm going to share with someone, they can get the ROM and the patch and sort it out however they'd like.

RHDN has the official SNES dev manual, so you can read up on how the internal header is structured. Then it's just a matter of using NSRT (to get the ROM type and the correct checksum), the calculator (to get the inverse) and a hex editor (to enter these two 2-byte values).

I'll check it out, thanks.

I assume magitek### here removes the clean dump from his romdir after hardpatching (which is fine if he never needs to update the patch, or to use a different combo of patches, and so on).

Yup, one game, one file, but I do keep backups of everything around just in case.

[Gil_Hamilton]

You misunderstand. I'm not saying YOU'RE going to do this. I'm saying that's why a tool to do what you want doesn't exist. Because people DO do that.
Which is why the GoodNES ROM auditing tool contains such an extensive collection of bad dumps and glitchy hacks. So people know that they DON'T have a good dump, and this ISN'T an emulation glitch. Or that they DO have a good dump and this IS an emulation glitch.
Sadly, it's had a bizarre side effect, as people decided they need complete "Good sets", and now actively collect all these NESticle hacks and overdumps and corrupt versions and blahblahblah.

SNES emulation is, fortunately, plagued by far fewer of these. Probably because dumping SNES games is SO much simpler than NES games with their slew of bank-switching chips.


Anyways, the point is people DO fix bad checksums on bad dumps, then distribute those dumps. While it's harder now with the PokeGodROMs mentality, it still happens.
So yeah, an app to fix checksums = bad.

[creaothceann]

The hack/translation authors could fix the checksum so that you know if the patch was applied to the correct ROM.

At least until IPS is no longer used...

[grinvader]

The hack/translation authors could fix the checksum so that you know if the patch was applied to the correct ROM.

There are two schools of romhackers in that regard - the "I am producing a perfectly working alternative, thus I release it with a correct checksum as an official localisation should have." and the "Regardless everything else, I'm merely modifying a clean dump. I will let the checksum fail to warn the users of this unofficial modification."

Exact reasons may vary from those, which are simply rough guesses.


Essentially, that means you will find romhackers that find it serios business never to fix the checksum on their patches.

[magitek369]

The hack/translation authors could fix the checksum so that you know if the patch was applied to the correct ROM.

There are two schools of romhackers in that regard - the "I am producing a perfectly working alternative, thus I release it with a correct checksum as an official localisation should have." and the "Regardless everything else, I'm merely modifying a clean dump. I will let the checksum fail to warn the users of this unofficial modification."

I guess that I can understand letting the checksum fail when it comes to minor hacks, and for just that reason; you wouldn't want someone new to emulation to mistakenly believe that the original Super Mario World featured flying unicorns or whatnot. However, if you're going through all the work that comes with making a complete translation then it seems like a simple matter to fix the checksum. I can understand the differing viewpoints on the subject, and it really is just a cosmetic issues, but I have to cast my chips in with the first school. I've seen plenty of translations that open up with a quick intro screen detailing who worked on the project, so I find it hard to believe that someone seeing that would be unaware that it was an unofficial modification, even if the ROM was being distributed pre-patched.

[sweener2001]

plenty don't. argument invalid.

i personally prefer soft-patching, because i like a folder full of clean dumps. saves and translations are stored separately.

[magitek369]

i personally prefer soft-patching, because i like a folder full of clean dumps. saves and translations are stored separately.

Which is exactly why I keep a backup folder of all my emulation downloads.

[PHoNyMiKe]

here's an easier way to do it:

download ucon64 and download the Visual C++ windows version if you're using windows. grab a command line and type in ucon64 --snes live.smc and you should see the header data including the rom name. below that is checksum information, should say Ok on the unpatched rom. if everything looks in place then do ucon64 --snes --chk live.smc it should fix the checksum then display the new header information. if anybody is scared of some good checksums then they can use NSRT to filter it out of their collection.

[magitek369]

download ucon64 and download the Visual C++ windows version if you're using windows. grab a command line and type in ucon64 --snes live.smc and you should see the header data including the rom name. below that is checksum information, should say Ok on the unpatched rom. if everything looks in place then do ucon64 --snes --chk live.smc it should fix the checksum then display the new header information. if anybody is scared of some good checksums then they can use NSRT to filter it out of their collection.

Oh cool, I'll have to check it out sometime, thanks.