Corak
Nintendo gamer
This was before buried in this thread. I decided it might be worthwhile to move it out with a proper topic so it's not missed by those interested in a solution. If you read the above thread already just skip this.
Overdumps are pretty easy to fix (in most cases) after some quick investigation. (I just compared Goldeneye (U) [!] and Goldeneye (U) [o1] in more detail).
Most overdumps are just one rom size larger than the original rom. The good roms usually end with a fill "FFFF" / "0000" block section themselves for the last remaining cartridge space since developers are seldomly able to fill up a cartridge with valid code until the very last available block. Overdumps usually contain all the good code including the good fill section but then add some real junk data afterwards (non "FFFF" / "0000" blocks) but normally also terminate with a standard space filler (again "FFFF" / "0000" blocks).
So usually:
[===F] - good dump
[===FjunkF] - overdump
So by simply removing "junkF" from the overdump a good dump can be recovered.
The awesome Bad2Good Pather fails to fix overdumps for some reason (but fixes about any other bad dump] but you can fix your overdumps yourself manually leveraging the above knowledge.
I wrote a small HOW-TO for this so others can profit from it and fix their overdumps. Overdumps might work fine but I still hate to have any non [!] dumps additional in wasting space.
Enjoy. I'm NOT responsible if you completely ruin your rom or blow up your computer by doing this.
You should of course do a backup of your rom before attempting something like this.
+---------------------------------+
HOW-TO FIX OVERDUMPS
+---------------------------------+
Get a good HexEditor. I recommend Hex Workshop. (All following values are based on Hex Workshop and might differ with other editors)
Address-table (for convenience, specifies the last valid block of good roms of all available sizes):
32.0 MBit - 003FFFF0 (8 blocks)
64.0 MBit - 007FFFE0 (16 blocks)
96.0 MBit - 00BFFFF4 (6 blocks)
128.0 MBit - 00FFFFE4 (14 blocks)
256.0 MBit - 01FFFFEC (10 blocks)
320.0 Mbit - 027FFFF0 (8 blocks)
512.0 MBit - 03FFFFFC (2 blocks)
1. check rom size of overdump XYZ (example: 256.0 MBit, either by looking at used end address or byte size or PJ64.. you get the idea)
2. run Hex Workshop
3. Ctrl-O: browse to dump XYZ
4. Ctrl-G:
- make sure "Hex" is selected for Offset
- paste end-adress hex-value of one rom size smaller than the overdump (example 00FFFFE4)
5. go with cursor to beginning of first junk block (add 1 to last valid block number in parantheses in above table, example: 15)
6. now delete all the junk and save the changes with SHIFT+END, DELETE, OK, CTRL-S, N
(7. look at byte file size of file, you know you cut about right when you get one of these values: 4,096 / 8,192 / 12,288 / 16,384 / 32,768 or 40,960)
8. verify result with GoodN64
9. [!] ?
- Yes: DONE
- No: repeat above procedure to make rom even one size more smaller (I personally didn't encouter such big overdumps yet though)
It would of course help if there was a database where you can see the real romsize of each cartridge.
Should anyone attempt the above method of fixing please post back with success / failure. Might be interesting.
My personal record so far:
SUCCESS:
GoldenEye 007 (U) [o1]
Virtual Chess 64 (U) [o1]
Killer Instinct Gold (U) (V1.0) [o1]
Wheel of Fortune (U) [o1]
FAILURE:
Dance Dance Revolution - Disney Dancing Museum (J) [o1]
Overdumps are pretty easy to fix (in most cases) after some quick investigation. (I just compared Goldeneye (U) [!] and Goldeneye (U) [o1] in more detail).
Most overdumps are just one rom size larger than the original rom. The good roms usually end with a fill "FFFF" / "0000" block section themselves for the last remaining cartridge space since developers are seldomly able to fill up a cartridge with valid code until the very last available block. Overdumps usually contain all the good code including the good fill section but then add some real junk data afterwards (non "FFFF" / "0000" blocks) but normally also terminate with a standard space filler (again "FFFF" / "0000" blocks).
So usually:
[===F] - good dump
[===FjunkF] - overdump
So by simply removing "junkF" from the overdump a good dump can be recovered.
The awesome Bad2Good Pather fails to fix overdumps for some reason (but fixes about any other bad dump] but you can fix your overdumps yourself manually leveraging the above knowledge.
I wrote a small HOW-TO for this so others can profit from it and fix their overdumps. Overdumps might work fine but I still hate to have any non [!] dumps additional in wasting space.
Enjoy. I'm NOT responsible if you completely ruin your rom or blow up your computer by doing this.
You should of course do a backup of your rom before attempting something like this.
+---------------------------------+
HOW-TO FIX OVERDUMPS
+---------------------------------+
Get a good HexEditor. I recommend Hex Workshop. (All following values are based on Hex Workshop and might differ with other editors)
Address-table (for convenience, specifies the last valid block of good roms of all available sizes):
32.0 MBit - 003FFFF0 (8 blocks)
64.0 MBit - 007FFFE0 (16 blocks)
96.0 MBit - 00BFFFF4 (6 blocks)
128.0 MBit - 00FFFFE4 (14 blocks)
256.0 MBit - 01FFFFEC (10 blocks)
320.0 Mbit - 027FFFF0 (8 blocks)
512.0 MBit - 03FFFFFC (2 blocks)
1. check rom size of overdump XYZ (example: 256.0 MBit, either by looking at used end address or byte size or PJ64.. you get the idea)
2. run Hex Workshop
3. Ctrl-O: browse to dump XYZ
4. Ctrl-G:
- make sure "Hex" is selected for Offset
- paste end-adress hex-value of one rom size smaller than the overdump (example 00FFFFE4)
5. go with cursor to beginning of first junk block (add 1 to last valid block number in parantheses in above table, example: 15)
6. now delete all the junk and save the changes with SHIFT+END, DELETE, OK, CTRL-S, N
(7. look at byte file size of file, you know you cut about right when you get one of these values: 4,096 / 8,192 / 12,288 / 16,384 / 32,768 or 40,960)
8. verify result with GoodN64
9. [!] ?
- Yes: DONE
- No: repeat above procedure to make rom even one size more smaller (I personally didn't encouter such big overdumps yet though)
It would of course help if there was a database where you can see the real romsize of each cartridge.
Should anyone attempt the above method of fixing please post back with success / failure. Might be interesting.
My personal record so far:
SUCCESS:
GoldenEye 007 (U) [o1]
Virtual Chess 64 (U) [o1]
Killer Instinct Gold (U) (V1.0) [o1]
Wheel of Fortune (U) [o1]
FAILURE:
Dance Dance Revolution - Disney Dancing Museum (J) [o1]