Getting PARK.COM onto 5160

[mechaniputer]

Hi all,

I have a working IBM 5160, with a working hard drive (I believe it to be the original MFM) which I picked up a few years ago. I'm finally tinkering with it and discovered that it didn't come with a drive parking utility of any kind. It came with some software floppies but none of them contain such utilities. I have no experience transferring files to this type of PC and I do not have a working 5.25" floppy drive on any of my more modern machines.

It has DOS 3.3 installed, as well as EZ-Menu, PopDOS, MultiMate, and Lotus 1-2-3. I didn't see anything which would be obviously useful for file transfer but I could have missed something. I am also attaching a photo of the ports on the back of the PC, which also shows what looks like a model/serial number? 5160-4060029

1. Is there a way I could write a basic peek/poke or asm routine to park the drive?
2. Is there a way I could bootstrap some way to transfer software to it over one of the ports on the back?
3. Is there a modern-ish device I could use to run it off a CF/SD card and not deal with the original drive at all?
4. Worse case, I can attempt to revive the 5.25 drive on my 386 system and use it as an intermediary to get data to the 5160. Are there any special considerations around disk format if I try this?
5. Where can I obtain the correct disk parking utility for this model?

Thanks in advance.

 

[vwestlife]

Depending on the OEM, DOS 3.3 may include its own parking utility. IBM put it on the Diagnostics disk, and called it "prepare system for relocation". Other OEMs had a standalone park utility called something like SHUTDOWN or SHIPTRAK.

And which make and model of hard drive do you have installed? Some MFM drives were auto-parking.

 

[krebizfan]

1) Yes. I am not sure where to find one now but there were scripts for DEBUG and BASIC programs that would output a COM file for many simple utilities.

2) Both Laplink and Kermit have simple bootstrap starters that require a little typing that would bring over the rest of the program through the serial port. Do you have a newer system with a serial port?

3) There are new expansion cards that will allow the use of either SD cards or CF cards.

4) Disk format will be the standard 360KB or 40 tracks, 2 sides, 9 sectors per track. If your 386 has a 1.2 MB drive, the disk might not be readable in a 40 track drive. The 1.2MB drive creates tracks that are half the width meaning that remnants of earlier writes could interfere.

5) Need to know the hard drive model to get the correct parking tool. Many generic tools work but the drive could have specified parking zone.

 

[vwestlife]

The subject of writing 360K disks in a 1.2MB drive is more mystery than facts. For example, Peter Norton claimed that the problem was isolated to early 1.2MB drives, and later ones solved the compatibility problem. (How? He didn't say.) Others claim that later 360K drives started using the same half-track-width heads as 1.2MB drives and that's what solved the compatibility problem. Either way, I've seen far more warnings that problems could happen than reports that problems did actually happen.

In my own experience, old full-height floppy drives tend to be cantankerous about reading any disks, even ones formatted and written to in the drive itself, while half-height drives (of either density) are much more reliable and rarely have any problems except when the media is bad (watch out for mold/fungus on the disk!).

And I've never known a park utility to be drive-specific. I suppose it's possible that some OEM designed their park utility to seek the drive to a specific hard-coded cylinder, but all the ones I've used just seek the drive to its innermost cylinder, whatever that happens to be.

 

[krebizfan]

The generic parking utility I used let one define the parking cylinder and just to be safe I used what the tech sheet said was the parking cylinder.

I have encountered the problem with 40 track disks written in 80 track drives so if possible, I try to write on 40 track disks on 40 track drives. I tend to think that alignment issues could play a part. A drive could be off by 25% of a track and still work. With the half width track, the 40 track drive would be reading part of the new track and part of the wider old track laid down before.

 

[mechaniputer]

2) Both Laplink and Kermit have simple bootstrap starters that require a little typing that would bring over the rest of the program through the serial port. Do you have a newer system with a serial port?

Yes, I have USB-serial adapters which I use with my CPUville Z80 kit SBC and with my Apple II for ADTPro.

4) Disk format will be the standard 360KB or 40 tracks, 2 sides, 9 sectors per track. If your 386 has a 1.2 MB drive, the disk might not be readable in a 40 track drive. The 1.2MB drive creates tracks that are half the width meaning that remnants of earlier writes could interfere.

Not sure what it is Haven't checked as it's been entirely non-working since before I obtained the machine. Fixing it is a long shot anyway.

5) Need to know the hard drive model to get the correct parking tool. Many generic tools work but the drive could have specified parking zone.

The drive is apparently an IBM WD-25. Not self-parking, but according to this thread, I don't need to worry about it until I physically move the machine? I will obviously need to do that eventually though. Besides, I am paranoid and would likely park it on every shutdown anyway if I had a good way to do that. https://forum.vcfed.org/index.php?threads/ibm-wd25-20mb-do-i-need-to-park-the-heads.1244877/

 

[mechaniputer]

Looks like the referenced version of PARK.COM is 505 bytes in size. I'd rather not have to punch that in manually but in the worst case, it would technically be feasible. I think the next rational thing is to look for a way to bootstrap a serial transfer from my modern PC.

 

[vwestlife]

Parking the heads is not necessary if you're not going to physically move the computer. And even then, if you're just picking it up and carrying it from one room to another, it'll be fine. Parking is really only necessary if it's going to be subject to any extreme shocks or vibration, like put on a rolling cart, transported in a car, or being packed up in a box and shipped.

 

[modem7]

I have a working IBM 5160 ...

In case you are unaware, there is lots of IBM 5160 information in the IBM 5160 section at [here]. In that section, the 'Basics' tab is important for those new to the 5160.

I have no experience transferring files to this type of PC ...

There are some methods at [here].

... and I do not have a working 5.25" floppy drive on any of my more modern machines.

Note that if you connect a 'standard' 1.44M diskette drive in place of the 5.25" drive, you can use 720K sized 3.5" diskettes. Details at [here].

 

[mechaniputer]

Just ordered a TexElec ISA IDE to SD adapter. That should get the job done and also give me a way to back up everything that came on the hard drive. Thanks for the advice everyone.

 

[modem7]

Just ordered a TexElec ISA IDE to SD adapter. That should get the job done ...

I have some information about that card at [here].

Note the warning about the card's default base (starting) address of the ROM being C8000 (a.k.a C800). The ROM on your MFM hard drive controller is most likely starting at that address, in which case, change the switches on the TexElec card so that the TexElec card's ROM starts at D0000 ("D000h").

... and also give me a way to back up everything that came on the hard drive.

Some information on an MFM HDD controller and XT-IDE/XT-CF card residing together in an XT-class computer, is in the 'MFM hard drive controller of XT-class' section of [here].

 

[mechaniputer]

I have some information about that card at [here].

Note the warning about the card's default base (starting) address of the ROM being C8000 (a.k.a C800). The ROM on your MFM hard drive controller is most likely starting at that address, in which case, change the switches on the TexElec card so that the TexElec card's ROM starts at D0000 ("D000h").


Some information on an MFM HDD controller and XT-IDE/XT-CF card residing together in an XT-class computer, is in the 'MFM hard drive controller of XT-class' section of [here].

Giving this a try now, but I think my lack of old DOS skills is a problem. I installed the card in slot 7, with the ROM at D0000h. The XTIDE BIOS comes up, and the C drive then boots as before. But I tried to use fdisk to partition the new drive (appearing as D). I created a max size DOS partition. When I apply the changes it advises me to put a DOS floppy in drive A for the reboot, but I assume this is not needed since C is my boot device. When it comes back up, I expected to be able to use format d: to format it, but it says that there was a format failure. I also (obviously perhaps) cannot get a dir listing of d:.

Where am I going wrong here? My goal is initially just to get a formatted SD card for file transfer but it would be nice to have a spare boot device as well.

 

[compaqportableplus]

The generic parking utility I used let one define the parking cylinder and just to be safe I used what the tech sheet said was the parking cylinder.

Not to derail this thread, but could you provide a copy of that or point me to a link where I could find it? I have tried looking for a park utility that would let you specify the landing zone in the past and I came up empty. Thanks!

 

[modem7]

Giving this a try now, but I think my lack of old DOS skills is a problem. I installed the card in slot 7, with the ROM at D0000h. The XTIDE BIOS comes up, and the C drive then boots as before.

So, for your particular configuration, booting to the MFM drive, as expected. The DOS partition on the MFM drive appearing as logical drive C:

But I tried to use fdisk to partition the new drive (appearing as D). I created a max size DOS partition. When I apply the changes it advises me to put a DOS floppy in drive A for the reboot, but I assume this is not needed since C is my boot device.

Correct. The MFM drive being used to boot to DOS.

When it comes back up, I expected to be able to use format d: to format it, but it says that there was a format failure.

Odd.

Where am I going wrong here? My goal is initially just to get a formatted SD card for file transfer but it would be nice to have a spare boot device as well.

We have seen cases where FDISK informed the user that it created a partition, but on reboot, it is discovered that the partition does not exist. Maybe this is what is going on here. If so, perhaps the particular model of SD card is incompatible with the 'TexElec IDE to SD Adapter'. Or perhaps the SD card is too large for the DOS version that you are using.

When you boot to DOS from the MFM drive, then run FDISK, does FDISK show the partition on the SD that you created earlier ?

At this time, do you have the ability on this computer to run DOS programs sourced online (e.g. via 720K disks)? If so, a good tool to run now is a DOS program named TESTMBR, available at [here]. TESTMBR will test the ability to read/write the first sector (known as the 'MBR'). Because, in your configuration, the MFM drive is physical drive 0, and the SD is physical drive 1, you would first use the D option so that hard drive 1 is the target, then you would use the T option to do the actual read/write test.

 

[mechaniputer]

We have seen cases where FDISK informed the user that it created a partition, but on reboot, it is discovered that the partition does not exist. Maybe this is what is going on here. If so, perhaps the particular model of SD card is incompatible with the 'TexElec IDE to SD Adapter'. Or perhaps the SD card is too large for the DOS version that you are using.

It was a 32GB Sandisk Ultra. I thought that the actual size of the SD card should be irrelevant here for the most part, but see below. Seems like the card was the issue probably.

When you boot to DOS from the MFM drive, then run FDISK, does FDISK show the partition on the SD that you created earlier ?

It did seem to persist across a reboot. However, fdisk was showing two partitions with the same start and end locations (0,1023) and only one of these (overlapping) partitions were recognized as DOS format.

I just tried an older 16GB SD card and fdisk did something different. It says the partition starts at 0, ends at 3, and it shows 1024 cylinders. It formatted and shows a very large number of bytes free.

At this time, do you have the ability on this computer to run DOS programs sourced online (e.g. via 720K disks)? If so, a good tool to run now is a DOS program named TESTMBR, available at [here]. TESTMBR will test the ability to read/write the first sector (known as the 'MBR'). Because, in your configuration, the MFM drive is physical drive 0, and the SD is physical drive 1, you would first use the D option so that hard drive 1 is the target, then you would use the T option to do the actual read/write test.

Looks like I have a way now! I was just able to run PARK.COM from the SD card! Mission accomplished! Thank you very much.

Some other day I will back up the HDD contents (mostly software) that came with the HDD and see what other fun can be had now that I can get files onto (and off of) it.

 

[modem7]

It did seem to persist across a reboot. However, fdisk was showing two partitions with the same start and end locations (0,1023) and only one of these (overlapping) partitions were recognized as DOS format.

Something horribly wrong there. A wipe of the drive's MBR may be in order.

I just tried an older 16GB SD card and fdisk did something different. It says the partition starts at 0, ends at 3, and it shows 1024 cylinders. It formatted and shows a very large number of bytes free.

A partition of:
4 heads (numbered 0 to 3) and 1024 cylinders. Therefore, 4096 tracks. Assuming that each track has 17 sectors (each of 512 bytes), 4096 x 17 x 512 bytes = approx. 34 MB

Looks like I have a way now! I was just able to run PARK.COM from the SD card! Mission accomplished!

Good.