CHKSUM = FAIL
Moderator: ZSNES Mods
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
CHKSUM = FAIL
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.
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.
Re: CHKSUM = FAIL
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?
Also, why are you using hard-patched ROMs and not using zsnes's soft patching? Are these multipart patches?
Maybe these people were born without that part of their brain that lets you try different things to see if they work better. --Retsupurae
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
Re: CHKSUM = FAIL
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.
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.
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
Re: CHKSUM = FAIL
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.
All it results in is a lot of bad dumps with fixed checksums being passed around.
KHDownloadsSquall_Leonhart wrote:DirectInput represents all bits, not just powers of 2 in an axis.You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Re: CHKSUM = FAIL
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).magitek369 wrote: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.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
Re: CHKSUM = FAIL
Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?
Maybe these people were born without that part of their brain that lets you try different things to see if they work better. --Retsupurae
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Re: CHKSUM = FAIL
I guess, but however...paulguy wrote:Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?
"game name.sfc" and "game patch.ips" would consume less space, especially since many IPS patches (particularly SMW hacks) tend to expand the ROM.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Re: CHKSUM = FAIL
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).paulguy wrote:Isn't "original rom.sfc" and "patch.ips" the same amount of files as "original rom.sfc" and "patched rom.sfc"?
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
Re: CHKSUM = FAIL
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.Gil_Hamilton wrote: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'll check it out, thanks.creaothceann wrote: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).
Yup, one game, one file, but I do keep backups of everything around just in case.grinvader wrote: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).
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
Re: CHKSUM = FAIL
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.
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.
KHDownloadsSquall_Leonhart wrote:DirectInput represents all bits, not just powers of 2 in an axis.You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Re: CHKSUM = FAIL
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...
At least until IPS is no longer used...
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Re: CHKSUM = FAIL
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."creaothceann wrote:The hack/translation authors could fix the checksum so that you know if the patch was applied to the correct ROM.
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
Re: CHKSUM = FAIL
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.grinvader wrote: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."creaothceann wrote:The hack/translation authors could fix the checksum so that you know if the patch was applied to the correct ROM.
-
- Inmate
- Posts: 1751
- Joined: Mon Dec 06, 2004 7:47 am
- Location: WA
Re: CHKSUM = FAIL
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.
i personally prefer soft-patching, because i like a folder full of clean dumps. saves and translations are stored separately.
[img]http://i26.photobucket.com/albums/c128/sweener2001/StewieSIGPIC.png[/img]
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
Re: CHKSUM = FAIL
Which is exactly why I keep a backup folder of all my emulation downloads.sweener2001 wrote: i personally prefer soft-patching, because i like a folder full of clean dumps. saves and translations are stored separately.
Re: CHKSUM = FAIL
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.
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.
-
- Hazed
- Posts: 70
- Joined: Sat Apr 24, 2010 2:19 am
Re: CHKSUM = FAIL
Oh cool, I'll have to check it out sometime, thanks.PHoNyMiKe wrote: 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.