Pertec Tape Drive Interface Musings

[Jon Elson]

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.

Jon