• Please review our updated Terms and Rules here

parking an ST-412

marcoguy

Experienced Member
Joined
Feb 12, 2012
Messages
485
Location
Boston
I was wondering if anybody had a debug script to park the hard drive heads of an ST-412. Thanks!
 
Judging by another thread I get the feeling he needs this for someone without floppy disk access ;)

I looked it up, but the BIOS call I was going to suggest is AT only, and setting CX to specify a track number confuses me because I'm a simple boy. Hopefully one of the pros rolls in.

If not, don't panic, my ST412 wasn't parked and had been moved around quite a few times (place to place), then in my boot for a 30 minute trip, then around my house a few times - before being parked - still no bad sectors :)
 
The person who needs to park it can't get any files to his 5150. He's actually selling it on Ebay, and doesn't have any other computers with 5.25 inch FDDs to transfer a disk parking utility to the 5150. It's going to be shipped out to the high bidder (Hopefully me;)) and I know that if I win I certainly wouldn't want it to ship to me without the ST-412 parked. He really just needs a quick fix to park the HD before it sells.

*Edit*
Oops, SpidersWeb, You beat me to it! And I can't imagine your ST-412 was shipped across the country or (in my case) even just from northern New England to Southern New England!
 
Last edited:
What type drives need to be parked before you move them?

Generally 5-40Mb MFM/RLL drives.
But that's not a hard set rule, there is exceptions.

ST251-1 is actually the only MFM or RLL drive I have that auto parks in my collection. You can tell because it makes a fart noise on power down. Don't think there is any IDE drives that don't auto park.
 
Just a point of curiosity...I suspect that most HD parking utilities use INT 13H, Function 0C = seek and probably use function 8 to get the number of cylinders and seek to one past that number.

Do all MFM and RLL controllers actually honor function 0C? I could envision a controller (e.g. SCSI) that does noting with the command--just returns an "operation complete". Since there's no way to determine if the seek operation is actually performed, how many drive/controller/park utility combinations are just no-ops? How many controllers/BIOS prevent seeking past the last data cylinder?
 
Granted I've only used one park utility, and 4 controllers, but I always hear the chirp of my drives moving on park. Couldn't guarantee every one, but not supporting general park methods seems rather odd.

k2 - doing their job just as they were before, cheers :)
 

I've found that you can also MANUALLY move that stepper arm to the end position when there is no power applied to the ST-412 drive.
Although there might be a slight risk doing this, if you're having a PC with an ST-412 shipped to you this is certainly better than
shipping it with the stepper arm at cylinder 0.

The debug procedure would be the preferred method for someone not having a diagnostics diskette. I wonder if it would be
possible to execute similar commands directly through the BASIC prompt, meaning the heads could be parked even if the user
didn't have a boot diskette with debug.
 
Last edited:
Definitely NOT recommended! Hard to say which is the lesser evil...

Well.... I do agree its not the best approach, but I have received two ST-412's that were working fine before they
were shipped. Both arrived with damage to cylinder 0 preventing a low level format from even starting. I was
able to 'revive' both of these ST-412's by adding a small 'extension' to the end of the stepper arm therefore
altering (moving very slightly deeper into the platter) the cylinder 0 position. In order to add this 'extension' I had to
manually move the arms quite a bit, and no harm was done. Both ST-412's are still working with this modification several
years later.

If the person shipping the drive has no way to park the heads, I would ask them to manually move the
stepper arm. Although I am not 100% sure this really moves the heads internally......but I think it does.....
 
Last edited:
I'd modify the DEBUG procedure to end with a jump to self, not a return to the DEBUG prompt. The reason being is that by going to the DEBUG routines again, an implicit invocation of interrupt 28H is performed as part of DOS's input code. If a caching routine hooks this, a subsequent disk access could result.
 
I'd modify the DEBUG procedure to end with a jump to self, not a return to the DEBUG prompt. The reason being is that by going to the DEBUG routines again, an implicit invocation of interrupt 28H is performed as part of DOS's input code. If a caching routine hooks this, a subsequent disk access could result.
I believe you. I've modified the code accordingly.
 
Back
Top