Pertec Tape Drive Interface Musings
jonelson126 at gmail.com
Wed Jun 10 13:19:06 CDT 2015
On 06/10/2015 11:12 AM, Mark J. Blair wrote:
>> On Jun 10, 2015, at 08:46, Al Kossow <aek at bitsavers.org> wrote:
>> On 6/10/15 8:15 AM, Mark J. Blair wrote:
>>> And that is precisely why I'm thinking of an ad-hoc interface rather than just plugging a SCSI drive into a UNIX box.
>> It also has the advantage that you can return the CRC/checksum and partially read blocks. Most SCSI tape drives don't
>> return the data if the read doesn't succeed.
> I particularly like the idea of being able to extract questionable data and CRC/checksum.
> Ok, now three more questions come to mind:
> 1) Is it ever acceptable to mix densities on a single tape? I'm not sure that my Kennedy drive will even allow that, but I don't know if that is universal.
No, never OK. There is a format ID written OVER the BOT marker for 1600
and 6250 that tells the drive what the density format is. If you EVER
see the density change, is is because a tape was partially overwritten
at a different density, and then you've either read off the end of the
re-written portion, or the last EOF was lost somehow.
> 2) What's the scoop on a final record overlapping the EOT marker? Or even a new record starting after the EOT marker? I seem to recall reading about some applications that stuck data after the EOT, such as backup volume information.
Yeah, the EOT sensor is only an inch or so ahead of the write head, so
any long record will overlap the EOT sensor, and then the trailer and
EOF records will have to continue on past that for a few additional inches.
> 3) Did anybody ever go over to the dark side and implement copy protection on magtapes, say, by deliberately including a record with bad CRC that a normal driver+drive would not support writing? Or was that evil limited to the floppy disk world?
UGH! You can't guarantee this would work on different vendor's hardware.
More information about the cctalk