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 ); 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 ); 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 ); 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 ); 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: 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: 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 ); 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 ); 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: 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 ); 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" To: postmaster@ix.netcom.com Cc: LIONEL GOLDBERG , 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 ); 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 ); 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 > 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 ); 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 ); 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: 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 ); 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 ); 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: 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 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: 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 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 ); 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 ); 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: 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" 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 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: 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 ); 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 ); 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: 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: 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 ); 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 ); 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: 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: To: rmsmith@csc.com Cc: info-PDP11@transarc.com, pdp8-lovers@ai.mit.edu In-Reply-To: (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" Reply-To: "Michael A. Patton, general reply address" From: Robert Smith 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 ); 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 ); 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 To: pdp8-lovers@mc.lcs.mit.edu Subject: Re: older decstation Message-Id: 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 ); 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 ); 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: 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 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: 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