Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 5 Jan 91 17:12:47 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Sat, 5 Jan 91 17:10:22 EST Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05059; Sat, 5 Jan 91 17:00:02 EST Received: from sask.usask.ca by mc.lcs.mit.edu id aa29476; 5 Jan 91 16:59 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Sat, 5 Jan 1991 15:59 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Sat, 5 Jan 91 15:59:04 CST id AA13358 for pdp8-lovers@mc.lcs.mit.edu Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA04215; Sat, 5 Jan 91 15:12:30 -0600 Date: Sat, 5 Jan 91 15:12:30 -0600 From: Shawn Switenky <874226@watt.usask.ca> Subject: Hello? To: pdp8-lovers@mc.lcs.mit.edu Message-Id: <9101052112.AA04215@watt.USask.Ca> X-Envelope-To: pdp8-lovers@mc.lcs.mit.edu Date: Sat, 5 Jan 91 15:12:30 -0600 From: Shawn Switenky <874226@watt.usask.ca> Subject: Hello? To: pdp8-lovers@mc.lcs.mit.edu X-Envelope-To: pdp8-lovers@mc.lcs.mit.edu Greetings all! How do I get on this list? I've got a basket case PDP8/e that I sure could use some help with. I'm also still looking for some kind of operating system to run on it, like OS/8 or TSS/8 but I have had no luck finding such things. I also have a PDP11/60 and a VAX11/750 that are working. +---------------------------------+----------------------------------------+ | Shawn Switenky | "Real Computers use Kilowatts" | | | | | Informatics Assistant | Every thing I say is my opinion, | | RHQ Prairies | and belongs to me. | | Correctional Service of Canada | | | | | +---------------------------------+----------------------------------------+ Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sun, 6 Jan 91 18:05:48 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Sun, 6 Jan 91 18:03:25 EST Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA23783; Sun, 6 Jan 91 17:51:41 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Sun, 6 Jan 1991 16:51 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Sun, 6 Jan 91 16:51:19 CST id AA16429 for pdp8-lovers@ai.mit.edu Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA07035; Sun, 6 Jan 91 16:51:12 -0600 Date: Sun, 6 Jan 91 16:51:12 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Hello! To: pdp8-lovers@ai.mit.edu Message-Id: <9101062251.AA07035@watt.USask.Ca> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Sun, 6 Jan 91 16:51:12 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Hello! To: pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu Hello Everyone! I'm just new to this list so I thought I'd introduce myself. I'm a Electrical Engineering / Computer Science student who attends the University of Saskatchewan in Saskatoon, Saskatchewan, Canada. I have been picking up old computers and playing with them for about three years now, with my first aquisition being a PDP8/e with all the LAB8 equipment. Shortly after I picked up a PDP11/60 and just recently I bought a VAX11/750. Both the 11 and the VAX work ( and nicely I might add ) but I have never managed to get the PDP8/e working. I have had the thing plugged in long enough to determine that the machine is locked up. Someday I'll have to break out the PDP8/e Maintenance Manual and the schematics and trouble shoot. I'm looking for an operating system for the PDP8 as well as a DECTape Controller and some boards for my TU56. Can anyone help me out with this? I also noticed from the DECUS catalog that DEC put some PDP8 operating systems ( ie WS/78.) I was wondering if DEC had also put OS/8 or TSS/8 in the DECUS library as well? How hard is it to find DECTapes? I need a few since I do not have any. While I'm on the subject of media, how hard is it to find RK05 platters for use with the PDP8? What is the difference between the ones uses on PDP11 and the onces used on the 8's? I noticed from past messages that Chris Zach use to post the occasional message here. Are you still around, Chris? Thats about all I can think of right now. Type at you all soon. +---------------------------------+----------------------------------------+ | Shawn Switenky | "Real Computers use Kilowatts" | | | | | Informatics Assistant | Every thing I say is my opinion, | | RHQ Prairies | and belongs to me. | | Correctional Service of Canada | | | | | +---------------------------------+----------------------------------------+ Greetings All! How do I get on this list? I've got a basket case PDP8/e that I really could use some help with, and now that I have a stable email account, I hope I can ask alot of questions Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 06:44:07 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 06:41:39 EST Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02024; Mon, 7 Jan 91 06:18:46 EST Received: from SUNIC.SUNET.SE by mc.lcs.mit.edu id aa06096; 7 Jan 91 6:18 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177) id AAsunic21729; Mon, 7 Jan 91 12:18:13 +0100 Date: Mon 7 Jan 91 12:17:33 From: Johnny Billquist Subject: Re: Hello? To: 874226@watt.usask.ca Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101052112.AA04215@watt.USask.Ca> Message-Id: <910107121733.23.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Mon 7 Jan 91 12:17:33 From: Johnny Billquist Subject: Re: Hello? To: 874226@watt.usask.ca Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101052112.AA04215@watt.USask.Ca> You send a request to pdp8-lovers-request@ai.mit.edu saying that you want to join in. Do you have WCS for your 11/60, by the way? I'd sure like to help you get going with your eight, as is probably a few other. I live in Sweden, though, so most stuff will probably be available from closer sources, but let me know how it goes. I have pretty much software, and some hardware that I'm willing to exchange for other stuff. Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 06:50:03 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 06:47:30 EST Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA02092; Mon, 7 Jan 91 06:27:08 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177) id AAsunic22019; Mon, 7 Jan 91 12:27:05 +0100 Date: Mon 7 Jan 91 12:26:34 From: Johnny Billquist Subject: Re: Hello! To: 874226@watt.usask.ca Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101062251.AA07035@watt.USask.Ca> Message-Id: <910107122634.23.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Mon 7 Jan 91 12:26:34 From: Johnny Billquist Subject: Re: Hello! To: 874226@watt.usask.ca Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101062251.AA07035@watt.USask.Ca> Operating systems for the pdp8 is no problem. A TD8E DECtape controller might be a little harder to come by. I have only one, and appearantly more people are looking for them. Presonally, though, I don't like the TD8E, since it isn't a DMA device. DEC has not released OS/8 nor the CUSPs for it, yet... Some are still hoping... Charles Lasner is probably the one who knows most about that thread. Are you referring to empty DECtapes, or with software? DEC stopped selling empty DECtapes about two years ago in Sweden, but I suspect that they still can dig some up. As for DECtapes with stuff on, I can fix that. The difference between the RK05 for the PDP8 and the PDP11 is that the PDP11 has 12 sectors/track and the PDP8 has 16 sectors/track. The sectors are marked by a "hole" in the platters bottom. My english isn't always the best, so let me know if you need further explanation of this. However, it is not possible to convert from one type to the other. Last I checked, DEC still sold RK05 platters for the PDP8. Also, some other company is still producing those platters, since I have another source for them too... Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:17:25 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:14:46 EST Received: from decpa.pa.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA08423; Mon, 7 Jan 91 12:49:45 EST Received: by decpa.pa.dec.com; id AA11114; Mon, 7 Jan 91 08:33:19 -0800 Message-Id: <9101071633.AA11114@decpa.pa.dec.com> Received: from narfvx.enet; by decwrl.enet; Mon, 7 Jan 91 08:33:27 PST Date: Mon, 7 Jan 91 08:33:27 PST From: "Illiterate? Write for free help. 07-Jan-1991 1128" To: pdp8-lovers@ai.mit.edu Subject: RE: DECtapes and RK05 cartridges... Date: Mon, 7 Jan 91 08:33:27 PST From: "Illiterate? Write for free help. 07-Jan-1991 1128" To: pdp8-lovers@ai.mit.edu Subject: RE: DECtapes and RK05 cartridges... Digital no longer sells DECtapes. We found this out when we (the DECsystem-10 group) had to put out a release and had no DECtapes for the front-end software. It turns out the 3M still makes them, but they dont come in the neat plastic cases any more -- only simple cardboard boxes. Also, they aren't certified or formatted -- you'll have to 'roll your own', literally! As far as RK05 disk cartridges go, there's no difference between the ones used on 11s and 8s. It's all in the formatting, which you have to do. You might contact any of several computer supply houses around the US and Canada. They're getting harder to find (as are packs for big disks like RP06s and RM05s). If you find a vendor that has the latter, they more than likely will have the former. Good luck! John Francini Former DECsystem-10 developer Digital Equipment Corporation Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:45:11 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:42:40 EST Received: from decpa.pa.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA08885; Mon, 7 Jan 91 13:10:26 EST Received: by decpa.pa.dec.com; id AA21366; Mon, 7 Jan 91 10:09:13 -0800 Message-Id: <9101071809.AA21366@decpa.pa.dec.com> Received: from narfvx.enet; by decwrl.enet; Mon, 7 Jan 91 10:09:32 PST Date: Mon, 7 Jan 91 10:09:32 PST From: "Illiterate? Write for free help. 07-Jan-1991 1307" To: 874226@watt.usask.ca Subject: Oops! I had it wrong about Rk05 cartridges... Date: Mon, 7 Jan 91 10:09:32 PST From: "Illiterate? Write for free help. 07-Jan-1991 1307" To: 874226@watt.usask.ca Subject: Oops! I had it wrong about Rk05 cartridges... Hmmm. Looks like I'm wrong about the RK05 cartridges. I forgot about the sector holes in the bottom of the platter. The rest of my message is still OK, though... John Francini Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 13:48:02 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 13:45:32 EST Received: from convex.convex.com ([130.168.1.1]) by life.ai.mit.edu (4.1/AI-4.10) id AA09006; Mon, 7 Jan 91 13:13:54 EST Received: from concave.convex.com by convex.convex.com (5.61/1.35) id AA00106; Mon, 7 Jan 91 12:12:47 -0600 Received: from groucho.convex.com by concave.convex.com (5.61/1.28) id AA00212; Mon, 7 Jan 91 12:12:44 -0600 Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.groucho.convex.com.sun3.4 via MS.5.6.groucho.convex.com.sun3_4; Mon, 7 Jan 1991 12:12:42 -0600 (CST) Message-Id: Date: Mon, 7 Jan 1991 12:12:42 -0600 (CST) From: "Anthony A. Datri" To: pdp8-lovers@ai.mit.edu Subject: Re: DECtapes and RK05 cartridges... In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com> References: <9101071633.AA11114@decpa.pa.dec.com> Date: Mon, 7 Jan 1991 12:12:42 -0600 (CST) From: "Anthony A. Datri" To: pdp8-lovers@ai.mit.edu Subject: Re: DECtapes and RK05 cartridges... In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com> References: <9101071633.AA11114@decpa.pa.dec.com> >As far as RK05 disk cartridges go, there's no difference between the >ones used on 11s and 8s. It's all in the formatting, which you have >to do. I'm pretty sure that the hub on the pack has slits to denote sectors -- 16 sectors for 12 bit machines; 12 sectors for 16 bit machines. >They're getting harder to find (as are packs for big >disks like RP06s and RM05s The latest DECdirect catalog still lists RK05's, RM05's, and RP06's. -- Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 16:28:31 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 16:26:06 EST Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA13515; Mon, 7 Jan 91 15:55:59 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan 1991 14:55 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91 14:55:19 CST id AA20907 for francini@narfvx.enet.dec.com Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10358; Mon, 7 Jan 91 14:55:11 -0600 Date: Mon, 7 Jan 91 14:55:11 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: RE: DECtapes and RK05 cartridges... To: francini@narfvx.enet.dec.com, pdp8-lovers@ai.mit.edu Message-Id: <9101072055.AA10358@watt.USask.Ca> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Mon, 7 Jan 91 14:55:11 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: RE: DECtapes and RK05 cartridges... To: francini@narfvx.enet.dec.com, pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu Amen on the availibility of RM05 packs... I've got a RM05 drive here for my vax, but I can't use it since I have no pack. Life is like that, I guess. What is the part number for the 3M Dectapes? I'd like to phone up 3M and say that I want this instead of " It's about the size of a big hockey puck, and has alot of mylar tape on it, and the design is older that you are." Shawn Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 17:10:55 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 17:08:15 EST Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA15008; Mon, 7 Jan 91 16:45:53 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan 1991 14:57 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91 14:57:21 CST id AA20922 for datri@concave.convex.com Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10363; Mon, 7 Jan 91 14:57:16 -0600 Date: Mon, 7 Jan 91 14:57:16 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: DECtapes and RK05 cartridges... To: datri@concave.convex.com, pdp8-lovers@ai.mit.edu Message-Id: <9101072057.AA10363@watt.USask.Ca> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Mon, 7 Jan 91 14:57:16 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: DECtapes and RK05 cartridges... To: datri@concave.convex.com, pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu I should read what I type. What I meant to say about the RM05's is I would like to find some used ones. DEC's price on new ones is about twice what I paid for my entire VAX system. Shawn Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 18:28:55 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 18:26:23 EST Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA17099; Mon, 7 Jan 91 18:01:47 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177) id AAsunic26225; Tue, 8 Jan 91 00:01:42 +0100 Date: Mon 7 Jan 91 23:25:47 From: Johnny Billquist Subject: RE: DECtapes and RK05 cartridges... To: francini@narfvx.enet.dec.com Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com> Message-Id: <910107232547.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Mon 7 Jan 91 23:25:47 From: Johnny Billquist Subject: RE: DECtapes and RK05 cartridges... To: francini@narfvx.enet.dec.com Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101071633.AA11114@decpa.pa.dec.com> Wrong. There IS a difference between RK05 for pdp8 and pdp11. It sure is the format, but you cannot format them yourself. They are hard sectored, with different number of sectors for pdp8 and pdp11. (Well, you CAN format them, but not change the number of sectors/track) Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:08:03 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:05:22 EST Received: from decwrl.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA16695; Mon, 7 Jan 91 17:43:32 EST Received: by decwrl.dec.com; id AA11956; Mon, 7 Jan 91 14:43:18 -0800 From: llustig!david@decwrl.dec.com Message-Id: <9101072243.AA11956@decwrl.dec.com> To: decwrl!pdp8-lovers@ai.mit.edu Subject: Re: Hello! Date: Mon Jan 7 14:42:00 1991 From: llustig!david@decwrl.dec.com To: decwrl!pdp8-lovers@ai.mit.edu Subject: Re: Hello! Date: Mon Jan 7 14:42:00 1991 (In a separate email to the originator, I offered to give him some spare DEC- tapes and copies of some maintenance information.) Mr. Billquist doesn't like the TD8E because it isn't a DMA (cycle-steal) device. Hah. Needless complexity, those cycle-stealers. Two whole additional registers, one of which is an upcounter! That's a lot of chips, you know. Maybe if you are time-sharing your -8 or doing real-time (foreground/back- ground) work, DMA is good. But for a simple single-user system, I don't see the need. The TD8E has the advantage of simplicity, a Good Thing, now that we have to maintain these things ourselves. Now I just need a spare weekend and a borrowed oscilloscope so I can fix what- ever is busted on my TD8E and TU56 DECtape system.... David Schachter voice phone: +1 415 328 7425 internet: david@llustig.palo-alto.ca.us uucp: ...!{decwrl,mips,sgi}!llustig!david Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:10:19 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:07:42 EST Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA16685; Mon, 7 Jan 91 17:43:08 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.177) id AAsunic25334; Mon, 7 Jan 91 23:42:58 +0100 Date: Mon 7 Jan 91 23:42:29 From: Johnny Billquist Subject: Formatting RL02 packs... To: pdp8-lovers@ai.mit.edu Message-Id: <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Mon 7 Jan 91 23:42:29 From: Johnny Billquist Subject: Formatting RL02 packs... To: pdp8-lovers@ai.mit.edu Does anybody know how you format RL02 packs. I have checked my docs for my RL8A, and it appears that the pdp8 controller cannot format the packs. If not: Why did DEC limit the controller in that stupid way? I don't need to format anything right now, but it seems to me that the occation might arise sometime... The same goes for the RX8 with the RX01. Why did DEC include the possibility to format floppies, I certainly could have some use of that. Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:25:47 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:23:25 EST Received: from cs.umn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20357; Mon, 7 Jan 91 20:08:34 EST Received: by cs.umn.edu (5.61/1.14) id AA21807; Mon, 7 Jan 91 19:08:24 -0600 Date: Mon, 7 Jan 91 19:08:24 -0600 From: "Lawrence T. LeMay" Message-Id: <9101080108.AA21807@cs.umn.edu> To: pdp8-lovers@ai.mit.edu Subject: DECtape Cc: lemay@cs.umn.edu Date: Mon, 7 Jan 91 19:08:24 -0600 From: "Lawrence T. LeMay" To: pdp8-lovers@ai.mit.edu Subject: DECtape Cc: lemay@cs.umn.edu I called 3M this afternoon, and asked about DECtape. The person I talked with didn't seem absolutely sure that she had the correct tape, but it was listed as 3/4" wide, and length of 260 (feet? inches?)... Anyways, they say that thsi tape was discontinued last September. They are looking for any reels that may still be in stock, and will get back to me. Does anyone else have any information on this? If they find a 'large' quantity of these tapes, i'll post a follow-up message. -Larry LeMay lemay@cs.umn.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 20:47:04 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 20:44:42 EST Received: from EDDIE.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA20659; Mon, 7 Jan 91 20:25:32 EST Received: by EDDIE.MIT.EDU (5.61/25-eef) id AA18646; Mon, 7 Jan 91 20:23:34 EST Date: Mon, 7 Jan 91 20:23:34 EST From: Robert E. Seastrom Message-Id: <9101080123.AA18646@EDDIE.MIT.EDU> To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se Cc: pdp8-lovers@ai.mit.edu In-Reply-To: Johnny Billquist's message of Mon 7 Jan 91 23:42:29 <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Subject: Formatting RL02 packs... Date: Mon, 7 Jan 91 20:23:34 EST From: Robert E. Seastrom To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se Cc: pdp8-lovers@ai.mit.edu In-Reply-To: Johnny Billquist's message of Mon 7 Jan 91 23:42:29 <910107234229.19.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Subject: Formatting RL02 packs... Date: Mon 7 Jan 91 23:42:29 From: Johnny Billquist Does anybody know how you format RL02 packs. I have checked my docs for my RL8A, and it appears that the pdp8 controller cannot format the packs. Yep; DEC is infamous for this sort of thing. It is in fact true that you can not format RL02s, regardless of the machine they are on. Someone once tried to give me a whole bunch of degaussed RL packs; I turned them down. If not: Why did DEC limit the controller in that stupid way? Well, you can't format RL01s either; you can't format RX01s (but you can format in RX01 format on an RX02), and I don't think you can format an RD53 (maxtor 71 meg drive on a Microvax). Probably if this is true, the same goes for the RD52 and the RD54 as well. Conspiracy? I dunno. You make the call... ---Rob Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 7 Jan 91 23:39:08 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 7 Jan 91 23:36:44 EST Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA23653; Mon, 7 Jan 91 23:13:35 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Mon, 7 Jan 1991 22:13 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Mon, 7 Jan 91 22:13:16 CST id AA22914 for D89.JOHNNY-BILLQUIST@aida.csd.uu.se Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA10848; Mon, 7 Jan 91 22:13:13 -0600 Date: Mon, 7 Jan 91 22:13:13 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: Formatting RL02 packs... To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, alberta!decwrl!ames!think!mit-eddie!rs@herald.usask.ca Cc: pdp8-lovers@ai.mit.edu Message-Id: <9101080413.AA10848@watt.USask.Ca> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Mon, 7 Jan 91 22:13:13 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: Formatting RL02 packs... To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, alberta!decwrl!ames!think!mit-eddie!rs@herald.usask.ca Cc: pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu TU58 Dectape II's are factory formatted as well, at least as far as I know. If anyone can format them, let me know cause I have a whole pile that have been degausses too. The sad thing is that system managers, the people who should know this, did the degaussing. Sad but true. Shawn Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 02:11:39 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 02:09:18 EST Received: from uunet.UU.NET by life.ai.mit.edu (4.1/AI-4.10) id AA26094; Tue, 8 Jan 91 01:49:31 EST Received: from apex.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA16394; Tue, 8 Jan 91 01:49:19 -0500 Message-Id: <9101080649.AA16394@uunet.UU.NET> From: apex!chuckh@uunet.uu.net (Chuck Huffington) Date: Mon, 7 Jan 1991 22:50:20 PST In-Reply-To: uunet!watt.usask.ca!874226 (Shawn Switenky) "Re: Formatting RL02 packs..." (Jan 7, 22:13) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: uunet!ai.mit.edu!pdp8-lovers@uunet.uu.net Subject: Re: Formatting RL02 packs... From: apex!chuckh@uunet.uu.net (Chuck Huffington) Date: Mon, 7 Jan 1991 22:50:20 PST In-Reply-To: uunet!watt.usask.ca!874226 (Shawn Switenky) "Re: Formatting RL02 packs..." (Jan 7, 22:13) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: uunet!ai.mit.edu!pdp8-lovers@uunet.uu.net Subject: Re: Formatting RL02 packs... Why can't RL02s be formatted? Two reasons come to mind: 1) It's hard to format an embedded servo pack. 2) It really cuts down on the competition for pack sales. Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 06:08:35 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 06:06:11 EST Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28911; Tue, 8 Jan 91 05:46:00 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA20912; Tue, 8 Jan 91 05:46:55 EST Date: Tue, 8 Jan 91 5:46:54 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Many Flames and Fortunes about Formatting (warning: *very* long) Message-Id: Date: Tue, 8 Jan 91 5:46:54 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Many Flames and Fortunes about Formatting (warning: *very* long) Flame warning: I don't design this stuff, I just use and program it. I have many "reliable" sources for the info which was obtained over many years of -8 association. Some of the ideas may be contrary to either DEC official policy (past and/or present), or may contradict some "official" documentation (which in actuality is *wrong* :-). So, to borrow from Elton John (from the album with Crocodile Rock on it), don't shoot me, I'm only the programmer (piano player) (I remember when rock (and the pdp-8!) was young; me and Susie had so much fun...) From: Charles Lasner (lasner@watsun.cc.columbia.edu) To: PDP8-Lovers.ai.mit.edu Subj: Formatting various DEC media used on the PDP-8, etc. I have been following this thread for a few days, and wanted to wait for the "smoke to clear" before responding, since some "dumb stuff" has been "going down." Here is some explanation to all would be formatter-type people: 1) DECtapes and LINCtapes are the same media, only wound in opposite directions on the same reels. They come in 150 foot and 260 foot versions. The LINCtapes are never "certified" or formatted in any way because there were too many incompatible formats in the LINCtape world to care about. At last check there were: a) 1000 blocks of 400 words/block (the LINC standard). b) 2000 blocks of 400 words/block (using the longer tapes). c) 1000 blocks of 400 words/block followed by 1000 blocks of 400 words/block (an inner additional "tape") on the longer tapes. The difference here is that b) uses blocks 0-1777 and c) uses 0-0777 followed by 0-0777 repeated as another whole "tape" image. d) 2000 or more blocks of 200 words/block (LINC-8 PDP-8 side standard). Sometimes used with incompatible checksum convention in O/S's such as CPS-4k and the LINCtape LINC-8 version of the DEC Library System. e) 2000 or more blocks of 201 words/block for the sake of pseudo-compatibility with PDP-8 DECtape software that needs the extra word such as PDP-12 DM System (Thank you, Mark Hyde!). d) and e) are considered the standard on the PDP-8-type O/S's for the PDP-12 such as OS/12 and P?S/12. Each system maintains the extra word as an optional "nuisance" that may have to be dealt with. The DECtapes come in only two formats which could be "certified" as a guaranteed tape ready to work out of the box. These are either PDP-10, etc. tapes formatted to 1102 blocks of 600 words/block which sport a purple certification label, or 2702 blocks of 201 words/block which sport an orange certification label. The label means that someone took the tapes out of new storage, and formatted them on a certain PDP-8 with a TC08 and eight drives using the standard tape formatter which can do either format (located in the Maynard Mill). The only advantage of doing eight at a time was that you could walk away from the operation sooner and for a longer break. If the program indicated no errors, the operator's initials and the date were written on the label. Occasionally mistakes were made, and a tape could be "certified" yet be the other standard length! Or it could be defective all together in spite of the label. This service was never worth the extra cost, especially since the tapes should be copied and reformatted every six months of actual usage. (Note, tapes just sitting around for 20 years read just fine!) There is a peculiar side story to this certification machine. The TC08 on this machine was actually BROKEN and is responsible for certain defective software in OS/8, etc., since the software only runs on broken machines. P?S/8 was "demoed" to DEC management on this system and it caused some embarassment when good code failed to perform! Eventually, the problem was seen on other TC08s and TU56s. The problem is an interaction between the buss driver and load resistor pullup card in the TC08 with a certain ECO of the receiver card in the TU56 when configured for negative tape busses. Curiously, it works fine with OLDER variations of the receiver card! Further, there was much "scuttle-butt" that "certified" tapes were "zero-skew" which was NEVER the case owing to the bad maintenance of this machine. A "nearly zero-skew" tape is ALWAYS creatable on ANY TU56 and is the BEST judge of the alignment of the drive at any time, since the test exaggerates the misalignment by a factor of two. More than adequate alignment is always possible in the field with nothing more than a skew test card or equivalent and a 'scope. We constructed a skew tester BETTER than DEC's using two G888 cards and a black-block (Don't need green, only single-sided!) and a VECTOR card edge and socket. Our tester brings the analog version of the signals out to the scope, whereas DEC's clips and only shows the zero crossings (optional with ours) which prevents judging the tape head amplitude, etc. A test point is available on the G888 apparently for this express purpose - after the pre-amp and before the waveshaping amp driven into saturation. To be fair, DEC's module is based on pieces of R-series cards and pieces of G882 modules from the negative TC01, etc. days, so there really isn't a good place to observe the equivalent waveforms. Using our card, it is readily possible to align the drive to about 3/4 of a microsecond, where DEC often let out 3.0 microsecond skew drives. We considered drives good if they were less than 2.0 microseconds since a DEC tech tip gave that number. In any case, the smaller the value, the more interchangeable tapes formatted there become. Various extended length variations exist on all of the above formats which depend on the tape being a certain length. Some (such as 4000 block 200 words/block LINCtapes or 3300 block 201 words/block DECtape) depend on the fact that the nominal 260 foot length was in fact *longer* in actual tapes (usually). The only "valid" excuse for returning a 260 foot tape to DEC was that PDP-10-style format wasn't do-able on the medium. Generally LINCtape formats produce slightly more blocks than their DECtape counterparts because the inter-block zone "overhead" is less. (LINCtapes, however cannot transfer bi-directionally, only search that way whereas DECtapes can also transfer backwards too.) Late production tapes were shipped "skimpy" and some couldn't manage being formatted as PDP-10-type DECtapes. If your guides were in good shape, you could also "cheat" a little on the mark clock setting, so more tapes could be "extra long" in the batch, but the reliability goes down due to friction, etc. The mark clock ratings documented in the various controllers were also sometimes mis-stated (the complement period instead of the actual one) or were just downright wrong, and various systems had ECOs to attempt to correct this, which were often overlooked. The proper setting is whatever it takes to make each 12-bit word take 133 microseconds to happen on a DECtape system or 160 microseconds on the LINC-8 due to slower and gentler motors. Originally LINCtapes or MICROtapes (as the early DECtapes were called) were packaged in either plain white boxes from 3M with blue liner and lettering or in various colored DEC-sold cardboard boxes of a two-part nature. Either a sleeve style or a box and cover, whereas the 3M package is a simple box with ear tabs. Eventually, 3M also poly-sealed the tapes in a bag in the box. Most of DEC's early containers are dark blue and white sleeve types, with a styrofoam circle glued to the sleeve to secure the tape. Some are black-and-white boxes with an imprint/photo of a tape reel in the slick print. Some covers are really attached clam-shell style and don't separate from the bottom. The earliest tapes which were 150 feet intended for the LINC (and eventually the LINC-8) came on bone-white reels which were slightly undersized compared to the later reels potentially holding the 260 foot (nominal) tape which were some form of creamy off-white (various shades of antique white). This style of reel also has a 3M sticker in an arc shape glued onto the reel in no particular position, and occasionally on the rear face. All DEC and later 3M reels have an inset area for the DEC standard reel label on the front. Tapes purchased from 3M for immediate DECtape usage are marked on the box "DIGL WND" presumably meaning Digital Wound or somesuch. All DEC reels also have the corporate name stamped into the mold. The real "deep" stampings usually have a visible mold mark/defect on them in the shape of a semi-circle near the label inset area. All DEC reels never have 3M labels on them, but the tape itself always starts with one. You were always advised to remove them, but few people did, so heads got sticky and needed more frequent cleaning! (They also let you cheat in mounting the tape on the takeup reel.) Eventually DEC sold tapes in plastic cannisters: Blue for DECtape and Green for LINCtape. The cannisters also can be identified by their shade of color, and the exact nature of the designs on the cannister back face label and the inner circular center label. There were at least five "vintages" by this method. Apparently both colors exist in all versions. Some cannisters cannot interchange covers, since this could yield either a sloppy fit or a too tight fit, etc. All plastic cannisters are fragile and many crack. There were also an extremely small number of cannisters of other colors: part clear, and all dark blue which were glommed on to by various managers. They claimed they were to be used for "official" releases to distribution of new software, but this apparently was never fully borne out. DEC also distributed a 3M part which was a set of strips of blue colorforms to hold the end down when storing the reel. Many people just lost them, and others tore them in half to increase their number to compensate for loss. They sometimes hold amazingly well, and other times won't work for beans. Red/Orange and Green colorforms never came from DEC, but people took them from Magtapes to put on the DECtapes and LINCtapes just to be "different" and stand out. DEC sold peel-off labels for the reels in Red, Blue, Green, and Yellow. One-color labels were never available to customers, but white with printed lettering was often used for release tapes. The orange and purple "certification" labels have preprinted format info regions on them. Occasionally, the DEC PAPER-TAPE label was attached to the outside of the cannister in various vintages. I have over 3000 tapes at present, and can possibly be "arm-twisted" to give up some to the "needy" since I am storing files on "bigger" things these days, but none are as reliable as good ol' DECtape. 2) DECtape II can only be hooked up on an -8 to a KL-8/E because you have to do a "break" character. The other -8 interfaces can't do it. There exists a "clandestine" ROM for the TU58 serial version that makes it FORMAT! I have one somewhere, and if I find it, I will send it here to PDP8-Lovers. I believe it is a 2716, so I need access to a ROM blaster/reader to dump its contents out. When you change the ROM, the TU58 talks to the host system with a MENU and various tape-tensioning and formatting/checking routines. This ROM was distributed secretly at a DECUS symposium back when they weren't DEC sales' versions of charged-admission Tupperware parties. Others may have this gem, but I only got one, and it's somewhere in a box in my "dungeon." :-( (I think it also came with a hex dump of the code also on a heavily re-zeroxed sheet.) 3) RX01 and RX02 CANNOT FORMAT! This is a myth generated by the uninformed! The disk format consists of pre-formatted patterns that are described as FM or double-frequency which means that the clock pulse always occurs in between data that may not appear (and thus becomes a zero if so). The entire RX01 format consists of this. The special headers such as index mark, address mark, etc. are formed by EXCEPTIONS to the above known as "missing clocks." As the name implies, you sync up on a clear pattern of clocks which are recognizable as such as soon as one absentee pulse confirms that is was a zero data bit, so its neighbors must be clocks. The circuit to do this is generally known as a data separator. Suddenly, the rules change, and a buffer register which tracks these things can form a pattern of which clocks actually didn't occur. The precise bit patterns of the missing clocks indicate exactly where you are. Neither the RX01 or RX02 can change any of this! The rest of the headers are a short data record and CRC followed by a much longer, albeit similar record. The first one is the address, which essentially means which track and sector this particular header is part of. The larger portion is the actual data which has its own CRC at the end too. In the RK8E, both of these are rewritten every time you write, and are indicated by exactly one data bit that is a one in the midst of otherwise zero bits. There are no missing clocks, but the whole sector gets reformatted! This is a little dangerous, especially on a floppy, so the RX01 will not rewrite the headers, rather only the data and CRC. If you corrupt the missing clocks or headers, and you only have an RX01, throw away the media. The RX02 situation is a little less "bleak" but has some problems (more on this later). The RX02 is totally compatible with the RX01 format *OR* it uses a variant: The missing clocks and their resultant patterns are maintained as in the RX01. But now the data and CRC are written by totally different rules if the disk is double-density. The basis of the method is called MFM (modified FM). This method "cheats" and is the father of most current data recording methods in the industry. The basic idea is that there is a mythical clock time (that *NEVER* happens!). If the actual pulse occurs sooner than the expected midpoint of time of arrival for the mythical clock then the data is a one. Should it arrive later, it is a zero. (These might arbitrarily be reversed; it really doesn't matter as long as you are consistent!) In any case, the arrival and determination of the latest bit's polarity calculates the next mid-point time for the next mythical clock. The major flaw in this scheme is that it is impossible to tell the difference between long strings of ones or longs strings of zeroes. The format must include some "guess-work time" to arbitrate the data as all zeroes when starting up. Clearly jitter is the real villain here. MFM drives have to be carefully "certified" in order to work reliably. So the RX02 includes an operation called SET MEDIA DENSITY which rewrites the header type and data areas with the requested type RX01 or double-density as needed. This can clean up a slightly dinged RX01 disk, BUT cannot rewrite the missing clocks inserted externally by an IBM 3740 or equivalent. There is yet another way to regain the disk format: use the DSD-210 drives from DSD or some other models which were -11 only. These non-DEC drives include extra operations to actually write the missing clock patterns and redeem ANY magnetically dinged media. (And I have one on my 8/e! :-) There are also some SCSI controllers that can format RX01 media if suitable 8" drives are attached to them. Then the RX02 can change the media density if required. There is another problem with the RX02 that only DSD fixed on the -11: When you write pulse transitions on any magnetic media, there is a "crowding" effect on the inner tracks. All 8" drives include a feature to lower the write current on inner tracks (above track 43) to partially offset this. The problem is that the actual timing of when the data separator "sees" the pulse happening shifts forward in time on these more "delicate" tracks so the inter-pulse timing will "drift" and screw up the MFM method (much less important on RX01 single-density). DEC forgot to do their "homework" on this one, and just left out any consideration while everyone else fixed it: You keep a running history of the last few bits you wrote. Depending on the actual data pattern, you pre-compensate some of the pulses and write them earlier (just a predictable "hair" of time earlier) then otherwise intended. The value is data dependent and could range over several values (including zero change which DEC's RX02 ALWAYS uses!) This compensates for the predictable crowding when read back and makes the drive MUCH more reliable. Notice that the write-compensation even helps the RX02 to read the data back so the best protection for your RX02 data is to do a blind diskcopy of your RX02 media on a DSD RX02-superset drive. 4) Embedded servo disks such as the RL01, RL02, and any RD3x or RD5x disk cannot be formatted in the usual sense. There is no caliper of position in these drives, rather the media has been subjected to an analog pattern "wave" across the entire media (between the tracks too!). The idea is that not every bit of a track is written on since there are designated guard areas as part of every sector. Within this area the media is "virgin" or at least what it was when it was installed in the drive. When you are over the exact valley of the "wave" the low-frequency energy is at a minimum. The data bits are a high-frequency phenomena and are filtered out here. Should the head deviate either way, the amplitude will shift in a way to oppose to deviation, thus the head follows (is a servo :-) the imbedded low-frequency info. Even if the whole track should get blown, the deviation either way still pushes the head back to the middle, as long as it is blown in the correct place! (But not as "sure-footedly" as when it isn't blown; generally good enough to still use though. Some drives can be heard as blown because when they are recalibrated, the "buzzing pattern" is disrupted over the corrupted region. This means that the drive may not survive being blown again over the same nominal track, since it might saturate an alternate area not suitable for use as that affected track, or you may flip-flop between two "copies" of the same track depending on where you last seeked from! The only fix is to get the media rebuilt with a servowriter which puts the patterns back down. This is only available in "clean-room" repair companies generally. (Yeah, it costs money!) :-( All of the mentioned media et. al. can be "formatted" in the sense that the data patterns and generally the address patterns can be rewritten. This presupposes a working servo pattern. Most DEC systems can do this lessor form of reformat but I won't vouch for all systems. Some systems allow changing the sector size, etc. while you are at it. Remember, this is a format in the same sense as an RK05, BUT the RK05 has a position caliper in each drive that must be adjusted to an external standard. No positioning info comes from the pack so a degaussed media is fine there. But that would destroy the imbedded servo analog wave pattern on these drives. Note also that it is cheaper to make a servo drive than a calipered drive for the same TPI, or alternatively you can crowd the tracks in real close only with imbedded servo. The strange part about the RL01 is that it has all the grief, yet only gives you 5 whole Megs for your trouble! DEC also paid less attention to the interface of the RLs, so the programming is a major step backwards compared to the RK05, etc. which is also 5.0 Megs error-free and totally reformatable (I am referring to the RK05F which can be slightly modified to take removable packs which can't interchange with the regular RK05 but none-the-less can interchange between RK05F's!) There is a major software price to be paid on the RLs on both the -8 and the -11. The -11 required major overhaul of RT-11, etc. just to support the RLs (to monitor the status of heads in motion of the non-automatic seeked drive!). The -8 problems are a little more insidious: The primary requirement for the RL on the -8 is to make OS/8 "like" the beast. All else doesn't matter because the other DEC systems are really glorified applications and don't have the "handler" problem. So DEC devised a scheme to use the RLs under OS/8. Each section of the 40-sector track is cut up into two 16-sector wedge-shaped regions and an 8-sector "extra" region. This allows each region to match OS/8's maximum size (or less) and is theoretically fine. But there is a performance price to be paid: each track always wastes the other 24 sectors not belonging to the current region, so the drive spends a lot of time spinning unproductively. There is even a "formatting" program that writes out mini-tables of bad spots so each area fends for itself by loading the handler with the local bad spots to "straddle" over. This would be the end of it, BUT not quite: When you design hardware without feedback, you get problems! DEC has been there may times, and then the software people have to figure out some "kludge" to get around the problem. (A hardware "nerd" once asked me why the position in a register of three bits mattered; I couldn't succeed in explaining to him why it "pessimized" the code and his arbitrary choice should have been moved before they committed it to a PC board.) Some DEC designer attempted to overcome an inherent defect in the transfer design of the RL8A: the inherent loss of bits when using 12-bit mode instead of 8-bit mode. I profoundly wish he hadn't tried! There is a word count register in the RL8A which is real great for 8-bit mode transfers: you get your chosen number of 8-bit bytes right-justified in every 12-bit word just fine, and you can even read in up to 4096 adjacent bytes. BUT, in 12-bit mode, there are 170 2/3 words in every sector, and if you set the word count to more than 128, you will get some of those useless words in his futile attempt to recover all the data in 12-bit mode. By the way, the 256th byte doesn't even get transferred, so this method is worthless even for cramming more data into the buffer for some mythical block-for-block copy utility. Of course, we want the first 128 12-bit words, and skip the rest. So, the handler has to do individual transfers of 128 12-bit words. The overhead of the single page transfers causes you to miss the next sector every time! So, the OS/8 handler uses a TWO-WAY INTERLEAVE to access the sectors! Yes, it takes two passes to read in 16 sectors per track which means that 64 sectors are ignored every two revolutions assuming no seeking and you just got to the beginning of the track at the right time; more realistically you have to add another 1/2 revolution on average, so each 1 field transfer takes 2.5 revolutions. Remember, the RK8E does a field in 1 pass with an average of 1.5 revolutions to do it in! The RL02 is the same as the RL01 but is twice as big thus there are 5 wedges instead of 2.5. All else applies. By the way, the -8's don't intermix drives like the -11. The problem is apparently that the "extra" bit of track addressing must be set somehow when talking to the RL01. I don't really know to what value, but apparently the RL01 jumper on the RL8A makes the corresponding AC bit be ignored and is substituted for in the hardware. (Guesses for this value include 0, 1, a parity bit, or perhaps a sign extension bit. In any case, they don't trust RL01 software to generate the correct value when the jumper is thrown to also allow RL02s.) Of course the bit takes on true meaning as an extension track bit when talking to actual RL02s properly. Perhaps all of the relevant software could be carefully rewritten to ensure the requirement of the RL01 and thus allow mixed drives systems. The RL78 option of the DECmate I apparently has no such bit and thus only officially supports RL02s. Today, I have PDP-8 SCSI devices, so my controllers are designed by controller companies, not DEC. But I still have RK05s and DECtapes and LINCtapes too. :-) cjl (lasner@watsun.cc.columbia.edu) Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 8 Jan 91 06:17:13 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 8 Jan 91 06:14:54 EST Received: from cc.usu.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29037; Tue, 8 Jan 91 05:59:57 EST Date: Mon, 7 Jan 91 22:25 MDT From: Roger Ivie Subject: Formatting on DEC machines and DECtape To: pdp8-lovers@ai.mit.edu Message-Id: X-Envelope-To: pdp8-lovers@ai.mit.edu X-Vms-To: IN%"pdp8-lovers@ai.mit.edu" Date: Mon, 7 Jan 91 22:25 MDT From: Roger Ivie Subject: Formatting on DEC machines and DECtape To: pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu X-Vms-To: IN%"pdp8-lovers@ai.mit.edu" > If not: Why did DEC limit the controller in that stupid way? > > Well, you can't format RL01s either; you can't format RX01s (but you > can format in RX01 format on an RX02), and I don't think you can > format an RD53 (maxtor 71 meg drive on a Microvax). Probably if this > is true, the same goes for the RD52 and the RD54 as well. Conspiracy? > I dunno. You make the call... You can format RDxx's on MicroVAXes, but I think you have to buy the diagnostic programs; this is certainly true of the MicroPDP-11s. However, you cannot format RX50 floppies on any DEC machine but the Rainbow, and that only because enough Rainbow customers complained to force DEC to include a formatter. I'm also looking for a TD8E, but for a slightly different reason. You see, I've got an original distribution kit for OS/8 V3C on DECtape and it would be kind of nice if I could read the thing. I can get my hands on drives but not the controller. Roger Ivie slsw2@cc.usu.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 9 Jan 91 00:32:39 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 9 Jan 91 00:30:19 EST Received: from akbar.cac.washington.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08856; Tue, 8 Jan 91 14:23:26 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.21 ) id AA29307; Tue, 8 Jan 91 11:23:23 -0800 Date: Tue, 8 Jan 1991 11:18:27 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: TD8/E To: PDP-8-LOVERS@ai.mit.edu Message-Id: Date: Tue, 8 Jan 1991 11:18:27 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: TD8/E To: PDP-8-LOVERS@ai.mit.edu I have an extra TD8/E that I'd be willing to let go, but only if I got for it what I paid for it a few years ago ($300) from the used computer sharks. I don't know if it works, I abandoned the project I got it for. Let me know if you're interested. -- Mark -- Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 10 Jan 91 16:58:46 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 10 Jan 91 16:56:24 EST Received: from EDDIE.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA25334; Thu, 10 Jan 91 16:38:01 EST Received: by EDDIE.MIT.EDU (5.61/25-eef) id AA00745; Thu, 10 Jan 91 16:36:28 EST Date: Thu, 10 Jan 91 16:36:28 EST From: Robert E. Seastrom Message-Id: <9101102136.AA00745@EDDIE.MIT.EDU> To: pdp8-lovers@ai.mit.edu Subject: can anyone help this fellow? Date: Thu, 10 Jan 91 16:36:28 EST From: Robert E. Seastrom To: pdp8-lovers@ai.mit.edu Subject: can anyone help this fellow? From: pbm@cybvax0.uucp (Paul B. McBride) Newsgroups: comp.sys.dec Date: 10 Jan 91 19:00:29 GMT Distribution: usa Organization: Cybermation, Inc. I have been contacted by someone who has some TU60 cassette tapes which they would like to read. The tapes were created on a PDP/8 using OS/8. They have an OS/8 system running on an RL02 disk, with the TU60 drive, and paper tape reader. They are unable to access the TU60 drive. The system seems to be working properly, but they do not have any manuals. Does anyone know how to access the TU60 drive from OS/8, or how to configure OS/8 so that it can access the TU60, or what additional driver is required? Does anyone know of someone who would be able to read and convert these tapes to a less ancient media? All comments and suggestions are welcome. Please mail responses to uunet!cybvax0!pbm. Thanks. -- -- Paul B. McBride (cybvax0!pbm) Cybermation, Inc. (617) 396-6500 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 14 Jan 91 13:31:16 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 14 Jan 91 13:28:49 EST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA16224; Mon, 14 Jan 91 13:10:39 EST From: rs@ai.mit.edu (Robert E. Seastrom) Received: by rice-chex (4.1/AI-4.10) id AA22705; Mon, 14 Jan 91 13:10:24 EST Date: Mon, 14 Jan 91 13:10:24 EST Message-Id: <9101141810.AA22705@rice-chex> To: pdp8-lovers@ai.mit.edu Subject: In case you don't read alt.folklore.computers... From: rs@ai.mit.edu (Robert E. Seastrom) Date: Mon, 14 Jan 91 13:10:24 EST To: pdp8-lovers@ai.mit.edu Subject: In case you don't read alt.folklore.computers... From: meissner@osf.org (Michael Meissner) Newsgroups: alt.folklore.computers Date: 14 Jan 91 12:37:48 GMT Organization: Open Software Foundation In article u502sou@mpirbn.mpifr-bonn.mpg.de (Ignatios Souvatzis) writes: | ... I've got a couple of working PDP 11/34s (w 128K RAM) and a | working PDP 11/20 (w 16K CORE) sitting next to me heating the house | up ... they are built like tanks ... | ^^^^^ | | Well said. On page n of one of those PDP-8 paperbacks I saved from the | trashcan, DEC tells us that they used to drop the PDP-8's from a | height of about one foot to test them. It reminds me how somebody 'proved' that a PDP-8 is a REAL computer, and the IBM PC is just a toy.... The first step is that you put the IBM PC on top of the PDP-8 and both run fine. The second step is you put the PDP-8 on top of the IBM PC, and only the PDP-8 runs... :-) -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET? Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 14 Jan 91 19:28:29 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 14 Jan 91 19:25:50 EST Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA26085; Mon, 14 Jan 91 18:53:46 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.179) id AAsunic24162; Tue, 15 Jan 91 00:53:27 +0100 Date: Tue 15 Jan 91 00:52:25 From: Johnny Billquist Subject: Re: can anyone help this fellow? To: rs@eddie.mit.edu Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101102136.AA00745@EDDIE.MIT.EDU> Message-Id: <910115005225.21.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Tue 15 Jan 91 00:52:25 From: Johnny Billquist Subject: Re: can anyone help this fellow? To: rs@eddie.mit.edu Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9101102136.AA00745@EDDIE.MIT.EDU> What is a TU60??? Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 15 Jan 91 22:46:12 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 15 Jan 91 22:43:12 EST Received: from SASK.USask.CA by life.ai.mit.edu (4.1/AI-4.10) id AA27107; Tue, 15 Jan 91 22:10:54 EST Received: from dvinci.USask.ca by SASK.USask.CA with PMDF#10255; Tue, 15 Jan 1991 21:10 CST Received: from watt.USask.Ca by dvinci.USask.ca (4.1/SMI-3.2); Tue, 15 Jan 91 21:10:28 CST id AA02853 for D89.JOHNNY-BILLQUIST@aida.csd.uu.se Received: by watt.USask.Ca (5.57/Ultrix3.0-C) id AA01912; Tue, 15 Jan 91 21:10:18 -0600 Date: Tue, 15 Jan 91 21:10:18 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: can anyone help this fellow? To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu Cc: pdp8-lovers@ai.mit.edu Message-Id: <9101160310.AA01912@watt.USask.Ca> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Tue, 15 Jan 91 21:10:18 -0600 From: 874226@watt.usask.ca (Shawn Switenky) Subject: Re: can anyone help this fellow? To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu Cc: pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu I believe a TU60 is a DEC storage device that used standard type audio cassettes. This was available for the PDP8, as well as perhaps some other machines. The machine dates back to the early to mid 70's Shawn Switenky 874226@watt.usask.ca Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 17 Jan 91 15:29:10 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 17 Jan 91 15:24:29 EST Received: from convex.convex.com by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Thu, 17 Jan 91 14:26:01 EST Received: from hydra-demo.convex.com by convex.convex.com (5.61/1.35) id AA01622; Thu, 17 Jan 91 13:27:21 -0600 Received: from concave.convex.com by hydra.convex.com (5.61/1.28) id AA18885; Thu, 17 Jan 91 10:30:35 -0600 Received: from lovecraft.convex.com by concave.convex.com (5.61/1.28) id AA26032; Thu, 17 Jan 91 10:29:35 -0600 Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.convex.com.sun4.40 via MS.5.6.lovecraft.convex.com.sun4_40; Thu, 17 Jan 1991 10:34:48 -0600 (CST) Message-Id: <4bZR8cm2e4Nh1oAptf@concave> Date: Thu, 17 Jan 1991 10:34:48 -0600 (CST) From: "Anthony A. Datri" To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu, 874226@watt.usask.ca (Shawn Switenky) Subject: Re: can anyone help this fellow? Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9101160310.AA01912@watt.USask.Ca> References: <9101160310.AA01912@watt.USask.Ca> Date: Thu, 17 Jan 1991 10:34:48 -0600 (CST) From: "Anthony A. Datri" To: D89.JOHNNY-BILLQUIST@aida.csd.uu.se, rs@eddie.mit.edu, 874226@watt.usask.ca (Shawn Switenky) Subject: Re: can anyone help this fellow? Cc: pdp8-lovers@ai.mit.edu In-Reply-To: <9101160310.AA01912@watt.USask.Ca> References: <9101160310.AA01912@watt.USask.Ca> >I believe a TU60 is a DEC storage device that used standard type audio >cassettes. True enough. Fit a whopping 96kb onto one. > This was available for the PDP8, as well as perhaps some >other machines Actually, I've never seen evidence of it being on 8's, although I've seen that low-end 11/10's for lab work were sometimes equipped with them, with the TA11 controller. True to DECform, you could run RT11 with these as you system device. I actually once saw an RT11 V1 distribution on cassettes. -- 336996351123355369963511235117*47*8*47*8*7471 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 18 Jan 91 03:28:19 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 18 Jan 91 03:25:54 EST Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01713; Fri, 18 Jan 91 03:08:18 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA10855; Fri, 18 Jan 91 03:09:37 EST Date: Fri, 18 Jan 91 3:09:37 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Fri, 18 Jan 91 3:09:37 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: TU60 Re: TU60's and PDP-8's It would be helpful if people would make reasonable assumptions about what DEC did prior to 1980 or so regarding peripherals. In essence, virtually every peripheral that was considered "important" (by marketing at least :-)) was "grafted" onto every DEC system including the PDP-8. This principle should over-rule people's assumptions when they lack specific information. Now onto the specifics. The TU60 is hooked to the TA8E controller card for one pair of drives usually known as CSA0: and CSA1:. There was limited support for more hardware to up this to CSA2: through as much as CSA7:, but few machines ever had that many. (The hardware was repeated bodily, using a different device code just like the RX's.) The TU60 is NOT block-replacable, and thus cannot really run any traditional operating system, but, like various magtape versions, the -11 world did allow for read-only release tape images such as RT and RSX, but these were hardly usable in the ordinary sense of the word. The -8 world of OS/8, etc. has no special distinction for read-only devices, and thus can't even be created for such a device as a bootable system media. The basics of OS/8 operation require that a "sacred" portion of the system be available for swapping at all times, so a read-only device could merely produce a prompt and then be incapable of doing anything. Purists may note that it is possible to use the "R" command under contrived circumstances as long as the executed program doesn't reference *ANY* OS/8 services. I myself wrote read-only tape-bound systems on magtape used to serially load in applications programs without OS/8 because of this kind of restriction. Several people even wrote block-replaceable magtape systems by creating blocks isolated by wide gaps that could be more or less guaranteed to not encroach on neighboring blocks as long as nothing crashed. Throughput was awful, but was theoretically viable. In any case, the TU60 is not capable of this kind of thing, and only holds a pitiful amount of data in strictly sequential form anyway. To help out here, DEC wrote two operating systems for the beast called CAPS (CAssete Programming System) on both the -11 and the -8. They were file compatible and strictly serial. OS/8 has a support program called MCPIP expressly designed to work with this stuff. I believe the directory is the last record before an end-of-tape condition, so as the storage grows, the directory is pushed down towards the physical end of medium. Perhaps other schemes are used, such as the directory is the first record and the entire device is always re-written when updated. This has the advantage of faster directory listing. In any case, deleting a file is a major chore. I believe that any editing or updating of the contents is accomplished by creating an appropriately modified descendent of the tape on the other drive and then discarding the original (the backup tape :-) A modified version of PAL8 and BASIC are the only two languages I am aware of on CAPS-8; there could be a few others, but the more "standard" OS/8 cusps were never "ported" to CAPS-8. Standard extensions include .PAL, .BIN and .BAS. For compatibility with CAPS-11, the files are in 6.3 notation like RT-11, not 6.2 as in OS/8. As a program restriction (read bad kludge here) MCPIP cannot uniquely determine the extension's third character, and can only write third character nulls in the extension; woe unto those that write files anomolous this way! This TU60 discussion started because of a posting for assistance by someone both on pdp8-lovers and on comp.sys.dec.micro. The actual user (off the net) contacted me by phone directly since my phone number is well published due to KERMIT-12 and DECUS connections, so we thank any and all persons attempting to hook us up, but it was done "off-line" and is in progress. I have already mailed out the appropriate disks. cjl (lasner@watsun.cc.columbia.edu) Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 24 Jan 91 22:51:52 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 24 Jan 91 22:49:18 EST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA17151; Thu, 24 Jan 91 22:34:54 EST From: rs@ai.mit.edu (Robert E. Seastrom) Received: by rice-chex (4.1/AI-4.10) id AA04598; Thu, 24 Jan 91 22:34:50 EST Date: Thu, 24 Jan 91 22:34:50 EST Message-Id: <9101250334.AA04598@rice-chex> To: pdp8-lovers@ai.mit.edu Subject: 12's on the left coast From: rs@ai.mit.edu (Robert E. Seastrom) Date: Thu, 24 Jan 91 22:34:50 EST To: pdp8-lovers@ai.mit.edu Subject: 12's on the left coast Cribbed from comp.sys.dec on abUsenet: From: aek@Apple.COM (Al Kossow) Newsgroups: comp.sys.dec,misc.forsale.computers Date: 24 Jan 91 22:36:39 GMT Distribution: usa Organization: Advanced Technology Group, Apple Computer, Cupertino CA I was just over at one of the bigger surplus stores in the Bay Area, and spotted two PDP-12's. If anyone is interested, give Roger Warren a call at Surplus Solutions (408) 434-0168. I wouldn't normally bother with this, but I haven't seen a '12 in a LONG time, and thought someone out there might want one.. -- Al Kossow @ Apple Computer, Inc., Cupertino, CA Internet: aek@apple.com Phone: (408) 974-5136