On Sun, 22 Jun 2008 06:19:11 -0700 (PDT), firstname.lastname@example.org wrote:
>I just acquired a new tape drive, and I've been trying to get it to
>work with my system. It's an IDT (Innovative Data Technology) 1054
>nine track drive, and it seems to have a formatted Pertec interface.
>It's dual density, 800/1600. This is a very nice, simple drive -
>manual thread, compliance arm tensioning, etc. I want to hook it up in
>place of a Cipher autoloader (which, most of the time, has to be
>manually loaded anyway). The Prime is a 2755, and it does work well
>with the afforementioned Cipher/Prime drive. With the Cipher
>connected, and a scratch tape loaded, I can issue a BOOT 10005, and
>the computer tries to boot from the tape, detects that it's not a boot
>tape, and tells me so. With the IDT connected in place of the Cipher,
>I get an ACTUAL: 000000, EXPECTED 000300. The tape doesn't spin.
>Now, this is the first time I've tried to connect an "industry
>standard" tape deck to a Prime - I've always had ones that Prime sold.
>I know that in the Exabyte drives, Prime had their own firmware
>modifications - but what about the older magtape drives? I don't see
>any ROMs in the Cipher with Prime labels on them, but...
>So, basically, is there anything funny that Prime did with their tape
>drives, like odd strapping or somesuch. The manuals for the IDT drive
>are up on Bitsavers, and from looking at the drive, it seems to be set
>up fairly "normal" (unit 0, etc). Can "other" drives be used on the
>Also, yes, I do relize that the Cipher drive is a better drive than
>this IDT, but the IDT is simple and open, and is easy to clean the
>heads on and work with, and I want it for sorting through some old
>tapes. Once I get this drive working, I plan on fixing the Cipher and
>eventually connecting both at once. But, first things first.
One of the more unpleasant experiences of my career was discovering
just non-standard, the standard pertec interface is. There were a lot
of drives sold that are supposedly 'industry standard Pertec', however
there was never an industry standard document that described it, and
having been actively involved designing a high performance Pertect
tape controller, I can assure you that there is NO SUCH THING AS A
STANDARD PERTEC INTERFACE. Each manufacturer has slight timing or
signal nuances on their transports.
You may well be dealing with an interface problem, especially if you
are dealing with a formatter. The biggest single problem is the
interface isn't 'interlocked'. For example on the STK and Telex
interfaces, everything is interlocked. Controller has to send a
request, the device has to come back ready, then the controller can
send a command with a strobe, and the device will respond with both
the response to the command, and a 'latch' signal to indicate that
there is a valid response, which resulted in the controller 'strobing'
to signal lines to collect the data. Essentially the Pertec interface
presents clock and signal lines/data, whether the controller is ready
or not. If the controller wasn't ready to receive the signals or data
when the Device clocked it out, too bad........
The initial work I did with the K9400 tape drive and a 2081 required
that we actually masked off some of the status signals. They weren't
arriving at the time the 2081 was expecting them, and caused all sorts
of grief. Basically the pertec interface isn't anywhere as standard as
most would like you to believe, the interplay timing between the
command bits can be tricky (and undocumented). The First Solutions
Pertec tape adapter actually had several switches on board to tell it
what kind of 'standard' pertect tape drive was connected....
In otherwords, it comes as no surprise to something other than the
original Pertec or Cipher 880 doesn't work properly.