Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for May, 2012

Data Preservation Case Study: AT&T 6312 WGS

Posted by Trixter on May 27, 2012

One of my hobbies is taking old IBM PCs (and clones) and restoring them.  “Restoring them” can mean anything, but for me, it usually means these three things:

  1. Get the hardware functional and booting up
  2. Archive the data off of any internal hard drives
  3. Wipe the hard drives clean and set it up for appropriate use

I did that last night to a new acquisition, an AT&T 6312 WGS.  This is one of the later “workstation”-class 286 machines that AT&T OEM’d from Olivetti, and I got it from a former AT&T/Teletype/Lucent employee (which is common, since they sold them to internal employees at a discount.  If you want to learn more about AT&T and their computer history, check out a video I made on the AT&T PC 6300.)

Step 1: Get the hardware functional and booting up

On opening it up, I saw both an internal hard drive and a second hardcard, a Western Digital PS30 which was a 32MB drive+card meant for the PS/2 Model 30.  I also saw a rechargeable battery pack, long since depleted, and sure enough, on bootup, the 6312 complained that it had no idea what the date/time was or what hard drive was installed in the system.  Furthermore, the PS30 hardcard started executing its option ROM at CA00 but then later spat out the dreaded 1701 error message, indicating that the drive was non-functional.  Fixing this requires the setup disk for the 6312 (which it helpfully barked at me during the BIOS POST), and thankfully NCR still had it available for download.  But when I got the file, I noticed with frustration that it was not a bootable disk image, but rather just a collection of files that came from the original bootable disk — and it had a specialized COMMAND.COM, which means they likely wouldn’t run by themselves and needed the specific boot disk environment to work.  You can’t just copy the DOS kernel files IBMBIO.COM and IBMDOS.COM to a disk and expect them to boot properly without a lot of work (usually the SYS command does this, but only for the DOS you currently have booted, so that wouldn’t work for me).

Sometimes restoration work requires creativity, and sometimes it just requires experience and educated guesses.  I used the latter to reconstruct the 6312 setup disk.  First, I looked at the IBMBIO.COM and IBMDOS.COM startup portions of DOS in a hex editor and determined that it was an AT&T OEM version of DOS (not surprising, really).  I figured I could find disk images of that DOS and use those to make a bootable disk on another vintage computer and then copy the 6312 setup files onto it.  Luckily, AT&T only produced two versions of DOS that supported hard drives, 3.2 and 3.3.  I checked the 3.2 image and sure enough the copyright string was identical and so were the IBMBIO/IBMDOS sizes, so I now had my bootable DOS disk to use.  But I had another problem:  The setup files were larger than a 360K disk.  This meant the 6312 setup disk was a 1.2MB floppy — and I didn’t have any vintage machines set up and working with a 5.25″ high-density 1.2MB floppy.  I know I could have tried to do things like take out the drive cage and swap cables, but I have a strong philosophy on trying to get the data off of the machine before messing with its innards (in case I break something).  So, I used a second vintage machine with both a double-density 5.25″ (360K) and 3.5″ (720K) drives in it to help me, and followed this procedure:

  1. Helper PC: Make an AT&T DOS 3.2 bootable 360K disk.  Make a .ZIP file of the setup files and put those on a 720K disk along with pkunzip.exe
  2. 6312: Boot the 360K disk and use it to run “format a: /s” to make a working 1.2MB bootable disk.  Put in the 720K disk and extract the setup files to the 1.2MB A: drive, taking care not to touch IBMBIO.COM and IBMDOS.COM.

That wasn’t so terrible, and I didn’t have to crack the drive cage open or attempt other trickery.

Once I could boot the setup program, I noticed I had over 30 hard drive types to choose from, and I couldn’t determine what the internal drive was because it was located underneath the floppy drives.  How to pick the right type without removing the drive to look at it?  While I could have tried all 30+ combinations, rebooting after each one and seeing if that worked, I did something much easier:  I set it to Type 1, a “10 MB” drive, just so the system would try to boot.  I then booted off of a floppy with Norton Diskedit and used it to look at the first sector of the drive (which will always work no matter what drive type you have, because it’s track 0 head 0 sector 0), choosing View->As Partition Table, and seeing how many tracks/sides/sectors per track there were.  There were 611 tracks defined, 17 sectors per track, and everything added up to 20MB.  So, we have a 20MB drive.  I checked a few CMOS drive table types online looking for 20MB drives with 600-ish tracks and 17spt and decided to try Type 16, which worked!  I could see the first hard drive’s contents, and after using LIST to check a few files, I was confident I had the geometry right.

This brought me to the second hard drive, the PS30 hardcard.  Every boot, I kept getting the 1701 error, which is usually drive death.  But on closer examination, I could see that the stepper motor axle was exposed — I could literally turn it with my fingers without dismantling anything.  I worked the stepper motor a few times, turned the machine back on, and it spun up and seeked!  The ROM on the card was smart enough to handle being the second drive as well as setting up the drive type/table; when I booted the machine, it showed up as D: and everything on it was readadble.

At this point, we have the 6312 back to its original operational capacity.  This entire process took about 2 hours, about half of which was careful thought on how to proceed.

Step 2: Archive the data off of any internal hard drives

There are two schools of thought on dealing with the data on old machines: Wipe the drives clean, or archive them.  Some people immediately wipe them, out of a sense of privacy for the previous owner, or maybe because they don’t want to unintentionally break any privacy laws.  I don’t do this; I try to preserve everything.  The main reason is that there might be a driver on the hard drive that is necessary in getting the thing working.  For example, there’s an extended memory board in this 6312 that, with the custom AT&T driver, can also be set up as a hardware LIM EMS board.  Without that driver, I would never have that option.  Another reason is that there might be some rare software on there that has been lost to the ages.  On this machine, I found a fantastic DOS version of VI that works better than any other VI clone I’ve run on a DOS machine, and I’d never heard of the product or the company before.  Researching it further, there’s a good reason:  It’s Custom Software Systems’ “PC/VI” and it was based on AT&T source which is why it works so damn well — and they hadn’t purchased a license for the source and it went off the market after only a year, which is why I hadn’t heard of it!

Poking around an old hard drive is sometimes like archaeology; you always find a piece of the prior owner there.  My favorite example of this was a no-name taiwanese clone I got as a gift a few years back.  The previous owner was a Chinese immigrant and had her college homework on it.  She was studying both business and politics, and the homework reflected how dry and boring it all was.  But tucked away in a corner of the drive was a single directory that contained several poems written by her — an oasis of creativity in the middle of all the tedium of trying to get an MBA.

To date, I haven’t spread my “system archives” around, out of respect for the prior owner.  (I’m not worried about privacy laws though:  If they threw it out, then they threw out their right to privacy.  This is why dumpster diving is legal, and why private investigators dig through people’s trash — anything they find, they can legally use.)

Okay, you’ve made the decision to get the data off the drives before they go bad, and a requirement is that the drives not be written to or altered during the process.  There are many different ways to do this, so I’ll outline a few:

  1. The hard way (floppies).  Using completely free software (ARJ, RAR for DOS, or PKZIP) and some pre-formatted floppies, you can just start archiving.  The big disadvantage to this is time, effort (it’s a manual process), and the risk of getting a bad floppy that you can’t read on the target halfway through your stack.  I only do this if I have one floppy’s worth of data to suck off the drive.
  2. Use a backup program.  This is the fastest way to format and write to floppy disk media, and you get error-correction thrown in for free, but the drawback is that you need another vintage computer to read the backups (one that can accept the floppy media and has enough space to hold the files, as well as a way to get them off to something more usable like through a network connection).
  3. Install a network card.  You can attempt setting up MS Lan Manager to mount a samba share as a drive letter, but sometimes I like to just load a packet driver and use mTCP to set up an FTP server and just suck the files off.  A lot less hassle.
  4. Connect external storage.  ebay is just maggoty with Iomega parallel-port ZIP drives, and as long as you’re trying to suck data off of a 286 or higher and can boot DOS 5.0 or higher (even from a floppy disk), they work great.  Each disk holds 100MB which is more than enough for most MFM and RLL drives.  One of these and XCOPY or PKZIP is all you need, and if you don’t have another machine to hook them up to, you can turn around and pull #3 (install network card) and upload the results.
  5. Parallel or Serial cable.  Laplink, FastLynx, and even DOS 6.x’s built-in INTERLNK can all transfer files over cable.  It’s inconvenient and not too swift, but it works.  I prefer FastLynx, which has exactly the same code as INTERLNK but has a nifty interface and can use realtime compression.

For the 6312, I chose the zip-drive-then-ftp-to-my-fileserver route.

Step 3: Wipe the hard drives clean and set it up for appropriate use

Wiping the drives clean is easy — you can just delete all of the data and then run Norton WIPEDISK.  If you’re more paranoid, you get to locate your drive’s low-level format program and have at it, secure in the knowledge that you’re laying down the low-level format at the same time (just make sure you enter in the defect table from the sticker on top of the drive!).

As for “appropriate use”, that is completely in the eye of the beholder.  Because this is an AT&T “WGS” machine (meant for workgroups), I’m going to leave all of the AT&T-specific software on it (there are some terminal emulators on it, etc.) and I’m going to set it up as a business-class PC:  A word processor or two, all of my typical programming tools and environments (Turbo Pascal, Turbo Debugger, Turbo Assembler, and a86/d86), and a network card with both the mTCP suite on it as well as MS LAN Manager.  I’ll configure the machine to boot up and set the time automatically via SNTP, and I’ll also investigate MS lanman so that it can mount my local SAMBA shares.  This will require a more beefy DOS than 3.2, so PC DOS 2000 is probably going to go on there.

Of course I’m going to throw some games on it too :-) Every system needs games.

Posted in Vintage Computing | 7 Comments »