Menu
What's new
By:
Filters

HOW-TO fix overdumps yourself

Corak

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]
 
L

Levez

New member
Success!

Hey, great guide... I was able to trim Goldeneye and Killer Instinct Gold myself. I presume that they must be good now, since Good N64 verified and renamed them to [!] okay :)

Thanks a lot!

Those are the only two overdumps I've found so far; I'll post if I have any success with other ODs. Would this be the place to do it?

Thanks again... it looked kinda scarey when I first looked at the guide but it's easy really ;>
 
RatTrap

RatTrap

GODLIKE
would it be possible maybe to put abit of code into the emulator so it will fix this automagically when it finds a file with this problem?.. if it is.. i think that would be the best solution really :)..
 
tbag

tbag

New member
RatTrap said:
would it be possible maybe to put abit of code into the emulator so it will fix this automagically when it finds a file with this problem?.. if it is.. i think that would be the best solution really :)..
Click to expand...

That woul be a very good implemented utility dunno though it might take up some resources but surely the emu would say Bad Rom now patching
 
N

Nemo

Master Sporksman
Yeah, maybe offer the user a choice to fix the overdump. It shouldn't take too long, and it would only be a one time thing - much easier than randomly stumbling upon this thread...
 
Niggy G

Niggy G

HTAFC will rise again!!!
And make sure you unzip the file first!

Because if you were incredibly stupid you could spend 30 mins thinking 'I cant see what im doing wrong', lol

:blush: :blush: :blush: :blush:
 
Plisco

Plisco

Sevillian
Niggy G said:
And make sure you unzip the file first!

Because if you were incredibly stupid you could spend 30 mins thinking 'I cant see what im doing wrong', lol

:blush: :blush: :blush: :blush:
Click to expand...
:teehee:
Thats a nice guide. Good Job Corak
 
I

ingonab

New member
Corak said:

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)
Click to expand...

This offset+block size notation is a bit complex. (I still haven't figured out why it's listed this way.) It might be easier if the listing went like:

32.0 MBit - 00400000
64.0 MBit - 00800000
96.0 MBit - 00C00000
128.0 MBit - 01000000
256.0 MBit - 02000000
320.0 MBit - 02800000
512.0 MBit - 04000000

With the caption stating:
"These are the valid file sizes for each ROM size. To fix the an overdump, delete all excess data starting from the file size offset."
 
Doomulation

Doomulation

?????????????????????????
Offsets are usually written in hex format. It's nothing complex about it. Windows calculator can easily make it to decimal. Besides that, even programs use hex when calculating offset.
 
I

ingonab

New member
Doomulation said:
Offsets are usually written in hex format. It's nothing complex about it.
Click to expand...

Perhaps, but assuming your post is in response to mine, your otherwise helpful information is irrelevant to my query or suggestion. --Because I was not questioning the use of hexadecimal addressing.

One point of correction though, --if you need to be technical-- programs do not "use hex when calculating offset". Programmers might, but programs do not.
 
A

allen

New member
Hello Corak.

Im trying to repair an overdumped rom but I'm confused with step 5.

-- 5. go with cursor to beginning of first junk block (add 1 to last valid block number in parantheses in above table, example: 15)--

I dont understand the example.

Any help would be appreciated.
Allen
 
I

ingonab

New member
allen,

This is how I go about fixing overdump roms, and I'm pretty sure it's what Corak meant.

Reference table:
Code: 
00400000 -  32.0 MBit
00800000 -  64.0 MBit
00C00000 -  96.0 MBit
01000000 - 128.0 MBit
02000000 - 256.0 MBit
02800000 - 320.0 MBit
04000000 - 512.0 MBit

1. Open the overdumped rom file in a hex editor.
2. Scroll down to the end of the file.
3. Go back up until you come across an offset that's one of those listed in the reference table above. (The numbers to left of the dash. --If your hex editor isn't set up to display offsets in hex, they won't match obviously. :))

Example:
Code: 
7fffe0 |ff ff ff ff|ff ff ff ff|ff ff ff ff|ff ff ff ff||................
7ffff0 |ff ff ff ff|ff ff ff ff|ff ff ff ff|ff ff ff ff||................
800000 |ff ff ff ff|ff ff ff ff|ff ff      |           ||..........
The above output might be what my hex editor shows as the data in the last few lines of my rom file. I can easily spot the the hex offset 800000h at the beginning of the last line. According to the reference table, this file is probably a 64Mbit rom with an extra 10 bytes trailing on the end.

4. Delete all the extra bytes from the offset to the end of the file.

The result from the above example is that I'm left with a file that now looks like this:
Code: 
7fffe0 |ff ff ff ff|ff ff ff ff|ff ff ff ff|ff ff ff ff||................
7ffff0 |ff ff ff ff|ff ff ff ff|ff ff ff ff|ff ff ff ff||................
800000 |           |           |           |           ||

5. Save the file and check it with GoodN64. If it didn't work, do the delete-from-offset thing again but with the offset of a rom size that's one size smaller. (You'll know you're doing it wrong if you find yourself deleting gibberish instead of a whole bunch of ff ff ffs or 00 00 00s or something repetitive like that.)

Note: If your hex editor isn't set up to show x bytes per line where x is divisible to those offsets in the reference table, you won't find the listed offsets in the offset display of the hex editor. :) But if you know your way around, you could just use the Goto command in the hex editor to go straight to the offset you're looking for.
 
Last edited:
MasterPhW

MasterPhW

Master of the Emulation Flame
Okay, this thread is very very old... sorry for posting, but do someone know a updated link for the bad2good thing?
 
MasterPhW

MasterPhW

Master of the Emulation Flame
Very funny, just to warn some people: these bad2good patches do some bad2bad patches, too. (because of the new GoodN64 I think) E.g. Holy magic century patch Holy Magic Century (G) [b1] to [!] made it to [b2].
Another question: (had read the readme, but it's very old, so probably the author had changed his oppinion) Were ever one of these "to big" patches released?
(Sorry for reposting in a very old thread, but would be cool to get a answer...)
 
Last edited:
P

PINJUNG

New member
Corak said:
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]
Click to expand...
 
Shpongled

Shpongled

News Junkie
I think I successfully fixed one because the size is 16,384kb.

Now my problem is with GoodWindows 2.4...

I follow the instructions in the "Using GoodN64 rev2.zip," but the program crashes as soon as I select the directory where the file is.

I wish I knew a command-line to rename a single file via GoodN64... Can anyone help me? :bye3:
 
You must log in or register to reply here.

Top