Changing Mod 02 Record 13 Offset 36 is trivial. This will enable/disable autopark at 20 seconds.
Reading and writing Offsets 36-39 looks to working fine now, but my code is rather amateurish. Took me quite a while to convert the char to array (since we’re dealing with 4 bytes now instead of 1 byte in idle3) and to get it to work with pointers, but finally I got it. Verified with Nazyura’s dump.
Next TODO is to read/convert/write Offsets 36-39 from/to desiseconds. I don’t see any point setting it beyond half an hour (might as well disable it), but what the heck.
User input : 2578103244 < For debugging purposes
atof tmptime : 2578103244 < For debugging purposes
After parsing to timer array : cc bb aa 99 < For debugging purposes
VSC_Set_Timer 1 : 204 187 170 153 < For debugging purposes
VSC_Set_Timer 2 : -52 -69 -86 -103 < For debugging purposes
APM timer set to 257810324.4s (0xccbbaa99)
Please power cycle your drive for the new setting to take effect. A reboot will not be enough!
[root@localhost apm]#./idle3ctl -g /dev/sdc
APM timer set to 257810324.4s (0xccbbaa99)
C:>mod2dump.exe 02_99aabbcc.MOD 13
ROYL header found
Update : The first 2 bytes are meant for the APM timer. The last 2 bytes are possibly meant for spindown or whatever that makes the drive goes to Standby. By setting it to 0x000000FF the drive starts and remains in permanent Standby mode and cannot be brought up by the OS. It’s totally not recognized by Linux. hdparm -C shows that it’s in Standby after several minutes. HDAT2 also shows that it’s in standby mode with APM at 0x60.
hdparm -C also shows Standby for 0x0000FF00 and APM at 0x60.
At 0x00FF0000, hdparm -C shows it’s Active.
This certainly makes more sense as no one would need a few years for a timer.
In fact the feedback that you provided in this thread proved to be very useful in formulating a procedure to facilitate the recovery of data from certain WD drives with the well known “slow issue”. The fix involves modifying a single byte in MOD 02, and clearing the contents of MOD 32. Unfortunately I’m not much of a programmer, so we had to apply the fix by way of an MHDD script (plus a FreeBasic program). So far, two users have been successful. If we had not modified the firmware, it would have taken several months at 24/7 to clone the drives, assuming they could have survived the ordeal. Instead it required only a matter of hours.
It would be nice if a real programmer could produce a simple “slow-fix” tool …
I think I read that article somewhere in HDDguru. If you could tell me which Record and offset of Mod 02 to patch, I can make one. Clearing Mod 32 will be a bit tricky since what we currently have is Record, Offset, and bytes. I can explore further though. I can see one of my Mod 32 has 0x00 from 0x84 onwards.
And I’m not a programmer, but I could explore editing a bit of codes here and there. I’ve tried compiling with Watcom to have it running in DOS but failed. So even if I could make the code for you, it’ll be in Unix. Are you ok with that?
The main part of the “slow fix” is to write a single byte (0x00) to section 0x1b at offset 0x02 in SA module 02.
The other part is to read MOD 32, clear certain data structures within it, and then write it back to the SA.
Perhaps a Linux tool that does the first part of the job could suffice. I could then use your proof-of-concept code to approach professional programmers to fill in the extras for us.
I compared the Before and After of Mod 32. Looks like I should not touch anything between 00-8F correct? And if I were to touch that portion, it’d only be the 4 bytes of checksum. Remaining part of the mod should be zeroed out.
Let me see what I can do.
Update : I checked my list of Mod 32 (all good hard disks from 80GB - 1TB) and it appears that everything is zero from 0x84 onwards.
From your code, the 10th byte is the length of the module.
Yes, that’s it. However, you need to first determine the size of MOD 32 and then write as many sectors back to the drive. It’s a completely different VSC. It may be best to stick with just MOD 02 and see how far we can get with it.
The other day I read your code and wanted to confirm if “the 10th byte is the length of the module”.
I can get Mod 02 for you in no time. It’s just a matter of altering a couple of lines in the code. We can speed things up if you could help test Mod 02 on your end. You just need to get idle3-tools and modify idle3ctl.c from :
My idle3ctl-modified code is able to read Mod 32’s length as well as correctly write the first 1024 bytes onto a file for backing up. For some reason, data beyond 1024 is not correctly read and thus written. Unsure if the disk is acting up since it’s a very old one. Need to solve this before I work on the write module.
Managed to read the whole file now. Since the 11th byte is the number of sectors, I’m curious how it handles Advanced Format drives. Do we multiply the value of byte 11 with 4096 for AF drives or still 512.
Trying to do some tests to understand “The checksum bytes are chosen so that the 32-bit little endian sum of all the 32-bit double words, including the checksum bytes, is 0x00000000”. If we have 4 bytes of 0xFFFFFFFF, does the checksum go at 0x01010101 or 0x01000000. Will try with chksum2.exe
BTW, the only way that I know to determine the size of a module is to begin with a sector count of 1 and read its first sector. Then change the sector count to reflect the size of the module, and read the entire module.
Thanks Franc, that’s what I did actually. Read the first sector, grab the sector count from Byte number 11 (if we start from 0x00 then it is 0xA, i.e. 2 bytes before the first checksum byte), then read the whole mod by multiplying it with 512.
Currently it is able to :
Read the whole Mod 0x32 and save it into a file.
Set offsets 0x84 - EOF to 00
Clear the checksum in order to calculate the total of each 32 bits value.
Recalculate the checksum and store it in offsets 0xC-0xF
Save the modified Mod 32 into a new file.
*** Since my drive is good, both original and new files’ md5sum are identical ***
Read the new file, determine its length and number of sectors (filesize divide by 512 - a bit lazy to code to read it from Byte 11) into memory buffer and write from memory back to a third file (instead of writing to my hard disk)
*** Validated that the third file’s md5sum is identical with the first two ***
I think we are almost there. Let me think carefully if I want to lose my 160GB if things go unexpectedly Or perhaps generate some non-0 values in 0x84-EOF, write to the hard disk, retrieve and see if my program gets to fix them.
I believe all AF drives still use 512-byte sectoring in the System Area.
Think I’m done coding for Mod 32h. Now for Mod 02.
I’ve read http://malthus.zapto.org/viewtopic.php?f=86&t=848 and it was mentioned that it’s Mod 02 Record 1A Offset 2, but in the example you gave earlier, it was Record 1B Offset 2. Which is correct?
Also, my code will zero fill anything from 0x84 onwards. If this is incorrect, I need you to tell me where to start.
Please give me some time to get my head around MOD 32 (and MOD 02).
Just today I received some feedback from someone who is using a professional tool. There are some differences between what the tool does and what the thread at the HDD Oracle is suggesting. I have also been offered a broken WD drive for testing.