A Small Exercise in Computer Archeology

My first computer was an Atari 1040STF, which I used until about 1995, when I replaced it with an HP 715/50 workstation. I put the Atari away in the attic, where it remained for the last 18 years.

While staying with my parents over Christmas, I decided to finally get it out and determine whether it would still work (and thus whether to keep it or dispose of it), and to try and get the data off its hard disk. There wasn’t anything terribly important on the hard disk—otherwise I would have done this earlier—, so there wasn’t really anything at stakes, but I thought it might be an interesting exercise in computer archeology.

My Atari ST
My Atari ST

The first problem with computers from that era—apart from dead power supplies—is to find a suitable monitor and the right cable. Atari used a proprietary DIN-style connector for either attaching an SM124 monochrome monitor or a color monitor. My SM124 had died, but I still had a cable for attaching the Atari to a TV’s SCART input. Luckily, even today’s fancy flat screen TVs still have SCART connectors, so I could connect the Atari to my parents’ TV, and, lo and behold, it booted up after a few tries. The ST had its operating system in ROM, so no disks were involved at this point. However, after marveling at the rock-solid color image—you know, back then it was flickering at 50 Hz—I discovered that the keyboard didn’t work. Now, this did not really come as a surprise, since I had heavily hacked the machine’s hardware, and one modification was to provide the keyboard chip, which also contains the real-time clock but did not have a backup battery, with external power. This hack had caused some trouble from time to time even back then. So, having determined that the machine was no longer useful, I had no qualms about getting rid of it.

Next, the hard disk. The ST used a proprietary interface called ACSI for attaching external hard disks (and the Atari laser printer). ACSI is actually a simplified (i.e., cheaper) version of SCSI; external drives actually contained standard SCSI disks and a small logic board that converted between SCSI and ACSI signals. This meant that I could take out the disk from its enclosure and connect it to another computer to create a disk image—assuming, of course, that the disk would still spin up after 18 years in the attic. So, before getting out the screwdriver, the first thing was to simply turn on the drive and listen… Damn, these things were loud! But the disk sounded ok, so I decided to go on.

The next step was to assess which equipment I would need and to check whether I had it:

  • A machine with a SCSI interface and preferably an Ethernet connection: Check, an HP 9000/C200 workstation.
  • An external SCSI enclosure: Check.
  • A SCSI cable with a Centronics-style connector (as used on the enclosure) on one end and a high-density connector (as used on the HP) on the other end: Check.
  • A SCSI terminator with a Centronics-style connector: Check.

I was surprised to actually have all the equipment I would need, because these aren’t actually household items today. The C200 is also a vintage machine, but quite a bit younger than the Atari. I had already booted it up earlier in 2013, so I had reason to believe it would work, even though it is not in regular use. In fact, it just sits under a table without a keyboard or a monitor attached. If you don’t know them, let me tell you that the C class machines—code name “Raven”—are beasts. They’re so heavy you risk breaking your back if you try to move them, so if I wanted to connect a monitor, I’d have to bring it to the machine. However, this would mean I’d have to unplug one of my dad’s monitors, untangle the cables—aw, no fun. So I decided to go even more old school and instead hook up an IBM 3161 terminal (mid-1980s vintage) to one of the C200’s serial ports. One of the nice things about real computers is that you can run them “headless,” i.e., without a keyboard and display. HP workstations automatically use the first serial port as console if no keyboard and monitor are attached.

I put the Atari’s hard disk (a 30 MB Seagate drive) into the external SCSI enclosure and attached it to the C200. Time to turn on the whole setup. Besides being heavy, the C200 is also loud as hell; when you turn it on, it sounds like a starting jet fighter. In any case, the system booted up fine, the external hard drive was there, and creating an image of it was merely a matter of saying

dd if=/dev/c2t1d0 of=/tmp/protar.img bs=512k

I then copied the disk image over the network to my MacBook.

Of course, the disk image is only useful if you can read it. You can’t simply mount it on the Mac, but luckily there are a number of Atari ST emulators that support hard disk images. In fact, you’ll eventually need an emulator anyway, in order to run the appropriate Atari ST software to read many of the legacy file formats. After trying a few emulators, I settled on Hatari. Using a hard disk image with Hatari is as easy as it gets: in the “Disks” section of the preferences, you simply select the image as “ACSI HD Image.” Hatari comes with EmuTOS, a free clone of TOS, the Atari ST operating system. EmuTOS detected the hard disk, but didn’t boot from it. I therefore installed real TOS ROM images, and voilà, up came the system exactly as I had left it 18 years before!

Gemini desktop running on the Hatari Atari ST emulator.
Gemini desktop running on the Hatari Atari ST emulator.

So, nice story? Yes, but actually it also pertains to the (alleged, I have to admit) topic of this blog, NLP for historical texts. For pre-digital historical texts, digitization is the first step before you can actually process them. For born digital historical texts (of which there will be more and more), getting access to (a) the bits and (b) to the encoded text are the first steps. Requirement (a) is about reading media such as punched cards, tapes, floppies, hard disks, CD-ROMs, USB sticks, etc., which requires suitable drives. An additional problem is that many of these storage media are subject to physical decay (e.g., demagnetization). Then, if you can get at the bits, in order to access the actual text—requirement (b)—, you will need to deal with data stored in proprietary legacy formats. Files in such formats can only faithfully be read by the applications that were used to create them—applications which are long gone and don’t run on modern computers anymore. So, in addition to obtaining the software, you will also need to recreate the platform on which it ran. (If you’re interested in the topic of preserving software, check out Thomas Haigh’s CACM column “Software and Souls; Programs and Packages.”)

By the way, nobody knows what will happen to texts stored in “the cloud”–or on social media platforms, for that matter—even ten years from now. I guess that for many people it feels like Google, Facebook, Dropbox, etc. have always existed and will always exist. But what will happen when one of the big service provider goes bust or is shut down for some reason? How much longer will Twitter be able to burn money? These platforms encourage their users to store everything with them and make it intentionally difficult to export their data, so many users won’t have offline backups. Sure, not everything may be worth preserving, but some valuable documents will without doubt also be lost. Historians of the future may face a situation familiar to classicists…

Author: Michael Piotrowski

Computational linguist, computer scientist, professor of digital humanities at the University of Lausanne.

4 thoughts on “A Small Exercise in Computer Archeology”

    1. Yes and no: actually it’s not a full keyboard but a kit consisting of keycaps, rubber domes, and springs to improve the original keyboard. I don’t remember the name of the company off-hand, I’m afraid.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search OpenEdition Search

You will be redirected to OpenEdition Search