PDA

View Full Version : HOW-TO fix overdumps yourself



Corak
May 31st, 2002, 23:58
This was before buried in this thread (http://www.emutalk.net/showthread.php?s=&threadid=5265). 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 (http://www.smiff.clara.net/utils/rom.htm) 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 (http://www.bpsoft.com/downloads). (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]

Slougi
June 1st, 2002, 06:05
/sticky
Nice How-to imo

Doomulation
June 1st, 2002, 22:41
Good thing. Maybe I'll try n' implent this. Added to suggestions :)

Levez
July 26th, 2002, 13:28
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
September 5th, 2002, 23:48
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
October 15th, 2002, 10:49
Originally posted by RatTrap
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 :)..

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

Nemo
January 9th, 2003, 01:11
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
April 26th, 2003, 01:49
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
April 26th, 2003, 02:04
Originally posted by Niggy G
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:
:teehee:
Thats a nice guide. Good Job Corak

ingonab
April 26th, 2003, 15:25
Originally posted by Corak

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)


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
April 26th, 2003, 18:25
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.

ingonab
April 26th, 2003, 19:10
Originally posted by Doomulation
Offsets are usually written in hex format. It's nothing complex about it.

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.

allen
May 14th, 2003, 07:59
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

ingonab
May 18th, 2003, 15:30
allen,

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

Reference table:


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:


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:


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.

MasterPhW
August 15th, 2004, 19:00
Okay, this thread is very very old... sorry for posting, but do someone know a updated link for the bad2good thing?

Allnatural
August 15th, 2004, 21:52
Okay, this thread is very very old... sorry for posting, but do someone know a updated link for the bad2good thing?
Same place, slightly different url:

http://www.smiff.clara.net/utilities/rom/index.htm#fixing

MasterPhW
September 29th, 2004, 14:29
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...)

PINJUNG
December 13th, 2004, 10:19
This was before buried in this thread (http://www.emutalk.net/showthread.php?s=&threadid=5265). 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 (http://www.smiff.clara.net/utils/rom.htm) 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 (http://www.bpsoft.com/downloads). (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]

Shpongled
January 13th, 2005, 12:03
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:

Clements
January 13th, 2005, 12:53
Remove the Have/Miss lists from your rom folder and follow the steps in this thread to get GoodWindows to work:

http://www.emutalk.net/showthread.php?t=20280

Shpongled
January 13th, 2005, 15:55
Thanks Clements! I changed it to "y" and now GoodWindows works without crashing. Great program!


It turns out that I editted the Hex wrong, so I followed the set of instructions that Ingonab gave, and it ended up working. I had to set the "Byte Order" of Hex Workshop to "Big Endian" and make sure the "File Offset" was set to "Hex." I'm so proud of myself, lol.

So, no more annoying [o1]! :icecream: Does anyone know what it means when it doesn't have any [o] or [b] or [h], but it still doesn't have a [!]? There doesn't seem to be any noticable problems -- NES file btw -- but I noticed there's no [!] . I would expect that since there are no other "flags" -- for lack of a better term -- besides the country code, that it would be a [!]...

Either way, thanks guys! :P

Clements
January 13th, 2005, 16:47
A rom with a region code on it's own with no [!] is usually the best dump of a game, but it has not yet been verified to be identical to the original cart yet. There are a lot of dumps like this in certain sets like NES.