Hello there !
First of all can you please post the terminal log that the drive outputs when powered up ? Most likely the problem is caused by bad heads, as it's very typical on 7200.10 when the drive is clicking.
Also you can't create a loader when the drive is already at F>. Think of this as "backing up data"; you can't backup the data when the drive is already damaged, you can just backup when the drive is good to use later when the drive is damaged. You can only create the loader when the drive is functional, because it needs for app code to be loaded on RAM, etc ...
What you can do is to use the library to get a compatible loader and try to load that. If you have a working drive similar to the one you are trying to repair you can use the good drive to create the loader and use the loader to start the damaged drive.
Think of UDMA loader as a packed file containing the app code, cert code, cert tables, vendor track, etc ..... Then when you are in "trouble" and the drive can't load that code from the platters you load it from that file.
If you have something like STCom it's easy to understand, as the "resources" are saved as "independent" files, so you can clearly see the file that is the dump of the app code, the one that is the cert code, etc ... instead of having just one file with everything packed inside (think of it as a big rar/zip file on PC3K UDMA format containing the drive resources).
When a drive drops to F (playing with people on the data recovery field we say the drive in F is Fuc***) it means that the app code was not loaded from the platter to the RAM on pcb. If you have the app code on a file (loader) you load that to try to get to T and work from there.
But first things first, post a log of the drive so we can confirm if heads/pre-amp are gone or not.
Also if you prefer you can post on the Acelab forum and i will reply there (you need legal PC3K UDMA to create an account there).
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)