> On Jun 10, 2015, at 08:05, Dennis Boone <d...@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 <n...@nf6x.net>
http://www.nf6x.net/
