10 Oct
2016
10 Oct
'16
5:06 a.m.
Folks,
I am "playing" with a small VAX and want to install software onto it, some
of which are in SIMH ".tap" format files. I was thinking it would be nice to
have a SCSI Tape emulator that worked a bit like the USB floppy emulators
that are about.
So it would plug into the SCSI bus and allow ".TAP" (and other tape formats)
stored on some kind of flash memory, say USB or SD card perhaps, to be read
by real hardware.
Does this sound usefull to any one? Any other thoughts on how this could be
achieved?
Dave Wade
G4UGM & EA7KAE
10 Oct
10 Oct
5:43 a.m.
This would be a quite useful device, not only for SCSI, but for other interfaces also.
Am 10.10.2016 um 11:06 schrieb Dave Wade
<dave.g4ugm at gmail.com>:
Folks,
I am "playing" with a small VAX and want to install software onto it, some
of which are in SIMH ".tap" format files. I was thinking it would be nice to
have a SCSI Tape emulator that worked a bit like the USB floppy emulators
that are about.
So it would plug into the SCSI bus and allow ".TAP" (and other tape formats)
stored on some kind of flash memory, say USB or SD card perhaps, to be read
by real hardware.
Does this sound usefull to any one? Any other thoughts on how this could be
achieved?
Dave Wade
G4UGM & EA7KAE
10:41 a.m.
On 10/10/16 2:43 AM, aswood at t-online.de wrote:
> So it would plug into the SCSI bus and allow
".TAP" (and other tape formats)
> stored on some kind of flash memory, say USB or SD card perhaps, to be read
> by real hardware.
>
>
>
> Does this sound usefull to any one? Any other thoughts on how this could be
> achieved?
>
yes it would be useful. a firmware mod to the existing scsi disk emulator board?
6:07 a.m.
On Oct 10, 2016 10:06 PM, "Dave Wade" <dave.g4ugm at gmail.com> wrote:
Folks,
I am "playing" with a small VAX and want to install software onto it, some
of which are in SIMH ".tap" format files. I was thinking it would be nice
to
have a SCSI Tape emulator that worked a bit like the
USB floppy emulators
that are about.
So it would plug into the SCSI bus and allow ".TAP" (and other tape
formats)
stored on some kind of flash memory, say USB or SD
card perhaps, to be
read
by real hardware.
Does this sound usefull to any one? Any other thoughts on how this could
be
achieved?
Dave Wade
G4UGM & EA7KAE
Would it not be a SMOP to get a SCSI2SD device to emulate a tape drive?
Mike
7:51 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mike Ross
Sent: 10 October 2016 11:07
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: SCSI Tape Emulator
On Oct 10, 2016 10:06 PM, "Dave Wade" <dave.g4ugm at gmail.com> wrote:
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.
Dave
Folks,
I am "playing" with a small VAX and want to install software onto it,
some of which are in SIMH ".tap" format files. I was thinking it would
be nice
to
have a SCSI Tape emulator that worked a bit like
the USB floppy
emulators that are about.
So it would plug into the SCSI bus and allow ".TAP" (and other tape
formats)
stored on some kind of flash memory, say USB or
SD card perhaps, to be
read
by real hardware.
Does this sound usefull to any one? Any other thoughts on how this
could
be
achieved?
Dave Wade
G4UGM & EA7KAE
Would it not be a SMOP to get a SCSI2SD device to emulate a tape drive?
Mike
11:24 a.m.
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.
-- Charles
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.
12:11 p.m.
On 10/10/2016 8:24 AM, Charles Anthony 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.
-- Charles
The only thing I might mention was that the brand name was used on some
initiators to either behave differently or not at all. We had an
emulation in our SCSI development package that emulated an ST-150 and it
worked on most initiators, but there were some who didn't like it, and
once we found out what the identification had to be things were good.
I don't recall what behavior was expected in the off cases, other than
possibly the block sizes of the transfers.
One could also emulate a half inch drive, vs. a QIC, which can have
variable block sizes. Emulating QIC is a bit simpler as you don't have
to deal with retrieving excess data commands which you might with half inch.
Our system was Peer Protocols 5000 and 7000. We also had a 0550 narrow
capture card. Would be interested if anyone worked with it.
thanks
Jim
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.
1:23 p.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.
3:53 p.m.
On Mon, Oct 10, 2016 at 10:23 AM, Paul Koning <paulkoning at comcast.net>
wrote:
the
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
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 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.
7:49 p.m.
From: Charles Anthony
Sent: Monday, October 10, 2016 12:53 PM
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.
Correction: .tap format uses 4 byte counters, in little-endian order.
Order is not relevant for the EOF tape marks, of course, since they're
4 bytes of 0.
The older DECUS .tpc format uses a 2 byte counter, also little endian,
but only at the front of the record (no read backwards capability).
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
8:40 p.m.
On Mon, Oct 10, 2016 at 4:49 PM, Rich Alderson <
RichA at livingcomputermuseum.org> wrote:
From: Charles Anthony
Sent: Monday, October 10, 2016 12:53 PM
Correction: .tap format uses 4 byte counters, in little-endian order.
Order is not relevant for the EOF tape marks, of course, since they're
4 bytes of 0.
Stupid memory of mine. Sigh. Anyway, IIUC, the SCSI2SD is like $70; the
firmware appears to be closed, but I wonder if an NDA with them would allow
adding tape emulation capability to their code base? (Given that I have no
knowledge of how SCSI2D works inside, I may be vastly underestimating the
scope of the project.)
-- Charles
9:11 p.m.
On 10/10/16 5:40 PM, Charles Anthony wrote:
On Mon, Oct 10, 2016 at 4:49 PM, Rich Alderson <
RichA at livingcomputermuseum.org> wrote:
The SCSI2SD firmware (and hardware) are open source, see the "Files"
section of the scsi2sd site for the git repo information.
Additionally, the guy behind the project is very receptive to feature
requests and bug reports...
- Josh
From: Charles Anthony
Sent: Monday, October 10, 2016 12:53 PM
Correction: .tap format uses 4 byte counters, in little-endian order.
Order is not relevant for the EOF tape marks, of course, since they're
4 bytes of 0.
Stupid memory of mine. Sigh. Anyway, IIUC, the SCSI2SD is like $70; the
firmware appears to be closed, but I wonder if an NDA with them would allow
adding tape emulation capability to their code base? (Given that I have no
knowledge of how SCSI2D works inside, I may be vastly underestimating the
scope of the project.)
-- Charles
9:19 p.m.
On Oct 10, 2016, at 6:11 PM, Josh Dersch <derschjo at gmail.com> wrote:
I was going to point this out as well.
My only misgiving would be whether SCSI2SD prior to v6 is powerful or fast enough for any
particular use, not whether sufficient resources are available to hack it.
-- Chris
-- who still needs a JTAG cable to reprogram the boot loader on his bricked SCSI2SD
On 10/10/16 5:40 PM, Charles Anthony wrote:
On Mon, Oct 10, 2016 at 4:49 PM, Rich Alderson <
RichA at livingcomputermuseum.org> wrote:
The SCSI2SD firmware (and hardware) are open source, see the "Files" section of
the scsi2sd site for the git repo information.
Additionally, the guy behind the project is very receptive to feature requests and bug
reports... From: Charles Anthony
Sent: Monday, October 10, 2016 12:53 PM
Correction: .tap format uses 4 byte counters, in little-endian order.
Order is not relevant for the EOF tape marks, of course, since they're
4 bytes of 0.
Stupid memory of mine. Sigh. Anyway, IIUC, the SCSI2SD is like $70; the
firmware appears to be closed, but I wonder if an NDA with them would allow
adding tape emulation capability to their code base? (Given that I have no
knowledge of how SCSI2D works inside, I may be vastly underestimating the
scope of the project.)
-- Charles
9:45 p.m.
On 10/10/16 6:19 PM, Chris Hanson wrote:
On Oct 10, 2016, at 6:11 PM, Josh Dersch <derschjo
at gmail.com> wrote:
I was going to point this out as well.
My only misgiving would be whether SCSI2SD prior to v6 is powerful or fast enough for any
particular use, not whether sufficient resources are available to hack it.
For *any* particular use? No -- I wouldn't put it it to use in a
datacenter :). I have, however, used it on a wide variety of machines.
Right now I have them in a Sun 3/60, a VAX-11/750, a VaxStation 3540, an
AT&T 3B2/600 and a Symbolics XL1200 where they work flawlessly. There
are certainly vintage machines where the SCSI2SD V4 would be noticeably
slower than a real drive, but many vintage machines are simply not fast
enough to come close to the peak throughput of the SCSI2SD.
- Josh
On
10/10/16 5:40 PM, Charles Anthony wrote:
On Mon, Oct 10, 2016 at 4:49 PM, Rich Alderson <
RichA at livingcomputermuseum.org> wrote:
The SCSI2SD firmware (and hardware) are open source, see the "Files"
section of the scsi2sd site for the git repo information.
Additionally, the guy behind the project is very receptive to feature requests and bug
reports... From: Charles Anthony
Sent: Monday, October 10, 2016 12:53 PM
Correction: .tap format uses 4 byte counters, in little-endian order.
Order is not relevant for the EOF tape marks, of course, since they're
4 bytes of 0.
Stupid memory of mine. Sigh. Anyway, IIUC, the SCSI2SD is like $70; the
firmware appears to be closed, but I wonder if an NDA with them would allow
adding tape emulation capability to their code base? (Given that I have no
knowledge of how SCSI2D works inside, I may be vastly underestimating the
scope of the project.)
-- Charles
-- Chris
-- who still needs a JTAG cable to reprogram the boot loader on his bricked SCSI2SD
3:56 p.m.
Don't tape emulator boxes already exist, both for SCSI and Pertec
interfaces? It seems to me that I've seen a few.
--Chuck
5:02 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis
Sent: 10 October 2016 20:57
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: SCSI Tape Emulator
Don't tape emulator boxes already exist, both for SCSI and Pertec
interfaces? It seems to me that I've seen a few.
--Chuck
Do you have any links, I couldn't turn any up?
Are they affordable?
Dave
G4UGM
6:07 p.m.
On Mon, Oct 10, 2016 at 2:02 PM, Dave G4UGM <dave.g4ugm at gmail.com> wrote:
Sure, they exist. Can you actually buy one, or afford to buy one?
Probably not. Looks like a few stale web pages out there for tape
drive emulators with no sales and pricing information => if you can
find someone that will tell you how much they cost the answer is you
can't afford one.
Of course I'd be happy to be proven wrong with hard data on actual
pricing and availability...
Don't tape emulator boxes already exist, both
for SCSI and Pertec
interfaces? It seems to me that I've seen a few.
--Chuck
Do you have any links, I couldn't turn any up?
Are they affordable?
6:34 p.m.
"9-track tape emulator" brings up the usual suspects on G
they are ~10k dollar devices.
http://www.arraid.com/
et. al.
On 10/10/16 3:27 PM, Chuck Guzis wrote:
On 10/10/2016 02:02 PM, Dave G4UGM wrote:
Do you have any links, I couldn't turn any
up? Are they affordable?
Only an echo of a name rattling around in my brainpan--AVAX.
Maybe a google search will turn up something.
--Chuck
7:25 p.m.
Something new:
http://embedded-computing.com/news/launch-scsiflash-tape-replacement-obsole…
but no price listed.
Not targeted at the classic computing hobbyist, so probably going to be expensive.
On 10/10/2016 3:34 PM, Al Kossow wrote:
"9-track tape emulator" brings up the usual
suspects on G
they are ~10k dollar devices.
http://www.arraid.com/
et. al.
On 10/10/16 3:27 PM, Chuck Guzis wrote:
> On 10/10/2016 02:02 PM, Dave G4UGM wrote:
>
>> Do you have any links, I couldn't turn any up? Are they affordable?
>
> Only an echo of a name rattling around in my brainpan--AVAX.
>
> Maybe a google search will turn up something.
>
> --Chuck
>
7:49 p.m.
brochure
http://www.ssd.gb.com/SCSIFlash/SCSIFlash-Tape/SCSIFlash-Tape%E2%84%A2.pdf
On 10/10/16 4:25 PM, Don North wrote:
Something new:
http://embedded-computing.com/news/launch-scsiflash-tape-replacement-obsole…
but no price listed.
Not targeted at the classic computing hobbyist, so probably going to be expensive.
7:53 p.m.
http://www.reactivedata.com/Products/SCSI_Bridge_Emulators_to_CF/imgs/SCSI(…
This looks like another (german) product.
Will keep digging.
On 10/10/16 4:49 PM, Al Kossow wrote:
.JPG){kind=link}
brochure
http://www.ssd.gb.com/SCSIFlash/SCSIFlash-Tape/SCSIFlash-Tape%E2%84%A2.pdf
On 10/10/16 4:25 PM, Don North wrote:
Something new:
http://embedded-computing.com/news/launch-scsiflash-tape-replacement-obsole…
but no price listed.
Not targeted at the classic computing hobbyist, so probably going to be expensive.
10:48 a.m.
On 2016-10-10 12:07, Mike Ross wrote:
Would it not be a SMOP to get a SCSI2SD device to
emulate a tape drive?
Did anybody try if it works on a VAX?
The SCSI2SD is the only one whioch I didn't try, now the newer version
is out, and should even be faster. But didn't have the time to try.
And, SCSI2SD was open-source? So it should be easy to add the .tap files ...
3:16 p.m.
On Oct 11, 2016 3:48 AM, "emanuel stiebler" <emu at e-bbes.com> wrote:
I have booted my VAX-11/730 from a SCSI2SD connected to an Emulex UC17
without any problems.
Mike
On 2016-10-10 12:07, Mike Ross wrote:
out,
and should even be faster. But didn't have the time to try.
Would it not be a SMOP to get a SCSI2SD device to
emulate a tape drive?
Did anybody try if it works on a VAX?
The SCSI2SD is the only one whioch I didn't try, now the newer version is 
9:02 a.m.
I am "playing" with a small VAX and want to
install software onto it, some
of which are in SIMH ".tap" format files. I was thinking it would be nice to
have a SCSI Tape emulator that worked a bit like the USB floppy emulators
that are about.
It would be nice! Not the same, but there is a perl script you may use
to write to the .tap file to a tape device. As I say, different but may
still be useful to some.
http://yagi.h-net.msu.edu/tapcat.pl
thanks to pjustice on #classiccmp irc for this link.
Aaron.
2914
days inactive
2914
days old
24 comments
15 participants
participants (15)
-
aaron＠aaronsplace.co.uk -
aek＠bitsavers.org -
aswood＠t-online.de -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
cmhanson＠eschatologist.net -
dave.g4ugm＠gmail.com -
derschjo＠gmail.com -
emu＠e-bbes.com -
glen.slick＠gmail.com -
jwsmail＠jwsss.com -
north＠alum.mit.edu -
paulkoning＠comcast.net -
RichA＠LivingComputerMuseum.org -
tmfdmike＠gmail.com