From cjl@maestro.com Mon Dec 19 00:54:28 1994
Received: from relay1.UU.NET 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AB05390; Sun, 18 Dec 94 21:01:07 EST
Received: from SunSITE.Unc.EDU by relay1.UU.NET with SMTP 
	id QQxuwd13077; Sun, 18 Dec 1994 16:54:41 -0500
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA14826; Sun, 18 Dec 1994 16:53:25 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05253
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 18 Dec 1994 16:53:19 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA15044
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 18 Dec 1994 16:53:17 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15483; Sun, 18 Dec 94 16:41:04 EST
Received: from rose.eecs.nwu.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AB15475; Sun, 18 Dec 94 16:41:03 EST
Received: by rose.eecs.nwu.edu (4.1/SMI-4.0)
	id AA07859; Sun, 18 Dec 94 15:40:55 CST
Date: Sun, 18 Dec 94 15:40:55 CST
From: holmer@rose.eecs.nwu.edu (Bruce Holmer)
Message-Id: <9412182140.AA07859@rose.eecs.nwu.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Re: Court Ordered Liquidation - Computer Memory - CPU's & Hdsk Drives
Cc: holmer@ai.mit.edu


I just called up 213-555-1212.
No listing for "Choice Trading Company".
Is this sale for real?

--Bruce


From cjl@maestro.com Mon Dec 19 00:54:52 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA06769; Sun, 18 Dec 94 21:30:44 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA27451; Sun, 18 Dec 1994 21:32:13 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27403
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Sun, 18 Dec 1994 21:32:06 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA21786
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Sun, 18 Dec 1994 21:32:05 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AB26183; Sun, 18 Dec 94 21:22:31 EST
Return-Path: <zachary!jimc@riva.com>
Received: from deathstar.riva.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA26179; Sun, 18 Dec 94 21:22:28 EST
Received: from zachary by deathstar.riva.com  with uucp 
	(Linux Smail3.1.28.1 #17)  id m0rJXjx-0001aQC; Sun, 18 Dec 94 21:22 EST
Message-Id: <m0rJWOi-000EIoC@zachary>
From: jimc@zachary.riva.com (James E. Carpenter)
Subject: Re: Court Ordered Liquidation - Computer Memory - CPU's
To: pdp8-lovers@ai.mit.edu
Date: Sun, 18 Dec 1994 19:56:19 -0500 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 438       

Why in hell has this been posted to pdp8-lovers?!?!

I may only have a PDP-11 but I'm pretty sure that a PDP-8 doesn't use PC
hardware such as SIMMs and CPUs.

Keep this crap where it belongs, in misc.forsale.computers.pc-clone. It
has nothing to do with PDP-8s.

-- 
James E. Carpenter                           E-Mail: jimc@zachary.riva.com
6 Munroe Drive                                  Tel: (508) 643-0908
Plainville, MA  02762-1132


From cjl@maestro.com Tue Dec 20 08:08:02 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA06136; Mon, 19 Dec 94 23:10:19 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA21119; Mon, 19 Dec 1994 22:58:05 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA16428
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Mon, 19 Dec 1994 22:59:16 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA13683
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Mon, 19 Dec 1994 22:59:14 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for John_Wilson@mts.rpi.edu id AA23723; Mon, 19 Dec 94 11:53:43 EST
Return-Path: <rs@ss1.digex.net>
Received: from access3.digex.net by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA23718; Mon, 19 Dec 94 11:53:38 EST
Received: from rs-pb.digex.net (rs-pb.seastrom.com) by access3.digex.net with SMTP id AA20456
  (5.67b8/IDA-1.5 for <pdp8-lovers@ai.mit.edu>); Mon, 19 Dec 1994 11:53:01 -0500
X-Mailer: InterCon TCP/Connect II 1.2.2
Message-Id: <9412191152.AA59725@rs-pb.digex.net>
Date: Mon, 19 Dec 1994 11:52:59 -0500
From: "Robert E. Seastrom" <rs@ss1.digex.net>
To: postmaster@ix.netcom.com
Cc: LIONEL GOLDBERG <actuary@ix.netcom.com>, pdp8-lovers@ai.mit.edu
Subject: Re: Court Ordered Liquidation - Computer Memory - CPU's & 
	Hdsk Drives


Postmaster:

I must strenuously object to the misuse of the PDP8-Lovers mailing list, 
which I run, for the purposes of advertising hardware that has nothing to do 
with old computers.

This is not the first incident of this individual posting his forsale message 
in inappropriate venues, and I am sure you have heard complaints about it 
before.

Please take whatever action you deem appropriate to ensure that this person's 
actions are not repeated.

Thanks,

					---Rob (for PDP8-Lovers-Request
)



> Received: from nfs1.digex.n
e
t
 
by ss2.digex.net with SMTP id AA13058 
>   (5.67b8/IDA-1.5 for <rs@ss2.digex.net>); Sun, 18 Dec 1994 18:34:47 -
> 0500 Received: from life.ai.mit.edu by nfs1.digex.net with SMTP id 
> AA13678 
>   (5.67b8/IDA-1.5 for <rs@digex.net>); Sun, 18 Dec 1994 18:34:46 -
> 0500 Received: by life.ai.mit.edu (4.1/AI-4.10)  id AA16850; Tue, 13 
> Dec 94 07:30:13 EST Received: from mc.lcs.mit.edu by life.ai.mit.edu 
> (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@
> ai.mit.edu pdp8-lovers-list id AA16836; Tue, 13 Dec 94 07:29:41 
> EST Received: from ix.ix.netcom.com by mc.lcs.mit.edu id aa18156; 13 
> Dec 94 5:17 EST Received: from  by ix.ix.netcom.com (8.6.9/SMI-4.1/
> Netcom) 
> 	id BAA00419; Tue, 13 Dec 1994 01:28:21 -0800 
> Date: Tue, 13 Dec 1994 01:28:21 -0800 
> Message-Id: <199412130928.BAA00419@ix.ix.netcom.com> 
> From: LIONEL GOLDBERG <actuary@ix.netcom.com> 
> Subject: Court Ordered Liquidation - Computer Memory - CPU's & Hdsk 
> Drives To: NOTABENE@taunivm.bitnet 
>  
> Choice Trading Company, Court Appointed Liquidators, have 
> been assigned to liquidate the following Multi-Million Dollar inventory 
> of computer Memory Chips, CPU's and Hard Disk Drives.  
> All items are new and come with applicable manufactures warranty. 
> Prices quoted include all state and local taxes plus shipping and 
> handling. 
>  
> Order                                                 Cost 
> Number   Mfg.       Description                      (EACH) 
>  
> Memory 
>  
> 1524    Toshiba    30 Pin Simms 1x3     70ns  1 meg  $ 25.00 
> 1525    Toshiba    30 Pin Simms 1x9     70ns  1 meg    25.00 
> 1526    Toshiba    30 Pin Simms 4x9     70ns  4 meg   100.00 
>  
> 1527    Toshiba    30 Pin Simms 1x3     60ns  1 meg    26.00 
> 1528    Toshiba    30 Pin Simms 1x9     60ns  1 meg    26.00 
> 1529    Toshiba    30 Pin Simms 4x9     60ns  4 meg   106.00 
>  
> 1624    Toshiba    72 Pin Simms 512x36  70ns  2  meg   50.00 
> 1625    Toshiba    72 Pin Simms 1x36    70ns  4  meg  100.00 
> 1626    Toshiba    72 Pin Simms 2x36    70ns  8  meg  200.00 
> 1627    Toshiba    72 Pin Simms 4x36    70ns  16 meg  400.00 
> 1628    Toshiba    72 Pin Simms 8x36    70ns  32 meg  800.00 
>                                                     
> 1624    Toshiba    72 Pin Simms 512x36  60ns  2  meg   52.00 
> 1625    Toshiba    72 Pin Simms 1x36    60ns  4  meg  104.00 
> 1626    Toshiba    72 Pin Simms 2x36    60ns  8  meg  208.00 
> 1627    Toshiba    72 Pin Simms 4x36    60ns  16 meg  416.00 
> 1628    Toshiba    72 Pin Simms 8x36    60ns  32 meg  832.00 
>  
> Memory for the Macintosh 
>  
> 1122    Toshiba    1 meg x 8 Simm Module 70ns  1 meg   31.00 
> 1123    Toshiba    2 meg x 8 Simm Module 70ns  2 meg   62.00 
> 1124    Toshiba    4 meg x 8 Simm Module 70ns  4 meg  109.00 
>  
> CPU's 
>  
> 1276    Intel      80486 DX/33                        115.00 1277    
> Intel      80486 DX/50                        188.00 1278    
> Intel      80486 DX-2/66                      156.00 1279    
> Intel      80486 DX-4/75                      358.00 1280    
> Intel      80486 DX-4/100                     498.00 1281    
> Intel      Pentium 80501-60                   366.00 1282    
> Intel      Pentium 80501-66                   453.00 1283    
> Intel      Pentium 80502-90                   558.00 
>  
> Hard Disk Drives 
>  
> Seagate Barracuda Drives 
> 1351    Seagate    ST11950N 8ms  3.5" 1.69 GB SCSI    658.00 
> 1352    Seagate    ST12550N 8ms  3.5" 2.1  GB SCSI    899.00 
> 1353    Seagate    ST15150N 8ms  3.5" 4.2  GB SCSI  1,526.00 
> 1354    Seagate    ST31200N 11ms 3.5" 1.05 GB SCSI    538.00 
> 1355    Seagate    ST11900N  9ms 3.5" 1.7  GB SCSI    628.00 
> 1366    Seagate    ST2400A   9ms 3.5" 2.1  GB SCSI    856.00 
> 1367    Seagate    ST15230N  9ms 3.5" 4.29 GB SCSI  1,454.00 
> 1368    Seagate    ST41080N 11ms 5.5" 9.08 GB SCSI  2,848.00 
>  
> Western Digital 
> 1366    Western    AC2340 12ms  3.5"  340  MB IDE     122.00 
> 1367    Western    AC2420 12ms  3.5"  420  MB IDE     136.00 
> 1368    Western    AC2540 12ms  3.5"  540  MB IDE     160.00 
> 1369    Western    AC2700 12ms  3.5"  731  MB IDE     230.00 
>  
> Conner 
> 1372    Connor     CFS420A  14ms  3.5"  420  MB  IDE  138.00 
> 1373    Connor     CFA540A  10ms  3.5"  540  MB  IDE  168.00 
> 1374    Connor     CFA1080A 10ms  3.5"  1080 MB  IDE  408.00 
>  
> ORDERING INFORMATION 
>  
> To order please use a company order form/letterhead or if for personal 
> use, use a plain white sheet of paper with your return address. List 
> the items desired by order number, the quantity and total cost.  Send 
> your order with check or money order payable to Choice Trading Company 
> to: 
>  
> Choice Trading Company 
> Order Processing  Lot #1776 
> 86228 Terminal Annex 
> Los Angeles, Ca. 90086-0228 
>  
> Orders are processed on a first come basis.  Adjustments and refunds 
> will be made immediately for items that have sold out. 
> Please allow 2 to 3 Weeks for shipping.  Due to court ordered 
> restrictions we are unable to accept COD, phone or credit card orders.  
>  
> This public offering is valid through December 30, 1994. Any 
> unsold inventories will be auctioned.  For auction information please 
> send a self addressed stamped enveloped to: 
>  
> Choice Trading Company 
> Lot #1776 
> 202 So. Broadway 
> Los Angeles, Ca. 90012 
> (213) 856 6172 
>  
> If you are unable to use this information, please pass it on to 
> someone who may. 
>  
> Lionel M. Goldberg 
> Actuary 
>  
>  
>  


From cjl@maestro.com Thu Dec 22 09:01:10 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA19154; Thu, 22 Dec 94 03:20:42 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24150; Thu, 22 Dec 1994 03:22:17 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04125
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 22 Dec 1994 03:22:08 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA14065
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 22 Dec 1994 03:22:05 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA02980; Thu, 22 Dec 94 03:12:44 EST
Return-Path: <John_Wilson@mts.rpi.edu>
Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA02886; Thu, 22 Dec 94 03:08:25 EST
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41);
	id AA20313; Thu, 22 Dec 94 02:32:22 EST for PDP8-LOVERS@AI.MIT.EDU 
Date: Thu, 22 Dec 94 02:32:14 EST
From: John_Wilson@mts.rpi.edu
To: INFO-PDP11@transarc.com, PDP8-LOVERS@ai.mit.edu
Message-Id: <4696668@MTS.RPI.EDU>
Subject: Re: Why a pdp-11

>Was that what the RS08 was? I thought the DF32 was the fixed head drive of 
>choice for the early 8's
 
DF32/DS32 was 32KW and smallish.  RF08/RS08 was 256KW and took up a whole
rack (500 lbs. total), although add'l RS08 drives were only 10.5" a pop
(you could have up to four).  The RF/RS was sort of, kind of, a little
compatible with the DF/DS, and TSS/8 had conditionals to use either for
swapping.
 
>I keep wondering as to why I have never SEEN a RS03/04 
 
If they're anything like the size/weight of an RS08, then as soon as
someone tried to wheel one across an asphalt parking lot on a summer day,
it sank full height into the ground and disappeared.  That would make
them a little harder to find...
 
Seriously, when we moved my RS08 into my parents' basement by sliding it
down the stairs on a sheet of plywood, THREE of us were unable to stop it
and it got downstairs before we did.  Luckily this was 1983 and the local
field circus office still had their RS08 formatter box and the two guys
they sent over had just spent a week on service contract time re-learning
how to format RS08s on a PDP-12 at MIT, so I didn't have to pay them $115
per hour to learn how to format mine.  Although, they *had* forgotten how
to load diags from paper tape.  They got it running again and were laid
off a couple of weeks later, never got around to sending me the bill.
All around a good deal...  The drive flaked out again a couple of years
later, shortly before the TSS/8.24 disk date format would have run out
(the PUTR DECtape format already had, it kept only the low digit of the
year since the 1970s seemed to last forever).
 
I can't believe my PDP-8 has doubled in age since I got it, it was a
dinosaur *then*!
 
The RF08 backplane contains 96 flip chips with not a single IC anywhere.
My favorite feature of the RS08 is the bank of switches that let you
write protect it 1/8th of a disk at a time.  Great for when you accidentally
blow the system away, just enable only the first 1/8, do a LOAD, and it'll
bomb out just before it would have overwritten your files.  Also the disk
(like the DF/DS) is addressable to the word, really neat.  TSS used blocks
anyway for the directory structure, but as a 100% artificial concept.
There was a system call to retrieve the block size, in case they ever
changed it (not as far as I know).
 
John Wilson   0,3


From cjl@maestro.com Fri Dec 23 10:03:40 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA25307; Thu, 22 Dec 94 09:41:21 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA07924; Thu, 22 Dec 1994 09:42:41 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA26287
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 22 Dec 1994 09:42:38 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA27566
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 22 Dec 1994 09:42:30 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA11359; Thu, 22 Dec 94 09:33:14 EST
Return-Path: <cjl@maestro.com>
Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA11352; Thu, 22 Dec 94 09:32:57 EST
Received: from maestro.Maestro.COM by relay3.UU.NET with SMTP 
	id QQxvju18224; Thu, 22 Dec 1994 09:32:51 -0500
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA25084; Thu, 22 Dec 94 09:31:13 EST
Date: Thu, 22 Dec 1994 09:31:11 -0500 (EST)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Why a pdp-11
To: John_Wilson@mts.rpi.edu
Cc: INFO-PDP11@transarc.com, PDP8-LOVERS@ai.mit.edu
In-Reply-To: <4696668@MTS.RPI.EDU>
Message-Id: <Pine.3.89.9412220913.A24620-0100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Thu, 22 Dec 1994 John_Wilson@mts.rpi.edu wrote:

> >Was that what the RS08 was? I thought the DF32 was the fixed head drive of 
> >choice for the early 8's
>  
> DF32/DS32 was 32KW and smallish.  RF08/RS08 was 256KW and took up a whole
> rack (500 lbs. total), although add'l RS08 drives were only 10.5" a pop
> (you could have up to four).  The RF/RS was sort of, kind of, a little
> compatible with the DF/DS, and TSS/8 had conditionals to use either for
> swapping.

DEC had been experimenting with head/track disks and drums for swapping 
etc.  The DF32 was originally intended to be the *memory* plane for the 
PDP-8/s, then code-named PDP-10!  Even in the final version it's 32Kx13 
or the (then) maximum memory of the PDP-8 architecture complete with 
memory parity.  This proved to be too slow for even the dreadfully slow 
-8/s, which eventually acquired the first ever quad cards as a 4K at a 
time memory plane, etc.  The DF32 was born as a result.  It's a DMA 
peripheral that can pass a word at a time if desired, since the transfer 
count can be set to 0001-4096 words, etc.

The RF08 is a larger device based on the same head/disk technology.  It 
isn't compatible, however they are similar enough that there is a 
bootstrap convention that serves both.  (It depends on power-clearing of 
register extensions, etc.)  The device code is the same in both, thus 
they never appear together in the same system.

The DF32 can be expanded with DS32 expander disks that plug into the DF32 
while the main DF32 has the buss interface, etc.  With the maximum of 
three DS32's, the total capacity is 128 KW, one half that of a single 
larger RF08.

The RF08 can be expanded with up to three RS08 expanders in a similar 
fashion for a total capacity of 1 MW, the logical maximum device under 
OS/8.  However, the RF08 has an obscure option to double this capacity 
using up to seven expanders coupled with what is known as the DV08 
option.  In this configuration, extra programming is needed to address an 
additional select bit for the (up to) four extra units.  The DV08 
automatically does additional DMA transfers to verity writes without 
program intervention.  Interrupts can occur on read-verify errors after 
the program-initiated write.  No program buffer or other operations are 
required, just initializing the DV08 itself, etc.

>  
> The RF08 backplane contains 96 flip chips with not a single IC anywhere.
> My favorite feature of the RS08 is the bank of switches that let you
> write protect it 1/8th of a disk at a time.  Great for when you accidentally
> blow the system away, just enable only the first 1/8, do a LOAD, and it'll
> bomb out just before it would have overwritten your files.  Also the disk
> (like the DF/DS) is addressable to the word, really neat.  TSS used blocks
> anyway for the directory structure, but as a 100% artificial concept.
> There was a system call to retrieve the block size, in case they ever
> changed it (not as far as I know).

The Disk Monitor System is based on the physical size of DECtape, which 
is 129 words.  The data is stored in the first 128 words, just like all 
other PDP-8 DECtape systems, but the 129th word is used as a link pointer 
to the next logical block.  This severely makes it dependent on the 
hardware, thus the DMS was only ever implemented on the few devices that 
could be adapted to this odd size:

1)	TC01/08 DECtape

2)	DF32

3)	RF08

4)	RK08 (wasting 127 words/sector; this is a 256 word/sector disk 
with the ability to set a word count from 001-256 words)

5)	PDP-12 LINCtape formatted to 128 words/block

While I've never seen it, there is allegedly an ALGOL for the PDP-8 that 
is based on simulating the data structure of some Burroughs model on an 
RF08.  The RF is necessary due to the need for some unwieldy size of data 
block to match the PDP-8-translated ALGOL environment, etc.  Apparently 
the compiler was compiled on a running Burroughs systems, and the binary 
was transferred to the RF08 along with an -8 support program for 
execution, etc.

While head/track disks are generally faster, especially at seeking, most 
PDP-8 systems were geared towards standard sized disk media.  All newer 
peripherals are designed this way even today, thus signaling the end of 
software locked into odd disk sizes, etc.  All PDP-8 disks, from the RK8E 
through the more recent SCSI-based designs, cannot perform odd-length 
transfers.

Additionally, the DF32 and RF08 were never properly designed to be 
powered down!  (Yes, they expected you to perpetually power them!)  Each 
power-down sequence is essentially a head crash.  The drives even have a 
few spare heads/tracks so you can switch to an auxiliary instead of 
powering down, etc.  This was never necessary conceptually, and various 
drum manufacturers solved the problem with a head-lift mechanism, but DEC 
never accomplished this, even with the PDP-11 variants (I think called 
RS64? and RF11).

cjl


From cjl@maestro.com Mon Dec 26 15:48:47 1994
Received: from zaphod.axion.bt.co.uk 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA26694; Thu, 22 Dec 94 10:33:52 EST
Received: from jasper.kbss.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Thu, 22 Dec 1994 15:34:43 +0000
Received: from lodestone.kbss.bt.co.uk by jasper.kbss.bt.co.uk; Thu, 22 Dec 94 15:34:47 GMT
From: Chris Green <chris@kbss.bt.co.uk>
Date: Thu, 22 Dec 94 15:34:20 GMT
Message-Id: <27059.9412221534@lodestone.kbss.bt.co.uk>
To: cjl@maestro.com
Subject: Re: Why a pdp-11
Cc: pdp8-lovers-request@ai.mit.edu

> Additionally, the DF32 and RF08 were never properly designed to be 
> powered down!  (Yes, they expected you to perpetually power them!)  Each 
> power-down sequence is essentially a head crash.  The drives even have a 
> few spare heads/tracks so you can switch to an auxiliary instead of 
> powering down, etc.  This was never necessary conceptually, and various 
> drum manufacturers solved the problem with a head-lift mechanism, but DEC 
> never accomplished this, even with the PDP-11 variants (I think called 
> RS64? and RF11).

Yes, I remember this!  I worked on PDP-12s in South Africa and Saudi
Arabia in the 1970s.  The RF08/RS08 were always on separate and extra
reliable power supplies and we avoided powering them down at all costs.
I seem to remember there being some sort of 'spec' somewhere saying that
they were only supposed to be able to survive three or four power cycles.

I definitely remember the horrible scraping noise the heads made the
one time we had to power down the disks in South Africa!  Nasty!

They were reasonably fast though by the standards of the time, small but
fast compared with the PDP-11 disk systems which mostly had moving rather
than fixed heads.  I remember I was really pleased with myself when I
managed to develop a double buffered backup program which could copy from
the RF08/RS08 to the LINCTape without stopping the tape.  The 'standard'
program only single buffered and thus wrote a block at a time and had
to stop the tape and rewind for every block because of the time taken
to read the next block from disk.
--
Chris Green                          CIX: cgreen@cix.compulink.co.uk
    Home: chris@isbd.demon.co.uk     Compuserve:          100023,657
    Work: chris@kbss.bt.co.uk        Essex Univ.: cgreen@essex.ac.uk


From cjl@maestro.com Mon Dec 26 15:50:38 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA27242; Thu, 22 Dec 94 11:17:35 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA12952; Thu, 22 Dec 1994 11:19:09 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05224
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Thu, 22 Dec 1994 11:18:03 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA16063
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Thu, 22 Dec 1994 11:18:01 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA15477; Thu, 22 Dec 94 11:04:49 EST
Return-Path: <jones@pyrite.cs.uiowa.edu>
Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA15470; Thu, 22 Dec 94 11:04:39 EST
Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
	  on Thu, 22 Dec 1994 10:04:37 -0600 id KAA05090 with SMTP 
Received: by pyrite.cs.uiowa.edu (5.59/890218) 
	  on Thu, 22 Dec 94 10:04:37 CST id AA02454
Date: Thu, 22 Dec 94 10:04:37 CST
From: "Douglas W. Jones" <jones@pyrite.cs.uiowa.edu>
Message-Id: <9412221604.AA02454@pyrite.cs.uiowa.edu>
To: INFO-PDP11@transarc.com, PDP8-LOVERS@ai.mit.edu
Subject: Fixed head disks (Why a PDP-11?)

CJL wrote:
> Additionally, the DF32 and RF08 were never properly designed to be
> powered down!  Each power-down sequence is essentially a head crash.

I accidentally powered down a roomfull of DDP-516's at Bell Labs (the
big red emergency power switch was right by the door, and I accidentally
hit it as I was going for the lights).  The sound of those old fixed head
disks coming to a stop is rather fearsome.

We had an RF11 (I think) on our PDP-11/20 at the U of Illinois back in
1973-74, and it eventually wore through the oxide on one side of the
disk after a few too many power cycles.  That machine was essentially a
dedicated card-based batch Pascal engine, at the time, offering a level
of service which the computer center, with it's big IBM mainframe, had a
hard time equalling.  By the time the error rate reached the point where
we had to call field service, most of the disk tracks were worn through
to the aluminum.  I can only guess, but I imagine that we must have been
successfully recording data using the sides of the heads working against
the walls of the groves they'd worn.

The field service rep noted that we had only a single-sided drive, and
that although the back of the platter wasn't certified, it looked like
it could be polished up pretty well.  A supply of lint free cloth, a
careful polishing with Turtle Wax (yes, that was the brand he used), and
a careful cleaning and reassembly of the drive gave us a system that
provided good service for quite a while longer.

While I'm on the subject of fixed head disks, I hacked a disk drive out
of an old Burroughs office machine that was destined for the scrapyard.
The dates stamped on the ICs in the machine suggest it was built in
1969, but the fixed head disk was indeed its main memory.  What surprised
me was that the disk has micrometer heads -- they don't fly, they're
mechanically spaced away from the disk surface on differential screw
thread mountings.  I'm tempted to spin the thing up someday and hook a
scope to the heads to see what kind of storage capacity the thing had.
It must represent the very trailing edge of fixed (as opposed to flying)
head technology.  I'm sure Burroughs used that approach to avoid the
problems with power cycling you'd expect in a dirty office environment.

				Doug Jones
				jones@cs.uiowa.edu


From cjl@maestro.com Mon Dec 26 15:58:21 1994
Received: from relay1.UU.NET 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA02147; Thu, 22 Dec 94 13:37:08 EST
Received: from rpi.edu by relay1.UU.NET with SMTP 
	id QQxvkk19044; Thu, 22 Dec 1994 13:38:42 -0500
From: John_Wilson@MTS.RPI.EDU
Received: from MTS.RPI.EDU by rpi.edu (4.1/SMHUB41);
	id AA24729; Thu, 22 Dec 94 13:38:36 EST for @relay3.UU.NET:cjl@Maestro.COM 
Date: Thu, 22 Dec 94 13:38:20 EST
To: cjl%Maestro.COM@relay3.UU.NET
Cc: INFO-PDP11@transarc.com, PDP8-LOVERS@ai.mit.edu
Message-Id: <4697565@MTS.RPI.EDU>
Subject: Re: Why a pdp-11

Field Circus told me the same story about never turning the drive off, which
was a bummer because it draws 4A at 110V even with the controller off.  Besides
keeping the heads flying, they mentioned something about the motor bearings
getting worn and wobbly after a few years, and how the gyroscopic effect is
Our Friend.  One thing that stressed me out is that air filters were no longer
available even then (at least not where I could find them), and they were
supposed to be replaced every 6 months or so.
 
SS fixed head disk -- I've never heard of a DS one.  The RS08 is also SS and
the drive can be stripped to expose it, according to the FS guys removing or
replacing the platter was utter hell, they had to set up a tent (like a mini
clean room) and the only way to get the platter on straight was by wrestling
for hours with four screws in the hub, loosen one, tighten the opposite one,
measure again, repeat until angry.
 
Oxide -- actually, I vaguely remember something about the coating being
something really ridiculous, like platinum.  Didn't know it had magnetic
properties...
 
DF/RF incompatibility -- well they aren't *that* different.  They differ in
all the details of course, but basic things are similar, like they both use
the 6601/6603 (DMAR/DMAW) instructions to load the low 12 bits of the disk
memory address from the AC and start a read or write (TSS/8 borrowed these
opcodes for its RFILE/WFILE IOTs), and I believe they used the same data
break locations.  The RS08 doesn't have a photocell like the DS32 does, so
they simulated it from the timing track.  Geometry is none of the programmer's
business so you don't notice any differences there (actually the TSS/8
comments consistently refer to 4KW tracks, maybe they were on the DS
(doubt it) but tracks are definitely 2KW on a RS08, they didn't even know
and their code still worked).
 
My favorite quote from the RF/RS manual:  (I don't remember the numbers but
you get the idea)
 
Power consumption: 600W
Heat dissapation: 350W
 
So like what, it's spinning faster and Faster and FASTER!!!  Or else those
front panel lights are a lot brighter than they look...  Or maybe the bus
drivers can handle miles of cable at 0ns slew.  :-)
 
John Wilson


From cjl@maestro.com Mon Dec 26 16:06:34 1994
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA26863; Mon, 26 Dec 94 15:58:07 EST
Date: Mon, 26 Dec 1994 15:58:06 -0500 (EST)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Why a pdp-11
To: John_Wilson@MTS.RPI.EDU
Cc: cjl@Maestro.COm, INFO-PDP11@transarc.com, PDP8-LOVERS@ai.mit.edu
In-Reply-To: <4697565@MTS.RPI.EDU>
Message-Id: <Pine.3.89.9412261545.B26584-0100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Thu, 22 Dec 1994 John_Wilson@MTS.RPI.EDU wrote:

> Field Circus told me the same story about never turning the drive off, which
> was a bummer because it draws 4A at 110V even with the controller off.  Besides
> keeping the heads flying, they mentioned something about the motor bearings
> getting worn and wobbly after a few years, and how the gyroscopic effect is
> Our Friend.  One thing that stressed me out is that air filters were no longer
> available even then (at least not where I could find them), and they were
> supposed to be replaced every 6 months or so.

Yes, and without powering the drives down.  BTW, I know someone who did 
target practice with the used filters.

>  
> SS fixed head disk -- I've never heard of a DS one.  The RS08 is also SS and
> the drive can be stripped to expose it, according to the FS guys removing or
> replacing the platter was utter hell, they had to set up a tent (like a mini
> clean room) and the only way to get the platter on straight was by wrestling
> for hours with four screws in the hub, loosen one, tighten the opposite one,
> measure again, repeat until angry.

No!  All of them are single-sided.  The DS is just the arbitrary notation 
- DS32 - as opposed to DF32.  It's DEC's way of specifying an expander 
disk.  The RF gets RS expanders, etc.

>  
> Oxide -- actually, I vaguely remember something about the coating being
> something really ridiculous, like platinum.  Didn't know it had magnetic
> properties...

As far as I know it's a magnetic coating.  But in any case, it really 
crashes after a few stops!

>  
> DF/RF incompatibility -- well they aren't *that* different.  They differ in
> all the details of course, but basic things are similar, like they both use
> the 6601/6603 (DMAR/DMAW) instructions to load the low 12 bits of the disk
> memory address from the AC and start a read or write (TSS/8 borrowed these
> opcodes for its RFILE/WFILE IOTs), and I believe they used the same data
> break locations.  The RS08 doesn't have a photocell like the DS32 does, so
> they simulated it from the timing track.  Geometry is none of the programmer's
> business so you don't notice any differences there (actually the TSS/8
> comments consistently refer to 4KW tracks, maybe they were on the DS
> (doubt it) but tracks are definitely 2KW on a RS08, they didn't even know
> and their code still worked).

Yes, the RF is the "big brother" of the DF.  They could have made them 
proper subsets of each other, but chose to instead put an elaborated 
interface into the RF, thus the incompatibility past the power-on state 
of the RF registers mapping the low-order transfer bits in the same way 
as the DF did, etc.

BTW, the photocell and its associated interrupt cannot be disabled in the 
DF32.  Some users modified the drive to do it RF style, but in the 
original version, you couldn't change it, etc.

Eventually, the DF32 was done over in a posibus version - DF32D - 
complete with DS32D expanders, etc.  This one can delete the photocell 
interrupt, etc.

>  
> My favorite quote from the RF/RS manual:  (I don't remember the numbers but
> you get the idea)
>  
> Power consumption: 600W
> Heat dissapation: 350W
>  
> So like what, it's spinning faster and Faster and FASTER!!!  Or else those
> front panel lights are a lot brighter than they look...  Or maybe the bus
> drivers can handle miles of cable at 0ns slew.  :-)

Was the 600 W the turn-on power, or the all-the-time power?  Also, are 
they considering the interface power or just the platter?

>  
> John Wilson
> 

cjl


From cjl@maestro.com Fri Dec 30 20:29:52 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA20174; Tue, 27 Dec 94 12:58:53 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA00496; Tue, 27 Dec 1994 13:00:24 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05175
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 27 Dec 1994 13:00:17 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA24507
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 27 Dec 1994 13:00:11 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA20465; Tue, 27 Dec 94 12:42:58 EST
Return-Path: <rmsmith@csc.com>
Received: from csc.com (explorer.csc.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA20235; Tue, 27 Dec 94 12:42:47 EST
Received: by csc.com (Smail3.1.28.1 #18)
	id m0rMfv2-000iDMC; Tue, 27 Dec 94 12:42 EST
Message-Id: <m0rMfv2-000iDMC@csc.com>
From: rmsmith@csc.com (Robert Smith)
Subject: Re: Why a pdp-11 (fwd)
To: info-PDP11@transarc.com, pdp8-lovers@ai.mit.edu
Date: Tue, 27 Dec 1994 12:42:44 -0500 (EST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 806       

JL said: 
> On Thu, 22 Dec 1994 John_Wilson@MTS.RPI.EDU wrote:
> 
> > Field Circus told me the same story about never turning the drive off, which
> No!  All of them are single-sided.  The DS is just the arbitrary notation 
> - DS32 - as opposed to DF32.  It's DEC's way of specifying an expander 
> disk.  The RF gets RS expanders, etc.

CJL et al: DF and DS are not arbitrary designations.  Dick Best, as Chief 
Engineer, assigned nomenclature and model numbers.
DF equates to Disk, Fixed.
DS equates to Disk, Slave.
RK equates to Disk, Kartridge.
RF started being used (along with RP/RS/etc) when the D was assigned to
Datacomm devices (DP8e, DP11, DH11, DM11, DMC11, DHL8, etc
The meanings have changed over the years but that was how it was when the
alpha vice numeric designations were started.
Bob


From cjl@maestro.com Fri Dec 30 21:00:57 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA09767; Tue, 27 Dec 94 22:36:14 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA29104; Tue, 27 Dec 1994 22:37:54 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10565
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Tue, 27 Dec 1994 22:37:51 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA04447
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Tue, 27 Dec 1994 22:37:50 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA12660; Tue, 27 Dec 94 22:21:17 EST
Return-Path: <MAP=Bounce@bbn.com>
Received: from BBN.COM by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA12656; Tue, 27 Dec 94 22:21:15 EST
Received: from GAAK.BBN.COM by BBN.COM id aa19083; 27 Dec 94 22:21 EST
Date: Tue, 27 Dec 1994 22:20:55 EST
Message-Id: <map=1994Dec27222055@gaak.bbn.com>
To: rmsmith@csc.com
Cc: info-PDP11@transarc.com, pdp8-lovers@ai.mit.edu
In-Reply-To: <m0rMfv2-000iDMC@csc.com> (message from Robert Smith on Tue, 27 Dec 1994 12:42:44 -0500 (EST))
Subject: Re: Why a pdp-11 (fwd)
From: "Michael A. Patton" <MAP@bbn.com>
Reply-To: "Michael A. Patton, general reply address" <MAP=Reply@bbn.com>

   From: Robert Smith <rmsmith@csc.com>
   Date: Tue, 27 Dec 1994 12:42:44 -0500 (EST)

   RF started being used (along with RP/RS/etc) when the D was assigned to
   Datacomm devices

And the story, as I heard it, was that "R" was chosen for "Rotating"
which makes:
   RK equates to Disk, Kartridge.
really RK => Rotating Kartridge and the expansion of RF (Rotating,
Fixed) sound like an oxymoron (it's "Rotating media, Fixed heads").

	-MAP


From cjl@maestro.com Fri Dec 30 21:11:32 1994
Received: from ucsd.edu 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA15269; Wed, 28 Dec 94 03:13:38 EST
Received: from sceard.UUCP by ucsd.edu; id AAA28785
	sendmail 8.6.9/UCSD-2.2-sun via UUCP
	Wed, 28 Dec 1994 00:01:55 -0800 for maestro.com!cjl
Received: by Sceard.COM (smail2.5/deliver1.5)
	id AA13154; 27 Dec 94 23:44:28 PST (Tue)
To: cjl@maestro.com
Subject: Re: Why a pdp-11
Cc: John_Wilson@mts.rpi.edu
Message-Id: <9412272344.AA13150@Sceard.COM>
Date: 27 Dec 94 23:44:27 PST (Tue)
From: mrm@Sceard.COM

>
>
>On Thu, 22 Dec 1994 John_Wilson@mts.rpi.edu wrote:
[...]
>>  
>> The RF08 backplane contains 96 flip chips with not a single IC anywhere.
>> My favorite feature of the RS08 is the bank of switches that let you
>> write protect it 1/8th of a disk at a time.  Great for when you accidentally
>> blow the system away, just enable only the first 1/8, do a LOAD, and it'll
>> bomb out just before it would have overwritten your files.  Also the disk
>> (like the DF/DS) is addressable to the word, really neat.  TSS used blocks
>> anyway for the directory structure, but as a 100% artificial concept.
>> There was a system call to retrieve the block size, in case they ever
>> changed it (not as far as I know).
>
And cjl responded:
>The Disk Monitor System is based on the physical size of DECtape, which 
>is 129 words.  The data is stored in the first 128 words, just like all 
>other PDP-8 DECtape systems, but the 129th word is used as a link pointer 
>to the next logical block.  This severely makes it dependent on the 
>hardware, thus the DMS was only ever implemented on the few devices that 
>could be adapted to this odd size:
>
>1)	TC01/08 DECtape
>
>2)	DF32
>
>3)	RF08
>
>4)	RK08 (wasting 127 words/sector; this is a 256 word/sector disk 
>with the ability to set a word count from 001-256 words)
>
>5)	PDP-12 LINCtape formatted to 128 words/block

And of course, the 9-track magtape (TU10) in core-dump mode and 7-track magtape
(I remember it as TU20, but I think my memory is flawed).

Using the scheme
  EOF with long gap
  two's complement block number
  129 words (link word last)
  EOF with long gap
  ...
and rewriting blocks in the middle of the tape.

Twisted, but it worked. 4KDMS running on a pair of magtape drives was a
sight to behold, especially with one of the drives a 9-track and the
other a 7-track with clunking and wheezing and reels-a-spinning. The
pain was how many places drivers for devices existed in the 4KDMS, e.g.,
in PIP, and how hard it was to patch in a driver for the magtape in the
place of the DECtape driver in each required place.

:-)

OS/8 on magtape-only systems was a kick, too.

>
>While I've never seen it, there is allegedly an ALGOL for the PDP-8 that 
>is based on simulating the data structure of some Burroughs model on an 
>RF08.  The RF is necessary due to the need for some unwieldy size of data 
>block to match the PDP-8-translated ALGOL environment, etc.  Apparently 
>the compiler was compiled on a running Burroughs systems, and the binary 
>was transferred to the RF08 along with an -8 support program for 
>execution, etc.

There was also ROGALGOL. I have a listing somewhere, but the tapes are
long ago turned to dust.

>
>While head/track disks are generally faster, especially at seeking, most 
>PDP-8 systems were geared towards standard sized disk media.  All newer 
>peripherals are designed this way even today, thus signaling the end of 
>software locked into odd disk sizes, etc.  All PDP-8 disks, from the RK8E 
>through the more recent SCSI-based designs, cannot perform odd-length 
>transfers.
>
>Additionally, the DF32 and RF08 were never properly designed to be 
>powered down!  (Yes, they expected you to perpetually power them!)  Each 
>power-down sequence is essentially a head crash.  The drives even have a 
>few spare heads/tracks so you can switch to an auxiliary instead of 
>powering down, etc.  This was never necessary conceptually, and various 
>drum manufacturers solved the problem with a head-lift mechanism, but DEC 
>never accomplished this, even with the PDP-11 variants (I think called 
>RS64? and RF11).

I seem to remember that the DF32/DS32 were single sided, even though
the platter was surfaced on both sides, and, if times were really hard,
the platter could be flipped once and then reformatted. Those were sick days...

>
>cjl
>

Regards,
Mike
--
Mike Murphy  mrm@Sceard.COM  ucsd!sceard!mrm  +1 619 598 5874
Better is the enemy of Good


From cjl@maestro.com Fri Dec 30 21:11:51 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA07053; Wed, 28 Dec 94 20:20:11 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA03704; Wed, 28 Dec 1994 20:21:46 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10852
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Wed, 28 Dec 1994 20:21:43 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA01113
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Wed, 28 Dec 1994 20:21:42 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA01705; Wed, 28 Dec 94 20:13:21 EST
Return-Path: <@uunet.ca,@mail.uunet.ca:jim@cml.com>
Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA01701; Wed, 28 Dec 94 20:13:14 EST
Received: from uunet.ca by mc.lcs.mit.edu id aa23250; 28 Dec 94 20:12 EST
Received: from inet.cml.com ([199.166.254.6]) by mail.uunet.ca with SMTP id <95247-5>; Wed, 28 Dec 1994 20:13:18 -0500
Received: from localhost (jim@localhost) by inet.cml.com (8.6.5/8.6.6) id UAA08700; Wed, 28 Dec 1994 20:12:21 -0500
Date: Wed, 28 Dec 1994 20:12:21 -0500
From: James Everett <jim@cml.com>
To: pdp8-lovers@mc.lcs.mit.edu
Subject: Re: older decstation
Message-Id: <Pine.BSD.3.90.941228200854.8575A-100000@inet.cml.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Can anyone help me get a set-up disk for an older decstation 316?

Have tried everywhere and found you in Internet Yellow Pages.

If you can help me or know someone who can please e-mail to jim@cml.com

Thanks!


From cjl@maestro.com Fri Dec 30 21:28:53 1994
Received: from SunSITE.Unc.EDU (president.oit.unc.edu) 
	by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA10911; Fri, 30 Dec 94 21:20:12 EST
Received: from watsun.cc.columbia.edu (calzone.oit.unc.edu) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24204; Fri, 30 Dec 1994 21:21:56 -0500
Received: from mailhub.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA22366
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@watsun.cc.columbia.edu>); Fri, 30 Dec 1994 21:21:54 -0500
Received: from life.ai.mit.edu by mailhub.cc.columbia.edu with SMTP id AA18643
  (5.65c+CU/IDA-1.4.4/HLK for <lasner@cunixf.cc.columbia.edu>); Fri, 30 Dec 1994 21:21:52 -0500
Received: by life.ai.mit.edu (4.1/AI-4.10) for lasner@cunixf.cc.columbia.edu id AA07948; Fri, 30 Dec 94 21:13:41 EST
Return-Path: <cjl@maestro.com>
Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -oi -fpdp8-lovers-request@ai.mit.edu pdp8-lovers-list id AA07944; Fri, 30 Dec 94 21:13:30 EST
Received: from maestro.Maestro.COM by relay2.UU.NET with SMTP 
	id QQxwpc04480; Fri, 30 Dec 1994 21:13:11 -0500
Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93)
	id AA10612; Fri, 30 Dec 94 21:11:21 EST
Date: Fri, 30 Dec 1994 21:11:20 -0500 (EST)
From: Charles Lasner <cjl@maestro.com>
Subject: Re: Why a pdp-11
To: mrm@sceard.com
Cc: John_Wilson@mts.rpi.edu, pdp8-lovers@ai.mit.edu
In-Reply-To: <9412272344.AA13150@Sceard.COM>
Message-Id: <Pine.3.89.9412302125.B9704-0100000@maestro.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On 27 Dec 1994 mrm@Sceard.COM wrote:

> >
> >
> >On Thu, 22 Dec 1994 John_Wilson@mts.rpi.edu wrote:
> [...]
> >>  
> >> The RF08 backplane contains 96 flip chips with not a single IC anywhere.
> >> My favorite feature of the RS08 is the bank of switches that let you
> >> write protect it 1/8th of a disk at a time.  Great for when you accidentally
> >> blow the system away, just enable only the first 1/8, do a LOAD, and it'll
> >> bomb out just before it would have overwritten your files.  Also the disk
> >> (like the DF/DS) is addressable to the word, really neat.  TSS used blocks
> >> anyway for the directory structure, but as a 100% artificial concept.
> >> There was a system call to retrieve the block size, in case they ever
> >> changed it (not as far as I know).
> >
> And cjl responded:
> >The Disk Monitor System is based on the physical size of DECtape, which 
> >is 129 words.  The data is stored in the first 128 words, just like all 
> >other PDP-8 DECtape systems, but the 129th word is used as a link pointer 
> >to the next logical block.  This severely makes it dependent on the 
> >hardware, thus the DMS was only ever implemented on the few devices that 
> >could be adapted to this odd size:
> >
> >1)	TC01/08 DECtape
> >
> >2)	DF32
> >
> >3)	RF08
> >
> >4)	RK08 (wasting 127 words/sector; this is a 256 word/sector disk 
> >with the ability to set a word count from 001-256 words)
> >
> >5)	PDP-12 LINCtape formatted to 128 words/block
> 
> And of course, the 9-track magtape (TU10) in core-dump mode and 7-track magtape
> (I remember it as TU20, but I think my memory is flawed).

TU10.  Correct the first time

> 
> Using the scheme
>   EOF with long gap
>   two's complement block number
>   129 words (link word last)
>   EOF with long gap
>   ...
> and rewriting blocks in the middle of the tape.
> 
> Twisted, but it worked. 4KDMS running on a pair of magtape drives was a
> sight to behold, especially with one of the drives a 9-track and the
> other a 7-track with clunking and wheezing and reels-a-spinning. The
> pain was how many places drivers for devices existed in the 4KDMS, e.g.,
> in PIP, and how hard it was to patch in a driver for the magtape in the
> place of the DECtape driver in each required place.
> 
> :-)
> 
> OS/8 on magtape-only systems was a kick, too.

Yes, this was also done on non-DEC magtapes as well.  I think the company 
was Iomega (Iomedia?  One of them is for bournoulli disks.  This is the 
other one :-).)  They are in turn a spin-off of Digitronics, the original 
company that made the big clunky rubber-roller white-painted paper-tape 
reader such as found on the PDP-5.  They made drives in 7-track, 9-track, 
and 1600 PE 9t.  I worked for Western Union.  Each remote site had the 
9-track and perhaps some set of the others.  My main machine had all of 
them (1 1600, 2 800-9 and 2 800-7).  (I had no LPT, but I could write a 
listing to a 7-track at 556 and then take the tape to an inhouse univac 
machine to get printed.  A two-page OS/8 handler did it, etc.)

Our handler depended on the Omnibus machine hack where executing 7016 at 
relative offset 015 of the page loads the page address+16 into the AC.  
Note that the position is important because it could be on the -8/a CPU.  
(On the -8/e CPU it doesn't matter, but on the -8/a, the value is 
absolute address, not page address+16, so you must load the instruction 
at 015 relative, etc.) (Note: I didn't write that handler :-).)

> 
> >
> >While I've never seen it, there is allegedly an ALGOL for the PDP-8 that 
> >is based on simulating the data structure of some Burroughs model on an 
> >RF08.  The RF is necessary due to the need for some unwieldy size of data 
> >block to match the PDP-8-translated ALGOL environment, etc.  Apparently 
> >the compiler was compiled on a running Burroughs systems, and the binary 
> >was transferred to the RF08 along with an -8 support program for 
> >execution, etc.
> 
> There was also ROGALGOL. I have a listing somewhere, but the tapes are
> long ago turned to dust.

Please find the listing; it can be scanned!

> 
> >
> >While head/track disks are generally faster, especially at seeking, most 
> >PDP-8 systems were geared towards standard sized disk media.  All newer 
> >peripherals are designed this way even today, thus signaling the end of 
> >software locked into odd disk sizes, etc.  All PDP-8 disks, from the RK8E 
> >through the more recent SCSI-based designs, cannot perform odd-length 
> >transfers.
> >
> >Additionally, the DF32 and RF08 were never properly designed to be 
> >powered down!  (Yes, they expected you to perpetually power them!)  Each 
> >power-down sequence is essentially a head crash.  The drives even have a 
> >few spare heads/tracks so you can switch to an auxiliary instead of 
> >powering down, etc.  This was never necessary conceptually, and various 
> >drum manufacturers solved the problem with a head-lift mechanism, but DEC 
> >never accomplished this, even with the PDP-11 variants (I think called 
> >RS64? and RF11).
> 
> I seem to remember that the DF32/DS32 were single sided, even though
> the platter was surfaced on both sides, and, if times were really hard,
> the platter could be flipped once and then reformatted. Those were sick days...

I heard the same.

> 
> >
> >cjl
> >
> 
> Regards,
> Mike
> --
> Mike Murphy  mrm@Sceard.COM  ucsd!sceard!mrm  +1 619 598 5874
> Better is the enemy of Good
> 

cjl


