Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 5 Jan 91 17:12:47 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Sat, 5 Jan 91 17:10:22 EST
Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05059; Sat, 5 Jan 91 17:00:02 EST
Received: from sask.usask.ca by mc.lcs.mit.edu id aa29476; 5 Jan 91 16:59 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Sat, 5 Jan
 1991 15:59 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Sat, 5 Jan 91
 15:59:04 CST id AA13358 for pdp8-lovers@mc.lcs.mit.edu
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA04215; Sat, 5 Jan 91
 15:12:30 -0600
Date: Sat, 5 Jan 91 15:12:30 -0600
From: Shawn Switenky <874226@watt.usask.ca>
Subject: Hello?
To: pdp8-lovers@mc.lcs.mit.edu
Message-Id: <9101052112.AA04215@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@mc.lcs.mit.edu

Date: Sat, 5 Jan 91 15:12:30 -0600
From: Shawn Switenky <874226@watt.usask.ca>
Subject: Hello?
To: pdp8-lovers@mc.lcs.mit.edu
X-Envelope-To: pdp8-lovers@mc.lcs.mit.edu

Greetings all!
	How do I get on this list?
	I've got a basket case PDP8/e that I sure could use some help with.  I'm
also still looking for some kind of operating system to run on it, like OS/8
or TSS/8 but I have had no luck finding such things.
	I also have a PDP11/60 and a VAX11/750 that are working.


+---------------------------------+----------------------------------------+
| Shawn Switenky                  | "Real Computers use Kilowatts"         |
|                                 |                                        |
| Informatics Assistant           | Every thing I say is my opinion,       |
| RHQ Prairies                    |   and belongs to me.                   |
| Correctional Service of Canada  |                                        |
|                                 |                                        |
+---------------------------------+----------------------------------------+


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sun, 6 Jan 91 18:05:48 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Sun, 6 Jan 91 18:03:25 EST
Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA23783; Sun, 6 Jan 91 17:51:41 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Sun, 6 Jan
 1991 16:51 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Sun, 6 Jan 91
 16:51:19 CST id AA16429 for pdp8-lovers@ai.mit.edu
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA07035; Sun, 6 Jan 91
 16:51:12 -0600
Date: Sun, 6 Jan 91 16:51:12 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Hello!
To: pdp8-lovers@ai.mit.edu
Message-Id: <9101062251.AA07035@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@ai.mit.edu

Date: Sun, 6 Jan 91 16:51:12 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Hello!
To: pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu

Hello Everyone!
	I'm just new to this list so I thought I'd introduce myself.

	I'm a Electrical Engineering / Computer Science student who attends the
University of Saskatchewan in Saskatoon, Saskatchewan, Canada.
	I have been picking up old computers and playing with them for about
three years now, with my first aquisition being a PDP8/e with all the LAB8
equipment.  Shortly after I picked up a PDP11/60 and just recently I bought
a VAX11/750.  Both the 11 and the VAX work ( and nicely I might add ) but
I have never managed to get the PDP8/e working.  I have had the thing plugged
in long enough to determine that the machine is locked up.  Someday I'll have
to break out the PDP8/e Maintenance Manual and the schematics and trouble
shoot.
	I'm looking for an operating system for the PDP8 as well as a
DECTape Controller and some boards for my TU56.  Can anyone help me out with
this?
	I also noticed from the DECUS catalog that DEC put some PDP8 operating
systems ( ie WS/78.)  I was wondering if DEC had also put OS/8 or TSS/8
in the DECUS library as well?  
	How hard is it to find DECTapes?  I need a few since I do not have any.
While I'm on the subject of media, how hard is it to find RK05 platters for
use with the PDP8?  What is the difference between the ones uses on PDP11 and
the onces used on the 8's?

	I noticed from past messages that Chris Zach use to post the occasional
message here.  Are you still around, Chris?

	Thats about all I can think of right now.  Type at you all soon.


+---------------------------------+----------------------------------------+
| Shawn Switenky                  | "Real Computers use Kilowatts"         |
|                                 |                                        |
| Informatics Assistant           | Every thing I say is my opinion,       |
| RHQ Prairies                    |   and belongs to me.                   |
| Correctional Service of Canada  |                                        |
|                                 |                                        |
+---------------------------------+----------------------------------------+

Greetings All!
	How do I get on this list?  
	I've got a basket case PDP8/e that I really could use some help with,
and now that I have a stable email account, I hope I can ask alot of questions


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 06:44:07 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 06:41:39 EST
Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02024; Mon, 7 Jan 91 06:18:46 EST
Received: from SUNIC.SUNET.SE by mc.lcs.mit.edu id aa06096; 7 Jan 91 6:18 EST
Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177)
	id AAsunic21729; Mon, 7 Jan 91 12:18:13 +0100
Date: Mon 7 Jan 91 12:17:33
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: Hello?
To: 874226@watt.usask.ca
Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101052112.AA04215@watt.USask.Ca>
Message-Id: <910107121733.23.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>

Date: Mon 7 Jan 91 12:17:33
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: Hello?
To: 874226@watt.usask.ca
Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101052112.AA04215@watt.USask.Ca>

You send a request to pdp8-lovers-request@ai.mit.edu
saying that you want to join in.

Do you have WCS for your 11/60, by the way?

I'd sure like to help you get going with your eight,
as is probably a few other.

I live in Sweden, though, so most stuff will probably be
available from closer sources, but let me know how it goes.
I have pretty much software, and some hardware that I'm
willing to exchange for other stuff.

	Johnny


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 06:50:03 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 06:47:30 EST
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA02092; Mon, 7 Jan 91 06:27:08 EST
Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177)
	id AAsunic22019; Mon, 7 Jan 91 12:27:05 +0100
Date: Mon 7 Jan 91 12:26:34
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: Hello!
To: 874226@watt.usask.ca
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101062251.AA07035@watt.USask.Ca>
Message-Id: <910107122634.23.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>

Date: Mon 7 Jan 91 12:26:34
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: Hello!
To: 874226@watt.usask.ca
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101062251.AA07035@watt.USask.Ca>

Operating systems for the pdp8 is no problem.

A TD8E DECtape controller might be a little harder to come by.
I have only one, and appearantly more people are looking for them.
Presonally, though, I don't like the TD8E, since it isn't a DMA
device.

DEC has not released OS/8 nor the CUSPs for it, yet...
Some are still hoping... Charles Lasner is probably the one
who knows most about that thread.

Are you referring to empty DECtapes, or with software?
DEC stopped selling empty DECtapes about two years ago in
Sweden, but I suspect that they still can dig some up.
As for DECtapes with stuff on, I can fix that.

The difference between the RK05 for the PDP8 and the PDP11 is that
the PDP11 has 12 sectors/track and the PDP8 has 16 sectors/track.
The sectors are marked by a "hole" in the platters bottom.
My english isn't always the best, so let me know if you
need further explanation of this.

However, it is not possible to convert from one type to the other.

Last I checked, DEC still sold RK05 platters for the PDP8. Also,
some other company is still producing those platters, since I have
another source for them too...

	Johnny


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:17:25 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:14:46 EST
Received: from decpa.pa.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA08423; Mon, 7 Jan 91 12:49:45 EST
Received: by decpa.pa.dec.com; id AA11114; Mon, 7 Jan 91 08:33:19 -0800
Message-Id: <9101071633.AA11114@decpa.pa.dec.com>
Received: from narfvx.enet; by decwrl.enet; Mon, 7 Jan 91 08:33:27 PST
Date: Mon, 7 Jan 91 08:33:27 PST
From: "Illiterate? Write for free help.  07-Jan-1991 1128" <francini@narfvx.enet.dec.com>
To: pdp8-lovers@ai.mit.edu
Subject: RE: DECtapes and RK05 cartridges...

Date: Mon, 7 Jan 91 08:33:27 PST
From: "Illiterate? Write for free help.  07-Jan-1991 1128" <francini@narfvx.enet.dec.com>
To: pdp8-lovers@ai.mit.edu
Subject: RE: DECtapes and RK05 cartridges...

Digital no longer sells DECtapes.  We found this out when we (the DECsystem-10
group) had to put out a release and had no DECtapes for the front-end
software.  It turns out the 3M still makes them, but they dont come in the
neat plastic cases any more -- only simple cardboard boxes.  Also, they
aren't certified or formatted -- you'll have to 'roll your own', literally!

As far as RK05 disk cartridges go, there's no difference between the
ones used on 11s and 8s.  It's all in the formatting, which you have
to do.  You might contact any of several computer supply houses around the
US and Canada.  They're getting harder to find (as are packs for big
disks like RP06s and RM05s).  If you find a vendor that has the latter,
they more than likely will have the former.

Good luck!

John Francini
Former DECsystem-10 developer
Digital Equipment Corporation


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:45:11 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:42:40 EST
Received: from decpa.pa.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA08885; Mon, 7 Jan 91 13:10:26 EST
Received: by decpa.pa.dec.com; id AA21366; Mon, 7 Jan 91 10:09:13 -0800
Message-Id: <9101071809.AA21366@decpa.pa.dec.com>
Received: from narfvx.enet; by decwrl.enet; Mon, 7 Jan 91 10:09:32 PST
Date: Mon, 7 Jan 91 10:09:32 PST
From: "Illiterate? Write for free help.  07-Jan-1991 1307" <francini@narfvx.enet.dec.com>
To: 874226@watt.usask.ca
Subject: Oops!  I had it wrong about Rk05 cartridges...

Date: Mon, 7 Jan 91 10:09:32 PST
From: "Illiterate? Write for free help.  07-Jan-1991 1307" <francini@narfvx.enet.dec.com>
To: 874226@watt.usask.ca
Subject: Oops!  I had it wrong about Rk05 cartridges...

Hmmm.  Looks like I'm wrong about the RK05 cartridges.  I forgot about
the sector holes in the bottom of the platter.  The rest of my message
is still OK, though...


John Francini


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:48:02 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:45:32 EST
Received: from convex.convex.com ([130.168.1.1]) by life.ai.mit.edu (4.1/AI-4.10) id AA09006; Mon, 7 Jan 91 13:13:54 EST
Received: from concave.convex.com by convex.convex.com (5.61/1.35)
	id AA00106; Mon, 7 Jan 91 12:12:47 -0600
Received: from groucho.convex.com by concave.convex.com (5.61/1.28)
	id AA00212; Mon, 7 Jan 91 12:12:44 -0600
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.groucho.convex.com.sun3.4
          via MS.5.6.groucho.convex.com.sun3_4;
          Mon,  7 Jan 1991 12:12:42 -0600 (CST)
Message-Id: <sbW=cO_2e4NaM58OYw@concave>
Date: Mon,  7 Jan 1991 12:12:42 -0600 (CST)
From: "Anthony A. Datri" <datri@concave.convex.com>
To: pdp8-lovers@ai.mit.edu
Subject: Re: DECtapes and RK05 cartridges...
In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com>
References: <9101071633.AA11114@decpa.pa.dec.com>

Date: Mon,  7 Jan 1991 12:12:42 -0600 (CST)
From: "Anthony A. Datri" <datri@concave.convex.com>
To: pdp8-lovers@ai.mit.edu
Subject: Re: DECtapes and RK05 cartridges...
In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com>
References: <9101071633.AA11114@decpa.pa.dec.com>

>As far as RK05 disk cartridges go, there's no difference between the
>ones used on 11s and 8s.  It's all in the formatting, which you have
>to do. 

I'm pretty sure that the hub on the pack has slits to denote sectors --
16 sectors for 12 bit machines; 12 sectors for 16 bit machines.

>They're getting harder to find (as are packs for big
>disks like RP06s and RM05s

The latest DECdirect catalog still lists RK05's, RM05's, and RP06's.

--


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 16:28:31 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 16:26:06 EST
Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA13515; Mon, 7 Jan 91 15:55:59 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan
 1991 14:55 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91
 14:55:19 CST id AA20907 for francini@narfvx.enet.dec.com
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10358; Mon, 7 Jan 91
 14:55:11 -0600
Date: Mon, 7 Jan 91 14:55:11 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: RE: DECtapes and RK05 cartridges...
To: francini@narfvx.enet.dec.com, pdp8-lovers@ai.mit.edu
Message-Id: <9101072055.AA10358@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@ai.mit.edu

Date: Mon, 7 Jan 91 14:55:11 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: RE: DECtapes and RK05 cartridges...
To: francini@narfvx.enet.dec.com, pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu

Amen on the availibility of RM05 packs...
I've got a RM05 drive here for my vax, but I can't use it since I have no pack.  
Life is like that, I guess.

What is the part number for the 3M Dectapes?  I'd like to phone up 3M and say
that I want this instead of " It's about the size of a big hockey puck, and has
alot of mylar tape on it, and the design is older that you are."

Shawn


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 17:10:55 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 17:08:15 EST
Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA15008; Mon, 7 Jan 91 16:45:53 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan
 1991 14:57 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91
 14:57:21 CST id AA20922 for datri@concave.convex.com
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10363; Mon, 7 Jan 91
 14:57:16 -0600
Date: Mon, 7 Jan 91 14:57:16 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re: DECtapes and RK05 cartridges...
To: datri@concave.convex.com, pdp8-lovers@ai.mit.edu
Message-Id: <9101072057.AA10363@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@ai.mit.edu

Date: Mon, 7 Jan 91 14:57:16 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re: DECtapes and RK05 cartridges...
To: datri@concave.convex.com, pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu

I should read what I type.
What I meant to say about the RM05's is I would like to find some used
ones.  DEC's price on new ones is about twice what I paid for my
entire VAX system.

Shawn


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 18:28:55 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 18:26:23 EST
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA17099; Mon, 7 Jan 91 18:01:47 EST
Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177)
	id AAsunic26225; Tue, 8 Jan 91 00:01:42 +0100
Date: Mon 7 Jan 91 23:25:47
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: RE: DECtapes and RK05 cartridges...
To: francini@narfvx.enet.dec.com
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com>
Message-Id: <910107232547.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>

Date: Mon 7 Jan 91 23:25:47
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: RE: DECtapes and RK05 cartridges...
To: francini@narfvx.enet.dec.com
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com>

Wrong. There IS a difference between RK05 for pdp8 and pdp11.
It sure is the format, but you cannot format them yourself.
They are hard sectored, with different number of sectors for
pdp8 and pdp11. (Well, you CAN format them, but not change the
number of sectors/track)

	Johnny


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:08:03 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:05:22 EST
Received: from decwrl.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA16695; Mon, 7 Jan 91 17:43:32 EST
Received: by decwrl.dec.com; id AA11956; Mon, 7 Jan 91 14:43:18 -0800
From: llustig!david@decwrl.dec.com
Message-Id: <9101072243.AA11956@decwrl.dec.com>
To: decwrl!pdp8-lovers@ai.mit.edu
Subject: Re: Hello!
Date: Mon Jan  7 14:42:00 1991

From: llustig!david@decwrl.dec.com
To: decwrl!pdp8-lovers@ai.mit.edu
Subject: Re: Hello!
Date: Mon Jan  7 14:42:00 1991

(In a separate email to the originator, I offered to give him some spare DEC-
tapes and copies of some maintenance information.)

Mr. Billquist doesn't like the TD8E because it isn't a DMA (cycle-steal)
device.  Hah.  Needless complexity, those cycle-stealers.  Two whole additional
registers, one of which is an upcounter!  That's a lot of chips, you know.

Maybe if you are time-sharing your -8 or doing real-time (foreground/back-
ground) work, DMA is good.  But for a simple single-user system, I don't see
the need.  The TD8E has the advantage of simplicity, a Good Thing, now that we
have to maintain these things ourselves.

Now I just need a spare weekend and a borrowed oscilloscope so I can fix what-
ever is busted on my TD8E and TU56 DECtape system....

                                               David Schachter
voice phone: +1 415 328 7425
internet:    david@llustig.palo-alto.ca.us
uucp:        ...!{decwrl,mips,sgi}!llustig!david


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:10:19 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:07:42 EST
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA16685; Mon, 7 Jan 91 17:43:08 EST
Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177)
	id AAsunic25334; Mon, 7 Jan 91 23:42:58 +0100
Date: Mon 7 Jan 91 23:42:29
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Formatting RL02 packs...
To: pdp8-lovers@ai.mit.edu
Message-Id: <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>

Date: Mon 7 Jan 91 23:42:29
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Formatting RL02 packs...
To: pdp8-lovers@ai.mit.edu

Does anybody know how you format RL02 packs.
I have checked my docs for my RL8A, and it appears that the pdp8
controller cannot format the packs.

If not: Why did DEC limit the controller in that stupid way?

I don't need to format anything right now, but it seems to me that
the occation might arise sometime...

The same goes for the RX8 with the RX01. Why did DEC include the
possibility to format floppies, I certainly could have some use
of that.

	Johnny


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:25:47 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:23:25 EST
Received: from cs.umn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20357; Mon, 7 Jan 91 20:08:34 EST
Received: by cs.umn.edu (5.61/1.14)
	id AA21807; Mon, 7 Jan 91 19:08:24 -0600
Date: Mon, 7 Jan 91 19:08:24 -0600
From: "Lawrence T. LeMay" <lemay@cs.umn.edu>
Message-Id: <9101080108.AA21807@cs.umn.edu>
To: pdp8-lovers@ai.mit.edu
Subject: DECtape
Cc: lemay@cs.umn.edu

Date: Mon, 7 Jan 91 19:08:24 -0600
From: "Lawrence T. LeMay" <lemay@cs.umn.edu>
To: pdp8-lovers@ai.mit.edu
Subject: DECtape
Cc: lemay@cs.umn.edu

I called 3M this afternoon, and asked about DECtape. The person I talked with
didn't seem absolutely sure that she had the correct tape, but it was listed
as 3/4" wide, and length of 260 (feet? inches?)...

Anyways, they say that thsi tape was discontinued last September. They are
looking for any reels that may still be in stock, and will get back to me.
Does anyone else have any information on this?

If they find a 'large' quantity of these tapes, i'll post a follow-up message.

-Larry LeMay
 lemay@cs.umn.edu


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:47:04 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:44:42 EST
Received: from EDDIE.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA20659; Mon, 7 Jan 91 20:25:32 EST
Received:  by EDDIE.MIT.EDU (5.61/25-eef)
	id AA18646; Mon, 7 Jan 91 20:23:34 EST
Date: Mon, 7 Jan 91 20:23:34 EST
From: Robert E. Seastrom <rs@eddie.mit.edu>
Message-Id: <9101080123.AA18646@EDDIE.MIT.EDU>
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: Johnny Billquist's message of Mon 7 Jan 91 23:42:29 <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>
Subject: Formatting RL02 packs...

Date: Mon, 7 Jan 91 20:23:34 EST
From: Robert E. Seastrom <rs@eddie.mit.edu>
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: Johnny Billquist's message of Mon 7 Jan 91 23:42:29 <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>
Subject: Formatting RL02 packs...

   Date: Mon 7 Jan 91 23:42:29
   From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>

   Does anybody know how you format RL02 packs.
   I have checked my docs for my RL8A, and it appears that the pdp8
   controller cannot format the packs.

Yep; DEC is infamous for this sort of thing.  It is in fact true that
you can not format RL02s, regardless of the machine they are on.
Someone once tried to give me a whole bunch of degaussed RL packs; I
turned them down.

   If not: Why did DEC limit the controller in that stupid way?

Well, you can't format RL01s either; you can't format RX01s (but you
can format in RX01 format on an RX02), and I don't think you can
format an RD53 (maxtor 71 meg drive on a Microvax).  Probably if this
is true, the same goes for the RD52 and the RD54 as well.  Conspiracy?
I dunno.  You make the call...


                                        ---Rob


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 23:39:08 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 23:36:44 EST
Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA23653; Mon, 7 Jan 91 23:13:35 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan
 1991 22:13 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91
 22:13:16 CST id AA22914 for D89.JOHNNY-BILLQUIST@aida.csd.uu.se
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10848; Mon, 7 Jan 91
 22:13:13 -0600
Date: Mon, 7 Jan 91 22:13:13 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re:  Formatting RL02 packs...
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se,
        alberta!decwrl!ames!think!mit-eddie!rs@herald.usask.ca
Cc: pdp8-lovers@ai.mit.edu
Message-Id: <9101080413.AA10848@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@ai.mit.edu

Date: Mon, 7 Jan 91 22:13:13 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re:  Formatting RL02 packs...
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se,
        alberta!decwrl!ames!think!mit-eddie!rs@herald.usask.ca
Cc: pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu

TU58 Dectape II's are factory formatted as well, at least as far as I know.
If anyone can format them, let me know cause I have a whole pile that
have been degausses too.

The sad thing is that system managers, the people who should know this, did
the degaussing.  Sad but true.

Shawn


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 02:11:39 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 02:09:18 EST
Received: from uunet.UU.NET by life.ai.mit.edu (4.1/AI-4.10) id AA26094; Tue, 8 Jan 91 01:49:31 EST
Received: from apex.UUCP by uunet.UU.NET (5.61/1.14) with UUCP 
	id AA16394; Tue, 8 Jan 91 01:49:19 -0500
Message-Id: <9101080649.AA16394@uunet.UU.NET>
From: apex!chuckh@uunet.uu.net (Chuck Huffington)
Date: Mon, 7 Jan 1991 22:50:20 PST
In-Reply-To: uunet!watt.usask.ca!874226 (Shawn Switenky)
       "Re:  Formatting RL02 packs..." (Jan  7, 22:13)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: uunet!ai.mit.edu!pdp8-lovers@uunet.uu.net
Subject: Re:  Formatting RL02 packs...

From: apex!chuckh@uunet.uu.net (Chuck Huffington)
Date: Mon, 7 Jan 1991 22:50:20 PST
In-Reply-To: uunet!watt.usask.ca!874226 (Shawn Switenky)
       "Re:  Formatting RL02 packs..." (Jan  7, 22:13)
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: uunet!ai.mit.edu!pdp8-lovers@uunet.uu.net
Subject: Re:  Formatting RL02 packs...

Why can't RL02s be formatted?

Two reasons come to mind:

1) It's hard to format an embedded servo pack.

2) It really cuts down on the competition for pack sales.


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 06:08:35 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 06:06:11 EST
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28911; Tue, 8 Jan 91 05:46:00 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA20912; Tue, 8 Jan 91 05:46:55 EST
Date: Tue, 8 Jan 91 5:46:54 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Many Flames and Fortunes about Formatting (warning: *very* long)
Message-Id: <CMM.0.90.0.663331614.lasner@watsun.cc.columbia.edu>

Date: Tue, 8 Jan 91 5:46:54 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Many Flames and Fortunes about Formatting (warning: *very* long)

Flame warning: I don't design this stuff, I just use and program it.  I
have many "reliable" sources for the info which was obtained over many
years of -8 association.  Some of the ideas may be contrary to either
DEC official policy (past and/or present), or may contradict some
"official" documentation (which in actuality is *wrong* :-).  So, to
borrow from Elton John (from the album with Crocodile Rock on it),
don't shoot me, I'm only the programmer (piano player) (I remember when
rock (and the pdp-8!) was young; me and Susie had so much fun...)

From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
To:     PDP8-Lovers.ai.mit.edu
Subj:   Formatting various DEC media used on the PDP-8, etc.

            I have been following this thread for a few days, and
        wanted to wait for the "smoke to clear" before responding,
        since some "dumb stuff" has been "going down."  Here is some
        explanation to all would be formatter-type people:

        1)  DECtapes and LINCtapes are the same media, only wound in
        opposite directions on the same reels.  They come in 150 foot
        and 260 foot versions.  The LINCtapes are never "certified"
        or formatted in any way because there were too many
        incompatible formats in the LINCtape world to care about.  At
        last check there were:

        a)  1000 blocks of 400 words/block (the LINC standard).

        b)  2000 blocks of 400 words/block (using the longer tapes).

        c)  1000 blocks of 400 words/block followed by 1000 blocks of
            400 words/block (an inner additional "tape") on the
            longer tapes.  The difference here is that b) uses blocks
            0-1777 and c) uses 0-0777 followed by 0-0777 repeated as
            another whole "tape" image.

        d)  2000 or more blocks of 200 words/block (LINC-8 PDP-8 side
            standard).  Sometimes used with incompatible checksum
            convention in O/S's such as CPS-4k and the LINCtape LINC-8
            version of the DEC Library System.

        e)  2000 or more blocks of 201 words/block for the sake of
            pseudo-compatibility with PDP-8 DECtape software that
            needs the extra word such as PDP-12 DM System (Thank you,
            Mark Hyde!).  d) and e) are considered the standard on
            the PDP-8-type O/S's for the PDP-12 such as OS/12 and
            P?S/12.  Each system maintains the extra word as an
            optional "nuisance" that may have to be dealt with.

            The DECtapes come in only two formats which could be
        "certified" as a guaranteed tape ready to work out of the
        box.  These are either PDP-10, etc. tapes formatted to 1102
        blocks of 600 words/block which sport a purple certification
        label, or 2702 blocks of 201 words/block which sport an
        orange certification label.

            The label means that someone took the tapes out of new
        storage, and formatted them on a certain PDP-8 with a TC08
        and eight drives using the standard tape formatter which can
        do either format (located in the Maynard Mill).  The only
        advantage of doing eight at a time was that you could walk
        away from the operation sooner and for a longer break.  If
        the program indicated no errors, the operator's initials and
        the date were written on the label.  Occasionally mistakes
        were made, and a tape could be "certified" yet be the other
        standard length!  Or it could be defective all together in
        spite of the label.

            This service was never worth the extra cost, especially
        since the tapes should be copied and reformatted every six
        months of actual usage.  (Note, tapes just sitting around for
        20 years read just fine!)

            There is a peculiar side story to this certification
        machine.  The TC08 on this machine was actually BROKEN and is
        responsible for certain defective software in OS/8, etc.,
        since the software only runs on broken machines.  P?S/8 was
        "demoed" to DEC management on this system and it caused some
        embarassment when good code failed to perform!  Eventually,
        the problem was seen on other TC08s and TU56s.  The problem
        is an interaction between the buss driver and load resistor
        pullup card in the TC08 with a certain ECO of the receiver
        card in the TU56 when configured for negative tape busses.
        Curiously, it works fine with OLDER variations of the
        receiver card!

            Further, there was much "scuttle-butt" that "certified"
        tapes were "zero-skew" which was NEVER the case owing to the
        bad maintenance of this machine.  A "nearly zero-skew" tape
        is ALWAYS creatable on ANY TU56 and is the BEST judge of the
        alignment of the drive at any time, since the test
        exaggerates the misalignment by a factor of two.  More than
        adequate alignment is always possible in the field with
        nothing more than a skew test card or equivalent and a
        'scope.

            We constructed a skew tester BETTER than DEC's using two
        G888 cards and a black-block (Don't need green, only
        single-sided!) and a VECTOR card edge and socket.  Our tester
        brings the analog version of the signals out to the scope,
        whereas DEC's clips and only shows the zero crossings
        (optional with ours) which prevents judging the tape head
        amplitude, etc.  A test point is available on the G888
        apparently for this express purpose - after the pre-amp and
        before the waveshaping amp driven into saturation.

            To be fair, DEC's module is based on pieces of R-series
        cards and pieces of G882 modules from the negative TC01, etc.
        days, so there really isn't a good place to observe the
        equivalent waveforms.  Using our card, it is readily possible
        to align the drive to about 3/4 of a microsecond, where DEC
        often let out 3.0 microsecond skew drives.  We considered
        drives good if they were less than 2.0 microseconds since a
        DEC tech tip gave that number.  In any case, the smaller the
        value, the more interchangeable tapes formatted there become.

            Various extended length variations exist on all of the
        above formats which depend on the tape being a certain
        length.  Some (such as 4000 block 200 words/block LINCtapes
        or 3300 block 201 words/block DECtape) depend on the fact
        that the nominal 260 foot length was in fact *longer* in
        actual tapes (usually).  The only "valid" excuse for
        returning a 260 foot tape to DEC was that PDP-10-style format
        wasn't do-able on the medium.

            Generally LINCtape formats produce slightly more blocks
        than their DECtape counterparts because the inter-block zone
        "overhead" is less.  (LINCtapes, however cannot transfer
        bi-directionally, only search that way whereas DECtapes can
        also transfer backwards too.)  Late production tapes were
        shipped "skimpy" and some couldn't manage being formatted as
        PDP-10-type DECtapes.

            If your guides were in good shape, you could also "cheat"
        a little on the mark clock setting, so more tapes could be
        "extra long" in the batch, but the reliability goes down due
        to friction, etc.  The mark clock ratings documented in the
        various controllers were also sometimes mis-stated (the
        complement period instead of the actual one) or were just
        downright wrong, and various systems had ECOs to attempt to
        correct this, which were often overlooked.  The proper
        setting is whatever it takes to make each 12-bit word take
        133 microseconds to happen on a DECtape system or 160
        microseconds on the LINC-8 due to slower and gentler motors.

            Originally LINCtapes or MICROtapes (as the early DECtapes
        were called) were packaged in either plain white boxes from
        3M with blue liner and lettering or in various colored
        DEC-sold cardboard boxes of a two-part nature.  Either a
        sleeve style or a box and cover, whereas the 3M package is a
        simple box with ear tabs.  Eventually, 3M also poly-sealed
        the tapes in a bag in the box.  Most of DEC's early
        containers are dark blue and white sleeve types, with a
        styrofoam circle glued to the sleeve to secure the tape.
        Some are black-and-white boxes with an imprint/photo of a
        tape reel in the slick print.  Some covers are really
        attached clam-shell style and don't separate from the bottom.

            The earliest tapes which were 150 feet intended for the
        LINC (and eventually the LINC-8) came on bone-white reels
        which were slightly undersized compared to the later reels
        potentially holding the 260 foot (nominal) tape which were
        some form of creamy off-white (various shades of antique
        white).  This style of reel also has a 3M sticker in an arc
        shape glued onto the reel in no particular position, and
        occasionally on the rear face.  All DEC and later 3M reels
        have an inset area for the DEC standard reel label on the
        front.  Tapes purchased from 3M for immediate DECtape usage
        are marked on the box "DIGL WND" presumably meaning Digital
        Wound or somesuch.  All DEC reels also have the corporate
        name stamped into the mold.  The real "deep" stampings
        usually have a visible mold mark/defect on them in the shape
        of a semi-circle near the label inset area.  All DEC reels
        never have 3M labels on them, but the tape itself always
        starts with one.  You were always advised to remove them, but
        few people did, so heads got sticky and needed more frequent
        cleaning!  (They also let you cheat in mounting the tape on
        the takeup reel.)

            Eventually DEC sold tapes in plastic cannisters: Blue for
        DECtape and Green for LINCtape.  The cannisters also can be
        identified by their shade of color, and the exact nature of
        the designs on the cannister back face label and the inner
        circular center label.  There were at least five "vintages"
        by this method.  Apparently both colors exist in all
        versions.  Some cannisters cannot interchange covers, since
        this could yield either a sloppy fit or a too tight fit, etc.
        All plastic cannisters are fragile and many crack.  There
        were also an extremely small number of cannisters of other
        colors: part clear, and all dark blue which were glommed on
        to by various managers.  They claimed they were to be used
        for "official" releases to distribution of new software, but
        this apparently was never fully borne out.  DEC also
        distributed a 3M part which was a set of strips of blue
        colorforms to hold the end down when storing the reel.  Many
        people just lost them, and others tore them in half to
        increase their number to compensate for loss.  They sometimes
        hold amazingly well, and other times won't work for beans.
        Red/Orange and Green colorforms never came from DEC, but
        people took them from Magtapes to put on the DECtapes and
        LINCtapes just to be "different" and stand out.

            DEC sold peel-off labels for the reels in Red, Blue,
        Green, and Yellow.  One-color labels were never available to
        customers, but white with printed lettering was often used
        for release tapes.  The orange and purple "certification"
        labels have preprinted format info regions on them.
        Occasionally, the DEC PAPER-TAPE label was attached to the
        outside of the cannister in various vintages.

            I have over 3000 tapes at present, and can possibly be
        "arm-twisted" to give up some to the "needy" since I am
        storing files on "bigger" things these days, but none are as
        reliable as good ol' DECtape.

        2)  DECtape II can only be hooked up on an -8 to a KL-8/E
        because you have to do a "break" character.  The other -8
        interfaces can't do it.

            There exists a "clandestine" ROM for the TU58 serial
        version that makes it FORMAT!  I have one somewhere, and if I
        find it, I will send it here to PDP8-Lovers.  I believe it is
        a 2716, so I need access to a ROM blaster/reader to dump its
        contents out.  When you change the ROM, the TU58 talks to the
        host system with a MENU and various tape-tensioning and
        formatting/checking routines.  This ROM was distributed
        secretly at a DECUS symposium back when they weren't DEC
        sales' versions of charged-admission Tupperware parties.

            Others may have this gem, but I only got one, and it's
        somewhere in a box in my "dungeon." :-( (I think it also came
        with a hex dump of the code also on a heavily re-zeroxed
        sheet.)

        3)  RX01 and RX02 CANNOT FORMAT!  This is a myth generated by
        the uninformed!  The disk format consists of pre-formatted
        patterns that are described as FM or double-frequency which
        means that the clock pulse always occurs in between data that
        may not appear (and thus becomes a zero if so).  The entire
        RX01 format consists of this.  The special headers such as
        index mark, address mark, etc. are formed by EXCEPTIONS to
        the above known as "missing clocks."  As the name implies,
        you sync up on a clear pattern of clocks which are
        recognizable as such as soon as one absentee pulse confirms
        that is was a zero data bit, so its neighbors must be clocks.
        The circuit to do this is generally known as a data
        separator.  Suddenly, the rules change, and a buffer register
        which tracks these things can form a pattern of which clocks
        actually didn't occur.  The precise bit patterns of the
        missing clocks indicate exactly where you are.  Neither the
        RX01 or RX02 can change any of this!

            The rest of the headers are a short data record and CRC
        followed by a much longer, albeit similar record.  The first
        one is the address, which essentially means which track and
        sector this particular header is part of.  The larger portion
        is the actual data which has its own CRC at the end too.  In
        the RK8E, both of these are rewritten every time you write,
        and are indicated by exactly one data bit that is a one in
        the midst of otherwise zero bits.  There are no missing
        clocks, but the whole sector gets reformatted!  This is a
        little dangerous, especially on a floppy, so the RX01 will
        not rewrite the headers, rather only the data and CRC.  If
        you corrupt the missing clocks or headers, and you only have
        an RX01, throw away the media.

            The RX02 situation is a little less "bleak" but has some
        problems (more on this later).  The RX02 is totally
        compatible with the RX01 format *OR* it uses a variant:

            The missing clocks and their resultant patterns are
        maintained as in the RX01.  But now the data and CRC are
        written by totally different rules if the disk is
        double-density.  The basis of the method is called MFM
        (modified FM).  This method "cheats" and is the father of
        most current data recording methods in the industry.  The
        basic idea is that there is a mythical clock time (that *NEVER*
        happens!).  If the actual pulse occurs sooner than the
        expected midpoint of time of arrival for the mythical clock
        then the data is a one.  Should it arrive later, it is a
        zero.  (These might arbitrarily be reversed; it really
        doesn't matter as long as you are consistent!)  In any case,
        the arrival and determination of the latest bit's polarity
        calculates the next mid-point time for the next mythical
        clock.  The major flaw in this scheme is that it is
        impossible to tell the difference between long strings of
        ones or longs strings of zeroes.  The format must include
        some "guess-work time" to arbitrate the data as all zeroes
        when starting up.  Clearly jitter is the real villain here.
        MFM drives have to be carefully "certified" in order to work
        reliably.

            So the RX02 includes an operation called SET MEDIA
        DENSITY which rewrites the header type and data areas with
        the requested type RX01 or double-density as needed.  This
        can clean up a slightly dinged RX01 disk, BUT cannot rewrite
        the missing clocks inserted externally by an IBM 3740 or
        equivalent.

            There is yet another way to regain the disk format: use
        the DSD-210 drives from DSD or some other models which were
        -11 only.  These non-DEC drives include extra operations to
        actually write the missing clock patterns and redeem ANY
        magnetically dinged media.  (And I have one on my 8/e! :-)
        There are also some SCSI controllers that can format RX01
        media if suitable 8" drives are attached to them.  Then the
        RX02 can change the media density if required.

            There is another problem with the RX02 that only DSD
        fixed on the -11:

            When you write pulse transitions on any magnetic media,
        there is a "crowding" effect on the inner tracks.  All 8"
        drives include a feature to lower the write current on inner
        tracks (above track 43) to partially offset this.  The
        problem is that the actual timing of when the data separator
        "sees" the pulse happening shifts forward in time on these
        more "delicate" tracks so the inter-pulse timing will "drift"
        and screw up the MFM method (much less important on RX01
        single-density).

            DEC forgot to do their "homework" on this one, and just
        left out any consideration while everyone else fixed it:

            You keep a running history of the last few bits you
        wrote.  Depending on the actual data pattern, you
        pre-compensate some of the pulses and write them earlier
        (just a predictable "hair" of time earlier) then otherwise
        intended.  The value is data dependent and could range over
        several values (including zero change which DEC's RX02 ALWAYS
        uses!)  This compensates for the predictable crowding when
        read back and makes the drive MUCH more reliable.

            Notice that the write-compensation even helps the RX02 to
        read the data back so the best protection for your RX02 data
        is to do a blind diskcopy of your RX02 media on a DSD
        RX02-superset drive.

        4)  Embedded servo disks such as the RL01, RL02, and any RD3x
        or RD5x disk cannot be formatted in the usual sense.  There
        is no caliper of position in these drives, rather the media
        has been subjected to an analog pattern "wave" across the
        entire media (between the tracks too!).  The idea is that not
        every bit of a track is written on since there are designated
        guard areas as part of every sector.  Within this area the
        media is "virgin" or at least what it was when it was
        installed in the drive.  When you are over the exact valley
        of the "wave" the low-frequency energy is at a minimum.  The
        data bits are a high-frequency phenomena and are filtered out
        here.  Should the head deviate either way, the amplitude will
        shift in a way to oppose to deviation, thus the head follows
        (is a servo :-) the imbedded low-frequency info.

            Even if the whole track should get blown, the deviation
        either way still pushes the head back to the middle, as long
        as it is blown in the correct place! (But not as
        "sure-footedly" as when it isn't blown; generally good enough
        to still use though.  Some drives can be heard as blown
        because when they are recalibrated, the "buzzing pattern" is
        disrupted over the corrupted region.  This means that the
        drive may not survive being blown again over the same nominal
        track, since it might saturate an alternate area not suitable
        for use as that affected track, or you may flip-flop between
        two "copies" of the same track depending on where you last
        seeked from!  The only fix is to get the media rebuilt with a
        servowriter which puts the patterns back down.  This is only
        available in "clean-room" repair companies generally.  (Yeah,
        it costs money!) :-(

            All of the mentioned media et. al. can be "formatted" in
        the sense that the data patterns and generally the address
        patterns can be rewritten.  This presupposes a working servo
        pattern.  Most DEC systems can do this lessor form of
        reformat but I won't vouch for all systems.  Some systems
        allow changing the sector size, etc. while you are at it.
        Remember, this is a format in the same sense as an RK05, BUT
        the RK05 has a position caliper in each drive that must be
        adjusted to an external standard.  No positioning info comes
        from the pack so a degaussed media is fine there.  But that
        would destroy the imbedded servo analog wave pattern on these
        drives.

            Note also that it is cheaper to make a servo drive than a
        calipered drive for the same TPI, or alternatively you can
        crowd the tracks in real close only with imbedded servo.  The
        strange part about the RL01 is that it has all the grief, yet
        only gives you 5 whole Megs for your trouble!

            DEC also paid less attention to the interface of the RLs,
        so the programming is a major step backwards compared to the
        RK05, etc. which is also 5.0 Megs error-free and totally
        reformatable (I am referring to the RK05F which can be
        slightly modified to take removable packs which can't
        interchange with the regular RK05 but none-the-less can
        interchange between RK05F's!)

            There is a major software price to be paid on the RLs on
        both the -8 and the -11.  The -11 required major overhaul of
        RT-11, etc. just to support the RLs (to monitor the status of
        heads in motion of the non-automatic seeked drive!).  The -8
        problems are a little more insidious:

            The primary requirement for the RL on the -8 is to make
        OS/8 "like" the beast.  All else doesn't matter because the
        other DEC systems are really glorified applications and don't
        have the "handler" problem.  So DEC devised a scheme to use
        the RLs under OS/8.  Each section of the 40-sector track is
        cut up into two 16-sector wedge-shaped regions and an
        8-sector "extra" region.  This allows each region to match
        OS/8's maximum size (or less) and is theoretically fine.

            But there is a performance price to be paid:  each track
        always wastes the other 24 sectors not belonging to the
        current region, so the drive spends a lot of time spinning
        unproductively.  There is even a "formatting" program that
        writes out mini-tables of bad spots so each area fends for
        itself by loading the handler with the local bad spots to
        "straddle" over.  This would be the end of it, BUT not quite:

            When you design hardware without feedback, you get
        problems!  DEC has been there may times, and then the
        software people have to figure out some "kludge" to get
        around the problem.  (A hardware "nerd" once asked me why the
        position in a register of three bits mattered; I couldn't
        succeed in explaining to him why it "pessimized" the code and
        his arbitrary choice should have been moved before they
        committed it to a PC board.)

            Some DEC designer attempted to overcome an inherent
        defect in the transfer design of the RL8A: the inherent loss
        of bits when using 12-bit mode instead of 8-bit mode.  I
        profoundly wish he hadn't tried!  There is a word count
        register in the RL8A which is real great for 8-bit mode
        transfers: you get your chosen number of 8-bit bytes
        right-justified in every 12-bit word just fine, and you can
        even read in up to 4096 adjacent bytes.

            BUT, in 12-bit mode, there are 170 2/3 words in every
        sector, and if you set the word count to more than 128, you
        will get some of those useless words in his futile attempt to
        recover all the data in 12-bit mode.  By the way, the 256th
        byte doesn't even get transferred, so this method is
        worthless even for cramming more data into the buffer for
        some mythical block-for-block copy utility.  Of course, we
        want the first 128 12-bit words, and skip the rest.  So, the
        handler has to do individual transfers of 128 12-bit words.
        The overhead of the single page transfers causes you to miss
        the next sector every time!  So, the OS/8 handler uses a
        TWO-WAY INTERLEAVE to access the sectors!  Yes, it takes two
        passes to read in 16 sectors per track which means that 64
        sectors are ignored every two revolutions assuming no seeking
        and you just got to the beginning of the track at the right
        time; more realistically you have to add another 1/2
        revolution on average, so each 1 field transfer takes 2.5
        revolutions.  Remember, the RK8E does a field in 1 pass with
        an average of 1.5 revolutions to do it in!

            The RL02 is the same as the RL01 but is twice as big thus
        there are 5 wedges instead of 2.5.  All else applies.

            By the way, the -8's don't intermix drives like the -11.
        The problem is apparently that the "extra" bit of track
        addressing must be set somehow when talking to the RL01.  I
        don't really know to what value, but apparently the RL01
        jumper on the RL8A makes the corresponding AC bit be ignored
        and is substituted for in the hardware.  (Guesses for this
        value include 0, 1, a parity bit, or perhaps a sign extension
        bit.  In any case, they don't trust RL01 software to generate
        the correct value when the jumper is thrown to also allow
        RL02s.)  Of course the bit takes on true meaning as an
        extension track bit when talking to actual RL02s properly.
        Perhaps all of the relevant software could be carefully
        rewritten to ensure the requirement of the RL01 and thus
        allow mixed drives systems.  The RL78 option of the DECmate I
        apparently has no such bit and thus only officially supports
        RL02s.

            Today, I have PDP-8 SCSI devices, so my controllers are
        designed by controller companies, not DEC.  But I still have
        RK05s and DECtapes and LINCtapes too. :-)

cjl (lasner@watsun.cc.columbia.edu)


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 06:17:13 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 06:14:54 EST
Received: from cc.usu.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29037; Tue, 8 Jan 91 05:59:57 EST
Date: Mon, 7 Jan 91 22:25 MDT
From: Roger Ivie <SLSW2@cc.usu.edu>
Subject: Formatting on DEC machines and DECtape
To: pdp8-lovers@ai.mit.edu
Message-Id: <DA08FEE119B700B44E@cc.usu.edu>
X-Envelope-To: pdp8-lovers@ai.mit.edu
X-Vms-To: IN%"pdp8-lovers@ai.mit.edu"

Date: Mon, 7 Jan 91 22:25 MDT
From: Roger Ivie <SLSW2@cc.usu.edu>
Subject: Formatting on DEC machines and DECtape
To: pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu
X-Vms-To: IN%"pdp8-lovers@ai.mit.edu"

>    If not: Why did DEC limit the controller in that stupid way?
> 
> Well, you can't format RL01s either; you can't format RX01s (but you
> can format in RX01 format on an RX02), and I don't think you can
> format an RD53 (maxtor 71 meg drive on a Microvax).  Probably if this
> is true, the same goes for the RD52 and the RD54 as well.  Conspiracy?
> I dunno.  You make the call...

You can format RDxx's on MicroVAXes, but I think you have to buy the
diagnostic programs; this is certainly true of the MicroPDP-11s.

However, you cannot format RX50 floppies on any DEC machine but the 
Rainbow, and that only because enough Rainbow customers complained to
force DEC to include a formatter.

I'm also looking for a TD8E, but for a slightly different reason. You
see, I've got an original distribution kit for OS/8 V3C on DECtape and
it would be kind of nice if I could read the thing. I can get my hands
on drives but not the controller.

Roger Ivie
slsw2@cc.usu.edu


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 9 Jan 91 00:32:39 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 9 Jan 91 00:30:19 EST
Received: from akbar.cac.washington.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08856; Tue, 8 Jan 91 14:23:26 EST
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu
	(5.65/UW-NDC Revision: 2.21 ) id AA29307; Tue, 8 Jan 91 11:23:23 -0800
Date: Tue, 8 Jan 1991 11:18:27 -0800 (PST)
From: Mark Crispin <MRC@cac.washington.edu>
Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
Subject: TD8/E
To: PDP-8-LOVERS@ai.mit.edu
Message-Id: <MailManager.663362307.9952.mrc@Tomobiki-Cho.CAC.Washington.EDU>

Date: Tue, 8 Jan 1991 11:18:27 -0800 (PST)
From: Mark Crispin <MRC@cac.washington.edu>
Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
Subject: TD8/E
To: PDP-8-LOVERS@ai.mit.edu

I have an extra TD8/E that I'd be willing to let go, but only if I got for it
what I paid for it a few years ago ($300) from the used computer sharks.  I
don't know if it works, I abandoned the project I got it for.  Let me know if
you're interested.

-- Mark --


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 10 Jan 91 16:58:46 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 10 Jan 91 16:56:24 EST
Received: from EDDIE.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA25334; Thu, 10 Jan 91 16:38:01 EST
Received:  by EDDIE.MIT.EDU (5.61/25-eef)
	id AA00745; Thu, 10 Jan 91 16:36:28 EST
Date: Thu, 10 Jan 91 16:36:28 EST
From: Robert E. Seastrom <rs@eddie.mit.edu>
Message-Id: <9101102136.AA00745@EDDIE.MIT.EDU>
To: pdp8-lovers@ai.mit.edu
Subject: can anyone help this fellow?

Date: Thu, 10 Jan 91 16:36:28 EST
From: Robert E. Seastrom <rs@eddie.mit.edu>
To: pdp8-lovers@ai.mit.edu
Subject: can anyone help this fellow?


   From: pbm@cybvax0.uucp (Paul B. McBride)
   Newsgroups: comp.sys.dec
   Date: 10 Jan 91 19:00:29 GMT
   Distribution: usa
   Organization: Cybermation, Inc.

   I have been contacted by someone who has some TU60 cassette tapes
   which they would like to read. The tapes were created on a PDP/8 using
   OS/8. They have an OS/8 system running on an RL02 disk, with the TU60
   drive, and paper tape reader. They are unable to access the TU60 drive.
   The system seems to be working properly, but they do not have any manuals.

   Does anyone know how to access the TU60 drive from OS/8, or how to
   configure OS/8 so that it can access the TU60, or what additional
   driver is required?

   Does anyone know of someone who would be able to read and convert these
   tapes to a less ancient media?

   All comments and suggestions are welcome. Please mail responses to
   uunet!cybvax0!pbm. Thanks.
   -- 

   -- 
					   Paul B. McBride (cybvax0!pbm)
					   Cybermation, Inc. (617) 396-6500


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 14 Jan 91 13:31:16 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 14 Jan 91 13:28:49 EST
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA16224; Mon, 14 Jan 91 13:10:39 EST
From: rs@ai.mit.edu (Robert E. Seastrom)
Received: by rice-chex (4.1/AI-4.10) id AA22705; Mon, 14 Jan 91 13:10:24 EST
Date: Mon, 14 Jan 91 13:10:24 EST
Message-Id: <9101141810.AA22705@rice-chex>
To: pdp8-lovers@ai.mit.edu
Subject: In case you don't read alt.folklore.computers...

From: rs@ai.mit.edu (Robert E. Seastrom)
Date: Mon, 14 Jan 91 13:10:24 EST
To: pdp8-lovers@ai.mit.edu
Subject: In case you don't read alt.folklore.computers...


   From: meissner@osf.org (Michael Meissner)
   Newsgroups: alt.folklore.computers
   Date: 14 Jan 91 12:37:48 GMT
   Organization: Open Software Foundation

   In article <U502SOU.91Jan14050731@mpirbn.mpifr-bonn.mpg.de>
   u502sou@mpirbn.mpifr-bonn.mpg.de (Ignatios Souvatzis) writes:

   |    ... I've got a couple of working PDP 11/34s (w 128K RAM) and a
   |    working PDP 11/20 (w 16K CORE) sitting next to me heating the house
   |    up ... they are built like tanks ...
   |                               ^^^^^
   | 
   | Well said. On page n of one of those PDP-8 paperbacks I saved from the
   | trashcan, DEC tells us that they used to drop the PDP-8's from a
   | height of about one foot to test them. 

   It reminds me how somebody 'proved' that a PDP-8 is a REAL computer,
   and the IBM PC is just a toy....  The first step is that you put the
   IBM PC on top of the PDP-8 and both run fine.  The second step is you
   put the PDP-8 on top of the IBM PC, and only the PDP-8 runs... :-)
   --
   Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
   Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

   Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 14 Jan 91 19:28:29 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 14 Jan 91 19:25:50 EST
Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA26085; Mon, 14 Jan 91 18:53:46 EST
Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.179)
	id AAsunic24162; Tue, 15 Jan 91 00:53:27 +0100
Date: Tue 15 Jan 91 00:52:25
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: can anyone help this fellow?
To: rs@eddie.mit.edu
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101102136.AA00745@EDDIE.MIT.EDU>
Message-Id: <910115005225.21.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE>

Date: Tue 15 Jan 91 00:52:25
From: Johnny Billquist <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
Subject: Re: can anyone help this fellow?
To: rs@eddie.mit.edu
Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se
In-Reply-To: <9101102136.AA00745@EDDIE.MIT.EDU>

What is a TU60???

	Johnny


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 15 Jan 91 22:46:12 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 15 Jan 91 22:43:12 EST
Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA27107; Tue, 15 Jan 91 22:10:54 EST
Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Tue, 15 Jan
 1991 21:10 CST
Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Tue, 15 Jan 91
 21:10:28 CST id AA02853 for D89.JOHNNY-BILLQUIST@aida.csd.uu.se
Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA01912; Tue, 15 Jan 91
 21:10:18 -0600
Date: Tue, 15 Jan 91 21:10:18 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re: can anyone help this fellow?
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu
Cc: pdp8-lovers@ai.mit.edu
Message-Id: <9101160310.AA01912@watt.USask.Ca>
X-Envelope-To: pdp8-lovers@ai.mit.edu

Date: Tue, 15 Jan 91 21:10:18 -0600
From: 874226@watt.usask.ca (Shawn Switenky)
Subject: Re: can anyone help this fellow?
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu
Cc: pdp8-lovers@ai.mit.edu
X-Envelope-To: pdp8-lovers@ai.mit.edu

I believe a TU60 is a DEC storage device that used standard type audio
cassettes.  This was available for the PDP8, as well as perhaps some 
other machines.  The machine dates back to the early to mid 70's

Shawn Switenky
874226@watt.usask.ca


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 17 Jan 91 15:29:10 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 17 Jan 91 15:24:29 EST
Received: from convex.convex.com by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Thu, 17 Jan 91 14:26:01 EST
Received: from hydra-demo.convex.com by convex.convex.com (5.61/1.35)
	id AA01622; Thu, 17 Jan 91 13:27:21 -0600
Received: from concave.convex.com by hydra.convex.com (5.61/1.28)
	id AA18885; Thu, 17 Jan 91 10:30:35 -0600
Received: from lovecraft.convex.com by concave.convex.com (5.61/1.28)
	id AA26032; Thu, 17 Jan 91 10:29:35 -0600
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.convex.com.sun4.40
          via MS.5.6.lovecraft.convex.com.sun4_40;
          Thu, 17 Jan 1991 10:34:48 -0600 (CST)
Message-Id: <4bZR8cm2e4Nh1oAptf@concave>
Date: Thu, 17 Jan 1991 10:34:48 -0600 (CST)
From: "Anthony A. Datri" <datri@concave.convex.com>
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu,
        874226@watt.usask.ca (Shawn Switenky)
Subject: Re: can anyone help this fellow?
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9101160310.AA01912@watt.USask.Ca>
References: <9101160310.AA01912@watt.USask.Ca>

Date: Thu, 17 Jan 1991 10:34:48 -0600 (CST)
From: "Anthony A. Datri" <datri@concave.convex.com>
To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu,
        874226@watt.usask.ca (Shawn Switenky)
Subject: Re: can anyone help this fellow?
Cc: pdp8-lovers@ai.mit.edu
In-Reply-To: <9101160310.AA01912@watt.USask.Ca>
References: <9101160310.AA01912@watt.USask.Ca>

>I believe a TU60 is a DEC storage device that used standard type audio
>cassettes.

True enough.  Fit a whopping 96kb onto one.

> This was available for the PDP8, as well as perhaps some 
>other machines

Actually, I've never seen evidence of it being on 8's, although I've
seen that low-end 11/10's for lab work were sometimes equipped with
them, with the TA11 controller.  True to DECform, you could run RT11
with these as you system device.  I actually once saw an RT11 V1
distribution on cassettes.

--
336996351123355369963511235117*47*8*47*8*7471


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 18 Jan 91 03:28:19 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 18 Jan 91 03:25:54 EST
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01713; Fri, 18 Jan 91 03:08:18 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA10855; Fri, 18 Jan 91 03:09:37 EST
Date: Fri, 18 Jan 91 3:09:37 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Message-Id: <CMM.0.90.0.664186177.lasner@watsun.cc.columbia.edu>

Date: Fri, 18 Jan 91 3:09:37 EST
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu

From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: TU60

Re: TU60's and PDP-8's

    It would be helpful if people would make reasonable assumptions
about what DEC did prior to 1980 or so regarding peripherals.

    In essence, virtually every peripheral that was considered
"important" (by marketing at least :-)) was "grafted" onto every DEC
system including the PDP-8.  This principle should over-rule people's
assumptions when they lack specific information.

    Now onto the specifics.

    The TU60 is hooked to the TA8E controller card for one pair of
drives usually known as CSA0: and CSA1:.  There was limited support
for more hardware to up this to CSA2: through as much as CSA7:, but
few machines ever had that many.  (The hardware was repeated bodily,
using a different device code just like the RX's.)

    The TU60 is NOT block-replacable, and thus cannot really run any
traditional operating system, but, like various magtape versions, the
-11 world did allow for read-only release tape images such as RT and
RSX, but these were hardly usable in the ordinary sense of the word.

    The -8 world of OS/8, etc. has no special distinction for
read-only devices, and thus can't even be created for such a device
as a bootable system media.  The basics of OS/8 operation require
that a "sacred" portion of the system be available for swapping at
all times, so a read-only device could merely produce a prompt and
then be incapable of doing anything.  Purists may note that it is
possible to use the "R" command under contrived circumstances as long
as the executed program doesn't reference *ANY* OS/8 services.

    I myself wrote read-only tape-bound systems on magtape used to
serially load in applications programs without OS/8 because of this
kind of restriction.  Several people even wrote block-replaceable
magtape systems by creating blocks isolated by wide gaps that could
be more or less guaranteed to not encroach on neighboring blocks as
long as nothing crashed.  Throughput was awful, but was theoretically
viable.  In any case, the TU60 is not capable of this kind of thing,
and only holds a pitiful amount of data in strictly sequential form
anyway.

    To help out here, DEC wrote two operating systems for the beast
called CAPS (CAssete Programming System) on both the -11 and the -8.
They were file compatible and strictly serial.  OS/8 has a support
program called MCPIP expressly designed to work with this stuff.

    I believe the directory is the last record before an end-of-tape
condition, so as the storage grows, the directory is pushed down
towards the physical end of medium.  Perhaps other schemes are used,
such as the directory is the first record and the entire device is
always re-written when updated.  This has the advantage of faster
directory listing.  In any case, deleting a file is a major chore.  I
believe that any editing or updating of the contents is accomplished
by creating an appropriately modified descendent of the tape on the
other drive and then discarding the original (the backup tape :-)

    A modified version of PAL8 and BASIC are the only two languages I
am aware of on CAPS-8; there could be a few others, but the more
"standard" OS/8 cusps were never "ported" to CAPS-8.  Standard
extensions include .PAL, .BIN and .BAS.

    For compatibility with CAPS-11, the files are in 6.3 notation
like RT-11, not 6.2 as in OS/8.  As a program restriction (read bad
kludge here) MCPIP cannot uniquely determine the extension's third
character, and can only write third character nulls in the extension;
woe unto those that write files anomolous this way!

    This TU60 discussion started because of a posting for assistance
by someone both on pdp8-lovers and on comp.sys.dec.micro.  The actual
user (off the net) contacted me by phone directly since my phone
number is well published due to KERMIT-12 and DECUS connections, so
we thank any and all persons attempting to hook us up, but it was
done "off-line" and is in progress.  I have already mailed out the
appropriate disks.

cjl (lasner@watsun.cc.columbia.edu)


Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 24 Jan 91 22:51:52 EST
Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 24 Jan 91 22:49:18 EST
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA17151; Thu, 24 Jan 91 22:34:54 EST
From: rs@ai.mit.edu (Robert E. Seastrom)
Received: by rice-chex (4.1/AI-4.10) id AA04598; Thu, 24 Jan 91 22:34:50 EST
Date: Thu, 24 Jan 91 22:34:50 EST
Message-Id: <9101250334.AA04598@rice-chex>
To: pdp8-lovers@ai.mit.edu
Subject: 12's on the left coast

From: rs@ai.mit.edu (Robert E. Seastrom)
Date: Thu, 24 Jan 91 22:34:50 EST
To: pdp8-lovers@ai.mit.edu
Subject: 12's on the left coast


Cribbed from comp.sys.dec on abUsenet:

   From: aek@Apple.COM (Al Kossow)
   Newsgroups: comp.sys.dec,misc.forsale.computers
   Date: 24 Jan 91 22:36:39 GMT
   Distribution: usa
   Organization: Advanced Technology Group, Apple Computer, Cupertino CA

   I was just over at one of the bigger surplus stores in the Bay
   Area, and spotted two PDP-12's. If anyone is interested, give
   Roger Warren a call at Surplus Solutions (408) 434-0168.

   I wouldn't normally bother with this, but I haven't seen a '12
   in a LONG time, and thought someone out there might want one..

   -- 

   Al Kossow @ Apple Computer, Inc., Cupertino, CA
   Internet: aek@apple.com
   Phone: (408) 974-5136


