jmarsint escribió:Con particiones windows alguna vez use el comando "fdisk /mbr". Alguna vez se corrompia la mbr y asi lo solucionaba, lo que hacía era reescribir al codigo de la MBR.
Si tienes la posibilidad de realizar un backup de la mbr de otro disco, yo probaría a escribirla en este.
, que mal! ![[bye]](/images/smilies/nuevos2/adio.gif "adios")
![[ayay]](/images/smilies/nuevos/sonrojado_ani1.gif "enrojecido")
![[risita]](/images/smilies/nuevos/sonrisa_ani1.gif "risita")
if something wrong has happened with a game installation using either
hdl_dump or winhiip and your disc is now unreadable do not despair!
check out the following information to get your disc back in working
order. this is not for the faint of heart or complete newbies. although
if you follow the instructions, i don't see why anyone couldn't do this.
to do this you will need winhex or some other editor that is able to
write directly to your hdd.
the first thing you should do before ANY install is to use the TOC
list feature of hdl_dump. this will show not only the main partition
sectors, but also the sub-partitions. copy and save this info to a text
file.
use the command line:
hdl_dump toc hddX:
(hddX, where X is the number of your ps2 hdd)
most of the time when 'corruption' occurs is when the APA partition chain
has been broken, or somehow otherwise tweaked. the scope of this little
tutorial is how to go about fixing the chain to restore your drive to its
original state prior to to corruption.
the first thing you want to do is to examine the _mbr partition at
offset 0x00000000.
it should resemble something like this:
00000000 13 0A 2F 7F 41 50 41 00 00 00 04 00 00 00 1C 0B ../APA.........
00000010 5F 5F 6D 62 72 00 00 00 00 00 00 00 00 00 00 00 __mbr...........
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 04 00 01 00 00 00 00 00 00 00 ................
00000050 00 2D 32 0B 13 06 D4 07 00 00 00 00 00 00 00 00 .-2...Ô.........
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100 53 6F 6E 79 20 43 6F 6D 70 75 74 65 72 20 45 6E Sony Computer En
00000110 74 65 72 74 61 69 6E 6D 65 6E 74 20 49 6E 63 2E tertainment Inc.
00000120 02 00 00 00 00 00 00 00 00 2D 32 0B 13 06 D4 07 .........-2...Ô.
the rest of this parition is filled with 00's up to the next partition.
let's break down what we're really looking at here:
***********checksum************next*partition*sect or
***************|**********APA***********|**last*pa rtition*sector
***************|***********|************|********* **|
***************V***********V************V********* **V
**********/*********\*/*********\**/*********\*/*********\
00000000 13 0A 2F 7F 41 50 41 00 00 00 04 00 00 00 1C 0B ../APA.........
so let's say that your previous TOC report shows that your last partition sector
is really 0CA00000. in this case, it is now reporting that 0B1C0000 is the last
sector.
to fix this we need to change the last sector value and adjust the checksum value.
the checksum algorithm is a simple one, all it does is (starting at offset xxxxxx04)
add the dword (32 bit) values in the header and that is the result. for our purposes
we don't need to add up all the values again. instead, we are just going to adjust
the existing checksum value by subtracting the value(s) in which we are replacing and
then adding to it the value(s) of the replacement value.
let's break this down even more. using the above information here's what you need to
do:
7F2F0A13 (checksum value)
-0B1C0000 (current last sector value)
---------
74130A13
+0CA00000 (new (or replacement) last sector value)
---------
80B30A13 (new checksum value)
the changed header would now look like this:
********new*checksum*value*****************new*las t*sector*value
***************|********************************** **|
***************V********************************** **V
**********/*********\**************************/*********\
00000000 13 0A B3 80 41 50 41 00 00 00 04 00 00 00 A0 0C
now we need to fix the chain.
go to the previously listed last sector (0B1C0000) and check it out.
(remember that a sector is 0x200 bytes long, so to figure the offset address
of the sector you need to multiply the sector by 0x200.)
********************next*partition*sector*pointer* (0*signifies*last*partition*on*disc)
**************checksum********************|*previo us*sector*pointer********
*****************|************************|******* ****|
*****************V************************V******* ****V
************/*********\**************/*********\*/*********\
1638000000 12 4A 92 7B 41 50 41 00 00 00 00 00 00 00 18 0B .J?{APA.......@.
1638000010 5F 5F 65 6D 70 74 79 00 00 00 00 00 00 00 00 00 __empty.........
1638000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1638000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1638000040 00 00 1C 0B 00 00 04 00 00 00 00 00 00 00 00 00 ..H.............
************\*********/*\*********/
*****************^***********^
*****************|***********|
***********current*sector****|
*********************current*sector*size
look at the above header. notice that the 'next partition sector pointer' is zero.
a zero here signifies that it is the last sector.
what you do here will vary from case to case depending on your hdd structure.
let's say (for an easy example) this is your original TOC listing:
0ac00000.: 2048MB 1337 [PP.HDL.GameDisc ]
...
0b3c0000.: 2048MB part # 1 in 0ac00000
so you see the next originally stable partition is at sector 0b3c0000.
this means that you have 0x200000 sectors in between the current last sector
and the real next partition in the chain. now, depending on the size of your
hdd will determine the maximum partition size allowed. partition sizes are
exponential in nature starting with a minimum size of 128MB. if you have a
120gb drive, the following are the allowable sub-partition sizes:
00040000 128mb
00080000 256mb
00100000 512mb
00200000 1gb
00400000 2gb
going from memory, i believe the maximum partition size can only be up to
2% of the entire drive size. so if you have a smaller drive you'll have to
figure smaller partitions, and for a 48-bit patched hdloader and >120gb drive
you can figure for larger partitions (this of course means that you'd need a
200gb drive in order to use the next biggest partition (4gb)). when i say
'partition size' i don't mean what winhiip reports, cuz it is combining all
sub-partitions for that specific entry. if you look at your TOC list, you'll
see a bunch of 'part #1 of xxx', etc.
getting back to the task at hand. using the above sample, simply adjust the
_empty partition's size to 00200000, the 'next sector' address, and the checksum.
remember, you can always figure the checksum using the existing value like so:
checksum = checksum - (next sector value + sector size) + (new next sector value + new sector size)
your new header should look like this:
*****************************next*partition*sector *pointer
**************checksum********************|*previo us*sector*pointer********
*****************|************************|******* ****|
*****************V************************V******* ****V
************/*********\**************/*********\*/*********\
1638000000 12 4A EA 86 41 50 41 00 00 00 3C 0B 00 00 18 0B .J?{APA.......@.
1638000010 5F 5F 65 6D 70 74 79 00 00 00 00 00 00 00 00 00 __empty.........
1638000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1638000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1638000040 00 00 1C 0B 00 00 20 00 00 00 00 00 00 00 00 00 ..H.............
************\*********/*\*********/
*****************^***********^
*****************|***********|
***********current*sector****|
*********************current*sector*size
now you have your sectors linked back together again. the only thing left
to do is to go to your original 'good' final sector and set the 'next sector pointer'
value to zero and adjust that partition's checksum. this will signify that it is the
final partition.
the above scenario is a best case scenario because all you have to do is change the
pointers and sector size in the messed up final partition. use the aforementioned
information as a guide to create (if you have to) multiple '_empty' partitions in
order to re-establish a link to your good existing partitions. the only final tip
i can give you with a multiple-partition creation scenario is to copy 0x100000 bytes
from the original _empty partition (this is 1mb btw) and paste it into where you
need to create your other linking partitions. then, of course, fix the headers
accordingly.
when you're done you should be able to do a TOC listing with hdl_dump again or do
a check with winhiip to make sure all of your old games are fine and restored.
if something isn't working, remember to go back and check your partition sector pointer
values and especially the checksum values.
i realise that this may seem like a monumental task (although it really isnt).
consider this: even if it takes you a couple hours to get this straight, it's
still a LOT quicker than refilling your 120gb drive with games again!
if something is incorrect in this tutorial please feel free to comment on it.
![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
![[+furioso]](/images/smilies/nuevos/furioso.gif "muy furioso")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
