Pertec Tape Drive Interface Musings

[Mark J. Blair]

> On Jun 10, 2015, at 08:05, Dennis Boone <drb at msu.edu> wrote:
> 
>> This hypothetical interface + matching software would be intended for
>> archiving old tapes and/or making new copies from archived file
>> (i.e., to make new boot media for bringup of an old computer). Key
>> features would include preservation of block sizes (even if varying
>> arbitrarily) and file marks. I'm not sure if there's already a good
>> file format for that, and I have a dim memory of previously reading a
>> lament about common archival methods failing to preserve blocking.
> 
> The E11/SimH .tap formats are dead simple, and relatively complete as
> far as capturing the arrangement of the bits on tape.  They retain block
> size, actual data, file marks, and have a provision for indicating
> errors encountered when reading the tape.

Cool! I will look them up. Being able to use the images in a simulator without any further translation is a plus.

>  There was a discussion
> recently (simh list?) about standardizing the behavior of the error
> marks.

I will look that up, too.

> Using dd to read tapes to disk discards the block size information.

And that is precisely why I'm thinking of an ad-hoc interface rather than just plugging a SCSI drive into a UNIX box. Chuck's comment about his USB to Pertec project woke up my own dormant Pertec interface project idea in my cluttered head. Hmm, this might be as simple as a BeagleBone Black board with an LCD board (both of which I already have), and a custom board with a cheap FPGA and the Pertec electrical interface.

Yeah, I could probably implement the interface just fine in software using a fast microcontroller with lots of GPIOs. But FPGAs are what I know best.

"When your only tool is a hammer, every problem ends up looking like broken pottery."
    -- Me


-- 
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/