Drive recognised but every sector is bad

I checked my resources for a suitable donor module. The closest I could find was this one:

Code:: module version (ASCII / hex) ------------------------------------------ 32.MOD 0 30 31.MOD 0 30 34.MOD 132R? 31 33 32 52 3F 33.MOD 132R? 31 33 32 52 3F

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 08 14 31 1E 32 30 00 00 00 3F 00 00 00 00 00 00 ..1.20...?...... 00000010 00 00 00 00 00 00 08 00 5C 00 00 00 6C 00 00 00 00000020 CC 0A 00 00 FA 0F 00 00 97 02 00 00 03 00 97 02 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000040 31 04 B9 04 B2 B6 B8 04 07 55 01 00 00 20 00 00 00000050 97 02 00 00 B7 A3 05 00 69 5A BE 04 00 00 00 00

Yours is ...

Code:: 31_00B0.MOD 0 30 33_0122.MOD 132D? 31 33 32 44 3F 34_000C.MOD 132D? 31 33 32 44 3F

Information from module 02 ...

yours

donor

FWIW, I also found a WD800JB-00FMA0:

Code:: 33.RPM 1500? 31 35 30 30 3F 32.RPM 1500? 31 35 30 30 3F 34.RPM 1500? 31 35 30 30 3F 31.RPM 1500? 31 35 30 30 3F

RD32SEC2 gave the the same error as the other script - Drive reports error

Sorry your last post went a bit over my head, are you saying that the modules look the same between the donor and mine?

fzabkar wrote:The following script works on my BB drive.

Sorry, I posted the wrong draft of my script. The corrected one was included in the RAR attachment, so no problem. Here is the correct version (which I tested and included in the RAR):

Code:: ; reads first 2 sectors of module 32 on heads 0 and 1 reset waitnbsy regs = $45 $0b $00 $44 $57 $a0 $80 waitnbsy regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd32h0s1.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3201.bin regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd32h1s1.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3211.bin regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd32h0s2.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3202.bin regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd32h1s2.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3212.bin ; end ; rd32h0s1.bin -- 0C 00 01 00 FE FF FF FF 00 00 F6 01 01 00 00 00 ; rd32h0s2.bin -- 0C 00 01 00 FE FF FF FF 00 00 F7 01 01 00 00 00 ; rd32h1s1.bin -- 0C 00 01 00 FE FF FF FF 01 00 F6 01 01 00 00 00 ; rd32h1s2.bin -- 0C 00 01 00 FE FF FF FF 01 00 F7 01 01 00 00 00

If you examine module 02, you will find text strings that identify the drive. The manufacture/build dates are 3 weeks apart. Also, if you compare the header information of the donor's MOD 32, you will see that it is similar to the header info in your patient's MOD 31. My only concern is in regard to the numbers at offset 0x40 and beyond. These numbers point to LBAs and cylinders which are reserved for sparing. They may not be the same in your drive.

I would be tempted to copy the donor's module to your own drive, but if we get it wrong, then that may render the drive inaccessible for further attempts.

You might first like to try the following modified script. It avoids head 0 and tries to read head 1.

Code:: ; reads first sector of module 32 on head 1 reset waitnbsy regs = $45 $0b $00 $44 $57 $a0 $80 waitnbsy regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd32h1s1.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3211.bin

This next script reads the first sector of MOD 31. You might like to try it before we do anything more adventurous. If this doesn't work, then this will point to a problem with your method.

As before, copy the script and BIN file to the appropriate places.

Code:: ; reads first sector of module 31 on head 0 reset waitnbsy regs = $45 $0b $00 $44 $57 $a0 $80 waitnbsy regs = $d6 $01 $be $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsfrom = rd31h0s1.bin regs = $d5 $01 $bf $4f $c2 $a0 $b0 waitnbsy checkdrq sectorsto = mod3101.bin ; end ; rd31h0s1.bin -- 0C 00 01 00 FE FF FF FF 00 00 42 01 01 00 00 00

Attachments

rd31sec1.rar: (316 Bytes) Downloaded 467 times

fzabkar wrote:You might first like to try the following modified script. It avoids head 0 and tries to read head 1.

Ok I'll give that a try, is there a way I can convert that code into the script and bin file that I need to run it?

fzabkar wrote:This next script reads the first sector of MOD 31. You might like to try it before we do anything more adventurous. If this doesn't work, then this will point to a problem with your method.

Ok done, I've uploaded the output .bin file here
http://www.filedropper.com/mod3101

Ok I'll give that a try, is there a way I can convert that code into the script and bin file that I need to run it?

Just copy the text into a script file using a text editor (not word processor). Choose a name such as RD32H1S1, and place it in the SCRIPTS directory. The RD32H1S1.BIN file is the same as previously uploaded.

Your uploaded mod3101.bin file is indeed the first sector of MOD 31, so your method is OK.

OK RD32H1S1 didn't work, gave the same error. Are the modules mirrored on the platters, so should the first sector of head 1 be identical to the first sector of head 0? Should we try the same script but for head 0?

Head 0 was the first head accessed by the original script. Since the script bombed on the first head, it was therefore unable to test the second head. My second script tested the second head on its own. In short, neither head is allowing access to MOD 32. :-(

Update:

The user was able to recover all but 20MB of the data. We achieved this by replacing the damaged module 32 via direct CHS writes, firstly to head #1, then to head #0. I don't know if we could have achieved the same end by "regenerating the translator" using NazYura's MHDD script. AIUI, module 31 is the translator, but perhaps the aformentioned command regenerates both modules ???

We used the following scripts. Please be WARNED that the write scripts are tailored for the OP's drive and should not be applied to another drive, even one with the same model and firmware version. This is because there is no guarantee that the modules will be located at the same CHS address.

http://www.users.on.net/~fzabkar/temp/write32.rar
http://www.users.on.net/~fzabkar/temp/write32hd0.rar
http://www.users.on.net/~fzabkar/temp/regntran.rar

BTW, I realise that we could have written module 32 using a different VSC, but I wanted to see what would happen when we specifically wrote to head #1.

Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad

Re: Drive recognised but every sector is bad