On Mon, Oct 10, 2016 at 10:23 AM, Paul Koning <paulkon...@comcast.net> wrote:
> > > On Oct 10, 2016, at 11:24 AM, Charles Anthony < > charles.unix....@gmail.com> wrote: > > > > On Mon, Oct 10, 2016 at 4:51 AM, Dave Wade <dave.g4...@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
