Review of Overland Data Nine Track Tape Drive Scheme

[Robert C. White]

I had wanted to add nine track capability to my Microport box
for some time, and with the help of a net person (Dave Carlsen)
I located Overland Data in San Diego, California.

Without being too commercial, Overland Data sells nine track
tape drives for small systems.  They had a tape driver for 
Microport 2.2, but not for 2.3. Their kernel guru, Ms. 
Gail Anderson, soon produced and delivered an updated driver
for 2.3, and the tape unit itself, a Qualstar TC-50, which
retails for $3,600 including the tape controller card.

The documentation is quite professional and very straightforward.
The software package for Microport includes a single mt.o file
and a configuration script that will incorporate the new module
into lib2. A simple make wini reconfigures the driver to support
the tape drive.

Unlike most drivers that I have seen, this one can be software
configured to use any one of the three DMA channels, any IRQ,
and any IO address.  This becomes essential if you have a
cartridge tape drive already installed in your system.
Hardware changes involve setting a few dip switches on the
controller card, and some gymnastics to fit the two connecting
cables through the back of the machine.

Full ioctl support is provided, including eof, weof, fsf, 
fsr, bsf, bsr, rewind, offline, rewoffl, status. An 'mtc'
program (with source code) is supplied to execute any one of
these ioctl functions. It works very well.

Mag tapes can be written at either 1600 or 3200 bpi. This unit
requires hand threading which I prefer over autoloading. I've
fought with many an autoloading tape drive, and they never seemed
to work the first try.

I ran into problems using microport's strm utility.  It cannot
be used with the tape drive, and asks you at inappropriate times
to change media and type in the new device name.  

Unfortunately this tape drive will not work properly at clock
speeds higher than an ordinary AT.  Apparently there is some new
hardware in development that will solve this problem.  If you 
try and run the tape drive at high clock speeds, the infamous
double panic will occur.

This tape drive will stream, provided you can read and/or write
to it "quickly" enough.  One way to cause streaming is to do this:
(assuming tape is blocked at 512 bytes, which you wouldn't 
 ordinarily do).

cat /dev/rmt0 | tar tvf -

If an good strm type utility can be developed, streaming writes
could probably be accomplished. Disk throughput without buffering
of some sort is simply not fast enough to maintain streaming.

One objective that I had in mind was to be able to read from the
cartridge tape and write directly to the mag tape without hitting
the disk.  This indeed works, but remember to read from the 
cartridge tape in 512 byte blocks. Reads of an arbitrary size 
from the cartridge tape drive will result in a read error.

Blocks of up to 64k can be written to tape.  As delivered, the 
maximum block size is somewhere around 10k, and the remaining
memory is used to buffer the read or write.  This scheme can be
patched using the patch utility, but the kernel must be recreated.
There is a 64k chunk of memory built into the controller card,
and some modifications at boot time prevent the system from 
grabbing this extra memory.

Using dd, you can write ebcdic tapes suitable for IBM mainframes.
All of the standard unix tape utilities (cpio and tar) work as
one would expect with the tape drive. 

Generally speaking, I feel the tape drive is a good investment
if you need this capability.  Using our machine in this way,
we have saved tens of thousands of dollars over other solutions.
Now, how about a good ethernet card? :-)

Robert White
boulder!qetzal!rcw