10 Oct
2016
10 Oct
'16
10:23 a.m.
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:
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
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.