RE: Front Panel Update

[Dave G4UGM]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of tony
duell
> Sent: 10 June 2015 05:46
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: RE: Front Panel Update
> 
> > Interesting.  Varian is a microwave equipment company; I have one of
their
> TWTs sitting on my H960 at home.
> > Vacuum equipment, I could believe that.  But yes, Varian made a 16 bit
> > minicomputer; I had a handbook for it at
> 
> My father was a physical chemist who did a lot of work with vacuum
systems.
> He would swear by Varian (and swear _at_ Vacuum Generators). I assume it
> was the same Varian company.
> 

I once had a Varian computer, well the local computer club had a Varian. I
can't remember what happened to it. 
A friend used to work for them mostly I think on gas chromatographs...

> A number of scientific instrument companies made computers too, of
> course. The most obvious being HP.
> 
> -tony

Dave

RE: 80 column (un)punched cards

[Dave G4UGM]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis
> Sent: 10 June 2015 06:07
> To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off-
> Topic Posts
> Subject: Re: 80 column (un)punched cards
> 
> On 06/09/2015 08:52 PM, Mike Stein wrote:
> > I just got rid of the last of my punched card equipment so I no longer
> > need any blank cards; anybody out there need any?
> >
> > 1 box (2000) normal light buff (off-white) colour, around 500 of same
> > with blue stripe, and several dozen of various colours, all with the
> > normal numbers printed and "all unperforated - ha ha ha!" (obscure and
> > lame reference to a line in Flanders and Swann's 'Have some Madeira,
> > M'dear!' that was apparently too risque for the American sensibility ;-).
> 
> I'd rather think that it was risque for British sensibilites. "A smile on her 
> face
> and an ache in her head..."
> 

So it wasn't about cake?

" She lowered her standards by raising her glass, Her courage, her eyes and his 
hopes"

> --Chuck
> 

Dave

Pertec Tape Drive Interface Musings

[Mark J. Blair]

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 
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 using the tapes in a 
streaming mode, such as when reading/writing one or more tar archives separated 
by file marks.

When writing a tar archive on a magtape from a Unix system, is the archive 
written as a sequence of fixed-size blocks? Or is the entire tar archive 
effectively written as one continuous block which must be streamed with no 
repositioning?

I'm curious because I'm daydreaming about how to build a tape drive interface 
controller, and I wonder whether it might need to potentially stream an entire 
tape in one go vs. being able to safely assume some maximal block size.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Pertec Tape Drive Interface Musings

[Johnny Billquist]

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, 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 using the tapes in a 
streaming mode, such as when reading/writing one or more tar archives separated 
by file marks.


Yes. Tapes pretty much always have blocks...


When writing a tar archive on a magtape from a Unix system, is the archive 
written as a sequence of fixed-size blocks? Or is the entire tar archive 
effectively written as one continuous block which must be streamed with no 
repositioning?


Yes, tar uses a fixed block size. You can actually tell it what block 
size to use.

Most versions of tar I know use the -b switch for this.


I'm curious because I'm daydreaming about how to build a tape drive interface 
controller, and I wonder whether it might need to potentially stream an entire 
tape in one go vs. being able to safely assume some maximal block size.


You can pretty much assume that no tape uses larger blocks than 64K. But 
you have to expect blocks of pretty much any size below that.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

RE: Pertec Tape Drive Interface Musings

[Dave G4UGM]

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. From what I remember as tapes are not the most reliable medium the
process was to have the read head after the write head so the tape could be
read and checked as it was written. If an error was returned the "system"
would backspace, erase the bad block to create a "long gap" and the try
again. Looking at the first MAN page for TAR I found it says it writes
20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
of 10% of the tape in gaps, assuming the tape is perfect.  You can write
longer blocks but then the amount of wastage when you write a bad block goes
up.

So I guess to answer your question. Operating systems and tools expect a
block level interface 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: Pertec Tape Drive Interface Musings
> 
> 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 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 using the
> tapes in a streaming mode, such as when reading/writing one or more tar
> archives separated by file marks.
> 
> When writing a tar archive on a magtape from a Unix system, is the archive
> written as a sequence of fixed-size blocks? Or is the entire tar archive
> effectively written as one continuous block which must be streamed with no
> repositioning?
> 
> I'm curious because I'm daydreaming about how to build a tape drive
> interface controller, and I wonder whether it might need to potentially
> stream an entire tape in one go vs. being able to safely assume some
> maximal block size.
> 
> --
> Mark J. Blair, NF6X 
> http://www.nf6x.net/

Re: Blue tape retainers

[COURYHOUSE]

 
They breathe better  if you do not have them sealed when  you are  baking 
them..ed _www.smecc.org_ (http://www.smecc.org) 
(resent due to error message)





 Original message  
From: Chuck Guzis  
Date: 06/09/2015 9:46  PM (GMT-07:00) 
To: gene...@classiccmp.org,  "discuss...@classiccmp.org:On-Topic and 
Off-Topic Posts"   
Subject: Re: Blue tape retainers 

On  06/09/2015 08:21 PM, ben wrote:

> Also would not a fall like that  damage the tape reel?

When baking tapes with the Wright Line seals, I've  learned to remove the 
seals.  If you leave them on, the tapes at 58C,  will often just fall 
right out the seal--the coefficient of expansion is  much larger for the 
seals than for the tape reels.  After the seal has  had a chance to cool 
off, it fits fine.

This is particularly a  problem with the smaller size  reels.

--Chuck

What is best place to buy new 1/2 tape ? (recent datecodes)

[COURYHOUSE]

What is best place to buy new 1/2 tape ? (recent datecodes)
 
thanks  for advice
 
Ed#  _www.smecc.org_ (http://www.smecc.org)  

Re: Front Panel Update

[Simon Claessen]

Read carefully the subject above and the contents below. change one of the two 
to match.

please.



On 10-06-15 09:15, Dave G4UGM wrote:

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of tony

duell

Sent: 10 June 2015 05:46
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Front Panel Update


Interesting.  Varian is a microwave equipment company; I have one of

their

TWTs sitting on my H960 at home.

Vacuum equipment, I could believe that.  But yes, Varian made a 16 bit
minicomputer; I had a handbook for it at


My father was a physical chemist who did a lot of work with vacuum

systems.

He would swear by Varian (and swear _at_ Vacuum Generators). I assume it
was the same Varian company.



I once had a Varian computer, well the local computer club had a Varian. I
can't remember what happened to it.
A friend used to work for them mostly I think on gas chromatographs...


A number of scientific instrument companies made computers too, of
course. The most obvious being HP.

-tony


Dave




--
Met vriendelijke Groet,

Simon Claessen
drukknop.nl

Re: Pertec Tape Drive Interface Musings

[Johnny Billquist]

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. From what I remember as tapes are not the most reliable medium the
process was to have the read head after the write head so the tape could be
read and checked as it was written. If an error was returned the "system"
would backspace, erase the bad block to create a "long gap" and the try
again. Looking at the first MAN page for TAR I found it says it writes
20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
of 10% of the tape in gaps, assuming the tape is perfect.  You can write
longer blocks but then the amount of wastage when you write a bad block goes
up.


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 longer.


You want to stream the tape, meaning you both get short gaps, and also 
much higher transfer rates, as the stop/start really cause the tape to 
be slow.
But for streaming mode to work, you need to feed data to the tape fast 
enough. And with that, I mean that when one block operation is finished, 
the command for the next one needs to happen very quickly, or else the 
tape will need to stop.


This also means that you do not always have a short gap with an error 
free tape. The gap size depends on whether the tape was running at speed 
or not, when the write starts.



So I guess to answer your question. Operating systems and tools expect a
block level interface to tapes. You need to duplicate this in your
interface.


Yes. Just as systems expects a block level interface to disks.
The "stream of bytes" concept is in many cases an artificial construct 
handled by the OS (Unix), and not the hardware.


Johnny



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 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 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 using the
tapes in a streaming mode, such as when reading/writing one or more tar
archives separated by file marks.

When writing a tar archive on a magtape from a Unix system, is the archive
written as a sequence of fixed-size blocks? Or is the entire tar archive
effectively written as one continuous block which must be streamed with no
repositioning?

I'm curious because I'm daydreaming about how to build a tape drive
interface controller, and I wonder whether it might need to potentially
stream an entire tape in one go vs. being able to safely assume some
maximal block size.

--
Mark J. Blair, NF6X 
http://www.nf6x.net/






--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Alpha 4100 CPU fan

[Rob Doyle]

On 6/9/2015 8:08 AM, Adrian Graham wrote:

Folks,

Trying to source a non-DEC fan for a 4100 CPU since getting them in the UK
is more and more tricky as time goes on. The originals are 12V 0.17A 60mm
3-wire and I've found some almost-identical-but-not-quite 0.18A variants.
Needed to rewire the plugs to match (12V, sense, gnd) but the machine
reports 'CPU0 Fan Fail' despite the fact the fan is running at speed.

Is +0.01A enough to make the monitor board think the fan's failed? Board
itself is fine as it works with its existing fan.

Cheers,


On a Pee Cee, one of the 3 wires is a tachometer output. The tach signal
is a logic signal that pulses when the fan rotor is in a particular
position. Some fans pulse once per rotation. Others are multiple times
per rotation.

Why do you think it measures the fan current?

What the the tach signal look like on the good fan?

Is the tach signal pulsing?

Rob.

RE: Pertec Tape Drive Interface Musings

[Dave G4UGM]

> -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,
> >
> >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. From what I remember as tapes are not the most reliable
> > medium the process was to have the read head after the write head so
> > the tape could be read and checked as it was written. If an error was
> returned the "system"
> > would backspace, erase the bad block to create a "long gap" and the
> > try again. Looking at the first MAN page for TAR I found it says it
> > writes
> > 20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
> > of 10% of the tape in gaps, assuming the tape is perfect.  You can
> > write longer blocks but then the amount of wastage when you write a
> > bad block goes up.
> 
> I don't think it really is that you have a long gap when you rewrite a "bad"
> block per se. 

What else do you get then? I can see from the IBM 2400  manual here:-

http://bitsavers.trailing-edge.com/pdf/ibm/24xx/A22-6862-4_2400_Series_Magnetic_Tape_Units_OEM.pdf

that write checking is accomplished by reading. There really isn't anything 
else you can do when a write fails...
.. well you can retry the write...

> But you get long gaps when you stop/start.

Not on Vacuum Column drives. The columns provide enough mechanical buffering to 
start and stop within the Inter Record Gap.

>  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 longer.
> 
> You want to stream the tape, meaning you both get short gaps, and also
> much higher transfer rates, as the stop/start really cause the tape to be 
> slow.
> But for streaming mode to work, you need to feed data to the tape fast
> enough. And with that, I mean that when one block operation is finished, the
> command for the next one needs to happen very quickly, or else the tape
> will need to stop.
> 
> This also means that you do not always have a short gap with an error free
> tape. The gap size depends on whether the tape was running at speed or
> not, when the write starts.
> 
> > So I guess to answer your question. Operating systems and tools expect
> > a block level interface to tapes. You need to duplicate this in your
> > interface.
> 
> Yes. Just as systems expects a block level interface to disks.
> The "stream of bytes" concept is in many cases an artificial construct handled
> by the OS (Unix), and not the hardware.
> 
>   Johnny
> 
> >
> > 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 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 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 using
> >> the tapes in a streaming mode, such as when reading/writing one or
> >> more tar archives separated by file marks.
> >>
> >> When writing a tar archive on a magtape from a Unix system, is the
> >> archive written as a sequence of fixed-size blocks? Or is the entire
> >> tar archive effectively written as one continuous block which must be
> >> streamed with no repositioning?
> >>
> >> I'm curious because I'm daydreaming about how to build a tape drive
> >> interface controller, and I wonder whether it might need to
> >> potentially stream an entire tape in one go vs. being able to safely
> >> assume some maximal block size.
> >>
> >> --
> >> Mark J. Blair, NF6X 
> >> http://www.nf6x.net/
> >
> >
> 
> 
> --
> Johnny Billquist  || "I'm on a bus
>||  on a psychedelic trip
> email: b...@softjar.se ||  Reading murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Wanted: stand for NeXT monitor

[Liam Proven]

On 29 May 2015 at 16:09, Chris Osborn  wrote:
> In fact, when I got OSX (aka OPENSTEP 5) running on a beige G3 tower for the 
> first time, I couldn’t understand why it was so absolutely unusable, since 
> the performance of OPENSTEP 4 on my NeXT was very snappy.


It *really* did not benefit from running on a RISC chip.

(E.g. http://arstechnica.com/civis/viewtopic.php?f=19&t=766974 --
sadly the original article has gone. Couldn't find a mirror.)

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Pertec Tape Drive Interface Musings

[wulfman]

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 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 
> 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 using the tapes in a 
> streaming mode, such as when reading/writing one or more tar archives 
> separated by file marks.
>
> When writing a tar archive on a magtape from a Unix system, is the archive 
> written as a sequence of fixed-size blocks? Or is the entire tar archive 
> effectively written as one continuous block which must be streamed with no 
> repositioning?
>
> I'm curious because I'm daydreaming about how to build a tape drive interface 
> controller, and I wonder whether it might need to potentially stream an 
> entire tape in one go vs. being able to safely assume some maximal block size.
>


-- 
The contents of this e-mail and any attachments are intended solely for the use 
of the named
addressee(s) and may contain confidential and/or privileged information. Any 
unauthorized use,
copying, disclosure, or distribution of the contents of this e-mail is strictly 
prohibited by
the sender and may be unlawful. If you are not the intended recipient, please 
notify the sender
immediately and delete this e-mail.

RE: 80 column (un)punched cards

[tony duell]

> 1 box (2000) normal light buff (off-white) colour,
> around 500 of same with blue stripe, and several
> dozen of various colours, all with the normal
> numbers printed and "all unperforated - ha ha ha!"
> (obscure and lame reference to a line in Flanders
> and Swann's 'Have some Madeira, M'dear!' that was
> apparently too risque for the American sensibility
> ;-).

Now I thought I knew most of Flanders and Swann, but 
'all unperforated' doesn't bring anything to mind. Care to
explain (off list if it's not suitable for the general public).

I did find it mildly amusing that the Facit 4070 service manual
refers to totally blank tape -- not even feed holes punched -- 
as 'virgin tape' ;-)

-tony

equipment available

[Jay West]

Lowboy rack, two RL0X drives and one 11/23. From the pictures it looks a bit
dirty, but we know RL0X and 11/23's are pretty solid even after age.

 

Location is Newbury, UK

 

Email me off-list if interested.

 

Best,

 

J

 

 

Re: Pertec Tape Drive Interface Musings

[Mark J. Blair]

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/

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 longer.

Some drives will back up, get up to speed, read the end of the previous
block, switch from write to read when the irg goes by.

The size of the irg can vary upwards from a minimum spec, at least in
drives that try to stream, as they will keep the tape running for a
moment in hopes that data will arrive to be written.

De

Re: Pertec Tape Drive Interface Musings

[Mark J. Blair]

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'm not sure if 
there's already a good file format for that, and I have a dim memory of 
previously reading a lament about common archival methods failing to preserve 
blocking.

This thing would have some sort of ad-hoc interface(s) (USB? Ethernet? 
Standalone with an SD card for storage? Pneumatic?), specifically to avoid 
being flavored by any particular operating system's idea of what a tape drive 
ought to look like. Is there any other sort of metadata that should be 
included? Any wish lists for features or file format details?

I'm just brainstorming, and this isn't guaranteed to ever see the light of day, 
of course.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 using the tapes in a streaming mode, such as when
 > reading/writing one or more tar archives separated by file marks.

The Cipher manuals have some nice diagrams of tape layouts and tape
movement that might be useful to you.

Rewriting blocks on tape doesn't usually work; the spacing and such
isn't quite repeatable enough.  That said, I _have_ seen VMS rename
files on tape.  Yes, I was abusing it to see if it would work. :)

 > When writing a tar archive on a magtape from a Unix system, is the
 > archive written as a sequence of fixed-size blocks? Or is the entire
 > tar archive effectively written as one continuous block which must be
 > streamed with no repositioning?

Tar will assemble blocks and write them.  You can control the block size
it uses.  For 9-track, max block size depends a bit on system, but won't
be above 64k.  Some systems may only support up to 32k, or even 16k
(Prime until the mid 80s).  On ANSI or IBM labeled tapes, it's common to
see records as short as 80 bytes (VOL1/HDR1 records), and shorter will
work.  I can't recall if there's a minimum.

Terminology may be key to understanding all of this.  On the 9-track
tape, there are only a few kinds of objects: records containing data,
inter-record gaps, erased areas, file marks, maybe noise records.  The
drive doesn't really care how much data is in a data record as long as
it's shorter than the max size.  There is no "fixed size record" on a
9-track tape.  The distinction between "record" and "block" really
exists in the host.  For example, tar will gather up data from a file in
file system sized units, e.g. 512 byte disk sectors.  It thinks of those
as records, and it assembles a block (-b option, say 5120 bytes) of a
given size, and writes that to the tape.  On tape, that block is just a
5120 byte record.

De

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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'm not sure if there's already a good
 > file format for that, and I have a dim memory of previously reading a
 > lament about common archival methods failing to preserve blocking.

The E11/SimH .tap formats are dead simple, and relatively complete as
far as capturing the arrangement of the bits on tape.  They retain block
size, actual data, file marks, and have a provision for indicating
errors encountered when reading the tape.  There was a discussion
recently (simh list?) about standardizing the behavior of the error
marks.  The format doesn't have a mechanism for preserving metadata.  In
the SimH variant, record lengths must be even.  In the E11 variant, they
on't have to be.  Otherwise, the two are equivalent.

Using dd to read tapes to disk discards the block size information.

De

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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 reliable.  I have 
memories of tossing about a half-dozen tapes into my big Samsonite 
briefcase and hopping a plane to travel cross-country routinely.  I 
don't think I ever gave a thought to the reliability of the tapes.  All 
in all, I think I had more problems with disk drives than with tapes.


After all, didn't the IRS keep its taxpayer records on many many reels 
of half-inch tape for decades?


Anent Pertec IFs:  You have to understand that the Pertec interface is 
extremely simple-minded from a bygone day  There are minor differences 
between manufacturers in the amount of information and features afforded 
by a given formatter, but generally, they do adhere to a common model.


One thing that I've never cared for on *nix tapes is that the 
implementors never enforced any sort of standard tape label records. 
That can be very frustrating if the physical labels have dried out and 
gotten lost or if they're cryptic (e.g. "Joe's archive").  The label 
records on, say, an IBM SL tape can tell you a great deal about the tape 
contents.  Even CDC on their NOS 9-track tapes tended to include ANSI 
labels before lapsing into the gobbledy-gook that was 6-bit display code 
and 60 bit words.


Perhaps some UNIX(R) installations implemented an ANSI labeling scheme, 
but to be sure, AT&T didn't use any on their distribution tapes.


--Chuck

Re: Pertec Tape Drive Interface Musings

[Mark J. Blair]

> 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 preservation of block sizes (even if varying
>> arbitrarily) and file marks. I'm not sure if there's already a good
>> file format for that, and I have a dim memory of previously reading a
>> lament about common archival methods failing to preserve blocking.
> 
> The E11/SimH .tap formats are dead simple, and relatively complete as
> far as capturing the arrangement of the bits on tape.  They retain block
> size, actual data, file marks, and have a provision for indicating
> errors encountered when reading the tape.

Cool! I will look them up. Being able to use the images in a simulator without 
any further translation is a plus.

>  There was a discussion
> recently (simh list?) about standardizing the behavior of the error
> marks.

I will look that up, too.

> 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. Chuck's comment about his USB to Pertec 
project woke up my own dormant Pertec interface project idea in my cluttered 
head. Hmm, this might be as simple as a BeagleBone Black board with an LCD 
board (both of which I already have), and a custom board with a cheap FPGA and 
the Pertec electrical interface.

Yeah, I could probably implement the interface just fine in software using a 
fast microcontroller with lots of GPIOs. But FPGAs are what I know best.

"When your only tool is a hammer, every problem ends up looking like broken 
pottery."
-- Me


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Pertec Tape Drive Interface Musings

[Jon Elson]

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 was for 800 BPI, and that they went 
to a 0.3" gap for 1600 and 6250.

From what I remember as tapes are not the most reliable medium the
process was to have the read head after the write head so the tape 
could be

read and checked as it was written.
Yes, other than some super-low end drives like Kennedy digital 
incremental and some Pertec drives, most drives were read after write.  
This required completely independent read and write hardware.


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.  It would write, back up and re-read the block to verify.  
My recollection was there was only one data head, so it HAD to back up 
to read the data.  My interface and the Z-80 was maxed out doing one or 
the other, so that was fine.

If an error was returned the "system"
would backspace, erase the bad block to create a "long gap" and the try
again.
Usually, it would just rewrite over the bad record.  Only if the bad 
record remained after several retries and a cleaner cycle, would it do 
the extended gap, to move the record to a new (and hopefully better spot 
on the tape).

Looking at the first MAN page for TAR I found it says it writes
20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a 
"waste"

of 10% of the tape in gaps, assuming the tape is perfect.  You can write
longer blocks but then the amount of wastage when you write a bad 
block goes

up.


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 longer.


You want to stream the tape, meaning you both get short gaps, and also 
much higher transfer rates, as the stop/start really cause the tape to 
be slow.
All tape systems I know of wrote essentially identical gaps whether 
doing start/stop or streaming.
Speed of transfer goes way up if you can avoid the start/stop, but it 
made no difference in capacity of a tape.  The record gaps are set by 
ANSI standards for data interchangeability.
But for streaming mode to work, you need to feed data to the tape fast 
enough. And with that, I mean that when one block operation is 
finished, the command for the next one needs to happen very quickly, 
or else the tape will need to stop.


I wrote a disk dump/restore program for our PDP-11 a long time ago. I 
discovered there was a 10 us "reinstruct window" in the Datum 
controller, so if you could just get a new write or read operation 
loaded into the controller within that time, it would stream the drive.  
No way to do that with interrupts, but with double buffering and doing 
everything by polling, it was just barely possible to make it in time.  
It required error-free media, but if you had that, you could dump or 
restore a 40 MB Calcomp disk to 45 IPM Pertec mag tape in under ten 
minutes, including rewind.
It was a total block for block copy, not a file by file copy, so the 
tape was pretty useless except for restoring again to a disk pack.


Jon

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > > 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/~eric/software/tapeutils/

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.

De

Re: Pertec Tape Drive Interface Musings

[Al Kossow]

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 if the read doesn't succeed. Some drives have a seismic mode 
for dealing with oil exploration tapes
which returns anything read, but it has it's own set of problems (it will 
happily return garbage if the density doesn't
match)

Re: Pertec Tape Drive Interface Musings

[Al Kossow]

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 box.  See e.g.:

http://www.brouhaha.com/~eric/software/tapeutils/

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.

De




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.

Re: Pertec Tape Drive Interface Musings

[Mark J. Blair]

> 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 partially 
> read blocks. Most SCSI tape drives don't
> return the data if the read doesn't succeed.

I particularly like the idea of being able to extract questionable data and 
CRC/checksum.

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.

2) What's the scoop on a final record overlapping the EOT marker? Or even a new 
record starting after the EOT marker? I seem to recall reading about some 
applications that stuck data after the EOT, such as backup volume information.

3) Did anybody ever go over to the dark side and implement copy protection on 
magtapes, say, by deliberately including a record with bad CRC that a normal 
driver+drive would not support writing? Or was that evil limited to the floppy 
disk world?


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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 drives that go both ways--one says it isn't and so 
doesn't increment the position (I'd call that an error) and other says 
it is.


It's mostly the problem of adding another layer of someone's 
interpretation to another older protocol and hoping for something 
coherent to come out.


--Chuck

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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, it depends on the 
drive.  Some will allow a density change only at load point.



2) What's the scoop on a final record overlapping the EOT marker? Or
even a new record starting after the EOT marker? I seem to recall
reading about some applications that stuck data after the EOT, such
as backup volume information.


Not that unusual--the EOT marker is mostly intended as a warning when 
writing.  Long-record tapes frequently write past the EOT.  On the old 
CDC vacuum-column (60x, 65x) drives, I'd sometimes add an extra BOT 
marker or two on a reel and start a new "logical tape" there.  You just 
hit the "LOAD" button again while the tape was already loaded and it 
would space down to the next BOT marker.  I don't know if anyone else's 
drives did that, though.  I had my pet deadstart tapes with several 
different versions of a system on them.



3) Did anybody ever go over to the dark side and implement copy
protection on magtapes, say, by deliberately including a record with
bad CRC that a normal driver+drive would not support writing? Or was
that evil limited to the floppy disk world?


Half-inch tape comes from a more polite, gentler era.  Although, on the 
7-track drives, you could toggle the parity, which would confuse the 
heck out of someone trying to read the tape.


--Chuck

Re: Pertec Tape Drive Interface Musings

[Al Kossow]

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 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.

You also should keep an eye on the rubber capstan, they go gooey. I think I 
still have a box of capstan motors with the capstans on them from about a dozen 
drives
I scrapped along with board spares. The 9610 was the only drive I've had luck 
with recently reading 800bpi tapes. It also is one of the better documented 
tri-density
streaming drives.


2) What's the scoop on a final record overlapping the EOT marker? Or even a new 
record starting after the EOT marker? I seem to recall reading about some 
applications that stuck data after the EOT, such as backup volume information.



It happens, esp in backup programs. I've seen it a lot in multi-volume DEC10 
backups. You have to treat the physical EOT sense tape as a warning.


3) Did anybody ever go over to the dark side and implement copy protection on 
magtapes


Not that I know of.

RE: Pertec Tape Drive Interface Musings

[Dave G4UGM]

> -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  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
> > partially read blocks. Most SCSI tape drives don't return the data if
the read
> doesn't succeed.
> 
> I particularly like the idea of being able to extract questionable data
and
> CRC/checksum.
> 
> 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.
> 

No idea. I suspect most drives will only change density at BOT

> 2) What's the scoop on a final record overlapping the EOT marker? Or even
a
> new record starting after the EOT marker? I seem to recall reading about
> some applications that stuck data after the EOT, such as backup volume
> information.

I seem to recall ALL applications put data after the EOT marker, should they
fill the tape. So on a write you get an EOT reached status, BUT to get this
you must have written past the EOT marker. If its non-labelled tape you
write a tape mark, rewind and unload the tape and ask for another.  It is up
to the application program to know there is more data. Typically on a
mainframe you wrote labelled tapes, so you needed to write a Tape Mark and
the End of Volume Label and any other labels needed, then another tape mark,
then unload and ask for the next reel. This usually goes after the EOT
marker. For labelled tapes the label tells you if there is another tape in
set.


> 
> 3) Did anybody ever go over to the dark side and implement copy protection
> on magtapes, say, by deliberately including a record with bad CRC that a
> normal driver+drive would not support writing? Or was that evil limited to
> the floppy disk world?


I don't believe you can do that. IBM Mainframe copy protection usually
involved using the serial number of the Mainframe. Total PITA when doing
Disaster recovery checks

> 
> 
> --
> Mark J. Blair, NF6X 
> http://www.nf6x.net/

Need DZQ11 (M3106) Print Set

[Noel Chiappa]

So I'm working with a group of 'busted' DZQ11's (the symptom is that Master
Clear - 020 - bit in the CSR stays set, even if I write a 0 to the CSR), and
so I need access to a set of prints for this card; they are MP-01795. They
don't seem to be online anywhere, though.

(They may not be fixable, because a lot of the circuitry is in a large custom
chip, which is of course now unobtainium, but I'm hoping it's something
simple.)

This is a relatively recent card, so I'm hoping someone out there has a set.
If not, I can probably dope out how it works from the Maintainence Manual
(which _is_ available), but it would be _much_ easier if I have some prints to
look at too...

I would gladly scan them in for general distribution/use, if someone has a set
they can loan me. I do have an A3 professional level scanner on a SCSI, so
it's a snap for me to scan prints. (Or if someone wants to scan them
themselves, that's of course fine too!)

Thanks in advance, and I'm crossing my fingers! :-)

 Noel

Re: WTB /WTT DEC TZ30 and/or 1/2" open reel SCSI magtape drives

[Mark J. Blair]

Update: TZ30 located and ordered.

And now I'm thinking that I ought to build a custom Pertec interface (as is 
being discussed in another thread) that's particularly suited for archival 
work, though I might still be interested in a SCSI magtape drive or SCSI/Pertec 
adapter anyway.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Alpha 4100 CPU fan

[Richard Loken]

On Tue, 9 Jun 2015, Adrian Graham wrote:

> Trying to source a non-DEC fan for a 4100 CPU since getting them in the UK
> is more and more tricky as time goes on. The originals are 12V 0.17A 60mm
> 3-wire and I've found some almost-identical-but-not-quite 0.18A variants.
> Needed to rewire the plugs to match (12V, sense, gnd) but the machine
> reports 'CPU0 Fan Fail' despite the fact the fan is running at speed.

I too found I could not find a sufficiently similar fan to run in a 4100
without being seen as a fan failure so I ended up rebuilding them.  These
are fans have replaceable bearings so I took mine apart, measured the
bearings with calipers, and purchased a dozen replacements from a random
web bearing supplier.  That was three or four years ago, if I hunt very
hard then I might the name of the vendor and the part number but right
now my basement office is in boxes as we clean up renovate after a burst
water pipe.

-- 
   Richard Loken VE6BSV, Unix System Administrator : "Anybody can be a father
   Athabasca University:  but you have to earn
   Athabasca, Alberta Canada   :  the title of 'daddy'"
   ** richar...@admin.athabascau.ca ** :  - Lynn Johnston

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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 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.


--Chuck

Re: Pertec Tape Drive Interface Musings

[Jon Elson]

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 return the CRC/checksum and partially 
read blocks. Most SCSI tape drives don't
return the data if the read doesn't succeed.

I particularly like the idea of being able to extract questionable data and 
CRC/checksum.

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.
No, never OK.  There is a format ID written OVER the BOT marker for 1600 
and 6250 that tells the drive what the density format is.  If you EVER 
see the density change, is is because a tape was partially overwritten 
at a different density, and then you've either read off the end of the 
re-written portion, or the last EOF was lost somehow.

2) What's the scoop on a final record overlapping the EOT marker? Or even a new 
record starting after the EOT marker? I seem to recall reading about some 
applications that stuck data after the EOT, such as backup volume information.
Yeah, the EOT sensor is only an inch or so ahead of the write head, so 
any long record will overlap the EOT sensor, and then the trailer and 
EOF records will have to continue on past that for a few additional inches.

3) Did anybody ever go over to the dark side and implement copy protection on 
magtapes, say, by deliberately including a record with bad CRC that a normal 
driver+drive would not support writing? Or was that evil limited to the floppy 
disk world?



UGH!  You can't guarantee this would work on different vendor's hardware.

Jon

Re: Pertec Tape Drive Interface Musings

[Mark J. Blair]

> 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 sure my imaginary interface doesn't pay attention to BOT 
marker while reading.


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 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, should one write a single error
mark, a pair of them, should one include the busted data, etc.  The
answers are complicated by the SCSI habit of hoarding the damaged data.

De

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 have indicated, portability of such a tape would be poor.

 > 2) What's the scoop on a final record overlapping the EOT marker? Or
 > even a new record starting after the EOT marker? I seem to recall
 > reading about some applications that stuck data after the EOT, such
 > as backup volume information.

I'll add two thoughts to the other answers:

1. The specs say there's supposed to be quite a bit of tape (10 feet, I
want to say) after the EOT reflector.

2. It was not unheard of for broken applications to run a tape clear off
the source reel.  The drive reports the passage of an EOT marker.  Few
systems enforce any behavior in this regard.  If you keep going, you
keep going.  At least until the tail comes off the source reel.

De

Re: WTB /WTT DEC TZ30 and/or 1/2" open reel SCSI magtape drives

[Jason T]

On Wed, Jun 10, 2015 at 12:11 AM, Chuck Guzis  wrote:
> Not complete off-topic, but I just received an email from Shaun Halstead
> that he's looking to get rid of a CDC Keystone drive (vertically mounted)
> (read: TU80 family, with Pertec interface) that was apparently used on a
> Xerox system.
>
> If you're in the Chicago area and interested, you might want to drop Shaun a
> line at microf...@microfilm.kscoxmail.com

I've also got a Pertec-interfaced 9-track to give away, also in the
Chicago area.  HP 9-track tape drive, badged as AT&T 1600/6250, Pertec
interface. In rack-mount case (not desktop) and has no rails.
Powers-up and passes internal self-tests. Haven't run a tape through
it yet.

I believe this model can accomodate HP's Pertec-to-SCSI adapter board,
assuming you can find one not already attached to a working drive.

j

Re: Pertec Tape Drive Interface Musings

[Al Kossow]

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, should one write a single error
mark, a pair of them, should one include the busted data, etc.  The
answers are complicated by the SCSI habit of hoarding the damaged data.



The current spec is 'undefined'. Bob extended it in Simh but behavior on read
errors was never specified. John Bordynuik extended it in other ways in the
tapes read by JBI, Inc., but I never found out what those extensions were.

As was discussed on the Simh list, there is a bunch of information, like drive
type and how it handles bad blocks, that should be in the tape image, but 
currently
is not.

I would think an error that returns no data would be a single error mark, but 
one
with returned data should be two to handle the read reverse case.

OEM minis /was Re: Front Panel Update

[Brent Hilpert]

On 2015-Jun-09, at 4:07 PM, William Donzelli wrote:
> Varian bought the design of the 620. I forget the name of the original
> firm, but I have a brochure on it.
> 
> Weird things happen. CDC rebadged small VAX machines and Nova 3s, for
> example, even with their minicomputer line intact.

> On Tue, Jun 9, 2015 at 6:45 PM, Paul Koning  wrote:
>> 
>>> On Jun 9, 2015, at 5:58 PM, tony duell  wrote
>>> 
 WTF? Varian was a competitor of DEC. They made minis themselves. Sounds
 extremely strange that one would take a DEC mini, and put a Varian badge
 on it. Did someone try to make a joke?
>>> 
>>> I will always think of Varian as a maker of (very high quality) vacuum 
>>> equipment.
>>> 
>>> I am sure this was not a joke. It wasn't just the name, the switch handles 
>>> were all green, the silkscreening
>>> was different, etc. It was a normal PDP8/e inside, though. It was part of a 
>>> piece of lab equipment (I forget
>>> what) and I had to do a minor repair on the PDP8/e side (this was over 20 
>>> years ago...). I was pleased to
>>> see that apart from a custom interface board, the rest of it was standard 
>>> DEC boards, so the printsets I
>>> had applied.
>> 
>> Interesting.  Varian is a microwave equipment company; I have one of their 
>> TWTs sitting on my H960 at home.  Vacuum equipment, I could believe that.  
>> But yes, Varian made a 16 bit minicomputer; I had a handbook for it at one 
>> time (now lost, I suspect).  And if memory serves, the reason is that there 
>> was one in the Computer Science department at the University of Illinois 
>> where I studied.  I remember nothing about the architecture, other than the 
>> fact it supported user microprogramming.
>> 
>> Possibly the OEM PDP8 predates that device.  Or possibly it wasn’t enough of 
>> a competitor for DEC to stop doing OEM business with Varian


Another case example, going from the brochures at CHM / bitsavers, in the early 
70s Foxboro were marketing their unique FOX-1 (perhaps the coolest-looking 
minicomputer ever):
http://www.computerhistory.org/revolution/artifact/132/544

.. while their FOX-2 was a rebadged / OEM PDP-11/20  (see page 5 of FOX-2 pdf):
http://bitsavers.trailing-edge.com/pdf/foxboro/

Out of curiousity: should any DEC-heads download the FOX-2 brochure, on pdf 
page 11, what is the unit above the 11/20 & paper tape reader? looks like it 
would be OEM from DEC, a disk or drum controller?.

Re: Pertec Tape Drive Interface Musings

[Johnny Billquist]

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,

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. From what I remember as tapes are not the most reliable
medium the process was to have the read head after the write head so
the tape could be read and checked as it was written. If an error was

returned the "system"

would backspace, erase the bad block to create a "long gap" and the
try again. Looking at the first MAN page for TAR I found it says it
writes
20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
of 10% of the tape in gaps, assuming the tape is perfect.  You can
write longer blocks but then the amount of wastage when you write a
bad block goes up.


I don't think it really is that you have a long gap when you rewrite a "bad"
block per se.


What else do you get then? I can see from the IBM 2400  manual here:-

http://bitsavers.trailing-edge.com/pdf/ibm/24xx/A22-6862-4_2400_Series_Magnetic_Tape_Units_OEM.pdf

that write checking is accomplished by reading. There really isn't anything 
else you can do when a write fails...
.. well you can retry the write...


You misunderstood me. It's not that you do not get a larger gap, but you 
can get a large gap even without an error. It's not an explicit error 
recovery strategy, but a fallout from having to stop, rewind, start and 
write again.



But you get long gaps when you stop/start.


Not on Vacuum Column drives. The columns provide enough mechanical buffering to 
start and stop within the Inter Record Gap.


The mechanical buffering don't have anything to do with this. It's a 
question of how fast you get the tape up to speed across the heads.
Now, admittedly, vacuum column tape drives have an advantage that you 
don't have to accelerate the reels that violently, since the vacuum 
columns gives you some time to speed up the reels. But the acceleration 
of the tape across the head is simply a question of friction of the 
drive wheel for that section of the tape, and the mass of the tape itself.


However, since vacuum column tapes have a much higher tape speed across 
the heads than direct drive or spring tensioned tape drives, you get 
into the same cat and mouse game anyway. Acceleration of tape across the 
heads is the issue. How much tape will pass before you reach top 
velocity, and how precise is this? A larger gap allows for more 
variation. If the tape is already running at full speed, and you are 
just continuously writing, then you can easily control how long gap you 
create, and can create minimal ones.


Johnny




  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 longer.

You want to stream the tape, meaning you both get short gaps, and also
much higher transfer rates, as the stop/start really cause the tape to be slow.
But for streaming mode to work, you need to feed data to the tape fast
enough. And with that, I mean that when one block operation is finished, the
command for the next one needs to happen very quickly, or else the tape
will need to stop.

This also means that you do not always have a short gap with an error free
tape. The gap size depends on whether the tape was running at speed or
not, when the write starts.


So I guess to answer your question. Operating systems and tools expect
a block level interface to tapes. You need to duplicate this in your
interface.


Yes. Just as systems expects a block level interface to disks.
The "stream of bytes" concept is in many cases an artificial construct handled
by the OS (Unix), and not the hardware.

Johnny



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 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 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 using
the tapes in a streaming mode, such as when reading/writing one or
more tar archives separated by file marks.

When writing a tar archive on a magtape from a Unix system, is the
archive written as a sequence of fixed-size blocks? Or is the en

Re: Pertec Tape Drive Interface Musings

[Johnny Billquist]

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, the gap will not be extended
  > any longer.

Some drives will back up, get up to speed, read the end of the previous
block, switch from write to read when the irg goes by.


I think they all back up and then start accelerating. But how precise 
can you make the acceleration? And how fast can you switch from read to 
write? All drives I've worked on created long gaps if they appended a 
new block from standstill.



The size of the irg can vary upwards from a minimum spec, at least in
drives that try to stream, as they will keep the tape running for a
moment in hopes that data will arrive to be written.


Yes.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Pertec Tape Drive Interface Musings

[Johnny Billquist]

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 block sizes (even if varying
  > arbitrarily) and file marks. I'm not sure if there's already a good
  > file format for that, and I have a dim memory of previously reading a
  > lament about common archival methods failing to preserve blocking.

The E11/SimH .tap formats are dead simple, and relatively complete as
far as capturing the arrangement of the bits on tape.  They retain block
size, actual data, file marks, and have a provision for indicating
errors encountered when reading the tape.  There was a discussion
recently (simh list?) about standardizing the behavior of the error
marks.  The format doesn't have a mechanism for preserving metadata.  In
the SimH variant, record lengths must be even.  In the E11 variant, they
on't have to be.  Otherwise, the two are equivalent.

Using dd to read tapes to disk discards the block size information.


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 many tapes I have "fixed" by just 
folding the tape in the opposite direction where there have been a 
bend/kink in it. Easy fix.


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.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Front Panels - Shipping commences

[Rod Smallwood]

Hi Guys
   I have started to ship 8/e front panels as of to-day.
I took some
 to the shippers to-day and more will go to-morrow
Everybody who placed an order will get at least one from the first batch.

The next batch will be twenty panels.
Type B will be available and both round holes will be cut by the 
plastics company


Rod Smallwood

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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 many tapes I have "fixed" by just
folding the tape in the opposite direction where there have been a
bend/kink in it. Easy fix.

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.


...and some errors are correctable by the formatter (and so indicated on 
the interface).  I see no way to indicate that in the SIMH tape proposal.


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.  Right now it just indicates date, device 
information, notes from the person doing the reading and error messages 
during reading and file structure; e.g.


536 x 10240 bytes
Filemark at block 537
3 x 80 bytes...

Okay for now; save for a photo of the tape.  Basically, anything known 
before and during reading of the tape and writing of the image.


--Chuck

Re: Looking for the Tek 465 of Logic Analysers

[Ken Seefried]

Thanks for the input everyone.  In summary, I got recommendations for:

- HP 16500C (lesser a 16500B, but not a 16500A) (mainframe)
- HP 16700/16900/17500 (mainframe, bigger-faster-stronger, still pretty
expensive, can use 16500 cards)
- HP 166x or 167x (portable, modern, look for hard drive)
- HP 165x (portable, older, only buy cheap, look for hard drive)
- HP 1630D, 1630G or 1631 (old, HPIB and HPIL interfaces, no special
software needed, but you apparently need be able to control it with an
external HPIB controller to get the most out of it)
- Tek 1240
- Gould Biomation K100D (software in rom, HPIB interface, assuming you need
HPIB literacy to use effectively)
- Tek DAS9200 (be careful to get the right pods (several variations), etc)
- Tek TLA710/TLA720 (PC attached, Linux capable)

General advice offered:

- Look for hard drives or no special software required for longest life.
Floppies required == bad.
- Make really sure you get probes, and the right probes, for your kit.
They're often not available separately for non-st00pid money.
- There's a crazy array of ancillary features to consider: o-scope
functions, processor assemblers/disassemblers, pattern generators,
specialized inputs/outputs, timebases, embedded Unix machines, etc.  Know
what you might need.

So I've got a lot of manuals to read, but the 16500C sure looks like a ton
of bang per US$.  You can even get an expansion chassis (10 additional
slots) if you need to go to ludicrous speed on the number of
probes/features.

KJ

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 error, and can therefore write an error free
image, _not_ marking the error somehow would be sort of cruel to the
next guy.  He might spend hours trying to _use_ the software that
contains a damaged file without any clue, else.

De

Re: Pertec Tape Drive Interface Musings

[Dennis Boone]

 > 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 in mind, it might be worth having the putative new spec use a
different name and file extension for itself.

De

Re: Pertec Tape Drive Interface Musings

[Chuck Guzis]

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 error, but also 
the "type" of error.Some formatters will raise the error flag during 
the transmission of a single frame in error.  It might be useful to have 
some way to notate that--assuming that a controller is capable of 
recording such an event.


In my case, it's mostly reading tapes and providing the data to 
customers.   So blocked EBCDIC record files have already been unblocked 
with EBCDIC->ASCII translation.  The .TAP file is provided as a 
reference in case of my getting something really wrong.


If it's a UNIX(R)-type unlabeled tape, I extract the data between 
filemarks and assign a name of 0001, 0002 and so forth.


--Chuck

Re: Alpha 4100 CPU fan

[Jon Elson]

On 06/10/2015 01:13 PM, Richard Loken wrote:

On Tue, 9 Jun 2015, Adrian Graham wrote:


Trying to source a non-DEC fan for a 4100 CPU since getting them in the UK
is more and more tricky as time goes on. The originals are 12V 0.17A 60mm
3-wire and I've found some almost-identical-but-not-quite 0.18A variants.
Needed to rewire the plugs to match (12V, sense, gnd) but the machine
reports 'CPU0 Fan Fail' despite the fact the fan is running at speed.

I too found I could not find a sufficiently similar fan to run in a 4100
without being seen as a fan failure so I ended up rebuilding them.  These
are fans have replaceable bearings so I took mine apart, measured the
bearings with calipers, and purchased a dozen replacements from a random
web bearing supplier.  That was three or four years ago, if I hunt very
hard then I might the name of the vendor and the part number but right
now my basement office is in boxes as we clean up renovate after a burst
water pipe.

Boca Bearings has just about any bearing you could want.  I've rebuilt 
some noisy Dell computer fans with their bearings.


Jon

Re: Madeirs (was 80 column (un)punched cards)

[Dennis Boone]

 > "all unperforated - ha ha ha!"  (obscure and lame reference to a line
 > in Flanders and Swann's 'Have some Madeira, M'dear!' that was
 > apparently too risque for the American sensibility ;-).

The Limeliters covered it in the US in 1961, so apparently not. :)

De

Re: Madeirs (was 80 column (un)punched cards)

[Mike Stein]

- Original Message - 
From: "Dennis Boone" 

To: "General Discussion: On-Topic and Off-Topic
Posts" 
Sent: Wednesday, June 10, 2015 8:15 PM
Subject: Re: Madeirs (was 80 column (un)punched
cards)



> "all unperforated - ha ha ha!"  (obscure and
> lame reference to a line
> in Flanders and Swann's 'Have some Madeira,
> M'dear!' that was
> apparently too risque for the American
> sensibility ;-).

The Limeliters covered it in the US in 1961, so
apparently not. :)

De


Well, the reference was to the following lines:

"He had slyly inveigled her up to his flat
To view his collection of stamps
(All unperforated, heh, heh, heh...)
[said in a most lewd and evil aside]

"And he said as he hastened to put out the cat
The wine, his cigar and the lamps,
Have some Madeira, m'dear!"

The 'All unperforated...' line (my favourite) was
in the English versions but for some reason they
(and the Limeliters) left it out of the American
version.

m

Re: Looking for the Tek 465 of Logic Analysers

[Ian S. King]

One thing on which I must disagree: you don't need 'an external HPIB
controller' to use the HP 1630.  It's nice to be able to save configs and
traces to floppy, but I don't know if the PC software to actually move it
to a host for analysis has survived.  I've never controlled my 1630G with
anything but its front panel.

On Wed, Jun 10, 2015 at 9:01 PM, Ken Seefried  wrote:

> Thanks for the input everyone.  In summary, I got recommendations for:
>
> - HP 16500C (lesser a 16500B, but not a 16500A) (mainframe)
> - HP 16700/16900/17500 (mainframe, bigger-faster-stronger, still pretty
> expensive, can use 16500 cards)
> - HP 166x or 167x (portable, modern, look for hard drive)
> - HP 165x (portable, older, only buy cheap, look for hard drive)
> - HP 1630D, 1630G or 1631 (old, HPIB and HPIL interfaces, no special
> software needed, but you apparently need be able to control it with an
> external HPIB controller to get the most out of it)
> - Tek 1240
> - Gould Biomation K100D (software in rom, HPIB interface, assuming you need
> HPIB literacy to use effectively)
> - Tek DAS9200 (be careful to get the right pods (several variations), etc)
> - Tek TLA710/TLA720 (PC attached, Linux capable)
>
> General advice offered:
>
> - Look for hard drives or no special software required for longest life.
> Floppies required == bad.
> - Make really sure you get probes, and the right probes, for your kit.
> They're often not available separately for non-st00pid money.
> - There's a crazy array of ancillary features to consider: o-scope
> functions, processor assemblers/disassemblers, pattern generators,
> specialized inputs/outputs, timebases, embedded Unix machines, etc.  Know
> what you might need.
>
> So I've got a lot of manuals to read, but the 16500C sure looks like a ton
> of bang per US$.  You can even get an expansion chassis (10 additional
> slots) if you need to go to ludicrous speed on the number of
> probes/features.
>
> KJ
>



-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: Need DZQ11 (M3106) Print Set

[Paul Anderson]

I might have a set and will try to check tomorrow.


On Wed, Jun 10, 2015 at 12:08 PM, Noel Chiappa 
wrote:

> So I'm working with a group of 'busted' DZQ11's (the symptom is that Master
> Clear - 020 - bit in the CSR stays set, even if I write a 0 to the CSR),
> and
> so I need access to a set of prints for this card; they are MP-01795. They
> don't seem to be online anywhere, though.
>
> (They may not be fixable, because a lot of the circuitry is in a large
> custom
> chip, which is of course now unobtainium, but I'm hoping it's something
> simple.)
>
> This is a relatively recent card, so I'm hoping someone out there has a
> set.
> If not, I can probably dope out how it works from the Maintainence Manual
> (which _is_ available), but it would be _much_ easier if I have some
> prints to
> look at too...
>
> I would gladly scan them in for general distribution/use, if someone has a
> set
> they can loan me. I do have an A3 professional level scanner on a SCSI, so
> it's a snap for me to scan prints. (Or if someone wants to scan them
> themselves, that's of course fine too!)
>
> Thanks in advance, and I'm crossing my fingers! :-)
>
>  Noel
>

Re: Madeirs (was 80 column (un)punched cards)

[Dennis Boone]

 > The 'All unperforated...' line (my favourite) was in the English
 > versions but for some reason they (and the Limeliters) left it out of
 > the American version.

For the Limeliters, I don't believe I've ever heard it without.  I'm
hardly an encyclopaedic reference to all their performances and
recordings, though.

For those who haven't seen this silliness, here's Lou Gottlieb
performing it.  I didn't get a good enough look at the other musicians
to identify them.

https://www.youtube.com/watch?v=vrbAyHVVYgI

De

Re: Madeirs (was 80 column (un)punched cards)

[Mike Stein]

- Original Message - 
From: "Dennis Boone" 
To: "General Discussion: On-Topic and Off-Topic 
Posts" 

Sent: Wednesday, June 10, 2015 10:31 PM
Subject: Re: Madeirs (was 80 column (un)punched 
cards)



> The 'All unperforated...' line (my favourite) 
> was in the English
> versions but for some reason they (and the 
> Limeliters) left it out of

> the American version.

For the Limeliters, I don't believe I've ever 
heard it without.  I'm
hardly an encyclopaedic reference to all their 
performances and

recordings, though.

For those who haven't seen this silliness, 
here's Lou Gottlieb
performing it.  I didn't get a good enough look 
at the other musicians

to identify them.

https://www.youtube.com/watch?v=vrbAyHVVYgI

De


You're absolutely right; thanks for that link (and 
making me spend an hour wallowing through the 
sixties folk scene... ;-)


m 

Looking for docs / schematics for MITS 88-HDSK and its associated Pertec drive

[Josh Dersch]

Hey all --

I'm assisting in the restoration of an Altair 8800 system which includes 
the MITS 88-HDSK ("Altair Hard Drive Controller") and Pertec D-3422 
removable pack/fixed platter drive  and after cleaning everything up, 
rebuilding supplies, etc, the drive spins up and goes Ready but all 
attempts to boot end in "LOAD ERROR: 1" which I have been told indicates 
that the Altair doesn't think the drive is ready.


I can't find any substantial documentation on the controller (the D-3400 
series is covered on bitsavers); I've checked with the Altair Computer 
Club and they don't have any docs posted (and the one guy who might have 
a copy of the docs is on vacation until the 12th, which wouldn't 
normally be a big deal but we're trying (perhaps in vain) to get this 
thing ready for an event on Saturday...).


Anyone have any docs or any other information for the 88-HDISK controller?

Thanks!
Josh

Re: Need DZQ11 (M3106) Print Set

[Paul Anderson]

Bingo!

DZV11  FIELD MAINT PRINT SET MP00462
 USERS GUIDE DZV11-UG-002
 TECH MANUAL DZV11-TM-001

  CVDZCB0 ECHO TEST DIAG
  DVDZD-A-0 INTERPROCESSOR TEST DIAG
  CVDZAD0 DIAG PART 1

   might be more in there- too much fine print to read.

On Wed, Jun 10, 2015 at 9:24 PM, Paul Anderson  wrote:

> I might have a set and will try to check tomorrow.
>
>
> On Wed, Jun 10, 2015 at 12:08 PM, Noel Chiappa 
> wrote:
>
>> So I'm working with a group of 'busted' DZQ11's (the symptom is that
>> Master
>> Clear - 020 - bit in the CSR stays set, even if I write a 0 to the CSR),
>> and
>> so I need access to a set of prints for this card; they are MP-01795. They
>> don't seem to be online anywhere, though.
>>
>> (They may not be fixable, because a lot of the circuitry is in a large
>> custom
>> chip, which is of course now unobtainium, but I'm hoping it's something
>> simple.)
>>
>> This is a relatively recent card, so I'm hoping someone out there has a
>> set.
>> If not, I can probably dope out how it works from the Maintainence Manual
>> (which _is_ available), but it would be _much_ easier if I have some
>> prints to
>> look at too...
>>
>> I would gladly scan them in for general distribution/use, if someone has
>> a set
>> they can loan me. I do have an A3 professional level scanner on a SCSI, so
>> it's a snap for me to scan prints. (Or if someone wants to scan them
>> themselves, that's of course fine too!)
>>
>> Thanks in advance, and I'm crossing my fingers! :-)
>>
>>  Noel
>>
>
>

Front Panel Tech Note 2

[Rod Smallwood]

Asof now I know of two variations

1,Selector switch positions 1 and 6  lines can be vertical or 
at an angle to the vertical


2,Vertical divider between groups of three lamps

Anybody seen an 8/e panel with anything else?

Rod