Reviving MS-DOS 5.0 on my retro PC

2024-01-20

... using a bit of modern technology.

(This blog post was written using Tim Baldwin's T on DOS.)

I have exactly one "old" PC at the moment, a Pentium 133. I put "old" in quotes because this thing has a lot of modern stuff in it: First, it's a Pentium (it can run modern OpenBSD including X11), then it has an Ethernet NIC so it can easily go online, it has a CD drive, and it has PCI slots. This CPU is already superscalar and what not.

For a while, I desperately wanted to get an older one, but some part of me kept say, "dude, no": Accumulating so much stuff goes against my principles of minimalism. (Not that I'm strictly a "minimalist". Just to some degree.) So, for now, I decided to stick to my P133 and don't get anything else. And, honestly, I like this box very much. Most importantly because it's not just some random machine but it really is my PC from back then.

I did want to get a more DOS-focused experience, though. The oldest version of DOS that I have in my archive is MS-DOS 5.0. I wanted to install that (on a separate hard disk), no Windows or OS/2. And no Ethernet.

Installation without floppies

So, step 1, how do I get it on the machine? I have some floppy disks left, but many of them are beginning to fail. The last batch I bought was probably more than 15 years ago. So I was looking for an alternative.

One approach that works very well with simple systems like DOS is using virtualization on a modern machine: Install DOS in a VM on a Linux box and then copy the resulting image to an actual hard disk.

First, prepare a new disk image:

$ qemu-img create -f qcow2 msdos50.qcow2 32M

I went with qcow2 here, because I want to keep the image on my normal workstation for use with overqemu. For the purpose of this blog post, raw would have been sufficient.

Then install DOS from floppy disk images:

$ qemu-system-x86_64 -enable-kvm -cpu host -m 32 -smp 1 \
    -drive file=msdos50.qcow2,if=ide \
    -drive file=msdos50-1.img,if=floppy,format=raw \
    -boot a

The installation process is super fast and painless. Afterwards, you have a basic DOS running in your VM:

Preparing for data transfer

Assuming I get this image on a real hard disk -- then what? How do I get programs and data on my old machine? I didn't want to use Ethernet but something more "period correct". Back in the day, we used one of three options: The obvious one is using floppies. That's out of the question for me, it's just wasting material and probably won't work anymore 5 years down the road, because I'm running out of floppies (and they have become expensive as fsck).

The next option would have been "Kirschbaum-Link", which we used for some time in the 90'ies. I guess this was a German product and international readers probably don't know it. I couldn't find any info about it online. The way it worked was: You connected two PCs using a (special?) parallel port cable and then you could transfer files. I think this was similar to mounting an NFS share on UNIX, but I really hardly remember. Anyway, Kirschbaum-Link isn't an option for me today, for two reasons: a) I want to copy files from Linux to DOS and that would be very cumbersome with some arcane thing like Kirschbaum, b) I don't have the software anymore. %) The only thing that's left is this cable:

So, the last option was using a serial cable and some "terminal" program. That is rather low-tech and doesn't require special components, I like that a lot. If I do get another old machine at some point, then this approach will probably work there as well. Plug a USB-to-serial dongle into my laptop and then connect to the DOS machine using a null-modem cable. That is already enough to be able to send some text messages -- but it's a bit cumbersome without special software.

My DOS program of choice here is "Telemate". I'm using version 3.10, which I have kept around since the 1990'ies. It even still had the configuration that we used to connect two PCs. Neat!

I copied Telemate to C: of my DOS VM as well.

Dumping the disk image to a hard disk

First convert the QCOW2 file to a raw disk image:

qemu-img convert msdos50.qcow2 dos.raw

Then somehow connect the drive to your machine and use dd to copy the data. Luckily, I still have an USB-IDE-cage, which made this step very easy:

Booting DOS and using Telemate

After installing the HDD in my other machine, DOS boots. Just like that. There are no drivers or other system configuration involved yet. It's all still very simple.

And there you go, Telemate:

(I had to redact some info here, sorry.)

Note the timestamps from 1993? Apparently, that's when this installation was last used by us. Crazy. (I wasn't the primary user of those mailboxes, though, I was still very young back then.)

Telemate supports -- among many other things -- ZMODEM to transfer files. On Linux, I'm using lrzsz and this little wrapper script:

#!/bin/sh

# Requires some udev rule like this:
#
#    SUBSYSTEM=="tty", ATTRS{idVendor}=="....",
#        ATTRS{serial}==".....", SYMLINK+="nullmodem"

# Due to bugs, you also need symlinks, i.e. "rz" and "sz" must exist in
# your $PATH.

case "$1" in
    sz)
        if [ -z "$2" ]
        then
            echo "Usage: $0 <rz|sz> <filename>" >&2
            exit 1
        fi

        args="sz $2"
        ;;
    rz)
        args="rz"
        ;;
esac

exec 32<>/dev/nullmodem

stty ispeed 115200 ospeed 115200 parodd cs8 -cstopb --file=/dev/fd/32

# Should be this:
#lrzsz-$args <&32 >&32
# But bugs. Use this and symlinks:
$args <&32 >&32

About those "bugs": Arch has recently renamed the lrzsz binaries. That program has a couple of hardcoded strings, though, so receiving files is now broken. I guess hardly anyone uses that these days, so it went unnoticed. I'll file a bug later. (Someone beat me to it.)

I'm aware that there are other ZMODEM clients. The above has the advantage that it's usable from the shell on Linux -- no interactive program needed.

The wrapper is needed because lrzsz cannot configure the serial port directly. And this configuration doesn't appear to be "persistent" -- the port resets when the file descriptor gets closed. Hence this little dance with exec 32<>....

And there you go, I can copy files:

Works in both directions.

It's not fast, but that doesn't matter, the files are all very small. But it is a bit wonky at times. Maybe the cable is bad (it's about 30 years old, maybe I should get a replacement) or the port on my old machine is. Good thing is that CRC32 is used, so errors are usually detected.

Conclusion

Alright, that was surprisingly easy. I'm all set up now to do some more Assembly experiments on DOS. I'll probably use NASM for that. There's a lot to learn and to explore, for example: How to write a TSR in DOS. Or maybe I'll write my own little ZMODEM replacement. Or more games.

Comments?