HOWTO: Get data in or out of an early IBM PC or clone

SomeGuy

A common question when dealing with early IBM PC clones is "how do I get data on or off of the machine?"

I thought I would quickly write up an outline of the different methods I'm aware of to get data and software in or out of an early IBM PC or clone. Sadly, it is not always quite that simple.

For comparison, Apple II computers have it fairly easy, as they have fairly standard hardware and a powerful BASIC system built in to ROM. All one has to to is type in "IN#1" at the basic prompt, where "1" is the serial card slot, and any remote serial device can type in basic or machine code. This makes it dead simple to upload an OS and software even if you had no Apple II boot disks. It even has a popular program for the job: ADTPro

IBM PCs, and clones vary quite a bit in their configuration and compatibility. To summarize, early PCs have the following I/O capabilities:

• Floppy disks
• Floppy controller I/O
• Cassette I/O (IBM 5150 and PCJr only)
• ROM Basic (Genuine IBMs only, not clones)
• ISA slots (laptops/compacts often lack these)
• Hard disk I/O
• Serial Port
• Parallel Port

Back in the day, the standard way to move data around was floppy disk. "Modern" lobotomized computers no longer have this ability built in. As such, there several different floppy related option to consider.

Kryoflux/SuperCard Pro:

• Requires a KF/SCP card and another matching floppy drive
• Can read and write copy protected floppy software
• Useful for platforms other than IBM PC
• Tedious, since you can't just copy files

This is my personal favorite as it enables me to read and write most protected disk images. IBM PCs were designed to primarily boot and run off of floppy disk, so this enables me to use a PC as-is with no modification. Images are read and written all at once, so it is not as easy as dragging and dropping files. It enables me to read and write copy protected disks, non-dos disks, and booters. I also don't have to worry if a target machine is even IBM PC compatible at all. It is not ideal for backing up or restoring hard drives, as that may require reading, writing, and switching many disks.

Floppy disk "tweener" system

• Requires another computer and matching floppy drive
• 360k disks can not be reliably written by 1.2mb drives

A "tweener" is an in-between system that can transfer data between an earlier PC system and a "modern" computer. Typically such a system is any Pentium or Athlon era PC with a floppy disk controller that supports 360k, 720k, 1.2mb and 1.44mb drives. The tweener is used to read or write floppy disks, and then can transfer files to other computers over a network, USB drives, or various other methods. Some of the last motherboards with floppy controllers are perfectly capable of running Windows 10, but since some disk writing utilities such as ImageDisk require DOS or direct FDC access, Windows 95 OSR2 or Windows 98SE are preferred.

XT-IDE/XTIDE Universal BIOS

• Requires XT-IDE or ROM and CompactFlash cards
• Requires an ISA slot, or alternatively a ROM socket and serial port
• Can co-exist with most 8-bit MFM controllers
• XTIDE BIOS supports emulating a drive over serial
• Bootable!

The XT-IDE is a new hobbyist-created device that adds the ability to use an IDE drive, SATA with IDE converter, or CompactFlash card as a hard disk to almost any IBM PC/XT/AT or clone that has an ISA slot. The XTIDE Universal BIOS adds the ability to select boot from different devices, swap drives at the BIOS level, and access larger drives. This makes it almost ideal for backing up or restoring MS-DOS formatted MFM/RLL hard drives.

The XT-IDE's main purpose is to replace a hard drive entirely. If you use an XT-IDE with a removable CompactFlash flash port, you can simply take the CF card to any computer with a CF card reader and directly read or write files.

The XTIDE Universal BIOS can actually be used without the XT-IDE hardware. It requires an EPROM chip, and a ROM socket, such as those found some network adapters. Some motherboards may have option rom sockets directly on the motherboard. In this mode, it can enhance the capabilities of an existing IDE interface. It can also emulate a hard drive using a serial port connected to another computer.

The main downside is that laptops or compact machines may not have the expansion necessary to add either form of hardware. Likewise, it only supports IBM PC hardware compatibles.

One other note: CF cards should usually be partitioned and formatted on the target computer - requiring that a DOS boot disk already exist. It is technically possible to set up a boot image in an emulator, but you must know exactly what drive geometry the target system will expect.

Laplink (Intersvr)

• Requires a compatible serial port or parallel port
• Requires nullmodem cable or special parallel cable
• Requires DOS to already be on the target computer
• Laplink can "bootstrap" itself but others need the software on both
• "Modern" computers don't have serial/parallel and USB usually won't work

Back in the day, a popular way to transfer files between computers was to use a "nullmodem" serial cable or "Laplink parallel" cable and the Laplink software program. There were various similar software products such as Interlnk/Intersvr included with MS-DOS 6.x. You simply connect the cable between two computers, run the software, and you can copy files back and forth.

Laplink has the ability to "bootstrap" itself to a target machine even if the machine does not already have the Laplink software. However, the target machine must already have DOS, either booted from a floppy or on a hard drive. So this is not much use if an IBM 5150 falls in your lap with no boot floppies. The target machines must also have standard PC compatible serial ports. A few early clones did not.

Nullmodem serial cables or adapters are easy to find, and easy make. They are basically standard serial cables with the signal wires reversed. Laplink parallel cables are not as common. Parallel can be faster, but serial is usually less hassle.

USB to serial adapters are garbage and usually will not work. PCI/PCIe serial and parallel port cards make it possible to add real hardware compatible serial ports to newer desktop computers.

Parallel Port Zip drive

• Native ZIP software is not compatible with plain 8088/8086
• Use USB Zip on newer computer

A popular way to get data on or off of a PC is with a Parallel port Zip 100mb drive. During the late 90s, iOmega produced a line of storage devices called the "Zip" drive (no relation to PKZip!). They were small floppy-like cartridges that could store 100mb of data. They came in parallel port, SCSI, IDE, IDE/ATAPI, and USB varieties.

Zips drives were quite common until USB flash drives took over, so they can be found fairly easily on eBay. One can attach a parallel port Zip to an earlier computer, and a USB, SCSI or IDE Zip to a "modern" computer or "tweener" and transfer files between them. SCSI Zip drives are also very useful on Macintosh computers (Mac Plus or later).

Simply attach the drive to a parallel port, and install the DOS or Windows software. Zip disks will be visible as a drive letter.

The main installation drawback is that the iOmega DOS driver software will not work on a stock 8088 or 8086 CPU. It requires a NEC V20/V30, 80186, 80206 or later. There is an non-free alternative to iOmega's software called Palmzip. I Thought someone had hacked iOmega's drivers for 8088 compatibility, but I couldn't find them off hand.

I have had no luck using an IDE Zip via an SATA converter, even when the SATA chipset is in IDE emulation mode.

Backpack parallel 1.44mb floppy or CD-ROM.

• External drive
• Sort of slow
• Neither are bootable and requires DOS already on the target computer

Similar to the Zip drive, Microsolutions produced a line of parallel port connected floppy drives and CD-ROM drives called Backpack drives.

Backpack parallel port external CD drives were very useful for loading up ~386/486 laptops that had no built in CD drives. They also made a similar parallel port external 1.44m floppy drive. An advantage to this is that the target computer's floppy controller does not have to support high density.

The downside to both of these is that neither are bootable. Before you can use either, you must have DOS and the appropriate Backpack drivers loaded.

Ethernet Network/net booting

• Requires an ISA network card
• Requires MS LanManager, mTCP, or other software
• Remote booting requires a boot rom and is not a common option
• Without a boot ROM you must already have DOS and drivers
• This can get REALLY complicated

It used to be you couldn't throw a rock in an IT office without hitting an ISA network card. There should still be plenty around. Having a computer directly on a LAN is a convenient way to transfer files around. However, setting it up, especially on an 8088 based computer can be incredibly complicated.

If you wanted to go this route, in a nutshell, you would want an ISA network card with an NE2000 compatible chipset (usually Realtec), an RJ45 port, and an option ROM socket. These will usually be 16-bit ISA cards but can be configured to operate on 8-bit ISA. In some cases the configuration software may require a 286 AT, but once configured the card should work on an 8088 based machine.

The two main TCP/IP clients to consider are Microsoft LanManager for DOS, and Mike Brutman's mTCP. These can both be made to run on an 8088 with 640k, but require some disk space. (A LanManager boot floppy usually requires a 1.44mb disk). I won't go in to installation or configuration here. Normally, you must already have DOS boot disks and disks containing this software.

It is possible to boot directly from a network card using an option ROM. I'm not sure what the best options for this are currently. I recall there were some free/open source solutions. Setting up a boot server usually requires intimate knowledge of Ethernet protocols. Again, I won't go in to details here.

Serial Networks

• Lantastic Z
• Slow compared to Ethernet

It is also possible to "network" two computers using a serial port. The difference between a network and Laplink is that a network will present the remote computer's storage as a drive letter, available to all running applications. Laplink just downloads/uploads files while the application is running.

One such product is "Lantastic Z". This was a special lower-cost version of the Lantastic networking software that only supported serial transfer. Some other networking product may support serial or parallel port connections, but I'm not familiar with those.

Moving MFM/RLL controllers between systems:

• MFM/RLL cards don't like Pentium era machines
• Controllers are not interchangeable
• Hard to find extra drives!

A tempting way to retrieve or load software from an 8088/8086/286 class machine is to take the drive and/or controller out of that machine and put it in a somewhat later machine with an IDE drive or one or more of the other solutions listed here. Unfortunately you can run in to lots of problem.

Boards with ISA slots were made up until about 2001. Some of these supported very fast, later produced, Pentium and Athlon CPUs. However, towards the end, the compatibility dropped. Some late Intel chipsets do not support DMA, and some devices conflict with on-board resources. In practice, placing an ISA MFM or RLL controller in anything later than a 486 is likely to have problems.

It is very important to be aware that MFM/RLL drives usually CAN NOT be moved between different controller models. Every controller implemented slight incompatible tweaks to their low-level format. If you attempt this, the drive will appear blank, as if it were never low-level formatted. Unless you happen to have an identical controller, you MUST keep the drive's controller with it.

It is also worth noting that there is an odd issue where 8-bit PC XT MFM/RLL controller cards operate much slower when they are moved to AT class (286/386/486) system. If you are just transferring data don't worry about it. If you plan to permanently use the controller in a different system, then run Spinrite to optimize the disk interleave.

Of course, if you need to use a temporary or spare MFM/RLL drive, tested working drives are now very expensive on eBay!

SCSI

• 8-bit SCSI is very uncommon
• Access to more drives, zip drive, or other storage devices
• Bootable (if no conflicts)

Similar to an XT-IDE, one might consider plopping in an ISA SCSI card. SCSI cards can access a wide array of storage devices. Since they normally have their own BIOS, they can boot any attached hard disk. (Some cheap SCSI cards only meant to run a tape drive or scanner may not have a BIOS)

The main down side is that 8-bit ISA SCSI cards were very uncommon, and almost no 16-bit ISA were 8-bit compatible.

Another down sides is that most SCSI cards were not really designed to share a system with another hard disk controller. The computer may not know which drive to boot, which drive letter to assign to what, and DOS or some tools might wind up writing to the wrong drive corrupting it.

Adding a 1.44mb drive:

• Only operates as 720k without a high density card
• Not all USB floppy drives support 720k
• High density card requires an ISA slot

It is possible to add a 3.5" 1.44mb floppy drive to an IBM PC/XT/AT and many clones. Back in the day, this was a common upgrade to give such machines more life.

A standard PC or XT class system only supports low density drives. It is still possible to attach a 1.44mb drive, but it will only read or write low density 720k disks. To attach a 3.5" drive you need a floppy cable that has a card-edge plug at the FDC end and an IDC plug at the floppy end. (There are also adapters, but floppy cables are easier to find and easy to make). You may also need a molex to 4-pin floppy power adapter (still sold at computer stores).

You can cover the density notch on most 1.44mb disks and re-format them as 720k. This usually works fine, but such disks are not recommended for long term storage.

1.44mb USB Floppy drives are SUPPOSED to support 720k low density disks, however many cheaper ones do not. Make sure you obtain one that supports 720k.

On a PC/XT class computer, MS-DOS will always assume the drive is 360k but will access pre-formatted 720k disks just fine. Either use a third party formatter, or add the DRIVPARM statement to DOS 5/6's config.sys.

Windows XP and later stupidly remove the option to format 720k disks from the GUI formatter. Use the command line formatter instead.

It is possible to add full 1.44m high density disk support to an IBM PC or XT, or any clone with an ISA slot, by installing an 8-bit high density floppy controller card. Unfortunately these are very highly sought after today and sell for lots of money on eBay.

It is possible to get partial 1.44m high density support in an 8-bit ISA system by using a 16-bit floppy controller (usually the FDC portion of a Floppy/Hard Disk controller). The drawback is PC/XT BIOS won't recognize this. You must load a software driver AFTER the system is booted from a hard drive. It will not boot normal MS-DOS, but somehow DR-DOS manages to boot. There does exist a free generic floppy BIOS extension that can be added to an empty motherboard or network card ROM socket. A bit of a hack, but it works.

The early IBM AT (IBM model 5170) comes with a high density controller but requires a motherboard BIOS update to fully support 1.44mb drives.

HxC/Gotek floppy drive emulators

• Can store multiple disk image in one flash device.
• Bootable.
• Heresy! Buy real floppy drives! Better yet, buy a dozen!

Oh, alright, if you absolutely must, there are several hardware devices that emulate floppy drive hardware. You can plug one of these in place of a standard IBM or "Shugart" style 360k/720k/1.2mb/1.44m floppy drive. It stores all disk images in a single flash storage device, which you can remove and take to "modern" machine. Some of these can handle copy protection.

The main advantage is these can store many floppy disk images in one flash device. The primary use for these are gamers that want to easily select from a large floppy software library. They are also sometimes used in industrial/embedded situations where reliability must be much higher than a standard floppy disk.

Since these directly replace a floppy drive, the target machine will boot any bootable disk images.

MFM/RLL drive emulator

• No need to replace the controller
• Not really useful for inter-operation
• Quickly duplicate an entire drive

There are a few hobbyist boards that directly replace an MFM or RLL ST-412/ST-506 interface hard drive. Once such board is here: https://www.pdp8.net/mfm/mfm.shtml . Although I have never tried it, supposedly these boards are also designed to READ and duplicate an existing hard drives at the low-level format level.

This sort of thing is very useful for computers, especially non-PCs, where a replacement controller is not an option.

The upshot is it duplicates hard drive signalling at a low-level, so it can be used with any MFM (or RLL?) controller.

The downside is that most controllers are not compatible between models, and I don't believe you can extract or insert data directly to the stored images.

This means, while you can boot one of these, you can not prepare a bootable image elsewhere.

Hypothetical - Serial bootstraping from ROM BASIC

• No one has done this yet?
• Genuine IBM PCs may not always have a serial port.
• Clone PCs do not have ROM basic
• A few clone PCs have monitor ROMS

Genuine IBM PC, IBM XT, IBM PCJr, IBM AT, IBM PS/2, and I think even some of their earlier laptops, boot to ROM BASIC when no other boot media is present. However, ROM BASIC knows nothing about DOS or accessing floppy disks.

I am not aware that anyone has tried this, but the question has been raised often as to why someone could not bootstrap an IBM PC via a serial port using BASIC similar to how ADT Pro bootstraps an Apple II.

There are a few reasons for this:
- An IBM PC may not always have an serial card (AKA "IBM Asynchronous Communications Adapter").
- IBM ROM BASIC has no serial redirection - you would have to manually enter lots of bootstrap code.
- IBM PC clones do not have ROM BASIC. (A few exceptions with pirated ROMs)
- Some PC clones do not have 100% hardware comparable serial hardware.
- Some IBM PCs with third party serial cards may be incompatible or configured oddly.
- Some IBM PCs with third party BIOSes may not have BASIC.
- Later 1990s IBMs do not have ROM BASIC.

A few PC clones such as the Zenith Z-150 and Columbia Data Products 1600 MPC have a monitor program similar to DEBUG built in to ROM. It is similarly theoretically possible one could enter a machine code bootstap in to these machines. But again, that is a lot of data entry, and each of these are a bit different.

(Actually, the CDP 1600 has an option that lets you control the BIOS and even DOS headlessly via a serial console port. It's just that awesome of a machine).

So, it would be interesting to hear if anyone ever tries this, but it's usefulness is somewhat limited.

Going a step beyond this would involve adding ROM. But then we already have the XT-IDE universal BIOS, described above. (If you are really lucky, perhaps you have a Tandy 1000 with DOS in a ROM disk. )

Hypothetical - Bootstrap over cassette port?

• Only applicable to IBM PC 5150 and PCJr
• No one has done this?

The IBM PC, model 5150 and the IBM PCjr include a cassette tape interface port. There were only two known commercial IBM PC cassette-based applications: IBM Diagnostics, and Microsoft Typing Tutor. Cassette interfaces were popular in less expensive home computers. However this died out as floppy drives became cheaper, just after the release of the IBM PC.

In theory, one could load a cassette BASIC program that, in turn, writes a floppy disk image or bootstraps a serial device.

This would be interesting, as writing a disk image might not require a serial port. An audio signal could be fed in from various "modern" devices including MP3 players or another computer's audio output. IBM never sold cassette connector cables, but they use the same as the TRS-80 and are not hard to make.

The main disadvantage is that the IBM XT, AT, and clones do not have a cassette port. This also requires ROM BASIC, however BASIC is reliably present in the PC and PCJr. Another issue is how much information one can store in a single cassette BASIC program.

Hypothetical - Automatic keyboard entry?

• Crazy idea

It IS one of the primary I/O devices. In theory one could perhaps attach SOME device to automatically type in bootstrap code. But similar to serial bootstrapping, it also requires ROM BASIC. Most clones and later machines have ZILCH you can do from the keyboard if no boot disk is found.

The only advantage to this would be less typing, and the main disadvantage is there is no standard hardware to automatically transmit PC/XT keyboard protocol signals. Another disadvantage is that IBM AT and later machine use a different keyboard protocol, and many clones used oddball keyboard interfaces.

--

At any rate, that is everything I can think of off hand. If anyone has any other ideas or alternatives, please discuss them.

SamirD

Ah, the days before networking...

So I used laplink a lot back in this era and we even had at least one set of both the serial and parallel cables (and still have them somewhere). While serial was the easiest to set up, parallel was at least 5x faster and wasn't much harder to get working (plug it in pretty much). The problem with laplink was that it was limited to their software and their software interface, which while good, wasn't the absolute best.

What brought a whole new level of capability was the interlnk/intersvr provided with MSDOS6. It basically separated the client and server side softwares. At first this looks like a huge disadvantage as it was more tedious to set up than just booting to DOS and running laplink. But the advantage was on the client side (which if memory serves me right was installed in the config.sys)--once this was installed, the 'server' (intersvr) drives appeared as regular drive letters on the 'client' interlnk system.

This was a game changer because then you could use anything you wanted to copy or manipulate files. In fact, (if memory serves me right) even the windows 3.1 file manager worked with it. On the 'server' side, you just ran intersvr and there was nothing to install like on the client side. So if you had a system that was your 'diagnostic' or 'toolbox' system (like a laptop) configured with interlnk, then you could simply run intersvr on any system you connect to and that laptop would have access to the drives.

And once the computers were connected, it really didn't matter who was the server or who was the client. For the purposes of moving data to/from a PC XT/AT, it wouldn't be simpler to just boot to DOS and run intersvr and then let the other computer have access to the drives. It is almost like networking (which we later did also have set up using a xircom pocket ethernet that connected to the parallel port, but it wasn't any faster than laplink/interlnk/svr so we just used interlnk/svr instead).

My brother used this extensively as he was actually the first computer lab manager in our high school because we figured out how to lock down window 3.1 from changes. And whenever someone would undo that somehow, he simply connected the messed up system to another one in the lab using interlnk/intersvr and would restore the changed files. He was able to manage 40 systems single handedly with just a set of laptlink cables that the school bought for him. Later on, I wrote batch files that automatically restored these systems at startup. And I wrote the same for locking down win95 and win98se from changes.

I love SCSI. I still do. It was the best and still is the best.

And there was a very, very common 8-bit scsi controller that worked with a lot of different systems, even those that others wouldn't. (We have one installed in our PS/2 30-286 that runs along side the factory installed drive.) This controller was the Seagate ST-01 and the ST-02. I believe the only difference between these was that the ST-02 had a bios for booting, but the ST-01 did have a boot eeprom socket so I think conversion was possible. (Now, this is all coming from memory from the early 1990s--over 30 years ago!--so I may not have remembered some of this correctly.)

One of the issues the ST-01 (and probably/possibly even the ST-02) was that it did not handle drives over 1024 cylinders. The reason I remember that is because the Quantum 240MB drive we had installed had <1024, but a Maxtor 213MB did have >1024 (1310 according to the specs found here--https://stason.org/TULARC/pc/hard-drives-hdd/maxtor/LXT-213SYD-213MB-3-5-HH-SCSI1-DIFF.html) and didn't show up as full size. Over the years I think a ROM corrected this, but we couldn't boot the PS/2 factory drive with the ROM so we never installed it (and we probably still have it somewhere as well). If you can find an ST-01/02 with a boot rom, it will be a nice controller to use with a period correct SCSI drive.