Pertec Tape Drive Interface Musings
Mark J. Blair
nf6x at nf6x.net
Wed Jun 10 10:15:20 CDT 2015
> 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
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."
Mark J. Blair, NF6X <nf6x at nf6x.net>
More information about the cctech