I’m trying to boot an old IBM PS/1, mostly with the intention to read out its hard disk. I realized quickly that the original floppy disk drive was broken, so I replaced it with a Gotek floppy emulator, following these instructions. As a last step, the instructions tell me to run CONFIGUR.EXE, which would supposedly make the machine detect the newly-installed drive. I assume that CONFIGUR.EXE would reside on the HDD. Now, it seems like the HDD was compressed using DriveSpace/DoubleSpace.

I can boot into the IBM four-quadrant screen just fine. Then, after choosing “Your Software”:

  • When I try opening the A: drive, I get an error message that there is no disk drive, presumably because I didn’t run CONFIGUR.EXE yet to detect it.
  • When I try opening the C: drive and choosing COMMAND, I get an error message that I’m running the wrong DOS version.
  • When I choose “DOS Prompt”, I get a familiar PC DOS 4.0 command line. I can’t run most DOS commands, though (Bad command or file name). DIR works however, and shows a single file called HOST_FOR_C

Unfortunately, the IBM PS/1 HDD uses a proprietary connector, so I can’t just connect it to another machine using a standard IDE connector.

Is there any way out of this situation that you can think of? Thanks for any advice!

  • 1
    You mean, you managed to get to this menu? What happens if you choose ‘IBM DOS’? Commented Oct 10, 2020 at 14:14
  • yes, this is the menu that shows up. Choosing 'IBM DOS' just tells me to insert a DOS Disk
    – Matthias
    Commented Oct 10, 2020 at 14:47
  • Let us continue this discussion in chat. Commented Oct 11, 2020 at 15:15

3 Answers 3


Note: The solution below ultimately failed to work for the asker as-is. I presume this is because my printable auxcopy binary was not written well enough to operate correctly on bare hardware (it was only tested in a VM); perhaps this flaw can be easily corrected, but I am not yet able to see how. Nevertheless, as it seems to have served as a major inspiration for the asker’s own solution, I am leaving it here for posterity.

Based on the question body and subsequent clarifications in the chat, the asker’s situation is a quite tricky one. The floppy drive is currently non-functional and is yet to be configured by a separate executable, which is not available at the moment. There is apparently a copy of MS-DOS 6 stored on a DoubleSpace-compressed disk, but it cannot be booted either. The only operating system that the asker can boot is a copy of PC DOS 4.0 stored in the machine’s ROM.

But that should be enough.

The PS/1 contains one other piece of hardware that you can use to transfer data between it and the outside world: the serial port. Using a null-modem cable, you can connect two PCs directly and send data from one to the other. To have data transferred via the serial line properly delimited into files, you will need a file transfer program. For example, a program whose binary code is as follows−1:


You can enter this program into the machine from the keyboard, using the command copy con auxcopy.com; when done, press Ctrl+Z (or F6) to return to the DOS prompt. This program has been carefully constructed to ensure this is possible to do by maintaining the following properties:

  • All the bytes other than line breaks are printable ASCII characters, readily possible to enter from a US-layout keyboard.
  • No line is longer than 80 lines; this is to accommodate the line buffer size of 128 bytes.

Other than line breaks, there are no whitespace characters in the binary. The line breaks are supposed to be encoded as CR+LF (as they usually are under DOS). Pay attention to confusable pairs (like O vs 0, 5 vs S, ' vs `, etc.) when typing the file in.

I expect the compressed hard drive to contain just enough free space to let this small executable and a little more data fit in the uncompressed area; DoubleSpace by default leaves some amount of free space available there.

What this program does0 is read a slightly modified form of base641 from the serial port and writes decoded data to standard output. This modified base64 can be generated from a given file by the following Unix command:

base64 -w0 < "${file}" | ( tr 'A-Za-z0-9+/=' '0-o~'; printf \~ )

After creating the executable on the DOS machine, launch it as follows:

C:\>AUXCOPY > file

Then, on the other end of the null-modem cable, send the encoded file over the serial port. The AUXCOPY program will exit when the transfer finishes (as long as the final ~ character is present). The serial port may need to be configured beforehand; on the PS/1 side that should be possible to accomplish by using the MODE.COM executable stored with the ROM DOS.

With this transfer program, you now have a good chance of bootstraping yourself out of this situation. You can use it to transfer any of the following:

  • The CONFIGUR.EXE program that will allow you to enable the floppy drive.
  • System files from the MS-DOS 6 distribution, such as SYS.COM, IO.SYS, MSDOS.SYS, FDISK.EXE, DEBUG.COM and COMMAND.COM, to attempt to repair hard disk boot (or set it up in the first place)
  • A more sophisticated serial file transfer program (supporting things like error correction), allowing you to extract files from the PS/1 over the serial port.

−1 I wrote — well, constructed, the process was partially automated — this one myself, actually. I might post source code somewhere someday; I think the way I managed to create this program is quite interesting on its own. For now, I’ll leave it here as a puzzle for reverse engineering junkies.

0 I tested it with a pair of QEMU instances whose serial ports were connected to each other via a FIFO.

12 The modification to base64 makes it simpler to decode, so that the decoding program is shorter.

2 This superscript is both an exponent and a footnote.

  • 1
    Thanks for your detailed answer! Unfortunately, I can't quite get this to work. I configured the serial port on the IBM PS/1 using mode using MODE COM1:9600,N,8,1,P. I tried to mirror those setting on my linux laptop using stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb. I subsequently try to send my enocded file using cat ${enc_file} > /dev/ttyUSB0 upon which the command line immediately returns, and nothing happens on the IBM.
    – Matthias
    Commented Oct 29, 2020 at 15:52
  • 2
    @Matthias: I think you can try ctty com1 to try out your serial connection. If it works then you can control DOS from a terminal program running on the other machine. You might even get away with entering the auxcopy machine code through a terminal like this.
    – ecm
    Commented Oct 29, 2020 at 16:26
  • 2
    this is spot on. I can indeed connect to the IBM PS/1 using ctty com1 on the IBM side and the minicom utility on the linux side. This means the cabling is correct and can be eliminated as a source of error.
    – Matthias
    Commented Oct 29, 2020 at 16:43
  • 2
    Did you try sending a sample text file first (e.g. base64 -w0 < /usr/share/common-licenses/GPL-3 | ( tr 'A-Za-z0-9+/=' '0-o~'; printf \~ ) > /dev/ttyUSB0 on the Linux box and just launch auxcopy on the PS/1 without redirecting the output)? Did you use ctty con to switch the terminal back? Commented Oct 29, 2020 at 20:57
  • 2
    Hmm. What happens if instead of auxcopy you run type aux or type com1? Does text get transferred cleanly? Does binary data? Commented Oct 31, 2020 at 16:00

I'm going to describe a process that worked for me. If you should happen to be in the same situation, I'd strongly recommend you try the procedure outlined by user3840170 in their answer. It is a much more sensible approach, however it did not work out for me, most likely because I failed to correctly set up the serial port on the Linux end for their auxcopy program to work.

To bootstrap out of this situation, the general plan is to connect a Linux machine to the IBM PS/1 using the IBM's serial connection.

First of all, buy a USB to null-modem adapter cable as well as a null-modem DE-9 to DB-25 connector. Make sure that the latter is in fact a null-modem adapter, since there are different pinouts for these things. On the Linux machine you need ckermit and optionally minicom. To test the cabling, boot both machines. On the IBM, enter mode com1:300,n,8,1,p and on the Linux machine launch minicom and set up the serial port to 300 baud, 8N1 (Ctrl+AZO → Serial Port Setup). After typing ctty com1 you should see the familiar C:\> prompt in minicom. Return the control to the IBM by typing ctty con in minicom.

The next step is now to input a small program that is able to receive text using the Kermit protocol on the IBM. Its source can be found here. It reads:


There is a DOS line break (CR+LF) after the first two lines but not the last one. I entered the program line by line using e.g.

C:\>copy con line1

(^Z is Ctrl+Z or alternatively F6) and subsequently copy line1+line2+line3 tcom.com. This way, you only have to re-type one line if you mess up. To check your program, you can connect using minicom, issue type tcom.com and compare the output e.g. using diff. tcom.com should also exit upon hitting the Esc key.

We will now use tcom.com to copy a small utility to the IBM machine, which is able to extract a BOO encoded file to a DOS executable, which can be found here. Copy the code to a text file called msbpct.com and make sure you set line endings to Windows/DOS (e.g. gedit supports this on Linux). On the IBM type tcom.com > msbpct.com. Then launch ckermit and enter:

set line /dev/ttyUSB0
set speed 300
set parity none
set local echo on
set transmit linefeed on
set transmit prompt \0
transmit msbpct.com

Then put a weight on the Return key of the IBM (I'm not making this up, it is not working without this for me). C-Kermit shows what has been written to the serial port already, and, after some time, should return to a Kermit prompt. Leave the weight on the Return key for a minute or so, then hit Esc. msbpct.com should now be successfully transmitted; when executed, it should give a usage hint message and return.

The next step is to encode our payload as a .BOO file and transmit it the same way. The file I required was CUSTOMIZ.EXE, which I obtained from here. The C source of a program to encode a binary file to .BOO can be found here. Compile it and use it to encode your payload like this:

gcc ckbmkb.c -o msbmkb && ./msbmkb CUSTOMIZ.EXE CUSTOMIZ.BOO

Finally, enter C-Kermit one last time and use it to transmit the .BOO file: simply replace transmit msbpct.com with transmit CUSTOMIZ.BOO in the Kermit session above (and likewise launch tcom > CUSTOMIZ.BOO on the PS/1). Repeat the “weight on Return” spiel as before. Now, enter msbpct.com CUSTOMIZ.BOO which will unpack CUSTOMIZ.EXE. In my case I had to simply run it, and chose hard disk boot from the GUI menu. Since then, my IBM PS/1 is booting from hard disk without hassle.

  • 1
    Perfectly sensible approach; I don’t think you need to recommend my solution over this one. I very much suspected some kind of printable file-transfer program like this existed already; had I known about this pair, I would have suggested you to use it. I only tried assembling my own after being unable to find an existing solution. Commented Nov 4, 2020 at 9:55
  • 2
    The Kermit project may not be at Columbia forever: its permanent home moved after the university cancelled the project nearly a decade ago. A better link for the source might be ftp.kermitproject.org/kermit/ckermit/ckbmkb.c . But yes, using a Kermit boot to get data to/from an unknown computer for the first time is a time-honoured technique
    – scruss
    Commented Nov 5, 2020 at 13:06

DOS 4 does not have DoubleSpace.

DoubleSpace was introduced in MS-DOS 6.0, improved in MS-DOS 6.2, removed in 6.21 due to a successful lawsuit from STAC Inc., and replaced with DriveSpace in MS-DOS 6.22.

If you are sure it is DoubleSpace not DriveSpace, then you will need to find a bootable disk image with MS-DOS 6.2 or failing that 6.0. (The matching versions of IBM PC DOS should work too, I think.) Boot from that disk image using your Gotek and it should be able to mount the compressed drive.

If you can access it, MS-DOS 6.x contains InterLink. This is MS' equivalent of Laplink, and will let you (very slowly) move the files off over the serial link that you say you have.

Failing that, you could probably find a copy of LapLink on an abandonware site. It can transmit itself over a serial cable.

However, this will not help you mount a DoubleSpace-compressed drive. You need MS-DOS 6 or later for that. You need to solve the DOS boot disk issue and mount the DoubleSpace volume before addressing the file-transfer problem.

It is possible to uncompress a DoubleSpace volume into a standard disk. If it is less than (approximately) 50% full you can do this in-place. If it is over 50% full, you must free up space to do it in situ. In that event, it is probably easier to fit a second drive, copy all the contents onto that, make it bootable, then disconnect the compressed drive. A circa 512MB CF card in a CF-to-IDE connector would do very well for this; then you could insert the CF card into a more modern computer to retrieve the contents.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .