> 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.
It seems like a straightforward task to take such a TAP file image and emulate
SCSI tape commands on it, but it definitely sounds like real work.
paul
