SCSI Tape Emulator

[Charles Anthony]

On Mon, Oct 10, 2016 at 10:23 AM, Paul Koning <paulkoning at comcast.net>
wrote:

>
> > On Oct 10, 2016, at 11:24 AM, Charles Anthony <
> charles.unix.pro at gmail.com> wrote:
> >
> > On Mon, Oct 10, 2016 at 4:51 AM, Dave Wade <dave.g4ugm at gmail.com> wrote:
> >
> >>> Would it not be a SMOP to get a SCSI2SD device to emulate a tape drive?
> >>
> >> I am not sure, it looks there is some code in there for tape but its
> very
> >> minimal.
> >> In addition there are no interfaces on the card to select the ".tap"
> file
> >> to be used.
> >>
> >>
> > Not needed; copy the .tap file directly to the SD card, no partition
> > tables, no file system:
> >
> >  dd if=foo.tap of=/dev/sdx
> >
> > Fix up the firmwre (a SMOP) with a pointer to where you are in the .tap
> > data; it starts at block 0, offset 0 at the location would be the first
> > block size word of the .tap data. Treat the disk as a file; read reads
> the
> > data at the pointer and moves the pointer to the end of the read.
> Assuming
> > LBA, the pointer value maps directly to block number/offset.
> >
> > Fill out the SCSI tape commands to use the pointer and the data.
>
> I don't understand how that would work.  A tape device implements SCSI
> tape commands, not block device (disk) commands.  A tape block corresponds
> to the chunk of data in a .TAP file between block header and trailer, and
> its length is given by that header.
>
> If you put a .TAP fie into a raw block device, it's still 512 byte sector
> data on a block device; a tape driver would not understand it.
>

Yes; the firmware needs to parse the .tap data to extract the tape records;
my point was that it was not necessary to add the ability to handle file
systems and file name specification -- if suffices to put the content of
the .tap file on the SD device.

Details: The .tap format is a series of tape records; each record is stored
as a 2 byte byte count, the data (sometimes rounded to an even number of
bytes), and a repeat of the 2 byte byte count. This format supports the
basic tape record operations; you need to keep a pointer to the current
record. A 'tape read' retrieves the byte count from the record pointed to
by the pointer, retrieves the data, and advances the pointer to the next
block. Tape marks are stored as 2 bytes of zeros. Skipping records forward
is done by retrieving the byte count and calculating the new pointer
value.  Skipping backward is done by backing the pointer up 2 bytes, and
retrieving the 2nd copy of the byte count of the previous record, and
calculating how far back to move the pointer. Rewind sets the pointer to 0.

A SCSI tape read command reads the record from the tape file, recovering
the byte count and data, and leaving the pointer pointing to the next
record. If the byte count is 0, the SCSI reply is "tape mark"; otherwise
the reply contains the byte length and the data.

This is more complex then seek/read_block of the disk, but not horribly so.
The bigger problem is the idiosyncratic behavior of SCSI tape drives with
respect to identification, status information and assumed command
sequences, as implemented by the drive manufacturer based on the Very Own
interpretation of the standards.

-- Charles