Howdy,
I just purchased a large stock of games on vacation and was in the process of dumping them when I ran across this (possible) issue. I use GoodSNES to verify my games, and as I dumped, I noticed that many of them were not being verified as correct. I tried cleaning them, and I had the same result.
So, to try to figure out what was going on I acquired some "official" dumps temporarily to compare them to my Retrode dumps. Here's what I found: the Retrode appears to overdump games whose ROMs are not exact powers of two and fills them with what appears to be garbage.
For example, attached is a side-by-side picture of the hex editor views of the "official" and Retrode dumps for Fatal Fury 2 (dumps as a 4,096KB ROM, "official" is 2,560KB). As you can see, the "official" dump stops at 0x27FFFF. The Retrode's dump keeps on going with what appears to be garbage all the way to 0x3FFFFF. (I say "appears to be garbage" because the "garbage" is always consistent.)
This issue doesn't occur with ROMs such as Shin Megami Tensei II, which was correctly verified and is a 2048KB ROM.
All of the ROMs should work correctly, even with the overdump; that's not what I'm worried about. However, I do like to verify my ROMs, to make sure they work completely before I start playing, and this is making it extremely difficult to do without downloading "official" dumps and comparing. (I felt dirty enough downloading this pair for the bug report.)
So, is this correct behavior? If so, how can I find where the "garbage" is starting so that I can get these dumps verified?
Thanks!
EDIT: Bonus piece of information: As far as I can tell, this only occurs with 2048KB and larger dumps. Either smaller ROMs are padding their data correctly, or the Retrode is handling them better.
EDIT 2: Also, as far as I know, I am not engaging the overdumping mode (by pressing the HWB button), so that shouldn't be it either.
Having tried hard to detect those non-standard odd sizes, I propose that one should modify the verification tool to allow overdumping :)
Quote from: Matthias_H on 02/Jul/2012 12:46:19 AM
Having tried hard to detect those non-standard odd sizes, I propose that one should modify the verification tool to allow overdumping :)
Heh, well, it's good to know at any rate that you're aware of the issue. Does the cart have no information about the size of its contents that could help when dumping? EDIT: NVM, I looked at a doc that shows it reports to the nearest multiple of 2. How distressing.
The problem with verifying it with the overdump is that the overdumped information significantly changes the hash, which is what every verification tool I have ever seen uses for verifying ROMs. We may have to start our own verification tool for Retrodeers, Matthias. ;D
At any rate, I guess I will have to continue my current trend of using "official" dumps to trim the ROMs that the Retrode is dumping for now, even though it irks me to do so. :-\
EDIT2: I don't really know how the Retrode works, (but I'd really like to, you should write this up at some point) but I see that the SNES cart header has a checksum from this (http://patpend.net/technical/snes/sneskart.html) article that is a bit wonky, but does appear to take into account the odd ROM sizes. Perhaps you could run a checksum on the full ROM, and if it doesn't check, try decreasing the size to the next smaller? If you run down to the next power of two, the ROM is bad. (Hooray for random advice from novice programmers, amirite? ;) )
I guess the simplest way would be to hash only the data up to the correct length of the ROM, which should be known to the tool.
Quote from: Matthias_H on 02/Jul/2012 07:05:16 AM
I guess the simplest way would be to hash only the data up to the correct length of the ROM, which should be known to the tool.
That would work if the ROM had a copier header, such as an SMC, but the SFCs the Retrode dumps would have the same problem of missing the true ROM size. I don't think there's any open source ROM verifier, but I think all the ROM info they have is the dump name and hash information.
As a temporary solution, now that I know the set of ROM sizes for the SNES, if a dump fails to verify, I can chop it down until it does so. Now, off to write a batch script to do it for me.