• Please review our updated Terms and Rules here

How to Park Fixed Disk Head on IBM 5160

P

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,839
Location
UK
Evening all, I've just picked up a 5160 in super condition, fully working including the original 10MB disk. Nice and quiet too, even with the cover removed, and no bad sectors either :D

Anyway I can't seem to find any info on parking the disk heads. So far I've just got DOS 2.1 on it - any info or download link to a suitable utility would be greatly appeciated!

Many thanks
 
Great, many thanks. So do we think it safe to just run shipdisk.com from the v2.2 disk from the command line?
 
Yes it should be. It just parks the head until next boot. ..eh.. sorry didn't quite fully read your question. It should be fine but worst case scenario it would give you an error about not being a correct dos version if it didn't have a function it needs. It should be ok though or you could boot off a floppy running v2.2.
 
Last edited:
Just make sure you run it from within the diagnostic program. If you just run shipdisk.com from the command line, you may risk corrupting parts of your HDD. IBM posted a warning about this at some point.

What I think is the problem is that shipdisk.com takes the state of the system for granted. By booting to the diagnostic program, you put the system in a known state which is known to always be safe when running shipdisk.com, but if you first boot to DOS and load the program, your system may be in such a state which may cause shipdisk.com to malfunct and corrupt the drive.
 
Thanks for this information. I've grabbed the disk image so will give that a whirl.
 
per said:
Just make sure you run it from within the diagnostic program. If you just run shipdisk.com from the command line, you may risk corrupting parts of your HDD. IBM posted a warning about this at some point.

What I think is the problem is that shipdisk.com takes the state of the system for granted. By booting to the diagnostic program, you put the system in a known state which is known to always be safe when running shipdisk.com, but if you first boot to DOS and load the program, your system may be in such a state which may cause shipdisk.com to malfunct and corrupt the drive.
Click to expand...
To satisfy any curiousity:

From the fifth edition of Mueller's 'Upgrading and Repairing PCs' book.
"the problem was that SHIPDISK.COM parks the heads then executes a software interrupt to return to the diagnostics-disk menu, and unpredictable things can happen (including stray disk writes) if the program was not run from the diagnostics-disk menu."
 
A couple times I've found myself working on a machine that has DOS installed on it, but for whatever reason, no floppy drive or other means of getting a program onto the drive itself to park it was available at the time.

I was thinking that a small script that one could type up (if debug was available on the machine) would be useful to post here just for completeness.

The attached park.com grabs the total drive size (int 21h fn 36h) and then does a disk read from the end of the data area. It's not complicated, but it looks to me like the program could be optimized a bit more to simplify it to make it into something someone could type up by hand. I suspect and hope that someone will beat me to posting a script to do it here-I see that my day is going to be quite busy. This is something that should also be added to our wiki.
 
hargle said:
A couple times I've found myself working on a machine that has DOS installed on it, but for whatever reason, no floppy drive or other means of getting a program onto the drive itself to park it was available at the time.

I was thinking that a small script that one could type up (if debug was available on the machine) would be useful to post here just for completeness.

The attached park.com grabs the total drive size (int 21h fn 36h) and then does a disk read from the end of the data area. It's not complicated, but it looks to me like the program could be optimized a bit more to simplify it to make it into something someone could type up by hand. I suspect and hope that someone will beat me to posting a script to do it here-I see that my day is going to be quite busy. This is something that should also be added to our wiki.
Click to expand...
Here is the core of the PARK.COM program, after stripping off any data strings, buffers, and unneccesary checking when running the code as a script. If you know the last sector on the drive, you can just put it into AX and skip all the code down to after the MUL DX instruction.
Code: 
		MOV	DL,03h		; Drive number, 03h is C, 04h is D, etc...
		MOV	AH,36h
		INT	21h
		MUL	DX

		MOV	DX,AX		; Last sector on drive
		MOV	AL,02h		; Drive number, 02h is C, 03h is D, etc... 
		MOV	BX,0200h	; Where to read the data
		MOV	CX,0001h	; Sectors to read
		INT	25h
		RET
What I see is that this routine only works with disks that only have one partion taking up the entire disk. A more proper routine should use BIOS Int 13h routines to place the head on the last physical cylinder of the drive, regardless of any partions.
 
Another option for parking, is a utility i have on my apco turbo xt.

Timepark is a little tsr, that will park your heads after so many minutes of inactivity.
 
Leaving the heads sitting on the last track will just means that any damage will happen there (sorry if I've misunderstood the conversation)... a seek should be passed to the drive to carry the heads beyond the last track into the landing zone.

For example the ST-412 LZ is 319 despite it having only 305 cylinders. Somewhat later drives interpretted any seek to a cylinder beyond the usable capacity as a seek to the landing zone, i.e. TM364 with 782 cylinders and a LZ of 783.

The following is from http://stason.org/TULARC/pc/hard-drives-hdd/seagate/ST124-21MB-3-5-HH-MFM-ST412.html:

When the read/write heads are positioned in the shipping zone, all portions of the head/slider assembly park inboard of the maximum data cylinder. The read/write heads may be parked by issuing a seek command to any cylinder between 614 and 666. When power is applied, the heads will recalibrate to Track 0.

Cheers
 
This is bad for posting the current (and possibly incorrect) code but if one was to make this a batch file (put this in parkit.bat):
Code: 
echo a > parkit.txt
echo MOV	DL,03		; Drive number, 03h is C, 04h is D, etc... >> parkit.txt
echo MOV	AH,36 >> parkit.txt
echo INT	21 >> parkit.txt
echo MUL	DX >> parkit.txtx
echo MOV	DX,AX		; Last sector on drive >> parkit.txt
echo MOV	AL,02		; Drive number, 02h is C, 03h is D, etc...  >> parkit.txt
echo MOV	BX,0200	; Where to read the data >> parkit.txt
echo MOV	CX,0001	; Sectors to read >> parkit.txt
echo INT	25 >> parkit.txt
echo RET  >> parkit.txt
echo ^PESC>> parkit.txt ;hold ctrl and press p then escape
echo rcx >> parkit.txt
echo 13 >> parkit.txt
echo n parkit.com >> parkit.txt
echo w >> parkit.txt
echo q >> parkit.txt
debug < parkit.txt
parkit.com

Is how you could have it create that for you although yes I'd agree that a bios call would be better but yes should be doable from a system functionality point of view. I suppose you might be able to use edit and just create the com file with ascii codes or ctrl+pctrl+CHAR

Just thinking outloud... on the internet..
 
pearce_jj said:
Leaving the heads sitting on the last track will just means that any damage will happen there (sorry if I've misunderstood the conversation)... a seek should be passed to the drive to carry the heads beyond the last track into the landing zone.
Click to expand...
I think our problem is that we can't discover (from software) where the landing zone is, so we can't tell the drive to go seek to it. I don't know of an INT 13 function to return that parameter.

The code snippet which discovers the size of drive could be changed to find the highest track, add 1 to it, then go read. I suspect it would fail, but the heads would technically be pushed out that far, right? If that's the case, what's to stop us from just trying to seek/read from track FFFF, or just keep incremmenting the track # until it fails?

Oh the joys of auto parking IDE... :)
 
I think the problem is that until the BIOS gained the landing zone in it's configuration with the AT, head parking was probably controller specific. Even the Amstrad PC2286's manual (c.1989) states that only the system supplied park utility should be used.

But in general for AT and newer, should be able to just call int 13h function 19h (DL=80h for C, 81h for D).
 
The highest availible physical data sector can be found in the BIOS drive parameters; obtained by Int 13h, function 08h.

However, this still doesn't represent the head parking zone. That must problably be done by low-level communication with the disk controller; a procedure which is controller-spesific.
 
hargle said:
I think our problem is that we can't discover (from software) where the landing zone is, so we can't tell the drive to go seek to it. I don't know of an INT 13 function to return that parameter.
Click to expand...
per said:
However, this still doesn't represent the head parking zone. That must problably be done by low-level communication with the disk controller; a procedure which is controller-spesific.
Click to expand...
From a Phoenix book: http://members.dodo.com.au/~slappanel555/misc/at_fdpt.pdf

So, on an AT class machine, to get the Landing Zone for C: (fixed disk 0), use the INT 41H vector. You don't call the interrupt - it's a simply an address vector. So get the vector stored at INT 41H (address 0000:0104). The vector points to the entry in the 'AT Fixed Disk Parameter Table' that corresponds to drive C:

The AT Fixed Disk Parameter Table starts at address F000:E401
Each entry in the AT Fixed Disk Parameter Table is 16 bytes long, the first entry corresponds to CMOS drive type 1, the second is type 2, etc.

For example. If the vector at 0000:0104 is 11 E4 00 F0 (address F000:E411), then that is pointing to the second entry, drive type 2, in the AT Fixed Disk Parameter Table.
But the type is not important. Once you have the address of the entry (e.g. F000:E411), simply add 11 bytes and you have the address of the drive's Landing Zone.
 
modem7 said:
From a Phoenix book: http://members.dodo.com.au/~slappanel555/misc/at_fdpt.pdf

So, on an AT class machine, to get the Landing Zone for C: (fixed disk 0), use the INT 41H vector. You don't call the interrupt - it's a simply an address vector. So get the vector stored at INT 41H (address 0000:0104). The vector points to the entry in the 'AT Fixed Disk Parameter Table' that corresponds to drive C:

The AT Fixed Disk Parameter Table starts at address F000:E401
Each entry in the AT Fixed Disk Parameter Table is 16 bytes long, the first entry corresponds to CMOS drive type 1, the second is type 2, etc.

For example. If the vector at 0000:0104 is 11 E4 00 F0 (address F000:E411), then that is pointing to the second entry, drive type 2, in the AT Fixed Disk Parameter Table.
But the type is not important. Once you have the address of the entry (e.g. F000:E411), simply add 11 bytes and you have the address of the drive's Landing Zone.
Click to expand...

(you should add 12 to the offset, not 11).
As said that's only for AT systems, as the parameter table for the PC XT HDD BIOS is slightly different. In the official IBM XT Xebec HDD controller BIOS, byte 12-15 is marked "reserved for future use".

Isn't there a "get disk parameter" call in the AT too?
 
Wow, I'd completely forgotten about INT 41h. And I not too long ago, even wrote an option ROM for a hard disk controller that utilized INT 41h! I think I've been spending too much time breathing solder fumes.

So a universal park program could be made for AT+ class machines to read this data and seek to it (or use INT13/19), however, most AT+ class machines are likely using newer auto-parking hard drives, so it's likely not even an issue. I wonder what year auto parking drives became commonplace?

For PC/XT machines, the best case would be use the OEM's park utility, which I've never actually found on any machine that I acquire. This OEM park utility is likely to do some low level poking to the controller itself to get the heads parked, so we would likely never be able to find and duplicate that in a program of our own making. Anyone have any OEM park utilities in their collection?

So the next best bet would be to try to either seek out farther than the maximum drive size, or just turn the system off and let the heads fall where they may be. At least that way the damage will be spread out across the drive...

I do love the way we have taken a fairly mundane topic and not only drilled so far into it to dig up all the technical details and keep the discussion going. :)
 
You must log in or register to reply here.
Back
Top