Need firmware for pc3k WDC WD20EARS-00MVWB0 25.12E

[hhddrec]

um....

ok...

you subject title of the thread states "Need firmware for pc3k WDC WD20EARS-00MVWB0 25.12E" .


so we would assume you had one.

Guess that it was because WDR works with the same file format that PC3K lolololol

Good to know. Thanks... never used WDR

Still confusing

This Known is very goog, Pc3k FW Compatible with WDR

[michael chiklis]

hhddrec i sent you pvt

[Cleanroom]

I have been using PC-3000 since back to the IDE days. so I have had no use to try other things that will try and do the same thing as it.

But the solve slow fix may not even fix the issue. Just that if it is acting slow, and the modules are good, and the head test shows good, it may be a good first try.

Good Luck

[michael chiklis]

I have been using PC-3000 since back to the IDE days. so I have had no use to try other things that will try and do the same thing as it.

But the solve slow fix may not even fix the issue. Just that if it is acting slow, and the modules are good, and the head test shows good, it may be a good first try.

Good Luck

Module 24 was damaged and i repaired it with smart reset, now the only damaged module is 6F, but einstein9 wrote this:

Code:

you don`t need it at all
in fact even NEW DRIVES comes with bad 6F

Also pcb is ok, because i've changed with a good one and did rom transfer, still slow.
WDR report that heads are good, so it may be the slow issue as you said...

[hhddrec]

I have been using PC-3000 since back to the IDE days. so I have had no use to try other things that will try and do the same thing as it.

But the solve slow fix may not even fix the issue. Just that if it is acting slow, and the modules are good, and the head test shows good, it may be a good first try.

Good Luck

Module 24 was damaged and i repaired it with smart reset, now the only damaged module is 6F, but einstein9 wrote this:

Code:

you don`t need it at all
in fact even NEW DRIVES comes with bad 6F

Also pcb is ok, because i've changed with a good one and did rom transfer, still slow.
WDR report that heads are good, so it may be the slow issue as you said...

slow issue -> Lot of posibilities

[BlackST]

E' possibile chiedere supporto a chi ha fatto il software ?

Why not ask support from the maker of the software ?

[michael chiklis]

If i try to do flash repair i get error 3746 on module 107?

What is module 107?
It's normal that is not shown in module list?

[labtech]

107 is ROM mod image. Not related to slow responding issue.
Other mods gets affected by this issue.
It's related to bad blocks.

[michael chiklis]

107 is ROM mod image. Not related to slow responding issue.
Other mods gets affected by this issue.
It's related to bad blocks.

I wanna try to fix mod 107, how should i do?

[labtech]

Can the soft read with ignoring read errors?

[michael chiklis]

I don't know because it's only few days that i have WDR 3.0 full, maybe Spildit knows how.

[michael chiklis]

I did selfscan module repair to repair those 4 errors, but didn't fix them.
As you can see in the pic selfscan modules F0 - F1 - F2 - F3 get error 3746.

I cleared module 32 (Translator Grown) and then i opened the module file with Hexworkshop (it cleared).
Then i did quick translator with P-list (WDR wrote "successfully"), but it's still slow.
Then i went into module operation menu, Road MAp - Via Enumeration and i found much more modules, also module 107 but it's corrupted ("read all modules" button doesn't really copy all modules, i don't know why).
I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

Module 0B:

Still slow...

So i flashed the firmware from the donor pcb and pushed "repair", but still the same problem (also i still get error on module 107).
Then i flashed again the pcb with the original rom, of course il still the same...

So I gave up and I realized that it is a problem of heads as you were saying at the beginning
So I wanted to try once again to test the heads, guess what ...

Now WDR detects bead head (only head 1), until yesterday it reported GOOD

Should i try to depop head?
I will need help how to do it because i never did in my life...

Thank you.

----------------------------------------------------------------------------------

P.S.
Now head 1 is reported again good

Attachments

Log.txt

(529.01 KiB) Downloaded 952 times

[fzabkar]

I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

You need to edit the MOD. Change the MOD ID from 0x000B to 0x0107 and then recompute the 4 checksum bytes. Pad the end with 0x00 bytes until it's the correct size.

If you upload the binary data for MOD 0B, I can do this for you.

[fzabkar]

You need to change offsets 0x08 - 0x09 from 0B 00 to 07 01. That's the MOD ID in little endian format.

The checksum bytes are computed as a 32-bit little endian sum over the entire MOD contents. This checksum is located at offsets 0x0C - 0x0F.

The new checksum is computed as follows:

new cksm = old cksm - (new MOD ID - old MOD ID)

= 0x826D3862 - (0x0107 - 0x000B) = 0x826D3766

Therefore you need to edit the checksum bytes as follows:

offset 0x0C - 0x0F from 62 38 6D 82 to 66 37 6D 82

You might like to use WDR to confirm that the checksum is correct.

[michael chiklis]

I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

You need to edit the MOD. Change the MOD ID from 0x000B to 0x0107 and then recompute the 4 checksum bytes. Pad the end with 0x00 bytes until it's the correct size.

If you upload the binary data for MOD 0B, I can do this for you.

~id000B.txt

(512 Bytes) Downloaded 750 times

[fzabkar]

FWIW, MOD 107 doesn't exist in the following resource dump:
http://www.datadonor.net/HD%20Western%2 ... 0MVWB0.rar

Other MODs such as 102, 104, 105 are "NOT_INIT", so they don't appear to be necessary.

Bytes 0x04 - 0x07 appear to be 01 00 1E 00 in the SA and 04 00 1E 00 in the ROM. Maybe that part of the header needs to be edited, too. ???

[fzabkar]

I suspect that this is what it should look like:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  52 4F 59 4C 01 00 1E 00 07 01 01 00 69 37 6D 82


But I suspect that MOD 107 may not be necessary. Did you check whether the others were NOT_INIT?

[michael chiklis]

FWIW, MOD 107 doesn't exist in the following resource dump:
http://www.datadonor.net/HD%20Western%2 ... 0MVWB0.rar

Other MODs such as 102, 104, 105 are "NOT_INIT", so they don't appear to be necessary.

Bytes 0x04 - 0x07 appear to be 01 00 1E 00 in the SA and 04 00 1E 00 in the ROM. Maybe that part of the header needs to be edited, too. ???

Also in WDR doesn't exist module 107 in the module list, but it appears if i do Road Map - Via Enumeration

[fzabkar]

I'm not a data recovery professional, so I don't know what WDR is doing. But if I examine MOD 01 with a hex editor, it appears that each MOD entry in the directory occupies 0x12 bytes and begins with 12 02 low_MOD_ID_byte high_MOD_ID_byte

So the entry for MOD 107 should begin with 12 02 07 01, but there isn't one. That might be why it doesn't appear in the module list.

I have no idea what "Enumeration" means in the present context.

[fzabkar]

ISTR from NazYura's documentation that he first looks for the MODs by consulting the directory in MOD 1. He then sometimes finds additional MODs that aren't in the directory. I suspect he does this by reading each MOD ID sequentially and then checking the command status. May be that's what is meant by enumeration, ie reading from MOD 0000 to MOD FFFF and monitoring the status.

ISTR that I once found a MOD 100 that didn't exist in the MOD 01 directory. I found it by reading the SA tracks and looking for "ROYL" signatures.