Line printer art: (was Re: tape baking)
cclist at sydex.com
Fri Jul 7 13:10:46 CDT 2017
On 07/07/2017 10:26 AM, Al Kossow via cctalk wrote:
> I stopped beating that horse years ago. They also assume that all of the data
> blocks read correctly, they don't save the error correction data if the block
> had it, etc etc.
> Need to update my reader anyway soon, so I'm going to append something similar to
> what you did the new images I create, probably just a ascii text record and a label picture.
I currently add 2 records (in TAP prefix/suffix format). The first
starts with CR-LF "LOG" CR-LF;the second is identifiable as a JPEG
"JFIF" file. Nothing more complicated than that.
At least the log identifies bad blocks and what the problem was insofar
as the reading software can determine. That may be all that's available
on some SCSI drives. Pertec-interface drives can pinpoint the frame in
error much of the time.
I've puzzled over how to do tape flux-transition recording in any
meaningful way. One of the problems is encoding skewing information as
well as tape speed--unlike floppies, you have parallel tracks and tape
speed (reading and writing) isn't constant. A good deal of the data
recovery circuitry in a 9 or 7 track drive involves deskewing and speed
I recall looking at customer samples back in the day from CDC 669 drives
using a low-power microscope and developer and being gobsmacked at how
crowded things were at the start of a tape block. The customer was
running the Navy Audit COBOL tests and the short block stop-start tape
I/O suite was giving the drives fits. Spence Preston eventually flew in
and reworked the firmware over about two weeks so that things held
together--I didn't get any detail on the specifics of his fix.
I suppose that one could simply oversample the tape, recording
sub-frames every 100 nsec or so, but I haven't thought that one through.
But it would be easy enough to do with a medium-power MCU. Writing
the code to make sense of the data, perhaps not so much.
More information about the cctech