Reading HP 9144 cartridge tapes

Al and I urgently needed a way to read old HP 9144 cartridge tapes. These are mechanically standard DC600 or DC615 tapes, but have an HP-unique format. Al hooked up a PC with an IEEE-488 interface card, and I voluneered to write code to read the tapes. I had no idea what I was getting into. I started writing a program around noon on Saturday, and had it mostly working by about 2:30 AM Sunday morning, but there’s still more work to be done.

The 9144 uses an IEEE-488 interface (AKA HP-IB or GPIB), and the HP CS/80 command set (CS/80 reference manual, PDF). In general it acts more like a disk drive than a tape drive; it has fixed-size 1KB blocks and supports random access read/write.

Al put a National Instruments 488 interface card into a luggable PC running Fedora Core 4, installed the Linux GPIB software, and hooked up a 9145 drive (higher density, but can read 9144 tapes).

I wrote a simple program called “read9144″, which as usual I have released under the GPL. I’ll probably turn it into a more general utility for dealing with CS/80 discs and tapes, and rename it “cs80util” or something.

The biggest stumbling block to debugging the program was that the ibrd() function sometimes returns a byte count of zero even though bytes have actually been transferred. It took me a while to realize that I was actually getting valid data. IEEE-488 doesn’t actually have any means for a device to send zero bytes of data; data transfers are terminated either by an end-of-line character, or by a byte sent with the EOI (End or Identify) line asserted. So when you ask a device to send data, it either will send you at least one byte of data, or you will get a timeout waiting for it to send. I wasn’t getting a timeout; ibrd() was returning instantly with the byte count of zero.

Some calls to ibrd() were returning a proper byte count. In particular, the code that reads a two-byte HP-IB identify response, and the code that read a one-byte CS/80 report both always return the correct byte count. But the calls to read a 1024 byte data block, 20 byte CS/80 Describe result, or 256 byte CS/80 transparent echo message always return zero. It’s not the length per se that is the problem, because if I change the code that tries to read the transparent echo message to only read one or two bytes (like the identify or report), it still returns a zero count. I suspect that the problem may have to do with whether the last byte has EOI asserted. Al tried to hook up an IEEE-488 analyzer, but it’s interfering with proper operation of the bus; he’s going to try to debug that. Meanwhile I looked into the user-space library (libgpib) sources, and it looks like the problem must be in the kernel side.

Anyhow, by ignoring the returned count and assuming that the drive returned the requested number of bytes, I was able to work around the problem. Mostly. It turns out that the although the drive mostly acts like a disk drive, it does have two significant tape-like features:

• It supports partial block writes, and each block stores its logical size (from 0 to 1024 bytes). The unwritten part of the block is zeroed by the drive. The drive has two read modes, non-byte-count which always reads full blocks regardless of the logical block size, and byte-count mode, in which the drive will return a short block followed by a 0×01/EOI terminator byte. I can’t support this without fixing (or better working around) the ibrd() zero byte count problem, and there doesn’t appear to be any other way to find out the logical size of a block.
• It supports tape marks. I can’t tell from the docs whether these are conceptually inbetween data blocks, or whether they effectively replace a block in the stream. In other words, if I write a data block at block address 3, then a tape mark, then another data block, is the latter data block at address 4 or 5? I’ll have to write a test program to determine this.

A word of warning for anyone that might actually want to use a 9144 or 9145 drive: the drive isn’t capable of reformatting a tape, so don’t bulk-erase the cartridges or try to use them after they’ve been reformatted on some other system.