Pertec Tape Drive Interface Musings

[Jon Elson]

On 06/10/2015 03:39 AM, Johnny Billquist wrote:
> On 2015-06-10 09:47, Dave G4UGM wrote:
>> Mark,
>>
>>    Traditional 9-track tapes are always written block-by block with a 
>> "short"
>> gap between the records, WikiPedia say 0.6" for 1600BPI which sounds 
>> about
>> right.
My recollection is that the 0.6" gap was for 800 BPI, and that they went 
to a 0.3" gap for 1600 and 6250.
>> From what I remember as tapes are not the most reliable medium the
>> process was to have the read head after the write head so the tape 
>> could be
>> read and checked as it was written.
Yes, other than some super-low end drives like Kennedy digital 
incremental and some Pertec drives, most drives were read after write.  
This required completely independent read and write hardware.

I got a Pertec key to tape system surplus, and created a mostly software 
interface with very minimal hardware to read and write tapes on my S-100 
Z-80 system.  It would write, back up and re-read the block to verify.  
My recollection was there was only one data head, so it HAD to back up 
to read the data.  My interface and the Z-80 was maxed out doing one or 
the other, so that was fine.
>> If an error was returned the "system"
>> would backspace, erase the bad block to create a "long gap" and the try
>> again.
Usually, it would just rewrite over the bad record.  Only if the bad 
record remained after several retries and a cleaner cycle, would it do 
the extended gap, to move the record to a new (and hopefully better spot 
on the tape).
>> Looking at the first MAN page for TAR I found it says it writes
>> 20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a 
>> "waste"
>> of 10% of the tape in gaps, assuming the tape is perfect.  You can write
>> longer blocks but then the amount of wastage when you write a bad 
>> block goes
>> up.
>
> I don't think it really is that you have a long gap when you rewrite a 
> "bad" block per se. But you get long gaps when you stop/start. And a 
> rewrite implies that you will get a stop/start situation.
> But in case you already were going stop/start, the gap will not be 
> extended any longer.
>
> You want to stream the tape, meaning you both get short gaps, and also 
> much higher transfer rates, as the stop/start really cause the tape to 
> be slow.
All tape systems I know of wrote essentially identical gaps whether 
doing start/stop or streaming.
Speed of transfer goes way up if you can avoid the start/stop, but it 
made no difference in capacity of a tape.  The record gaps are set by 
ANSI standards for data interchangeability.
> But for streaming mode to work, you need to feed data to the tape fast 
> enough. And with that, I mean that when one block operation is 
> finished, the command for the next one needs to happen very quickly, 
> or else the tape will need to stop.
>
I wrote a disk dump/restore program for our PDP-11 a long time ago. I 
discovered there was a 10 us "reinstruct window" in the Datum 
controller, so if you could just get a new write or read operation 
loaded into the controller within that time, it would stream the drive.  
No way to do that with interrupts, but with double buffering and doing 
everything by polling, it was just barely possible to make it in time.  
It required error-free media, but if you had that, you could dump or 
restore a 40 MB Calcomp disk to 45 IPM Pertec mag tape in under ten 
minutes, including rewind.
It was a total block for block copy, not a file by file copy, so the 
tape was pretty useless except for restoring again to a disk pack.

Jon