On 08/03/2015 09:54 PM, Eric Smith wrote:
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone d...@msu.edu wrote:
The main limitation seems to be that it's hard to get the (broken)
data from a block that had a read error when using SCSI hardware.
There's probably a way around this if one digs into
On 08/04/2015 06:17 PM, jwsmobile wrote:
I was on the SCSI committee when the tape commands were proposed. The
original that was proposed was to only have a commands which would be on
disk controllers (who were the main players) to perform backups of disk
units and restores. Luckily that
On 08/03/2015 10:48 PM, Jon Elson wrote:
OK, I verified it was indeed made by Pertec. The title
block of the drawings doesn't have anything real obvious,
but there is a bunch of legal boilerplate advising the
restrictions on use of the drawings, and the last words
are prior written
: Pertec Tape Drive Interface Musings
Wasn't Exabyte the only vendor of 8mm tape backup?
--Chuck
On 08/04/2015 09:54 AM, Chuck Guzis wrote:
BTW, what do you use to read UNIX v7 tar files? Linux/BSD modern tar
seem not to like the old archive format--they use the posix
version.
Scratch that--it helps if what you're working with is actually a .tar file.
Nevermind. It's not even 10:30AM
From: Chuck Guzis
BTW, what do you use to read UNIX v7 tar files? Linux/BSD modern tar
seem not to like the old archive format
I have a very slightly hacked version of the V7 tar, which runs under Windows
(under Cygwin). It read all the older TAR files which the newer TARs barfed
On 8/3/2015 9:54 PM, Eric Smith wrote:
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone d...@msu.edu wrote:
The main limitation seems to be that it's hard to get the (broken) data
from a block that had a read error when using SCSI hardware. There's
probably a way around this if one digs into
On 08/03/2015 03:40 PM, Al Kossow wrote:
On 6/10/15 8:17 AM, Jon Elson wrote:
I got a Pertec key to tape system surplus, and created a
mostly software interface with very minimal hardware to
read and write tapes on my S-100 Z-80 system.
XL-40?
The system I had was, I'm pretty sure, made
On 8/3/15 6:41 PM, Jon Elson wrote:
On 08/03/2015 03:40 PM, Al Kossow wrote:
On 6/10/15 8:17 AM, Jon Elson wrote:
I got a Pertec key to tape system surplus, and created a mostly software
interface with very minimal hardware to read and write tapes on my S-100 Z-80
system.
XL-40?
The
On 08/03/2015 09:06 PM, Al Kossow wrote:
do you have anything on the instruction set?
Instruction set? This was not a computer. It was an all
hard-wired-logic key to tape system. It could be set to
enter data to tape, verify data by retyping it, and it would
beep if a record did not
On Wed, Jun 10, 2015 at 9:47 AM, Al Kossow a...@bitsavers.org wrote:
I need to figure out why this program also doesn't deal with tape errors
well.
If you get an error, it will go into an endless loop creating -1 byte
records.
I haven't looked at that in many years, so I'm not sure. Maybe
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone d...@msu.edu wrote:
The main limitation seems to be that it's hard to get the (broken) data
from a block that had a read error when using SCSI hardware. There's
probably a way around this if one digs into lower layers of SCSI magic;
I haven't gone
On 6/10/15 8:17 AM, Jon Elson wrote:
I got a Pertec key to tape system surplus, and created a mostly software
interface with very minimal hardware to read and write tapes on my S-100 Z-80
system.
XL-40?
Someone out here put some XL-40 parts and docs up on eBay this weekend, so I
went
I was looking at a couple of documents describing the Pertec tape interface;
the manual for my Kennedy 9610 tape drive, and a nice reference by a fellow
with a rather familiar name:
http://www.sydex.com/pertec.html
According to my Kennedy manual, issuing a read command causes the drive to
.
Dave
-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mark J.
Blair
Sent: 10 June 2015 08:34
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Pertec Tape Drive Interface Musings
I was looking at a couple of documents describing
On 6/10/15 8:40 AM, Dennis Boone wrote:
Using dd to read tapes to disk discards the block size information.
And that is precisely why I'm thinking of an ad-hoc interface rather
than just plugging a SCSI drive into a UNIX box.
It's eminently possible to image tapes sanely on a unix
-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mark J.
Blair
Sent: 10 June 2015 17:13
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Pertec Tape Drive Interface Musings
On Jun 10, 2015, at 08:46, Al Kossow
On Jun 10, 2015, at 08:46, Al Kossow a...@bitsavers.org wrote:
On 6/10/15 8:15 AM, Mark J. Blair wrote:
And that is precisely why I'm thinking of an ad-hoc interface rather than
just plugging a SCSI drive into a UNIX box.
It also has the advantage that you can return the CRC/checksum
On 6/10/15 9:12 AM, Mark J. Blair wrote:
Ok, now three more questions come to mind:
1) Is it ever acceptable to mix densities on a single tape? I'm not sure that
my Kennedy drive will even allow that, but I don't know if that is universal.
It happens. Len Shustek's copy of APL/360 has
On 2015-06-10 16:32, Dennis Boone wrote:
I don't think it really is that you have a long gap when you rewrite
a bad block per se. But you get long gaps when you stop/start. And
a rewrite implies that you will get a stop/start situation. But in
case you already were going stop/start,
On 06/10/2015 09:40 AM, Al Kossow wrote:
It happens. Len Shustek's copy of APL/360 has JCL that switches from
1600 to 6250 after the label is written. None of my drives can deal with
that, incl the 9610.
I've never tried programatic density switching on the 9610, which is
supported.
Just
On 06/10/2015 12:36 PM, Johnny Billquist wrote:
One problem with preserving errors is that actual tapes do not have
any indication that you have a tape error. In fact, many times you can
recover a tape block by repeatedly read it. Eventually you might read it
without errors. Not to mention how
On 06/10/2015 11:12 AM, Mark J. Blair wrote:
On Jun 10, 2015, at 08:46, Al Kossow a...@bitsavers.org wrote:
On 6/10/15 8:15 AM, Mark J. Blair wrote:
And that is precisely why I'm thinking of an ad-hoc interface rather than just
plugging a SCSI drive into a UNIX box.
It also has the
I need to figure out why this program also doesn't deal with tape
errors well. If you get an error, it will go into an endless loop
creating -1 byte records.
Any block length with the high bit set is an error mark. The loop part
is a good question, though.
The discussion of .tap format
I particularly like the idea of being able to extract questionable
data and CRC/checksum.
That _would_ be really nice.
1) Is it ever acceptable to mix densities on a single tape? I'm not
sure that my Kennedy drive will even allow that, but I don't know if
that is universal.
As others
I guess it could possibly be useful to indicate a bad block on a
tape, in order to preserve the numbering of all the blocks, and
constantly giving a read error when used in a simulator. But it's
kindof a weird reflection of a physical error into a virtual one.
Unless you've corrected the
Earlier, I discussed how I've begun appending metadata to tape image
files after the EOM indicator. Thus far, no simulator chokes on
it. I really need to extend it.
I've seen software that doesn't understand EOM marks, though I think
it's never been one of the major simulators.
With that
27 matches
Mail list logo
