Not sure if it's a "bug" as such but I just re-dumped a 4GB cart (using "full" rather than "trimmed") to test it against my Gateway and Uncart dumps and got a different checksum. On checking it in HxD it was clear why: the dump via Decrypt9WIP was 512 bytes shorter. The data up to that point matched but I'm assuming it's to do with the 4GB size limit or something like that... right? Gateway dumps 4GB carts in two parts and I *think* the non-a9lh Uncart did the same.
Yes, I know I can just dump it using the trimmed option and then pad back to full size (as I'd do using the a9lh build of Uncart) but I thought I'd mention it all the same.
Yes, I know I can just dump it using the trimmed option and then pad back to full size (as I'd do using the a9lh build of Uncart) but I thought I'd mention it all the same.
since an actual full dump of a 4GB is larger than what FAT32 can handle (it's *one* byte too large), the last sector is removed by Decrypt9. also (just curious) why do you need padded roms?
fair enough, I guess. I don't use padded roms when I can mostly just to save space (not really looking for "100% good" dumps)
To be honest, I could probably just use trimmed going ahead but I guess I got into the habit of dumping via Gateway and then the older version of Uncart and there's also the "it doesn't hurt to go full belt and braces" attitude I have with doing backups of any kind of data. I've dumped a load of game tapes over the years too (yes, I'm an "older"?! gamer) and "discovered" a lot of variants and missing stuff because people often assumed the B-side would be the same as the A-side. Anyway.... like I said, it's not a major biggie.
The No-Intro dat files are all for untrimmed, encrypted dumps.fair enough, I guess. I don't use padded roms when I can mostly just to save space (not really looking for "100% good" dumps)
I usually dump them trimmed, use rom_tool to untrim them, verify then trim & cryptofix them. Voila, trimmed, compressible, verified roms
BTW @richy some roms don't verify correctly if you dump them fully. Pokemon games store the save in the same address space as the rom so it gets dumped with them. I couldn't get my pokemon dumps to verify until I trimmed then untrimmed them to remove the save data, So full dumps aren't really necessary and can actually be a problem. I think this is a characteristic of Card2 games.
Yeah, I know the Pokemon ones can be a bit of a pain. I've got one which was Card2 which doesn't match the scene release and also a Card1 which doesn't match either. One of them was dumped from a brand new/never been used cart so it ought to have been "perfect" but unfortunately they were my mate's games and he sold them straight after (and before I'd verified them) so I can't re-dump to see if it was a mis-read or whatever. They're both on my "to do" list at some point but I think I already tried trimming and erasing the save data area on mine and the scene ones and still got mismatches. Anyway.... something to sometime SOON™ I thinkThe No-Intro dat files are all for untrimmed, encrypted dumps.
I usually dump them trimmed, use rom_tool to untrim them, verify then trim & cryptofix them. Voila, trimmed, compressible, verified roms
BTW @richy some roms don't verify correctly if you dump them fully. Pokemon games store the save in the same address space as the rom so it gets dumped with them. I couldn't get my pokemon dumps to verify until I trimmed then untrimmed them to remove the save data, So full dumps aren't really necessary and can actually be a problem. I think this is a characteristic of Card2 games.
It could be a new version of a cart. I do know that some have multiple versions available and the dats are always updating.Yeah, I know the Pokemon ones can be a bit of a pain. I've got one which was Card2 which doesn't match the scene release and also a Card1 which doesn't match either. One of them was dumped from a brand new/never been used cart so it ought to have been "perfect" but unfortunately they were my mate's games and he sold them straight after (and before I'd verified them) so I can't re-dump to see if it was a mis-read or whatever. They're both on my "to do" list at some point but I think I already tried trimming and erasing the save data area on mine and the scene ones and still got mismatches. Anyway.... something to sometime SOON™ I think
P.S. I remember games on tape too. The horror
Actually it would be pretty easy to verify trimmed roms vs untrimmed checksums: Calculate the checksum up to the 'trimmed' point, continue calculating the checksum using all zeroes up to where the next 'reasonable' size is reached. Checksums are calculated sequentially (byte after byte), so it is easy. It's just that I don't know any tool that would do that.The No-Intro dat files are all for untrimmed, encrypted dumps.
I usually dump them trimmed, use rom_tool to untrim them, verify then trim & cryptofix them. Voila, trimmed, compressible, verified roms
BTW @richy some roms don't verify correctly if you dump them fully. Pokemon games store the save in the same address space as the rom so it gets dumped with them. I couldn't get my pokemon dumps to verify until I trimmed then untrimmed them to remove the save data, So full dumps aren't really necessary and can actually be a problem. I think this is a characteristic of Card2 games.
I'm using EvoCRC, btw, and the dev behind that said that he had considered trimmed ROM verification, but ditched the idea because it would not fit his codebase... I doubt it would be that difficult, but I also know how apparently (aka perceived by others as) small changes can mess up your whole design.
Last edited by d0k3,
So if a ROM dump runs past 4GB, couldn't you finish up the file when it gets close, add a .001 to the filename, and continue the bytestream in a second file? Basically every OS in use has a simple command to just concatenate two files (like copy /b in Windows) so it's trivial to join them up when they're off the FAT32 card.
I mean, it gets difficult to verify the dump in D9, but that can be done on a PC, too.
I mean, it gets difficult to verify the dump in D9, but that can be done on a PC, too.
Last edited by Krude,
not really necessary, since the rest of the rom is usually just "0xFF" padding anyway. there's no game yet that actually uses the full 4gb.
That's actually a pretty nice idea. A general rom tool would just have to take into account what the padding is. I suppose they standardised on full dumps in case of carts where the empty space isn't all the same value or the size of the valuable data is hard to determine.
Incidentally, every 3DS rom I've dumped (>35) has been sized to the next power of 2. 256MB/512MB/1G/2G/4G
I think the max size of a cart is 8GB, though I've never even heard of one that big yet. A 4.1GB game would have soo much wasted space.
Last edited by Kirtai,
, Reason: clarified what roms I've dumped
And adding to this, even on full dumps it first checks if that sector is actually used and doesn't remove it if it is.
Hi and thanks for the update!
How do I update Decrypt9WIP in my 2DS? I have the previous version 20160607 installed in my system.
Do I simply delete the previous files (Decrypt9.log+Launcher.dat+Decrypt9WIP.dat) and just drag and drop the new Decrypt9WIP.dat and Launcher.dat from inside the zip file?Does that work?
Thank you!
How do I update Decrypt9WIP in my 2DS? I have the previous version 20160607 installed in my system.
Do I simply delete the previous files (Decrypt9.log+Launcher.dat+Decrypt9WIP.dat) and just drag and drop the new Decrypt9WIP.dat and Launcher.dat from inside the zip file?Does that work?
Thank you!
Last edited by PrometheusG.,
Similar threads
-
Xdqwerty
what are you looking at? -
Sonic Angel Knight
-
-
-
-
@
SylverReZ:
@Psionic Roshambo, The Doom NES cartridges, a few batches were made. One was given to AVGN as seen in his Doom video.+1 -
-
@
Sicklyboy:
I finally modeled and 3d printed the new HDD cages I need in order to build my 2nd NAS. Original ones don't fit the mounting holes on the hdds I'm using. Been sitting on this project for over 2 years smfh -
-
@
Sicklyboy:
I'm finally gonna get this NAS racked and powered on tonight, install truenas core, and burn the disks in with badblocks
-
@
Sicklyboy:
Also another 70TB going in the front mount drive bays of this server. 182tb raw, going to probably use a zfs RAID-Z3 for 3 parity disks, so 140TB usable
-
@
Sicklyboy:
I could claw back 14tb by only doing 2 parity disks but I feel like with 13 disks in the RAID I'd be kind of pushing my luck on rebuild time if I encounter a disk failure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
