Coming back to the NES/FC dumper again. While I have tested TSROM and TKSROM (MMC3) so far I noticed that the CART.nes file does not have an iNES header. Would be nice if you could add that after dumping since you already set the mapper properly for the dumped cart. If you do plan to add it, perhaps allow the user to set "cart has battery" option, too.
I built and tested the cartridge reader, with V4.0 software released on September 27th. It works very well for all my SNES and GBA cartridges. Thank you Sanni for the hard work!
However, I tried it on Sega Genesis/Megadrive cartridges, and three out of nine are not read correctly: there is a checksum error for:
Quackshot (Megadrive version)
Indiana Jones and the Last Crusade (Megadrive version)
Pitfall The Mayan Adventure (Genesis version).
For Quackshot, I suspected a dirty contact on the address lines, as I saw the same header “SEGA MEGA DRIVE (C)SEGA 1991.SEPI LOVE DONALD DUCK GURUZIA OH NOHIHOU” four times in the dumped file. It is located at these addresses: at 0x100, at 0x40100, at 0x80100, and at 0xc0100. Even when cleaning the cartridge contacts, I get the same checksum and the same checksum error message (and the same dumped file).
For Indiana Jones, I do not understand the checksum error message: I compared the md5 of my dump with the one provided here on the Libreto database and they match:
bc40ee0ea033ba893f4f2ee17368f2b6 TIERTEXDEMO.MD
For Pitfall, I have no clue: the md5 checksum does not match any checksum from the Libreto database.
What would you recommend to solve these two or three problems?
Please try out version 3.1 to see if the dumping error is a result of the recent speed-up or not: https://github.com/sanni/cartreader/releases/tag/V3.1
Version 3.1 does not calculate checksums so you have to compare the MD5 again.
Hi Sanni,
Thank you for the prompt reply ! I just uploaded version 3.1 and used it to dump the same cartridges: QuackShot, Indiana Jones and the Last Crusade, and Pitfall The Mayan Adventure.
The binary files are identical to the ones I got with version 4.0.
Moreover, I decided to move to TOSEC as my reference data for the checksums, and I have two pieces of good news:
My Quackshot cartridge is known in the TOSEC database (same MD5, same SHA1).
The Indiana Jones is also known in the TOSEC database (same MD5, same SHA1).
Partial conclusion: both versions 3.1 and 4.0 of your software create perfect dumps for these cartridges. The only problem is the message in version 4.0 about the wrong checksum, even though the binary dump is perfect.
Pitfall is the only cartridge for which I consistently get the very same “unknown” binary file, whether it is with version 3.1 or version 4.0 (I even tested the reader with different power supplies). This binary file has checksums that are unknown in the TOSEC database. However, seeing that there are already seven known US variants of this Pitfall game in the TOSEC database, maybe I own another model not yet listed in the database?
For the record, here are the checksums for my Pitfall cartridge:
Based on your feedback, I may submit these checksums to the TOSEC team.
Conclusion: I would not worry about the binary files created by your software and hardware, they seem correct. The only thing that I do not understand yet is the reason why the checksum computed by the reader triggers this checksum error message.
Might just be normal for this game to have a bad checksum. Or the developer used a non-standard way to compute the checksum.
Could you please test the other roms too with ESE to confirm that this is the case, if not I'll have another look at the checksum function in my code, maybe I made an error there.
If it is allowed by the forum rules, I can send (by private message if needed) a link to my dump to someone who already has this cartridge, so as to compare the full dumps.
Regards,
Lionel
Yes, as I mentioned above, I checked the known Pitfall (U) ROM and it doesn't contain the 2000 VERSION text in it. The Version note was in an entry in the No-Intro DAT-o-MATIC. I don't know where that info came from.
The start of your dump matches the start of the known ROM.
Confirm the size of your dump. It should be 2097152 bytes. If the size matches then it is either a bad dump or a previously unknown version.
On a different note, FC/NES Mapper 82 carts might use some type of register initialization to access the PRG-RAM. The first cart that I tested did not use the initialization sequence but the test cart that I recently acquired (SD Keiji Blader) uses the initialization sequence. More testing to do...
There are only two bytes different. The bytes at 0x269D8 and 0x269DB appear to be swapped.
In the known ROM, 0x269D8 is 0x03 and 0x269DB is 0xED.
In your ROM, 0x269D8 is 0xED and 0x269DB is 0x03.
It is rather odd. The swapped bytes don't occur at a point where you would suspect an error in the dumping code. It could be a corrupt ROM chip which is rare but does occur. Only way to confirm is to use another method to dump the cart.
Thank you Skaman for the analysis and the comparison. So far, I have been able to run the first level without issues.
All my other dumps have the correct checksums (11 Megadrive cartridges and 20 SNES compared with the reference MD5 and SHA1 checksums available in TOSEC) so I still trust this great system designed by Sanni.
Lionel
Also if you're using V4.0_Portable.zip be sure to update the *.ino files inside to the latest version from the Github main branch as I wrongly defined the variable "index" as byte instead of int in this release breaking all mappers above I think 70 or something like that.