Sorry my mistake. Your BASE is F68E, not F86E, typo error!
Now, lets estimate a damage: attempted cylinder to write is F89A but last address SA is F70D. It is outside of service area. Error message FE means invalid address. Thanks God, nothing wrong happened, command was simply aborted.

My fault, but you didn't obey my instruction: .
So this time check your BASE before executing script, please. Command '%'

Hello SAJunky. Thanks for clarification. When I checked I did the same mistake as you and missed the typo.
I do not blame anyone except me if something goes wrong in this operation.

BASE is indeed 0F68E. I ran the corrected write script. But the result is essentially the same: Drive starts with "Stuff was unreadable". I do not fully understand the write script and especially why there are two parts. the second part seems to start with the same number 210 but I assume this is correct.

Here my print outs:
Ñêîðîñòü COM/HDD=115200 / B0115
Ö
T>
çàïîëíÿåì áóôåð
210
211
212
213
214
215
216
217
218
219
21A
21B
21C
21D
21E
21F
çàïîëíèëè áóôåðû íà÷èíàÿ ñ 210 10 øò èç ôàéëà C:\Install\ST_MEM_FREE\vnd.trc
/2
2>
2>
sF6BA,0
2>
w,0,10
2>
Ñêîðîñòü COM/HDD=115200 / B0115
T>
T>
çàïîëíÿåì áóôåð
210
211
çàïîëíèëè áóôåðû íà÷èíàÿ ñ 210 2 øò èç ôàéëà C:\Install\ST_MEM_FREE\vnd.trc
/2
2>
2>
sF6BA,0
2>
w,10,2
2>
Ñêîðîñòü COM/HDD=9600 / B0096
T>


Furthermore the drive shows now MaxHd=0:
Age=50 Type=20 MxCyl=16358 MxHd=0 MxSct=44C BSz=0000 TCode=0000

Another side effect of the operation is that the drive is now more silent with respect of read errors (No head no errors?)

But on the whole in my opinion my saved vendor track is already corrupt. The Disk Name "ST1Disk2Heads" in the STUFF-region in the saved Track indicates that this is not the right one. Also the Signature Number at 0xE00 is still not there as in my other drive.

From the log I see that writing was successful.
Cycle power to make sure it picks up stuff from hard drive. Or even better, rerun script and immediately after cycle the power.
Script is correct assuming BASE is matching.
How it works? In two stages:
1. fill up the buffer
2. write buffer to the platters.
As buffer is 0x10 sectors long and we need to write 0x12 sectors, we need to repeat filling up buffer (this time only 2 sectors left) and write it to the platter. Hope it clarify.
Awaiting your feedback

From the log I see that writing was successful.
Cycle power to make sure it picks up stuff from hard drive. Or even better, rerun script and immediately after cycle the power.
Script is correct assuming BASE is matching.
How it works? In two stages:
1. fill up the buffer
2. write buffer to the platters.
As buffer is 0x10 sectors long and we need to write 0x12 sectors, we need to repeat filling up buffer (this time only 2 sectors left) and write it to the platter. Hope it clarify.
Awaiting your feedback

Edit: I know that stuff was corrupt, but I need to know if restoring the old one will restore ATA interface.

Had the script rerun after power cycle. Result is the same: Stuff is still unreadable. I downloaded the track again and compared it. Was different at many stages, but not in the STUFF-regions. But you said that the drive writes some sectors.

But I found out another interesting thing:
My other ST380011A, which ATA-interface works, starts also with:
Head Mask FFFF - Switch to full int. Spin Ready
8.01 04-05-04 15:38
(P)PATA Reset
Master

So no Master / Slave. (b.t.w. I have no ATA cable connected).

I have some plan outlined before, but before proceeding I want to see damage, I need a log from boot and response to these commands in order: ^T ^Z ^U ^L ^A . ; % ?
When necessary ^R, then
/2
2>x
What worries me is the following (posted 5 Aug):
That was a time something wrong happened and now after restoring Vendor track it didn't came to (sick) but previous state.
If above repeats, catch it also, but don't try too hard, not worth it.
In meantime I made more experiments on my drive and still didn't lose data. So head up, relax, as long we can write firmware back it can be fixed.

The fact you can write some part of service area doesn't necessarily mean it is accepted and will bring access to data !
P.s. Seems a trial and error approach when the problem - if any - is elsewhere.

BlackST. What we are doing is not exactly trial and error. We do according to this:
BlackST wrote:

So we do this in order, still busy at fixing STUFF. ASCIFE didn't work and restoration of Vendor area didnt bring it back to the previous state. It could be somethng corrupted in meantime. Our second option would be rewriting STUFF sector with original copy @ 0x1200, which I tried already without negative results. Third option is as prescribed here:
I asked question regarding above and nobody responded, so I am currently trying on my drive to see what happen. All according to your advice lads/pals.

Make up your mind : you want data back or want to fuck data and selfscan ? Because whatever the choice you want, STUFF is the latest thing you need. If it's not trial and error, it reminds me something like Ray Charles trying to help Stevie Wonder crossing a road...

Please confirm what do you mean using word 'latest'. I am lost here...
latest = the most recent or newest (using dictionary)

Do you want to help, go ahead , I will be beaten and ashamed... I don't mind... at least OP will resque data and will be happy.

I think BlackST wants to say that STUFF is not needed alt all. And even not selfscan. I Do not have any deterministic plan. Information on that in the Internet is few. And we have spent too Much time in this yet. So I have decided to stop These Experiments for now. I Do not expect some of the magicians will Release his/her expensive knowledge. But perhaps someone will send a Quote for retreiving Data Much lower than that form seagate, ontrack and another local service.
Thank you very Much vor your help, SAJunky!
P.S. golden Times are ahead for Data rescue. Millions of cheap Terabyte Disks are thrown on the Market awaiting failure and a professional rescue.

Selfscan would PROBABLY fix the drive but will fuck every data - in this case it can also abort "as is" . In every case, you need at least something more know how even for selfscan - hw tools are not exactly mandatory. But this is another story. Final note - in this state, assuming important sections of fw are working and untouched, it is still a relatively cheap job (no apparent media damage and with some 'horse power' no need for cleanroom - but it is just 'accurate guessing'...)

No,No,No. BlackST already wrote that selfscan is dectructive on data. Regarding STUFF, it is neccessary to fix it, as this information is passed to BIOS and when it reports LBA 0, you won't get access to your data. He is not telling you things which would provide information to advance to the next level. The only purpose of his posts is to create distraction, destroy self-confidence and expose to stress, so you will be more likely desperate and make mistakes. That way he can prove his evil agenda.
In particular he makes no comments especially to:
1. Repairing STUFF by ASCIFE, manually repairing STUFF1 from copy of STUFF2 (0x1200) or alternatively from a donor firmware.
2. Reseting SMART which is 100% safe.
3. Clearing G-list. Clearing Glist is not 100% safe, but frequently used (except perhaps on very late devices). What can be lost in result of clearing G-list? Only data which had been written to already relocated LBa's. All fake bad sectors will be removed. You have fake bad sectors, as your heads are not bad, so reason for fake bad sectors is different.
The most common reason I wanted to eleiminate on the beginning:

I reviewed your posts and didn't see you have responded to this. It won't repair already corrupted firmware, but it is the first things to do. I strongly suspect your firmware instability is due to poor contacts. If doubts, I refer to repeated booting with safe mode BASE.

I agreee. After so much distraction efforts I would do the same. Put it on the shelf, keep backed up firmware files. In meantime information will keep coming and your data is safe.

Magicians are thinking short term. Keeping these secrets support those poor who's life depends on 5 minute fix. These who work hard should not afraid releasing such information. They also don't think long-term, as this situation only helps big corporation to expand its own Ontrack data recovery business and slowly, but inevitably eliminate small players on the market.

Here we go again!!!

Come on really Come back to the real world & stop reading those dam Marvel comics
I think comments like this will only stop members helping you when you ask for help.

Loki

Show me a post on this forum where I asked for help and received honest advice.
If you can't, stop interrupting conversation of others, as you have nothing to add on-topic. You are useless.

geez with such aggressive response, people loose respect of you. who would want to help a person such as you with a bad attitude. its like making enemies out of people and expecting them to help you.

@SAjunky,

As I was invoked (oh yes, the source of all evil) let me say something , then for me all this junk will stay as is (not my problem, not my data, not my help, not my business) :
First, the old trick to tell lies to get truth doesn't work anymore .
Now you say the problem can be "poor contacts" , what's next ?
If you had so "incredible" certainties, why "wait for information to come" ?
Would be nice to see how you ruled out heads problem and if you really know how these puppies work (there's a great world beside APP CERT OVERLAYS and STUFF).
The fact that "MAYBE" some day you fixed for a friend a drive doesn't mean you can fix every other "similar" ( ? ) case.
It takes MUCH MORE than "more or less free" programs and info grabbed here and there to SAFELY do some kind of jobs.
I know you were waiting for a public correction like "you're totally wrong, let me explain you how to do it" but this won't come at least from me - and from many many others. Times for free lunch are over.
You got plenty of clues, but this is one of the "good will is not enough" case - and honestly I don't know what to do about it.
Last : do not attack people that way, or the least you can get is a report and a ban (but in case think that not all evil is bad, it can be useful to take a break and calm the nerves ).

P.S. clearing the G-list, poking with firmware and even SMART with unstable firmware or unstable disk is really a bad idea. Oh, when you have time, investigate what really happens during CERT (possibily not on a drive that contain live data ). Be sure you can fix the drive later feeding it with what is needed to bring it back to life or it will be a single (not round) educational trip. This should clarify your ideas.

What if I did lose my hope for receiving help on this forum? Reality is in my my post above as quoted.

I don't say it 'now'. I wrote in my post 30 July 14:20
What do you want to prove?


It is not ruled out completely, but with high probability. Not by me, but other posters, including you perhaps, I won't bother to verify.


I am lost completely here.


I see in your incredible vision you have assessed matter properly. <G> However it doesn't explain your tactics which as I wrote is disruptive, creating distraction, attacking OP self confidence and exposing OP to unneccesary stress. Aiming for OP to make mistakes. I can't explain it other way. This is evil tactics and I uphold this firmly.

I agree to the point, it is why my strategy was fixing STUFF first.

Perhaps you should always start with a DISCLAIMER before suggesting to people powerful instructions that can render their data unrecoverable.

You are simulating a restorative/destructive procedures to a drive of your own that has NO VALUABLE DATA for recovery. Yet the person on the other end you are instructing is TOYING around with DATA they are not likely wishing to KILL!

Wouldn't care what you think if I made you aware I work for K.O. does that make me part of your suggested evil agenda?

PS: Fair enough anything I have said here has no substance to add this topic.. other than your attitude STINKS!