10 Jun
2015
10 Jun
'15
8:15 a.m.
On Jun 10, 2015, at 08:05, Dennis Boone <drb at
msu.edu> wrote:
Cool! I will look them up. Being able to use the images in a simulator without any further
translation is a plus.
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. 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/