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 compensation. 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. --Chuck
