>If you're willing to run MSDOS with an appropriate ASPI driver,
>I can send you a utility that I know works []You're
>welcome to the source code.
>--Chuck
Chuck,
Could you share your DOS code with me too? I just assembled the hardware for
that: a self loading HP88780B SCSI-1 9-track Tape Driv
: Pertec Tape Drive Interface Musings
Wasn't Exabyte the only vendor of 8mm tape backup?
--Chuck
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 effort
On 8/3/2015 9:54 PM, Eric Smith wrote:
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone 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
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 permis
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 barfe
On 08/04/2015 09:28 AM, Al Kossow wrote:
On 8/3/15 11:00 PM, Chuck Guzis wrote:
One of these days, I'll port the SCSI interface of the program to
sg(), but not right away--too many other irons in the fire. But
you're welcome to the source code.
It would to be nice to look at. I was back at
On 8/3/15 11:00 PM, Chuck Guzis wrote:
One of these days, I'll port the SCSI interface of the program to sg(), but not
right away--too many other irons in the fire. But you're welcome to the source
code.
It would to be nice to look at. I was back at cartridge tape recovery this
weekend so
On 08/03/2015 09:54 PM, Eric Smith wrote:
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone 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
On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone 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 looking.
On Wed, Jun 10, 2015 at 9:47 AM, Al Kossow 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 when
you get a re
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 match
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 s
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 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 ov
On 06/10/2015 02:07 PM, Dennis Boone wrote:
With that in mind, it might be worth having the putative new spec use a
different name and file extension for itself.
Well, it could be, but if it were my show, I'd greatly extend the file
format to accommodate not only the occurrence of a tape erro
> 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 tha
> 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 t
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 2015-06-10 17:05, Dennis Boone wrote:
> This hypothetical interface + matching software would be intended for
> archiving old tapes and/or making new copies from archived file
> (i.e., to make new boot media for bringup of an old computer). Key
> features would include preservation of
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/s
On 2015-06-10 11:00, Dave G4UGM wrote:
-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny
Billquist
Sent: 10 June 2015 09:39
To: cctalk@classiccmp.org
Subject: Re: Pertec Tape Drive Interface Musings
On 2015-06-10 09:47, Dave G4UGM wrote:
Mark
On 6/10/15 11:25 AM, Dennis Boone wrote:
The discussion of .tap format to which I referred earlier largely seemed
to revolve around the question of representing errors. Block length
markers occur at the beginning and end of data records, unless they're
file marks (length 0). On a read error, s
> 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 oth
> 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 forma
> On Jun 10, 2015, at 11:16 , Chuck Guzis wrote:
>
> Just stick another BOT marker somewhere within the label area, take the drive
> offline and hit LOAD, setting your new density accordingly. AFAIK, no drive
> pays attention to the BOT status while reading.
Brilliant!
Note to self: Make sur
On 06/10/2015 11:12 AM, Mark J. Blair wrote:
On Jun 10, 2015, at 08:46, Al Kossow 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 ret
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 stick
> -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, 20
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 JC
On 06/10/2015 09: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.
Acceptable? I don't know about that. Otherwise,
Another issue with SCSI tape interfaces are in the details. Al has
pointed out the lack of data returned with error conditions. There are
also niggling little differences between implementations that don't
exactly follow ANSI X3T10. For example, is a tape mark considered a
block? I've got dr
> On Jun 10, 2015, at 08:46, Al Kossow 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 and parti
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
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 and partially
read blocks. Most SCSI tape drives don't
return the data
> > 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 box. See e.g.:
http://www.brouhaha.com/~er
On 06/10/2015 03:39 AM, Johnny Billquist wrote:
On 2015-06-10 09:47, Dave G4UGM wrote:
Mark,
Traditional 9-track tapes are always written block-by block with a
"short"
gap between the records, WikiPedia say 0.6" for 1600BPI which sounds
about
right.
My recollection is that the 0.6" gap w
> On Jun 10, 2015, at 08:05, Dennis Boone wrote:
>
>> This hypothetical interface + matching software would be intended for
>> archiving old tapes and/or making new copies from archived file
>> (i.e., to make new boot media for bringup of an old computer). Key
>> features would include preservat
On 06/10/2015 05:06 AM, wulfman wrote:
What memories that brings back. I worked in chatsworth at Pertec on
them tape drives as a Tech on the assembly line. they were a pain in
the butt to make work perfectly. Glad them tape drive days are over.
Mainframe/vacuum column drives were pretty darned
> This hypothetical interface + matching software would be intended for
> archiving old tapes and/or making new copies from archived file
> (i.e., to make new boot media for bringup of an old computer). Key
> features would include preservation of block sizes (even if varying
> arbitrarily) an
> According to my Kennedy manual, issuing a read command causes the
> drive to return one block of data. I can see how that would be used
> in block-oriented applications in which blocks may be randomly read,
> written and re-written on the tape. But most of my magtape experience
> has been us
This hypothetical interface + matching software would be intended for archiving
old tapes and/or making new copies from archived file (i.e., to make new boot
media for bringup of an old computer). Key features would include preservation
of block sizes (even if varying arbitrarily) and file marks
> 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, the gap will not be extended
> any longe
See, thats what I love about this list: Ask a question and get not only good
answers, but also an anecdote from somebody who worked at the company. Thanks,
everybody!
--
Mark J. Blair, NF6X
http://www.nf6x.net/
What memories that brings back. I worked in chatsworth at Pertec on them
tape drives as a Tech on the assembly line.
they were a pain in the butt to make work perfectly. Glad them tape
drive days are over.
On 6/10/2015 12:34 AM, Mark J. Blair wrote:
> I was looking at a couple of documents descri
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny
> Billquist
> Sent: 10 June 2015 09:39
> To: cctalk@classiccmp.org
> Subject: Re: Pertec Tape Drive Interface Musings
>
> On 2015-06-10 09:47, Da
ohnny
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 the Per
rface to tapes. You need to duplicate this in your
interface.
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: P
On 2015-06-10 09:34, Mark J. Blair wrote:
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,
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
51 matches
Mail list logo
