When re-living ones’ childhood, most would listen to some old music, or play a classic board game. The writer of this blog re-enjoys a quarter-inch-cartridge tape drive.
Recently I mentioned my LTO tape backup solution, a modern type of tape backup which promises minimum 30 years of storage. In the context of anything IT related this feels like quite a bold claim.
If you just want to see a video of the tape spinning back and forth – you can skip to the end of the article.
I though it would be interesting to dig up a tape backup solution from 30 years ago. There is one type of tape from that era that is of particular personal significance to me:
Pictured is a 3M DC6525 (525MB) QIC (Quarter Inch Cartridge) tape – which is the exact type of tape that was used to backup data from our family computer when I was a child.
Disclaimer: A cornucopia of different tapes where also used in our household including DC6250, DC6150, DC600A, and even some mini-QIC tapes (DC2120, DC2000) – just for good measure.
The QIC form factor enjoyed a huge lifespan – with the earliest 2.9MB (DC300A) tapes appearing in 1972, right through to the final 20GB (SLR50) type released 25 years later in 1997. Even today we’re practically up to our knees in QIC tapes and drives, the world over. All of the stuff I show here remains cheap and plentiful!
While our tapes are unlikely to ever be seen again, if we could reach into the past and grab that tape briefcase, what kind of prospects would we have of recovering that data?
That unfortunately is the one test I cannot easily do, because I don’t have any period-written tapes test, and I’m not entirely comfortable about buying other peoples’ tapes off eBay. Besides, the laws of physics tell us that we don’t need to test this. If the tape is intact (not so likely in the case of cheap “no brand” tapes of the day), the data will be there.
More likely, it’s everything else that’s going to get in our way – software, tape drive hardware, interfaces, drivers, etc. Let’s hit up eBay for a pile of old tape junk, and see what kind of difficulties we run into.
The drive I’ve selected is a Wangtek 51000HT – it has an old school charm about it, sharing the same primitive mechanical design from their earlier drives. Wangtek were a big player in early QIC type drives but went bankrupt in 1995. This particular drives features an easy-to-use SCSI interface and reads and writes 250MB, 525MB and 1.2GB tapes.
There was a later 52000HT model also supporting 2.4GB tapes, as well as the earlier 5525ES model supporting only 250 and 525MB tapes, Most of those have some pretty major rework (image) on the main PCB – making them quite fragile.
Earlier drives (i.e. 5150, 5125, 5099) had an obscure “QIC” interface which required a special ISA interface card. “Formatter” cards were available, which were attached to the underside of the drive, translating the oddball QIC interface to SCSI. On my drive the formatter is crammed onto the same PCB as the basic drive control circuitry.
The issue we’re very likely going to hit with these drives is the rubber-like material on the capstan, a rubber Tyre on a brass wheel which drives the tape backwards and forward. Unfortunately – after several decades it breaks down and turns to goop.
I was already aware that capstan restoration is a big subject in vintage computing so was expecting difficulties – but initially thought I’d be right because my capstan looked intact. I put a tape in the drive, it spun back and forward OK but eventually seized up. I pulled the tape out to discover this:
To get my drive going again, I’ve just wound some polyester tape around it, capping it off with 4 layers of glue lined heat shrink. This is a known, but frowned-upon technique within the vintage computing community. It wont last, so I’ll eventually have to come up with something better.
My polyester tape + heatshrink combo didn’t go too badly – I was able to read and write a couple of tapes with it without anything coming apart. The main problem is that my capstan isn’t quite round, causing quite a lot of vibration. Unfortunately it’s not so straight forward to get heatshrink tube to shrink uniformly – so I subsequently went back and tried something different:
I had some soft silicon rubber tubes (THER-T-LARGE), which are designed for insulating TOP-3 transistors on heatsinks. A final layer of that appears to have worked quite a lot better in place of the heatshrink tube. The Kapton tape I have is thicker than the polyester tape I was using (3M ‘5’) so I’ve got a larger ‘bump’ at the end of that tape, but the vibration is still a heck of a lot less than the heatshrink solution. I was able to minimise the tape lead off ‘bump’ by finishing it with a long wedge shape. The tape is wound on upside-down so that the end of it offers an adhesive layer to keep the silicon rubber tube properly attached.
This has actually turned out to be a pretty nice capstan replacement. I’ve thrashed it for 10 hours straight now, and it’s still going strong! My drive is now sounding a lot more like I remember it is supposed to.
Modern LTO tape drives do not have a capstan. Tape spools are magnetically docked directly onto the drive motor. I suspect the designers of the LTO system incorporated this lesson.
Potential tape troubles
Another commonly mentioned problem is the elastic drive belt inside the tape. Tension of belts in early tapes (i.e. DC600A and prior) is likely to be less than exciting today but apparently belts in newer tapes last significantly better.
Even using period tapes – I did not have any troubles with belt tension. Once again, in our modern LTO drives, no belts whatsoever.
As previously mentioned, my selected drive is SCSI – making attachment to a PC pretty easy. I tried to attached it to a modern Adaptec PCIe adapter which did detect that something was at the selected ID, but wasn’t able to communicate with it, so unfortunately wouldn’t be booting a Windows 10 PC with this drive attached.
I’ll be attaching my using an Adaptec SlimSCSI PCMCIA – inserted into an IBM Thinkpad 760XL from the 1990s
Operating system drivers
The operating system running on my test PC is Windows NT 4.0. NT4 it turns out, has pretty good built-in support for tape drives of the time.
I’m fully aware that Linux also supports these drives, and likely still does to this day however Linux didn’t exist, or wasn’t commonly used during the era of these drives, so I won’t be looking at this for this article.
The most likely operating system used with these drives was DOS, along with the popular Sytos suite, but I don’t have a period desktop PC handy, and using an Adaptec APA-1460 PCMCIA on DOS is a hassle I have previously spent hours tearing my hair out over. I cannot be bothered with it at this time.
The driver to use with my drive is “Wangtek 525, 250, or 9500 tape drive” (wangqic.sys). Easy? Apparently not.
Upon rebooting NT – we’ve got an error in the event log:
for f–ks sake. It’s the correct driver for the drive, what the heck is the problem?
Fortunately the source code for the driver is out there, both in the leaked snapshot of NT4.0 and in the NT4 DDK. This will make getting to the bottom of this a heck of a lot easier.
Within seconds there’s a hint as to what might be wrong – the driver is performing a SCSI INQUIRY command on the drive, then doing a text comparison of the result against its own list of supported drives. I wrote a small test program to check what the drive was sending:
C:\Projects\enqtest>enqtest.exe Port 1, ID 3: Vendor string: "UNISYS " Device string: "QIC1000 " C:\Projects\enqtest>
It turns out my drive has bastardised Unisys firmware on it, which would explain why the NT driver doesn’t like it. This is likely because it was sold as a Unisys qualified and supplied part, and whatever operating system that machine was running only worked with drives which responded like the above, so if you were adding or replacing a tape drive on that machine, it was important to ensure you were paying the appropriate price for it.
It’s pretty unlikely that anything other than the device ID was changed – having a custom firmware image which deviated from the relevant QIC standards would have created a lot of unnecessary hassle and expense for Unisys.
A quick solution to this problem is to just hack wangqic.sys to expect the above device string, but this is only half a solution because any backup software I point at it is also going to spit the dummy, requiring yet more software hacking. Let’s deal with this properly…
The device ID is coming from the firmware running on the Z80 CPU, which is loaded from a socketed EPROM. There is also an Intel 8031 on the same PCB with its own socketed EPROM.
The offending incorrect device ID is found in seconds, and replaced with what it is supposed to be. The chip this firmware is stored on unfortunately is an OTP EPROM (AT27C512) – I had to buy another to make this modification.
After flashing the new EPROM, it’s back in the drive, now let’s see what we get:
C:\Projects\enqtest>enqtest.exe Port 1, ID 3: Vendor string: "WANGTEK " Device string: "51000HTSCSI " C:\Projects\enqtest>
Looks better – the NT driver is happy too:
Now I’m back to a retail 51000HT, with a makeshift capstan – let’s try use this thing.
If I was just wanting to play around with the drive its self, NTBackup (Supplied with NT 4.0) is a pretty respectable way to write/read files to/from tape.
A trip down the memory lane of backup solutions wouldn’t be complete without some proper backup software – specifically I’ll be using Backup Exec. A very popular suite which started as a small relatively simple DOS program, eventually evolving into a comprehensive enterprise backup solution. It remains very popular to this day.
As I previously mentioned – Sytos was more popular for use with QIC tape drives back in the day, however I am not in a position to fire that up at present.
Getting my hands on an old copy of Backup Exec turned out to be another unexpected difficulty. I was looking specifically for version 8.6 which was one of the last to support my drive, and it also runs on NT 4.0. It’s actually much newer – from circa 20 years ago, so I won’t be covering it in any detail. It has no problems reading tapes created by earlier versions of its self, so no need to go back any further.
Downloading it turned out to be impossible, so in the end I had to hit up eBay for a tatty retail boxed copy (it cost next to nothing) but even then I still had a problem. Sure as the sun rises each morning – I was jipped by the seller – It’s upgrade version, so I needed a license key from a previous version to install it. Has he got one? Of course not. FFS.
The day was saved by a cheeky utility from that same era – Microsoft ScriptIt – a UI automation tool. In minutes I whipped up a small script which sits there entering randomly generated license keys into the installer. After 15 minutes at a rate of 4 attempts per second: Bingo. We’ve got a “full” key for version 8.6. Most primitive keygen ever!
We’re in business. A few clicks later and Backup Exec is writing some data this ancient tape drive. Initially I found the OS kept locking up during operations – suspecting the revision ‘A’ Adaptec SlimSCSI I was using, I cast it aside and plugged in a revision ‘D’ card (I’ve got a few). That seems to have fixed the problem.
Eventually I got a successful run of a ~180MB data set which took about 15 minutes to write, and another 15 minutes to verify.
Reviving ancient backup sets is no problem at all, provided that all of the tapes, hardware to read them, cables, interface cards, software and software license keys are all available to whoever might be trying to read back those tapes several decades from now.
Someone restoring a QIC-525 backup set might want to look at a Tandberg drive – assuming they don’t want to grapple with the “capstan” problem.
Despite my initial disinterest in this subject – I’m really impressed with the engineering of all of the products I’ve looked at here. If we overlook the dodgy capstan, that Wangtek tape drive is a nicely designed product which still works perfectly even three decades later. The tapes I’ve used area also “period” – once again, working perfectly. I’ve had no mechanical problems, errors or anything!
It is unfortunate that older versions of Backup Exec are so hard to come by, because this means no-one much really cares about them. It was good to give this forgotten release another day in the sun.