From Huwaert@chex.ucl.ac.be Wed Mar 2 11:42:43 EST 1994 Article: 667 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!EU.net!ub4b!info-sparc1.info.ucl.ac.be!huwaert From: huwaert@info-sparc1.info.ucl.ac.be (Christian Huwaert) Subject: Looking for PDP-11 info Message-ID: <1994Mar1.114906.27625@info.ucl.ac.be> Sender: news@info.ucl.ac.be (News Administrator) Nntp-Posting-Host: lewsun Reply-To: Huwaert@chex.ucl.ac.be Organization: Faculty of Medicine, Catholic University of Louvain (Belgium) X-Newsreader: Tin 1.1 PL3 Date: Tue, 1 Mar 1994 11:49:06 GMT Lines: 19 Hi everybody Does anybody know where I can find info about PDP-11 (and more particularly RSX-11M+) stuff on the internet. I apologize if this is the wrong group to post my question but this is the closest group I've found... (and I am quite new at this...) My problem is that I must face an old PDP-11 at work and extract a lot of info from it (without the accompanying docs, guru, )... Thanking you in advance... Christian. ---------------------------------- C. Huwaert at Catholic University of Louvain e-mail : Huwaert@chex.ucl.ac.be ---------------------------------- From supnik@ucoder.ljo.dec.com Wed Mar 2 11:42:54 EST 1994 Article: 668 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!koriel!decwrl!pa.dec.com!sousa.ako.dec.com!ucoder.ljo.dec.com!supnik From: supnik@ucoder.ljo.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 1 Mar 1994 19:05:27 GMT Organization: Digital Equipment Corporation Lines: 33 Distribution: world Message-ID: <2l03ln$jl4@sousa.ako.dec.com> References: <2km8fn$53a@krel.iea.com> Reply-To: supnik@ucoder.ljo.dec.com (Bob Supnik) NNTP-Posting-Host: ucoder.ljo.dec.com This is from the PDP8/E Maintenance Manual, Volume 2, Part 1, Extended Arithmetic Element (Description of SAM) 'The "Greater Than" signal is derived as follows: a. If the MQ and the old AC are of different signs, the MQ is greater than the AC if the MQ is positive. The MQ is less than the AC if the MQ is negative. b. If the MQ and the old AC are of the same sign, the MQ is greater than (or equal to) the old AC if the output of the most-significant bit of the adder is positive. Otherwise, the MQ is less than the AC. Logic at the input of the gT flag computes the "Greater Than" signal.' So: L = (unsigned) AC <= (unsigned) MQ gtf = (signed) AC <= (signed) MQ SAM with AC = 1, MQ = 2: L = 1, gtf = 1 SAM with AC = 3, MQ = 2: L = 0, gtf = 0 SAM with AC = 4001, MQ = 2: L = 0, gtf = 1 SAM with AC = 2, MQ = 4001: L = 1, gtf = 0 -- Bob Supnik >Supnik@ucoder.ljo.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From pcg@panix.com Wed Mar 2 11:43:11 EST 1994 Article: 669 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!ddsw1!panix!not-for-mail From: pcg@panix.com (Paul Gallagher) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 2 Mar 1994 01:44:29 -0500 Organization: PANIX Public Access Internet and Unix, NYC Lines: 18 Message-ID: <2l1ckd$49k@panix2.panix.com> References: <2kp7tp$2cb@gazette.bcm.tmc.edu> NNTP-Posting-Host: panix2.panix.com Keywords: PDP-8 PDP8 In <2kp7tp$2cb@gazette.bcm.tmc.edu> guenther@bcm.tmc.edu (Margaretha M. Guenther) writes: >How did the PDP-8 compare to later Micros? I'm curious too. How do they compare in terms of RAM? What's program memory, which is mentioned in the FAQ? Also, what were the common operating systems for the machines? I remember as a kid, back in 1976, learning to program in Basic on some kind of PDP-8. As far as I can remember, this involved starting up the computer by flipping some switches on the machine, then entering the numbered Basic lines at the prompt on the teletype, and storing them on paper tape. It seems like some steps are missing there in my memory, since I don't recall interacting with an operating system at all... Paul pcg@panix.com From roby@ida.org Wed Mar 2 11:43:22 EST 1994 Article: 670 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!gumby!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!proto.ida.org!roby From: roby@ida.org (Clyde Roby) Newsgroups: alt.sys.pdp8 Subject: Re: There is actually PDP8 users out there * STILL * Date: 28 Feb 1994 16:24:14 GMT Organization: IDA, Alexandria, Virginia Lines: 25 Message-ID: <2kt5re$oc0@dmsoproto.ida.org> References: <2kqtfn$bv8@bigblue.oit.unc.edu> NNTP-Posting-Host: csed-115.ida.org Cc: roby@ida.org X-Newsreader: TIN [version 1.2 PL0] Charles Lasner (lasner@sunSITE.unc.edu) wrote: [...stuff deleted...] I don't consider myself a wizard for the LINC-8/PDP-8 line of computers (even though when I was at WVU, we did develop a LINC-8 based OS, based upon LAP-6 (using 8-character tags instead of number-letter tags). This was in 1967 at the WVU Medical Center research labs...wow! : Bonus question of the day: Can anyone explain the reasoning behind the : LINC/LINC-8 instruction ZZZ (which was renamed QLZ in the PDP-12)? (On a : scale of 1-10, this question is worth 8 frames of paper-tape leader/trailer.) The Z register was used for the least significant 11 bits of a fractional multiply (MUL) instruction, getting the Z register with the ZTA (Z to A) instruction. the ZZZ was the Z Zero Skip instruction (Bit 11 of Z=0). I think that it was used for multiple precision arithmetic, e.g., floating point packages, etc. ================================================================ Clyde G. Roby, Research Staff Member Institute for Defense Analyses Phone: (703) 845-6666 1801 N. Beauregard Street FAX: (703) 845-6788/6848 Alexandria, VA 22311-1772 Email: roby@ida.org ================================================================ From jones@pyrite.cs.uiowa.edu Wed Mar 2 11:43:42 EST 1994 Article: 671 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 2 Mar 1994 15:42:49 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 50 Distribution: inet Message-ID: <2l2c5p$7t0@nexus.uiowa.edu> References: <2l1ckd$49k@panix2.panix.com> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2l1ckd$49k@panix2.panix.com>, by pcg@panix.com (Paul Gallagher): >>How did the PDP-8 compare to later Micros? > > I'm curious too. How do they compare in terms of RAM? A PDP-8 without memory management option has a maximum of 4K words (call it 12K bytes). The normal memory management option ups this to 32K words (48K bytes). When you recall that this was sold as a low end machine in the early 1970's, it's not too different from the memory people remember on the original Apple II or the original Altair 8800. In the late 1970's, larger memory expansion options came out, but none ever let you hang a megabyte on the machine, and after the PDP-8/E cpu in 1970, nobody tried to design a faster model. Your average Power PC today can run a PDP-8 emulator faster than any hardware implementation anyone ever sold. > What's program memory, which is mentioned in the FAQ? Grepping the faq for the string "program memory" I find it discussed in the DECmate III+ entry. This machine had two memory banks of 32K words each, one available to application programs and the operating system, and one used by DEC's slushware to emulate hardware functions that were done in software on this model. This took care of, for example, keyboard and screen handling, so that console I/O looked, to the operating system, like a serial line interface to a DEC VT series terminal. If you don't have a DECmate (and I don't), you don't need to worry about this stuff. Even if you do, you're most likely to live with DEC's slushware and confine your hacking to the 32K of program memory. > Also, what were the common operating systems for the machines? DEC's OS-8 (and various renumberings like OS-278) was the only really common operating system, but many others were written, such as TSS-8, a timesharing system. > I remember as a kid, back in 1976, learning to program in Basic on some > kind of PDP-8. ... I don't recall interacting with an operating system > at all... You probably didn't interact with an operating system. DEC sold stand-alone BASIC and FOCAL systems that didn't rest on any operating system. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Wed Mar 2 11:43:55 EST 1994 Article: 672 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 2 Mar 1994 16:19:26 GMT Organization: University of North Carolina, Chapel Hill Lines: 38 Message-ID: <2l2eae$t68@bigblue.oit.unc.edu> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> NNTP-Posting-Host: calypso.oit.unc.edu In article <2l03ln$jl4@sousa.ako.dec.com>, Bob Supnik wrote: > >(Description of SAM) > >L = (unsigned) AC <= (unsigned) MQ >gtf = (signed) AC <= (signed) MQ > >SAM with AC = 1, MQ = 2: L = 1, gtf = 1 >SAM with AC = 3, MQ = 2: L = 0, gtf = 0 >SAM with AC = 4001, MQ = 2: L = 0, gtf = 1 >SAM with AC = 2, MQ = 4001: L = 1, gtf = 0 It works as Bob describes it; I checked it out on my machine with KE8E. I apologize for my mistatement in an earlier post on the subject. What I meant to say was that the greater-than flag itself isn't part of EAE. (Not really very useful without it though! You can load it with RTF, retrieve it with GTF, and skip on it with SGT, but not much else.) Another issue surfaces from this thread: Some people were attempting to apply un-pdp-8-like arguments to explain how it ought to work. The reasoning stems from how *other* machines do it. Curiously enough, SAM works more like other machines, but not because the rest of the -8 architecture does it that way. The specific point is that the -8 does not set the link ever as a result of any operation except the explicit CLL. This isn't a problem because you can micro-code in a CLL or even CLL CML if you need it preset before some operation. But in general, you are looking for a link flip or not, as opposed to it being set as some sort of "condition code". OK, another related question: what is the behavior of the link in the double-precision operations of mode B EAE? cjl From lasner@sunSITE.unc.edu Wed Mar 2 11:44:05 EST 1994 Article: 673 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: There is actually PDP8 users out there * STILL * Date: 2 Mar 1994 16:37:13 GMT Organization: University of North Carolina, Chapel Hill Lines: 57 Message-ID: <2l2fbp$9s7@bigblue.oit.unc.edu> References: <2kqtfn$bv8@bigblue.oit.unc.edu> <2kt5re$oc0@dmsoproto.ida.org> NNTP-Posting-Host: calypso.oit.unc.edu In article <2kt5re$oc0@dmsoproto.ida.org>, Clyde Roby wrote: >Charles Lasner (lasner@sunSITE.unc.edu) wrote: > >[...stuff deleted...] > >I don't consider myself a wizard for the LINC-8/PDP-8 line of computers >(even though when I was at WVU, we did develop a LINC-8 based OS, based >upon LAP-6 (using 8-character tags instead of number-letter tags). >This was in 1967 at the WVU Medical Center research labs...wow! Not a wizard, but at least an old hat! (And one whose name I know! Any of the WVU people still around? I want to put some of the WVU stuff into the sunsite archive. One of the utilities is alleged to be a program to stuff OS/8 files into an OS/8 file.) > >: Bonus question of the day: Can anyone explain the reasoning behind the >: LINC/LINC-8 instruction ZZZ (which was renamed QLZ in the PDP-12)? (On a >: scale of 1-10, this question is worth 8 frames of paper-tape leader/trailer.) > >The Z register was used for the least significant 11 bits of a fractional >multiply (MUL) instruction, getting the Z register with the ZTA (Z to A) >instruction. the ZZZ was the Z Zero Skip instruction (Bit 11 of Z=0). >I think that it was used for multiple precision arithmetic, e.g., floating >point packages, etc. I'll give you six of the 8 paper-tape frames. You missed a key point about the bit notation and the mnemonic itself, which is why it was changed. Neglecting the LINC-8, which was on the fence as to whether to use LINC-originated conventions or to use PDP-8 conventions, the ZZZ symbol originates in the LINC, and was changed to QLZ on the PDP-12. The reason is that the low-order bit of the Z register is *NOT* bit[11], rather it's bit[0]. Yes, the LINC registers are numbered in a non-pdp-8-like way of right to left. (I guess the LINC design comes from an ancient Hebrew text :-).) So, it's ZZZ because it's skip if the Z register bit Zero is Zero. On the PDP-12, there are no separate registers, so the Z register is replaced with the PDP-8's MQ. PDP-8 registers are always numbered left to right (because the PDP-8 design comes from an ancient Hebrew text read in a mirror :-)). So they changed the symbol to QLZ. (skip if "Q" register Low-order bit is Zero) (On the LINC-8, most registers are PDP-8, so the -8-like notation dominates.) > >================================================================ >Clyde G. Roby, Research Staff Member >Institute for Defense Analyses Phone: (703) 845-6666 >1801 N. Beauregard Street FAX: (703) 845-6788/6848 >Alexandria, VA 22311-1772 Email: roby@ida.org >================================================================ cjl From supnik@human.enet.dec.com Fri Mar 4 01:23:10 EST 1994 Article: 674 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 2 MAR 94 19:33:58 Organization: Digital Equipment Corporation Lines: 63 Message-ID: <2l3cn8$d0k@sousa.ako.dec.com> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> <2l2eae$t68@bigblue.oit.unc.edu> NNTP-Posting-Host: human.enet.dec.com Summary: Link behavior varies Keywords: PDP-8, EAE In article <2l2eae$t68@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... > [text deleted] >OK, another related question: what is the behavior of the link in the >double-precision operations of mode B EAE? Working from the EAE maintenance manual. 1. DCM... "The KE8-E disables normal Link gatting and places CARRY OUT L from the adders onto the LINK DATA L line of the OMNIBUS. The Link, AC, and MQ are loaded at the conclusin of each step." In short, 1.1 Swap AC and MQ (because MQA!MQL must be microprogrammed with this instruction; if not included, omit this step) 1.2 L'AC = AC (formerly MQ) ^ 07777 + 1, the link is unconditionally loaded per the above 1.3 Swap AC and MQ again 1.4 L'AC = AC (restored) ^ 07777 + carry in = Link from step 1.2, the link is unconditionally loaded per the above Net effect: if AC'MQ = 0000 0000, L = 1 else L = 0 2. DPIC. Essentially the same as DCM, except the input to the adder in steps 1.2 and 1.4 are not complemented first. Net effect: if AC'MQ = 7777 7777, L = 1 else L = 0 3. DAD. A flow with many interesting side affects. 3.1 "During TS3 of the FETCH cycle, ADLK DIS is grounded, enabling the OMNIBUS LINK DATA and LINK LOAD inputs... since no data was placed on LINK DATA, the Link is cleared." L = 0 3.2 SKIP is asserted, PC = PC + 1 3.3 EN0, CARRY IN, and F D SET are asserted. This causes MA (which pointed at the instruction word) to be incremented, and the location now addressed TREATED AS A DEFERRED OPERAND. That it, it is fetched from memory and used as the ADDRESS of the operand. One consequence of this is that if the second word of the instruction is in locations 0010-0017, it is AUTOINCREMENTED: MA = MA + 1; if ((MA & 07770) = 00010) M[MA] = M[MA] + 1; MA = M[MA]; 3.4 The memory data and MQ are added and the results propagated to the Link and AC. At the same time, the AC is moved to the MQ. Because the Link is cleared, this in effect unconditionally loads the Link with the carry: MQ = AC; L'AC = M[MA] + old MQ + Link (0 due to step 3.1); 3.5 MA is now incremented to point to the next word, and the operation is repeated: MA = MA + 1; MQ = AC (low order result of add from step 3.4); L'AC = M[MA] + old MQ (original AC) + Link (carry out from 3.4) Net effect: L'AC'MQ = (AC'MQ) + (M[MA+1]'M[MA]); 4. DST. The Link is unchanged. DST shares with DAD the odd use of DEFER state (so do MUY and DVI in mode B). "It's just this little chromium switch over here..." Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From bqt@Krille.Update.UU.SE Fri Mar 4 01:27:15 EST 1994 Article: 675 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!pipex!uknet!EU.net!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 3 Mar 1994 15:59:02 +0100 Organization: Update Computer Club Lines: 63 Message-ID: <2l4u04$lfd@Krille.Update.UU.SE> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> <2l2eae$t68@bigblue.oit.unc.edu> NNTP-Posting-Host: krille.update.uu.se In <2l2eae$t68@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article <2l03ln$jl4@sousa.ako.dec.com>, >Bob Supnik wrote: >> >>(Description of SAM) >> >>L = (unsigned) AC <= (unsigned) MQ >>gtf = (signed) AC <= (signed) MQ >> >>SAM with AC = 1, MQ = 2: L = 1, gtf = 1 >>SAM with AC = 3, MQ = 2: L = 0, gtf = 0 >>SAM with AC = 4001, MQ = 2: L = 0, gtf = 1 >>SAM with AC = 2, MQ = 4001: L = 1, gtf = 0 >It works as Bob describes it; I checked it out on my machine with KE8E. Interesting. Then it seems as the link is set if there isn't a borrow. Could this mean that they start out by setting the link, and then use Link + MQ as a 13-bit number which they substract AC from? Thereby being sure that the substract never really overflows. Hmmm, sounds like a nice way to do it anyway. >I apologize for my mistatement in an earlier post on the subject. What I >meant to say was that the greater-than flag itself isn't part of EAE. >(Not really very useful without it though! You can load it with RTF, >retrieve it with GTF, and skip on it with SGT, but not much else.) >Another issue surfaces from this thread: >Some people were attempting to apply un-pdp-8-like arguments to explain >how it ought to work. The reasoning stems from how *other* machines do >it. Curiously enough, SAM works more like other machines, but not >because the rest of the -8 architecture does it that way. >The specific point is that the -8 does not set the link ever as a result >of any operation except the explicit CLL. This isn't a problem because >you can micro-code in a CLL or even CLL CML if you need it preset before >some operation. But in general, you are looking for a link flip or not, >as opposed to it being set as some sort of "condition code". Yes, that is the fact in the normal instructions, but this was the EAE. And (I assume you a referring to my reasonings) I didn't really take it from how other machines work, but from how hardware work. (In my reasonings.) I then, in another posting, made a comparision with how other machines work, so people who might think things are strange in the 8, because of the names of things, might get a grasp. >OK, another related question: what is the behavior of the link in the >double-precision operations of mode B EAE? Just like the SAM. Link indicates overflow. Clear if no overflow, set if there is. So, no toggle there. (Only instruction which might affect Link is DAD, DPIC and DCM.) Johnny -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From pcg@panix.com Fri Mar 4 01:47:25 EST 1994 Article: 676 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!news.intercon.com!panix!not-for-mail From: pcg@panix.com (Paul Gallagher) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 3 Mar 1994 23:53:18 -0500 Organization: PANIX Public Access Internet and Unix, NYC Lines: 19 Distribution: inet Message-ID: <2l6eru$qht@panix2.panix.com> References: <2l1ckd$49k@panix2.panix.com> <2l2c5p$7t0@nexus.uiowa.edu> NNTP-Posting-Host: panix2.panix.com In <2l2c5p$7t0@nexus.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > You probably didn't interact with an operating system. DEC sold > stand-alone BASIC and FOCAL systems that didn't rest on any > operating system. Thank you very much for the help. You're probably right about this. I found this in the FAQ: POLY BASIC was a BASIC only system submitted to DECUS and later sold by DEC as part of its EduSystem marketing program. I wonder how much that cost. That's a very limited machine! I went to school in Concord, Mass., which is right next to Maynard, the home of Digital, so we may have received the computers as a gift. Paul pcg@panix.com From lasner@sunSITE.unc.edu Fri Mar 4 01:47:34 EST 1994 Article: 677 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 4 Mar 1994 06:22:23 GMT Organization: University of North Carolina, Chapel Hill Lines: 47 Message-ID: <2l6k2v$rqc@bigblue.oit.unc.edu> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> <2l2eae$t68@bigblue.oit.unc.edu> <2l3cn8$d0k@sousa.ako.dec.com> NNTP-Posting-Host: calypso-2.oit.unc.edu Keywords: PDP-8, EAE In article <2l3cn8$d0k@sousa.ako.dec.com>, Bob Supnik wrote: > >In article <2l2eae$t68@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >> [text deleted] >>OK, another related question: what is the behavior of the link in the >>double-precision operations of mode B EAE? DCM: > Net effect: if AC'MQ = 0000 0000, L = 1 else L = 0 So, the L is loaded, not flipped while CIA would merely flip the L. DPIC: > Net effect: if AC'MQ = 7777 7777, L = 1 else L = 0 So, again the L is loaded while IAC would flip the L. DAD: > Net effect: L'AC'MQ = (AC'MQ) + (M[MA+1]'M[MA]); As usual, the L is loaded while TAD would flip it. Also, when 0010-0017 are referenced in the deferred state as pointers, the expected PDP-8-like action is taken; they become auto-increment registers. This means the instruction in placed into 0007-0016 so the in-line pointer is in 0010-0017. One of the KE8E diagnostics actually checks this case! >4. DST. The Link is unchanged. DST shares with DAD the odd use of > DEFER state (so do MUY and DVI in mode B). Not really odd at all. It allows a useful 32K addressing space set of DP instructions. I'd like to start some related topics: Some of the DP instructions demand that the MQA and MQL bits be set. What actually happens when one or both is left out? Are any of these "useful"? Wasn't there some documentation screwup on one of the DP instructions, I think DPSZ (double-precision skip if zero)? (It could have been related to some aspect of this requirement of MQA and/or MQL.) > >"It's just this little chromium switch over here..." Please expand on that reference! cjl From lasner@sunSITE.unc.edu Fri Mar 4 01:47:40 EST 1994 Article: 678 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 4 Mar 1994 06:26:40 GMT Organization: University of North Carolina, Chapel Hill Lines: 10 Message-ID: <2l6kb0$aik@bigblue.oit.unc.edu> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> <2l2eae$t68@bigblue.oit.unc.edu> <2l4u04$lfd@krille.update.uu.se> NNTP-Posting-Host: calypso-2.oit.unc.edu In article <2l4u04$lfd@krille.update.uu.se>, Johnny Billquist wrote: > (Only instruction which might affect >Link is DAD, DPIC and DCM.) Don't forget DVI! L set if divide overflow, clear if not. (Not a DP instruction!) cjl From lasner@sunSITE.unc.edu Fri Mar 4 01:47:49 EST 1994 Article: 679 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 4 Mar 1994 06:47:11 GMT Organization: University of North Carolina, Chapel Hill Lines: 81 Message-ID: <2l6lhf$hmt@bigblue.oit.unc.edu> References: <2l1ckd$49k@panix2.panix.com> <2l2c5p$7t0@nexus.uiowa.edu> <2l6eru$qht@panix2.panix.com> NNTP-Posting-Host: calypso-2.oit.unc.edu In article <2l6eru$qht@panix2.panix.com>, Paul Gallagher wrote: >In <2l2c5p$7t0@nexus.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >> You probably didn't interact with an operating system. DEC sold >> stand-alone BASIC and FOCAL systems that didn't rest on any >> operating system. > >Thank you very much for the help. You're probably right about this. I >found this in the FAQ: > >POLY BASIC was a BASIC only system submitted to DECUS and later > sold by DEC as part of its EduSystem marketing program. > >I wonder how much that cost. That's a very limited machine! I went to >school in Concord, Mass., which is right next to Maynard, the home of Digital, >so we may have received the computers as a gift. > >Paul >pcg@panix.com > > I can't comment on DEC's pricing or gifting, but I can give some background on the development of POLY BASIC which was done while I was at POLY itself. The original POLY BASIC was attempted as a system program on the original R-L Monitor System (aka MS/8, the forerunner of P?S/8). It was not entirely successful because of limitations of the system that aren't useful to BASIC in its extended form: R-L files consist of text in sequential form without line numbers much like any other system. However, there are also line numbers stored at the back end of the files in binary form. They are paired with pointers to the text they pertain to. R-L utilities can choose to ignore the line-number info or retain it as necessary. Of course in BASIC, the numbers are quite integral to the program. An ugly solution would have been to have *double* line numbers: 100 100 REM LINE 100 110 110 PRINT "INFINITE LOOP" 120 120 GOTO 100 130 130 END The reason this is necessary is that POLY BASIC supports EDIT RESEQUENCE where the line numbers are resequenced in nice neat increments (by 10) and all of the references in the program context are changed accordingly. It would become quite unweildy to hinge this on the binary line numbers at the back of the file, since this would make the input to the compiler dependent on the entire file, as opposed to sequential buffers of the input files, etc. Thus, a decision was reached to make POLY BASIC a stand-alone system. The file format is straight text including the digits of the line numbers. All versions of POLY BASIC were developed on and for a 4K PDP-8 with a TC01 and a TU55 DECtape. (This is also the minimum configuration for MS/8 and also P?S/8.) Eventually, after it all worked, it was taken to Digital where support was added for other devices. (It was the first time that Richard Lary and Lenny Elekman had access to these other devices such as RF08, etc.) Eventually, in a move not everyone believes is ethical, DEC sold this software after it was submitted to DECUS. They changed the name to EDU-System 30. There was also a version called EDU 15/30. It could run on a TD8E using either the MR8E-C ROM and KM8E (to access the field 7 ROM) or 8K. (Creating the system put an altered image of teh ROM into field 1 and built a system that depended on it. Overall, there was dependance on the non-volatility of core.) A feature DEC added on was the ability to read mark-sense punch cards. In some instances, non-standard marks were made to stand for entire tokens such as PRINT, etc. This allows a school system to trade student tedium of hand-marking cards for individualized editing of files and limited disk space. All in all, POLY BASIC shows just what can be done with a 4K machine given a reasonable set of peripherals etc. cjl From jones@pyrite.cs.uiowa.edu Fri Mar 4 11:48:01 EST 1994 Article: 680 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 4 Mar 1994 15:43:43 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 14 Distribution: inet Message-ID: <2l7kvf$gvf@nexus.uiowa.edu> References: <2l6eru$qht@panix2.panix.com> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2l6eru$qht@panix2.panix.com>, by pcg@panix.com (Paul Gallagher): > > POLY BASIC was a BASIC only system submitted to DECUS and later > sold by DEC as part of its EduSystem marketing program. > > I wonder how much that cost. Entry level EduSystems always sold for under $10,000 dollars. I've got a letter from DEC to an old professor of mine (now dead) dating to about 1972, offering him an entry-level EduSystem, based on a PDP-8/E, for about 7500 dollars, including teletype, FOCAL and BASIC. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Fri Mar 4 11:48:49 EST 1994 Article: 681 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: What's a PDP-8? Date: 4 Mar 1994 16:47:42 GMT Organization: University of North Carolina, Chapel Hill Lines: 60 Message-ID: <2l7one$6gs@bigblue.oit.unc.edu> References: <2l6eru$qht@panix2.panix.com> <2l7kvf$gvf@nexus.uiowa.edu> NNTP-Posting-Host: calypso-2.oit.unc.edu In article <2l7kvf$gvf@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article <2l6eru$qht@panix2.panix.com>, by pcg@panix.com (Paul Gallagher): >> >> POLY BASIC was a BASIC only system submitted to DECUS and later >> sold by DEC as part of its EduSystem marketing program. >> >> I wonder how much that cost. > >Entry level EduSystems always sold for under $10,000 dollars. I've got >a letter from DEC to an old professor of mine (now dead) dating to about >1972, offering him an entry-level EduSystem, based on a PDP-8/E, for about >7500 dollars, including teletype, FOCAL and BASIC. > > Doug Jones > jones@cs.uiowa.edu Not good enough. Neglecting the cost of the software, we are talking about adding on at least a TD8E with TU56H, KM8E, MR8E-C in the most minimal EDU-15/30 system. And it was geared towards classrooms encouraged to add on mark-sense card capabilities so we include a CR8E (CR8F? I think that's what they call a mark-sense version of the card reader). EDU 30 systems are more money still because it requires either TC01/08 and TU55/56 or DF32 or RF08 (or to be run on a PDP-12 LINCtape system). (Or an obscure hack: 32K "RAM" disk in core.) EDU 15/30 was brought out because of the TD8E being less money than any of the above. The only actual difference between 15/30 and 30 is the disk device support was excised out and replaced with a two-choice routine: MR8E-C ROM in field 7 or a "fake" copy of the ROM in field 1. Either method requires extended memory control (M837 or KM8E). Other than the faked-out device handling analogous to the equivalent in OS/8 and P?S/8, this is a strictly 4K system. However, it is capable of running significently larger programs than 4K-BASIC or FOCAL because it's a true compiler. Only user code and a run-time are in memory after the compiler has done its work. Additionally, it's not any form of interpreter in any sense (generates code, not tokens). The compiler is itself more than 4K as it swaps parts of itself in. The editor is about 2K and has overlays for the various functions such as edit resequence. User files and the editor occupy 4K. Edit resequence brings in the resequencer code over the editor and updates the user file in place. Then the editor is swapped back in, etc. The RUN command writes the user file to a dedicated scratch space. The compiler comes in and reads in the user file in several passes. Segments of the compiler are called in to parse as necessary. The net result is a binary file (incidentally compatible with MS/8 and P?S/8 internally!) written to a dedicated scratch space. IF there are no errors, the run-time system is loaded and the user's binary overlays the run-time system which then executes the stack of user code, etc. While most of the run-time system is resident during execution, there are a few swappable routines where the run-time is required to execute seldom-needed routines, etc. So, this is "somewhat" more than the minimal 4K FOCAL and BASIC systems! cjl From roby@ida.org Sat Mar 5 09:31:16 EST 1994 Article: 682 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!proto.ida.org!roby From: roby@ida.org (Clyde Roby) Newsgroups: alt.sys.pdp8 Subject: Re: There is actually PDP8 users out there * STILL * Date: 4 Mar 1994 17:49:35 GMT Organization: IDA, Alexandria, Virginia Lines: 31 Message-ID: <2l7sbf$ppe@dmsoproto.ida.org> References: <2kqtfn$bv8@bigblue.oit.unc.edu> <2kt5re$oc0@dmsoproto.ida.org> <2l2fbp$9s7@bigblue.oit.unc.edu> NNTP-Posting-Host: csed-115.ida.org X-Newsreader: TIN [version 1.2 PL0] Charles Lasner (lasner@sunSITE.unc.edu) wrote: : Not a wizard, but at least an old hat! (And one whose name I know! Any : of the WVU people still around? I want to put some of the WVU stuff into : the sunsite archive. One of the utilities is alleged to be a program to : stuff OS/8 files into an OS/8 file.) None of them are still at WVU as far as I know. Last word on some of them are -- Tom McIntyre lives in the Harvard, MA area working for his son's company as a consultant (Tom used to work for DEC at one time); Larry Pearson used to work at DEC, too, but I think is a consultant, too; Darrell Duffy used to work for DEC but is now in the Silicon Valley area of California. Jerry Farmer used to live in the Huntington area of WV last time I heard (over a decade ago). I don't think anyone would mind your putting the WVU stuff into the sunsite archive. Yea, the WVU gang used to do a lot of little utilities for the PDP-12 and PDP-8 after we had worked on the LINC-8 for awhile. Maybe someone from WVU can respond -- anybody down at the Computer Center, at the CS Department, or even at the Med Center -- how about it? ================================================================ Clyde G. Roby, Research Staff Member Institute for Defense Analyses Phone: (703) 845-6666 1801 N. Beauregard Street FAX: (703) 845-6788/6848 Alexandria, VA 22311-1772 Email: roby@ida.org ================================================================ From supnik@human.enet.dec.com Sat Mar 5 09:32:24 EST 1994 Article: 683 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 3 MAR 94 21:46:51 Organization: Digital Equipment Corporation Lines: 27 Message-ID: <2l67ls$7r1@sousa.ako.dec.com> References: <2km8fn$53a@krel.iea.com> <2l03ln$jl4@sousa.ako.dec.com> <2l2eae$t68@bigblue.oit.unc.edu> <2l4u04$lfd@Krille.Update.UU.SE> NNTP-Posting-Host: human.enet.dec.com In article <2l4u04$lfd@Krille.Update.UU.SE>, bqt@Krille.Update.UU.SE (Johnny Billquist) writes... > [text deleted] >Interesting. Then it seems as the link is set if there isn't a >borrow. Could this mean that they start out by setting the link, >and then use Link + MQ as a 13-bit number which they substract >AC from? >Thereby being sure that the substract never really overflows. >Hmmm, sounds like a nice way to do it anyway. No, it's done by complementing the subtrahend and setting carry in = 1. In C terms: L'AC = MQ + (AC ^ 07777) + 1 Thus, if MQ = 2, and AC = 1, the calculation is 2 + 7776 + 1 = 1'0001; if MQ = 2 and AC = 3, the calculation is 2 + 7774 + 1 = 0'7777. There's no borrow calculation, only a carry from the add. This is how most of the early minis, including the NOVA, worked. The PDP-11 created a "true" borrow by placing logic between the adder carry and the condition codes. For add, PSL.C = adder carry, but for subtract, PSL.C = ~adder carry. Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From Kevin@kmurrell.demon.co.uk Sat Mar 5 09:57:12 EST 1994 Article: 684 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 From: Kevin@kmurrell.demon.co.uk (Kevin Murrell) Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!insosf1.infonet.net!convex!convex!cs.utexas.edu!howland.reston.ans.net!pipex!demon!kmurrell.demon.co.uk!Kevin Subject: Past News Organization: Myorganisation Reply-To: Kevin@kmurrell.demon.co.uk X-Newsreader: Demon Internet Simple News v1.27 Lines: 7 Date: Sat, 5 Mar 1994 10:02:02 +0000 Message-ID: <762861722snz@kmurrell.demon.co.uk> Sender: usenet@demon.co.uk Recently someone posted a note with the ftp address of all the past news in this group. Can anyone re-post for me? Have PDP8 Mk 1 and PROUD of it! -- Kevin Murrell From lasner@sunSITE.unc.edu Sat Mar 5 09:57:27 EST 1994 Article: 685 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Past News Date: 5 Mar 1994 14:56:59 GMT Organization: University of North Carolina, Chapel Hill Lines: 73 Message-ID: <2la6jr$fqr@bigblue.oit.unc.edu> References: <762861722snz@kmurrell.demon.co.uk> NNTP-Posting-Host: calypso-2.oit.unc.edu In article <762861722snz@kmurrell.demon.co.uk>, Kevin Murrell wrote: >Recently someone posted a note with the ftp address of all the past >news in this group. Can anyone re-post for me? > >Have PDP8 Mk 1 and PROUD of it! ^^^^ What exactly is a "Mk 1"? (or do you just mean an original -8? There are others with them!) > >-- >Kevin Murrell There are now several -8 archives of sorts. I am the librarian for the one on sunsite.unc.edu in the directory: /pub/academic/computer-science/history/pdp-8 and lower directories, etc. Within there is ....../pdp-8/usenet/alt.sys.pdp8 which has the archives of alt.sys.pdp8 from inception through last month. I also understand that through defective propagation there is at least one "splinter" of a.s.p carried only in au. I would appreciate someone sending me that feed so I can add in the au-only articles where appropriate, etc. (All Ozzies please step forward!) Does anyone know the current status of Eric Smith, (former?) maintainer of a similar archive on ftp.telebit.com? There is also an archive maintained by Johnny Billquist and a more recent one started up by Jeff Russ. To my knowledge, mine is the only one archiving the newsgroup. More recently, I have started on a longer-term project which is to archive the pdp8-lover's mailing list, which many of our subscribers are on also. So far, I am "all the way up" to May, 1989! I am sorting through several independent sets of hand-maintained archives. In all probability, just about all of the articles will be available assuming that the "gaps" in each set don't overlap, etc. If anyone wants to contribute any of this material they have been privately maintaining, please e-mail me as lasner@sunsite.unc.edu on this topic. The archive will be storing both a.s.p and the lover's list in files by months. For example, 8904.lov is the pdp8-lovers list for April, 1989. The most recent a.s.p file is 9402.asp which is the archive for alt.sys.pdp8 for February, 1994. Please e-mail me if you have any pdp-8 or DECmate relevant stuff. The archive will accept any useful material. This includes disk/disk-images, graphics/picture files, binary paper-tape files, source files, operating systems, etc. Various people have appropriate media conversion facilities, so don't worry if you believe you have stuff on media you can't currently read; chances are someone else can read it and get it back to you on something else you can deal with, etc. Towards the previous end, I need some help myself! Does anyone know anything about PDP-11/TC-11 DECtapes used on PDP-11 unix systems? Alledgedly, these tapes were maintained by a facility named "tp" some moons ago. If I had to guess, I would say that "tp" borrows some ideas from "tar" and some from the RT-11 style of tape layout. I can physically read the tapes, as they are of course PDP-6/10/7/9/15/11 standard physical format. But I need next-level structure info on block layout, etc. in order to retrieve some source files for someone who would be overjoyed if we can do it! (If anyone is running unix on an -11 and can directly handle this, I can send a copy of the DECtapes (2 of them in all) to them real easily as they can be trivially copied on the -8 with TC08 using DTCOPY.) cjl From mccrohan@iol.ie Sat Mar 5 23:54:11 EST 1994 Article: 686 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: mccrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: re: Looking for PDP-11 info Date: 5 Mar 1994 18:59:42 -0000 Organization: Ireland On-Line Lines: 12 Message-ID: <2lakqu$5f3@ulysses.iol.ie> NNTP-Posting-Host: ulysses.iol.ie hf> hf>Does anybody know where I can find info about PDP-11 (and more particularly hf>RSX-11M+) stuff on the internet. hf> alt.sys.pdp11 ....vmsnet.pdp11 --- þ KingQWK 1.05 þ -- foo From guenther@bcm.tmc.edu Tue Mar 8 13:51:57 EST 1994 Article: 687 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!bcm!bcm.tmc.edu!guenther From: guenther@bcm.tmc.edu (Margaretha M. Guenther) Newsgroups: alt.sys.pdp8 Subject: PDP-8 in Space? Date: 7 Mar 1994 01:16:01 GMT Organization: Baylor College of Medicine, Houston, Tx Lines: 19 Message-ID: <2ldv8h$ka2@gazette.bcm.tmc.edu> NNTP-Posting-Host: bcm.tmc.edu Keywords: PDP8, PDP-8, SPACE Here's a dumb question: Just how State-of-the-art is the PDP-8 ? Are they in Space? My husband gets a "Newsletter" from National Instruments in Austin, TX. The Sring '94 edition has a drawing (I only look at the pictures) of an experiment in the Space Shuttle Columbia in October '93 (p 11). In this drawing there's a panel in the wall marked "PDP-8 Computer controlling experiment hardware and downlink." I thought that the PDP-8 was an *old* and *heavy* computer with a Teletype for input? Was that a misprint, or is there really a PDP-8 in Space? Meg. ________________?(^v^)?______________________________ From supnik@human.enet.dec.com Tue Mar 8 13:53:17 EST 1994 Article: 688 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!hookup!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 6 MAR 94 22:44:06 Organization: Digital Equipment Corporation Lines: 26 Message-ID: <2le7q6$8mm@sousa.ako.dec.com> NNTP-Posting-Host: human.enet.dec.com Summary: If SWP missing, la deluge Keywords: DPIC-, DCM- >lasner@sunsite.unc.edu asked >How do DCM and DPIC behave if the SWP is not included with them? 1. DCM... a L'AC = AC ^ 07777 + 1, the link is unconditionally loaded b Swap AC and MQ c L'AC = AC ^ 07777 + carry in = Link from step a net: MQ = - AC L'AC = ~(old MQ) + (new MQ == 0) 2. DPIC... a L'AC = AC + 1, the link is unconditionally loaded b Swap AC and MQ c L'AC = AC + carry in = Link from step a net: MQ = AC + 1 L'AC = old MQ + (new MQ == 0) The little chromium switch is from the beginning of the Firesign Theatre's "Don't Crush That Dwarf, Hand Me The Plyers" Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From magnus@thep.lu.se Tue Mar 8 14:23:15 EST 1994 Article: 689 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!sunic!news.lth.se!news.lu.se!magnus From: magnus@thep.lu.se (Magnus Olsson) Subject: POLY BASIC (was: What's a PDP-8?) Message-ID: <1994Mar7.180132.15834@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: lena.thep.lu.se Organization: Dept. of Theoretical Physics, Lund University, Lund, Sweden References: <2l1ckd$49k@panix2.panix.com> <2l2c5p$7t0@nexus.uiowa.edu> <2l6eru$qht@panix2.panix.com> <2l6lhf$hmt@bigblue.oit.unc.edu> Date: Mon, 7 Mar 1994 18:01:32 GMT Lines: 37 Xref: bigblue.oit.unc.edu alt.sys.pdp8:689 alt.folklore.computers:60161 In article <2l6lhf$hmt@bigblue.oit.unc.edu>, Charles Lasner wrote: >R-L files consist of text in sequential form without line numbers much >like any other system. However, there are also line numbers stored at >the back end of the files in binary form. They are paired with pointers >to the text they pertain to. R-L utilities can choose to ignore the >line-number info or retain it as necessary. Of course in BASIC, the >numbers are quite integral to the program. An ugly solution would have >been to have *double* line numbers: > >100 100 REM LINE 100 >110 110 PRINT "INFINITE LOOP" >120 120 GOTO 100 Wouldn't the obvious solution have been to dispense with Basic's using line numbers as labels (which has always appeared as sort of a kluge to me) and introduce Fortran-style labels instead? That would make your example look like 100 REM THIS LINE DOESN'T NEED ANY LABEL 110 10 PRINT "INFINITE LOOP" 120 GOTO 10 instead, and the programs would not only be more readable but also the renumbering problem would go away. Of course, modern Basics have chosen this direction (but with alphanumeric labels rather than just numeric ones). But I suppose that you had compatibility with other Basics (that all used line numbers back then) as a design goal? Pity, since you might have made the "modern Basic" revolution happen a few years earlier... Magnus Olsson | \e+ /_ Department of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< magnus@thep.lu.se, thepmo@selund.bitnet | / \===== g PGP key available via finger or on request | /e- \q From steveq@swifty.dap.CSIRO.AU Tue Mar 8 14:30:43 EST 1994 Article: 690 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!swrinde!sgiblab!munnari.oz.au!news.uwa.edu.au!dmsperth.per.dms.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!steveq From: steveq@swifty.dap.CSIRO.AU (Stephen Quigg) Subject: Re: Past News Message-ID: Sender: news@syd.dms.CSIRO.AU Nntp-Posting-Host: swifty.dap.csiro.au Organization: CSIRO, Division of Applied Physics, Sydney References: <762861722snz@kmurrell.demon.co.uk> <2la6jr$fqr@bigblue.oit.unc.edu> Date: Sun, 6 Mar 1994 22:50:07 GMT Lines: 19 In article <2la6jr$fqr@bigblue.oit.unc.edu>, Charles Lasner wrote: >I also understand that through defective propagation there is at least >one "splinter" of a.s.p carried only in au. I would appreciate someone >sending me that feed so I can add in the au-only articles where >appropriate, etc. (All Ozzies please step forward!) > The problem was stuff not getting into or out of Oz, although stuff that was cross-posted found it's way back into a.s.p. This problem went away as of Dec '93; notice that this is an a.s.p only post, and it comes from Oz. cheers, Steve "is it my '8 collection growing or my garage shrinking" Quigg. P.S. The rumor that DECtapes run the other way in the Southern Hemisphere are largely untrue!! From vengeance@vax1.mankato.msus.edu Tue Mar 8 14:31:01 EST 1994 Article: 691 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!ulowell!MathWorks.Com!panix!zip.eecs.umich.edu!umn.edu!msus1.msus.edu!vax1.mankato.msus.edu!vengeance Newsgroups: alt.sys.pdp8 Subject: Omaha Project Message-ID: <1994Mar8.081453.2271@vax1.mankato.msus.edu> From: vengeance@vax1.mankato.msus.edu Date: 8 Mar 94 08:14:53 -0500 Organization: Mankato State University Lines: 9 I am trying to build a list of names and E-Mail addresses of people in the Omaha Nebraska area for a school related project. If you live in Omaha or go to school there or know someone that does and will be around for three months or more, please reply via E-Mail to Vengeance@vax1.mankato.msus.edu. Thank you very much! Ryan Krueger From lasner@sunSITE.unc.edu Tue Mar 8 14:31:26 EST 1994 Article: 692 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: POLY BASIC (was: What's a PDP-8?) Date: 8 Mar 1994 19:22:52 GMT Organization: University of North Carolina, Chapel Hill Lines: 102 Message-ID: <2lijac$k2m@bigblue.oit.unc.edu> References: <2l1ckd$49k@panix2.panix.com> <2l6eru$qht@panix2.panix.com> <2l6lhf$hmt@bigblue.oit.unc.edu> <1994Mar7.180132.15834@nomina.lu.se> NNTP-Posting-Host: 152.2.22.81 Xref: bigblue.oit.unc.edu alt.sys.pdp8:692 alt.folklore.computers:60242 In article <1994Mar7.180132.15834@nomina.lu.se>, Magnus Olsson wrote: >In article <2l6lhf$hmt@bigblue.oit.unc.edu>, >Charles Lasner wrote: >>R-L files consist of text in sequential form without line numbers much >>like any other system. However, there are also line numbers stored at >>the back end of the files in binary form. They are paired with pointers >>to the text they pertain to. R-L utilities can choose to ignore the >>line-number info or retain it as necessary. Of course in BASIC, the >>numbers are quite integral to the program. An ugly solution would have >>been to have *double* line numbers: >> >>100 100 REM LINE 100 >>110 110 PRINT "INFINITE LOOP" >>120 120 GOTO 100 > >Wouldn't the obvious solution have been to dispense with Basic's >using line numbers as labels (which has always appeared as sort of a kluge >to me) and introduce Fortran-style labels instead? That would make your >example look like > >100 REM THIS LINE DOESN'T NEED ANY LABEL >110 10 PRINT "INFINITE LOOP" >120 GOTO 10 > >instead, and the programs would not only be more readable but also >the renumbering problem would go away. We are mixing a discussion up here. 1) The model for BASIC back that far was GE-235 BASIC. It worked as POLY BASIC imitated. In that kind of system, the line numbers can't be dispensed with because of the integrated editing environment. In the R-L/P?S/8 kind of system, you can go either way. But to accede to the R-L line numbers means to have to depend on them when required. Since the numbers are stored at the back end of the file, you have to read in the text and numbers into two different buffers and independently work with them whenever a resequence is required. Remember, this a 4K total system! Of course it could have been done, but would have required a forced writing out of the file, then reading it back in on both ends until the "middle" was reached, then doing another pass on it again, perhaps writing out and then reading in again a detail file that marks all of the areas marked for resequencing, etc. That much swapping would be quite a sight, especially on DECtape! So, they chose to invent a new operating system that worked like the GE system, and the line numbers are stored as plain text characters; the editor requires them. 2) Your method minimizes line-numbers, but hardly eradicates them. In any case, being lock-step with the GE system prevents your suggestions; leaving it on the R-L/P?S/8-type system would have at least allowed for future expansion as you suggest. However, doing so forces the dependency on the binary line numbers at least being allocated for, i.e., BASIC could put up some form of alternate character-oriented editor without enforced line-numbers. Some versions of TECO have had to put up with that nuisance - allowing for the stripping/restoring of line numbers for the benefit of SOS, etc. > >Of course, modern Basics have chosen this direction (but with >alphanumeric labels rather than just numeric ones). But I suppose that >you had compatibility with other Basics (that all used line numbers >back then) as a design goal? Pity, since you might have made the >"modern Basic" revolution happen a few years earlier... Yes, had they been forced into having at least one language component allowed to exist sans line number, then they would have likely stayed within the R-L/P?S/8 guidelines of merely treating line numbers as an artifact of a suggested editor, not a contents enforcement as in POLY BASIC. Additionally, P?S/8 has outgrown the original R-L limitation of files fixed to exactly 2K length with the line-number info at the back end of the file, etc. It is possible to create variable length files similar to OS/8 and pass these to system programs. The trade-off is that the 2K files can be edited in the style of the line-number BASIC without much overhead, even on DECtape-based systems with 4K. The longer files have to be edited using more common techniques with the attendant largely increased tape motion, etc. By the time BASIC was revisited for OS/8, the line numbers are just text in the file. If the language can delete unnecessary line numbers in the text, so be it. (Note: most of the PDP-8 BASIC's were written by the same handful of people!) > > Magnus Olsson | \e+ /_ > Department of Theoretical Physics | \ Z / q > University of Lund, Sweden | >----< > magnus@thep.lu.se, thepmo@selund.bitnet | / \===== g >PGP key available via finger or on request | /e- \q cjl ps: A bootable version of POLY BASIC for TC01/08 DECtape may become available to be placed on sunsite. If so, it can be dealt with by any OS/8 system that can support ENCODE.SV and DECODE.SV. However, it can only be *run* if the hardware includes TC01/08. If anyone can provide alternate bootables (such as TD8E) it can be posted to the archive as well (using my machine to accomplish it). From lasner@sunSITE.unc.edu Tue Mar 8 14:31:39 EST 1994 Article: 693 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Past News Date: 8 Mar 1994 19:30:13 GMT Organization: University of North Carolina, Chapel Hill Lines: 42 Message-ID: <2lijo5$dkl@bigblue.oit.unc.edu> References: <762861722snz@kmurrell.demon.co.uk> <2la6jr$fqr@bigblue.oit.unc.edu> NNTP-Posting-Host: 152.2.22.81 In article , Stephen Quigg wrote: >In article <2la6jr$fqr@bigblue.oit.unc.edu>, >Charles Lasner wrote: > >>I also understand that through defective propagation there is at least >>one "splinter" of a.s.p carried only in au. I would appreciate someone >>sending me that feed so I can add in the au-only articles where >>appropriate, etc. (All Ozzies please step forward!) >> > The problem was stuff not getting into or out of Oz, although stuff that >was cross-posted found it's way back into a.s.p. This problem went away as >of Dec '93; notice that this is an a.s.p only post, and it comes from Oz. Yes, but a.s.p started in Sep '92. I would like to include anything worth archiving in the main collection. I was led to believe that there indeed was some useful stuff, and that it only ever got out on "the backs" of posts to other groups, such as alt.folklore.computers, etc. Thus, there may be some "internal" stuff that should be taken in, etc. BTW, do OZ'er's have ftp access to sunsite.unc.edu? There is an incoming directory for stuff such as this, etc. > >cheers, >Steve "is it my '8 collection growing or my garage shrinking" Quigg. Or both? > >P.S. The rumor that DECtapes run the other way in the Southern Hemisphere are >largely untrue!! No, those are LINCtapes! (Not known as the "LAP-6 Coriollis" effect!) cjl From eweingar@cs.indiana.edu Tue Mar 8 19:33:17 EST 1994 Article: 694 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!swrinde!sgiblab!news.cs.indiana.edu!eweingar@cs.indiana.edu From: "Peter Weingartner" Subject: Re: PDP-8 in Space? Message-ID: <1994Mar8.120846.3218@news.cs.indiana.edu> Keywords: PDP8, PDP-8, SPACE Organization: Computer Science, Indiana University References: <2ldv8h$ka2@gazette.bcm.tmc.edu> Date: Tue, 8 Mar 1994 12:08:41 -0500 Lines: 38 Well, I wasn't going to answer this (since I assumed there were people out there who could answer the space bit [I can't]). Since no one has replied, yet, here are my two cents: In article <2ldv8h$ka2@gazette.bcm.tmc.edu>, Margaretha M. Guenther wrote: >Just how State-of-the-art is the PDP-8 ? Are they in Space? I don't know about the PDP-8 being in space. I've never heard one way or the other. >I thought that the PDP-8 was an *old* and *heavy* computer with a Teletype >for input? Well, the PDP-8 certainly is old, and the original computers certainly would be on the heavy side. There are, however, more modern implementations of the PDP-8 that are smaller and lighter. According to the model FAQ, Intersil made a single chip implementation (the 6100) which was used in the VT78. Certainly, this could have been used in space. Also, using TTL and modern PLD technology, you can implement a PDP-8 on a ciruit board about a foot square (students here at IU do that in our hardware sequence). I believe ('though I haven't had any experience with this), that you could even implement a PDP-8 (without memory) on a single FPGA. I do not know why you'd want to use a PDP-8 in space (perhaps because of its simple instruction set or its time-tested quality :->), but there is no reason you couldn't find a small enough implementation. --pj -- "As I understand it from eyewitness reports, the Scheme initiation ritual is to sit in a circle around the Common Lisp manual and make gagging sounds and jokes about how thick it is." -- Scott E. Fahlman sef+@cs.cmu.edu (It's true.) From lasner@sunSITE.unc.edu Tue Mar 8 19:46:03 EST 1994 Article: 695 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 in Space? Date: 9 Mar 1994 00:45:03 GMT Organization: University of North Carolina, Chapel Hill Lines: 41 Message-ID: <2lj66f$cp5@bigblue.oit.unc.edu> References: <2ldv8h$ka2@gazette.bcm.tmc.edu> <1994Mar8.120846.3218@news.cs.indiana.edu> NNTP-Posting-Host: calzone.oit.unc.edu Keywords: PDP8, PDP-8, SPACE In article <1994Mar8.120846.3218@news.cs.indiana.edu>, Peter Weingartner wrote: >Well, the PDP-8 certainly is old, and the original computers certainly >would be on the heavy side. There are, however, more modern >implementations of the PDP-8 that are smaller and lighter. According >to the model FAQ, Intersil made a single chip implementation (the >6100) which was used in the VT78. Certainly, this could have been used >in space. Also, using TTL and modern PLD technology, you can implement >a PDP-8 on a ciruit board about a foot square (students here at IU do >that in our hardware sequence). I believe ('though I haven't had any >experience with this), that you could even implement a PDP-8 (without >memory) on a single FPGA. The board of a DECmate III is 8" x 10" and that includes two VLSI chips that talk to 10 interfaced devices. The rest of the machine is just metalwork, a power supply, a case, and a pair of floppy drives. Stripped down to a more appropriate minimal system, there is nothing particularly deficient about a 6120-based PDP-8 system in terms of comparable miniaturization to just about any other system. The CPU doesn't really impact on this aspect of size. Peripherals are peripherals, and regardless of processor take up whatever space they need to exist. I once participated in a 6100-based project to produce a hand-held pdp-8 for a special application. It was about the size and shape of a calculator, and indeed, the only peripherals were a calc-type display and minimal keypad. Due to its low power consumption, the CMOS 6100 allowed a smaller battery supply than some other designs. Even the 1970-71 PDP-8/e is basically only a few square feet of boards. The rest is the space to accomodate external memory and many peripherals. The actual single most problematic aspect with regard to miniaturization is really the power supply! So, the largest advance towards miniaturization often lies with the size of the peripherals and power source, not what CPU is present! cjl From guenther@bcm.tmc.edu Thu Mar 10 16:41:47 EST 1994 Article: 696 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!wupost!bcm!bcm.tmc.edu!guenther From: guenther@bcm.tmc.edu (Margaretha M. Guenther) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 in Space? Date: 10 Mar 1994 14:12:20 GMT Organization: Baylor College of Medicine, Houston, Tx Lines: 21 Message-ID: <2ln9s4$jpl@gazette.bcm.tmc.edu> References: <2ldv8h$ka2@gazette.bcm.tmc.edu> <2lj66f$cp5@bigblue.oit.unc.edu> NNTP-Posting-Host: bcm.tmc.edu Summary: Size of hardware largely depends on power consumption rather than the size of the power supply. Keywords: PDP8, PDP-8, SPACE cjl wrote: > So, the largest advance towards miniaturization often lies with the size > of the peripherals and power source, not what CPU is present! Yes, a power supply is often the single largest component in a computer. However, given an on-board DC supply to begin with, the largest part of a power supply - the transformer - is eliminated. The next largest components, the smoothing capacitors may also be absent. What is left is a power dis- tribution, rather than supply. BTW, I wrote the original posting about PDP8 in space, and the diagram which I saw indicates a 19 inch rack mounted computer of about 8 inch height. Anyone wanting a copy of the newsletter can call National Inst. at 1-800-433-3488 and ask for "Instrumentation Newsletter" Vol 6, #1, Spring 1994. Tell them you heard of "Labview for Windows" and want to see some articles on applications (PC data aquisition). *DON'T* tell them who sent you. Meg. From jones@pyrite.cs.uiowa.edu Fri Mar 11 10:46:02 EST 1994 Article: 697 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 in Space? Date: 10 Mar 1994 22:38:37 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 11 Distribution: world Message-ID: <2lo7hd$lih@nexus.uiowa.edu> References: <2ln9s4$jpl@gazette.bcm.tmc.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2ln9s4$jpl@gazette.bcm.tmc.edu>, by guenther@bcm.tmc.edu (Margaretha M. Guenther): > BTW, I wrote the original posting about PDP8 in space, and the diagram > which I saw indicates a 19 inch rack mounted computer of about 8 inch > height. Sounds like the real thing. Doug Jones jones@cs.uiowa.edu From jones@pyrite.cs.uiowa.edu Fri Mar 11 10:47:18 EST 1994 Article: 698 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8,sci.electronics Subject: Collins Radio Date: 10 Mar 1994 22:53:22 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 29 Distribution: world Message-ID: <2lo8d2$m0r@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Xref: bigblue.oit.unc.edu alt.sys.pdp8:698 sci.electronics:64855 I was just up at the surplus outlet at the Rockwell International Collins Radio plant in Cedar Rapids Iowa. Cedar Rapids is 25 miles north of I-80 on I-380. The plant is about a mile east of I-380 on Collins Road, and the surplus outlet is a few blocks north of Collins Road between Rockwell Drive and Avionics Drive, next to the Education and Training Center. The place is open from noon to 5, Tuesday Wednesday and Thursdays. It's a great surplus outlet. While I was there, they sold a nice kettle drum (I asked, and they had no idea what a big defense contractor was doing selling one of those). They also had lots of 5400, 54LS00 and 54LS04 chips (some with lots more inspection codes on them than I've ever seen on a chip before, but I don't usually deal in Mil Specs parts). More notably, I picked up 15 or so 8" diskettes for my RX01 drives, and I saw that they had a pile of RK05 disk packes and 3 or 4 RK05 drives (I'm not into RK series stuff, but it indicates that a fair amount of DEC hardware passes through the place). They also had a few big top-loading CDC disk drives. Lots of strange stuff was there also, such things as a slab of berrylium copper about 1 foot by 4 feet by 2 inches, as well as a large stock of aluminum bar and sheet stock. They had large stocks of IBM PC vintage stuff, as well as a number of Hewlett Packard test instruments of various kinds, an HP 9000 series 200 workstation of some kind, lots of DECwriter IIIs, and plenty of junk. Doug Jones jones@cs.uiowa.edu From koppel@werple.apana.org.au Sun Mar 13 12:32:37 EST 1994 Article: 699 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!uwm.edu!msuinfo!harbinger.cc.monash.edu.au!yarrina.connect.com.au!werple.apana.org.au!news From: koppel@werple.apana.org.au (David Broadbent) Newsgroups: alt.sys.pdp8 Subject: I am SORRY but ----> Date: 12 Mar 1994 07:53:48 +1000 Organization: werple public-access unix, Melbourne Lines: 35 Message-ID: <2lqp9c$nq5@werple.apana.org.au> NNTP-Posting-Host: werple.apana.org.au X-Newsreader: TIN [version 1.2 PL1] Yes, you guessed it. I had to due to extreme space limitations etc, wreck a 2 by 19" rack mounted pdp8i. One cabinet had the processor and the other had a Vermont Research 10" "Rotating Magnetic Memory Drum". But before you Wizards cast spells on me, I hasten to add I tried in vain for 12 months to give it away,transport free on the east coast of australia. Neither Dec (aus) or any of the 30+ universities & techs I rang were interested. And no one answered my news paper ad. Sigh !!!!!!!!!. I cried all night. Two days later I picked up some 286 IBM pcs from a dealer near me and proceeded to hack them to pieces with a large Battle Ax. It gave me some sense of relief, BUT I Chipped my good Battle Ax !!!!!!. I took me 6 hrs work to weld,harden,temper & re grind it. Anyway I think I hid some of the pcb and the manuals in the atic, suitably protected; BUT I have to clear out the atic soon SO I HAVE BEEN TOLD.!!!! If any of you are interested post me and I will try to give you an idea of whats left. If you are interstate or overseas you will have to pay for any freight costs in advance. No charge for the bits. It was a working machine, and I did have some brand new spares for it, still in origional packaging I think. Regards David. Ps I sent my girlfriend a valentine message of 30 words plus from the paper tape punch,which I now have working on an CPM machine. I took her 20 hrs to decode the holes manually. But she loved it, as it was unique in todays society. At least some of my old pdp8i brings joy, but I dont know what my other half would say about that 30 word message. From mad@mv.mv.com Mon Mar 14 02:02:43 EST 1994 Article: 700 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!MathWorks.Com!noc.near.net!mv!mv.mv.com!mad From: mad@mv.mv.com (White Trash) Subject: *** WANTED: PDP-8 *** Message-ID: Nntp-Posting-Host: mv.mv.com Sender: usenet@mv.mv.com (System Administrator) Organization: MV Communications, Inc. Date: Mon, 14 Mar 1994 01:59:41 GMT X-Newsreader: TIN [version 1.2 PL2] Lines: 8 My father worked at DEC for 18 years, and thought it would be fun to have a PDP-8 around the house (again :) ). If you have one, mail me at mad@phun-sys.mv.com. I am looking for one preferably with manuals, but if you don't have them, that's OK too. -- Mike (mad@phun-sys.mv.com/lunatic@deeptht.armory.com) From lasner@sunSITE.unc.edu Mon Mar 14 02:04:52 EST 1994 Article: 701 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: *** WANTED: PDP-8 *** Date: 14 Mar 1994 07:04:24 GMT Organization: University of North Carolina, Chapel Hill Lines: 16 Message-ID: <2m129o$kh3@bigblue.oit.unc.edu> References: NNTP-Posting-Host: calzone.oit.unc.edu In article , White Trash wrote: >My father worked at DEC for 18 years, and thought it would be fun to have >a PDP-8 around the house (again :) ). If you have one, mail me at >mad@phun-sys.mv.com. I am looking for one preferably with manuals, but if >you don't have them, that's OK too. > >-- >Mike (mad@phun-sys.mv.com/lunatic@deeptht.armory.com) > Assuming this is a legitimate request, then I guess someone will help this man out. However, assuming it to be disingenuous, perhaps someone should explain our purpose here? cjl From ramsey@netcom.com Tue Mar 15 13:33:58 EST 1994 Article: 702 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!magnus.acs.ohio-state.edu!csn!csus.edu!netcom.com!ramsey From: ramsey@netcom.com (Marc Ramsey) Subject: Re: PDP-8 in Space? Message-ID: Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.2 PL2] References: <2ldv8h$ka2@gazette.bcm.tmc.edu> Date: Tue, 15 Mar 1994 00:08:46 GMT Lines: 16 Margaretha M. Guenther (guenther@bcm.tmc.edu) wrote: : In this drawing there's a panel in the wall marked "PDP-8 Computer : controlling experiment hardware and downlink." : I thought that the PDP-8 was an *old* and *heavy* computer with a Teletype : for input? : Was that a misprint, or is there really a PDP-8 in Space? In hopes of providing a pointer to more solid information, I remember seeing years ago a photograph of the interior mockup of the ESA SpaceLab. The most prominent feature of the mockup (to my eyes, anyway) was a PDP-8 front panel. At the time, a PDP-8 was probably the logical choice for an instrumentation computer, given the difficulties associated with changing flight hardware, they may never have bothered upgrading the CPU. Anyone have any recent pictures of the SpaceLab interior? From talon@MCS.COM Wed Mar 16 08:50:30 EST 1994 Article: 703 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!udel!MathWorks.Com!panix!ddsw1!not-for-mail From: talon@MCS.COM (Dave Skwarczek) Newsgroups: alt.sys.amiga.uucp.patches,alt.sys.intergraph,alt.sys.pdp8,alt.sys.sun,alt.sys.unisys Subject: The Final C/Fest.594 Reminder Date: 15 Mar 1994 18:09:22 -0600 Organization: Another MCSNet Subscriber, Chicago's First Public-Access Internet! Lines: 34 Message-ID: <2m5ini$pe0@Mercury.mcs.com> NNTP-Posting-Host: mercury.mcs.com X-Newsreader: TIN [version 1.2 PL2 (KSD)] Xref: bigblue.oit.unc.edu alt.sys.amiga.uucp.patches:721 alt.sys.intergraph:1766 alt.sys.pdp8:703 alt.sys.sun:10541 [ Article crossposted from alt.3d,alt.alien.vampire.flonk.flonk.flonk,alt.alien.visitors,alt.alt,alt.amateur-comp,alt.amiga.demos,alt.angst,alt.architecture,alt.architecture.alternative ] [ Author was Dave Skwarczek ] [ Posted on 14 Mar 1994 18:45:27 -0600 ] Well, let me say that this message is crossposted nicely so you'll only have to read it once! Here's the final reminder about Cyberfest.594. I've been hard at work planning all this, and it's finally nearing fruition! If you haven't read anything about it, here's the scoop. Cyberfest.594 will be Chicago's first ever cyber/club event - featuring VR, graphics, video, MIDI, gaming and telecommunications hardware and software; two live electronic bands; and cyber-art from local and national cyber-artists - all packed neatly into one of the largest nightclubs in the city. A true socio-technological blowout. The official "who/what/when/where" announcement will take place NEXT MONDAY, MARCH 21 at every Usenet board on which this message appears. For the companies/pioneers/sigs/zines that have received their registration folders : Deadline for registration is this Friday, March 18! If you missed the mail boat, we can still fax you info on the few remaining exhibit spaces. If you're a 2D/3D/video/audio/whatever cyber-artist interested in having some work out and about at the event, send me some email! April 1 is our deadline for artists' submissions. thanks you rock dave talon@mcs.com From lasner@sunSITE.unc.edu Thu Mar 17 02:45:32 EST 1994 Article: 704 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Responses to old RX questions from June, 1989 Date: 17 Mar 1994 07:44:49 GMT Organization: University of North Carolina, Chapel Hill Lines: 302 Message-ID: <2m91ph$t6h@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu I've just finished archiving the PDP8-Lovers list stuff for June, 1989! It can now be found on sunsite.unc.edu in the directory: /pub/academic/computer-science/history/pdp-8/pdp8-lovers as the file 8906.lov in keeping with the filename convention established, etc. In going through it, I found a few (marginally!) worthwhile things to respond to. Here goes one or two of them: >Date: 1-Jun-89 18:13:16 +0200 >From: Johnny Billquist >To: pdp8-lovers@mc.lcs.mit.edu >Subject: RX8 vs. RX28. > >There exists both the RX8 and RX28 drive for the omnibus, >RX8 using RX01, and RX28 using RX02, however, a paper of mine >states that the RX28 consists of the RX8-E and an RX02. >Is it possible to hang an RX02 drive to my RX8-E, use the >RX28 device driver, and just be happy? > > /Johnny Of course! Well, sort-of. On the hardware issue, of course this is correct, and is the only way to even do it. The same M8357 module is always used for all Omnibus RX applications regardless of which drive pair is used. The software for the RX series, even just limiting the discussion to OS/8 family is another matter entirely. For the moment, let's just stick to the official DEC type of support as has been seen in various OS/8 family incarnations. The original RX01 handler was eventually officially withdrawn! It had the dubious distinction of actually not exactly qualifying as a handler at the fundamental level: 1) Write out the caller-specified buffer data to the caller-specified logical record for the caller-specified length. Return with an error if this cannot be carried out. 2) Read in the caller-specified data at the specified logical record for the caller-specified length into the caller-specified buffer. Make a reasonable attempt at error recovery and return an error only if this cannot be carried out. This "almost" handler couldn't carry out either 1) or 2)! When you attempt a write, it's quite possible to get an error before the actual write is carried out, such as a seek error, etc. In such a case, the handler would attempt an error recovery procedure that causes the caller-specified data to be ignored! In its place is written the current contents of unit 0, track 1, sector 1! Assuming the error condition abates, the handler returns to the caller without an error return as if the caller's request has been carried out, yet it has not! There is no way to determine if this has happened without a followup readback and data compare, since merely verifying the readability doesn't reveal the problem! (Note: neither readback and data compare nor verify is performed by any OS/8 utility!) When the handler is patched to remove error recovery, then it does almost qualify as a reasonable handler - at least it then *is* a handler! However, by removing error retry, then 2) doesn't occur. It is *not* reasonable to never retry a read on an RX device because this raises the error rate. (This is a device where it is recommended to carry out a series of at least data-read retries and also seek/recalibrate operations for the likes of a seek error; in its original form, the handler actually carries out too much error recovery, i.e., it does everything in the event of anything going wrong, etc. Such "over-recovery" actually encourages certain types of errors, such as the inability to recover from marginal data errors where leaving the head down eventually overcomes the read error, etc. To my knowledge, the only available handlers that deal with RX's in the recommended manner are in P?S/8!) Thus, you have two choices with this original handler: 1) Play Russian Roulette with your data writing and only maybe find out eventually (I got some DECUS disks with this very defect!) that it was mis-written way back when, 2) Remove the error recovery and then know that the data written is reliable, but constantly be subject to premature handler fails caused by total lack of error recovery! This handler did allow an 8K RX01 system! It was eventually "retired" in favor of the series of 12K system handlers that at least don't have this problem! Additionally, the inclusion of a 12K handler for other than a TD8E could only be accomplished when a standard was developed for programs that move handlers around, such as F4 and BASIC, etc. Up until then, this was known as "The TD8E Problem" but it eventually became obvious that there would be a group of problematic handlers. It is apparent that the problems of this handler led to the completion of that specification sooner! An additional quirk of this early handler (and a few that followed it) was that it required an odd feature of the RX01 that wasn't available on the RX02. When the handler is entered/exited, the done flag is used as an idle/busy flag. Thus, the handler should wait until the done flag raises, then proceed with the work of the caller, then raise the done flag and leave. This allows CAF and other buss resets to make all compatible handlers wait for the self-test to complete, etc. and allows good synchronization of all code, etc. However, there is a problem with the instruction set of the RX: all skip-on-flag instructions also clear the associated flag (shades of the DECmate keyboard problem to come!). Thus, once you have waited for a function to finish, the flag is no longer up. Thus, to fulfill the specification, the handler performs a "NOP" function as it leaves without checking the done flag, which of course eventually raises harmlessly (in a few hundred microseconds or so). By the time the next call is made, the flag is already up and adds no material delay time, etc. The specific function used by these early handlers is function 100, which while being a NOP on an RX01, is the "Set Media Density" function on the RX02! Fortunately, there are protocol considerations associated with proper use of the function which aren't performed by these handlers, so you never have a case of accidental data destruction! However, all the handler calls get unclearable errors, etc. Actually, the RX02 has a compatibility mode switch inside. Throwing the switch makes function 100 become a compatible NOP, thus allowing the early handlers to function (as RX01's!) on the RX02 drive. In this mode, it is impossible to reference any double-density aspect of the RX02. (Note: there are some other programs that can be confused by this bit in conjunction with an anomalous status register bit elsewhere in the RX02!) Eventually, DEC released 12K handlers that overcome this problem by using an alternate function for the NOP, the "read error register" function. This will function equally on RX01 or RX02, etc. Another issue was speed, especially on the VT78, DEC's slowest RX-worthy model. The routine to calculate physical sectors/tracks from logical records is written for minimum code size; it runs extremely slow! On the VT78, the situation is so bad that throughput suffers because the mapped 2:1 interleave cannot be kept up with because of the calculation overhead. (Note: in P?S/8, better algorithms are used that do keep up on the VT78! However, this is because in P?S/8 there is far more handler space available to accomplish this!) To partially offset this, the sector calculation is initiated during the time spent waiting for reading or writing. This does make a marked improvement on the VT78, except for the higher track numbers where it still falls behind. Since OS/8 only allows two pages for handlers, error recovery has always been the greatest weak spot of the handlers. The only advance has been past the original handler's fatal weakness. All newer handlers can do some semblance of error recovery, and will never falsely write other than the user's data! (Of course all of these handlers still "over-recover" since there is never enough handler code space to sort out particular errors, etc.) Newer handlers for single-density media are all RX02-aware. Generally, the only change is the boot code. The original boot code cannot be used because it accidentally sets a density bit in the command, and thus can only work on the RX02 set to compatibility mode. (Note: the official RX01 boot can fit into the MI8E (M847) 32 word boot card limit while the official RX01/02 boot is too long!) The newer boot attempts to load drive 0 or 1 in both single and double density modes. If executed on an RX01, the density bits are ignored. For compatibility, the newer boot indicates which drive and also which density in a way useful to both early and late handlers. (Some of the data is redundant, but wouldn't be useful to the RX02 in the form early RX01 handlers demand!) The non-system handlers are also generally available in an alternate form with a different device code. This is to allow two pairs of drives on a single Omnibus machine. In the VT78 and DECmate I, this is accomplished with a single interface that multiplexes against a bit in the new instruction SEL (6750) which defines AC[11] as selecting which pair of drives is selected currently. On power clear pair 0 is selected. Since there is no room in the system handler to select this, the non-system handlers always ensure that pair 0 is selected when exiting! (Actually, there is a third method of selecting drives beyond the first pair: in the DSD-210, there is an available bit adjacent to the unit select bit DEC uses. Thus, this bit can be used to select a second pair of drives. DSD actually sold a box containing three drives; several -8 users have them. The drive buss supports up to four drives. There exists a non-system handler that has three co-resident handlers within it for this configuration; the code is essentially the same as DEC's on all other aspects of the hardware, etc. P?S/8 handlers support up to four drives using either the SEL method or the DSD unit bit method. As in OS/8, reassembling the handler for an alternate device code produces a handler for alternate Omnibus address, etc.) As of OS/78 V3, a new non-system handler appeared that, through a PIP kludge, can actually handle both single and double density diskettes with a single handler. When the handler is called for the first time, it determines whether the media is either: 1) Single-sided single density 2) Single-sided double density 3) Double-sided single density 4) Double-sided double density Note that the double-sided diskettes require RX03 hardware! While never released, DEC did prototype the RX03, and wrote both OS/8 and RT-11 support for it! DSD (among others) produced RX03-compatible hardware that used the RT-11 support. The double-sided support consists of an additional status bit only allowable on an RX02/03 (which is an error bit on an RX01!). On an RX02, the bit always reads 0. Support for a double-sided device consists of appending the "back" side of the disk to the front thus exactly doubling the allowed logical length, etc. Since the logical record length of any device in the system is only known to PIP.SV, PIP was modified to perform a special-case check for the logical device number of this RXNS handler. (So much for device independence!) If the RX logical device number is being used, PIP calls the handler with the impossible record number 7777. Of course, an error occurs. However, instead of just returning an arbitrary negative number on the error return (generally 4000 or 7777, but anything negative is allowed), the handler returns the two's complement of the logical length of the currently mounted diskette. Thus, PIP can determine how to zero the device! All other OS/8 programs use the existing directory info to determine the device size, etc., so this is actually viable. (Note: the error recovery associated with this handler for inexplicable reasons is marginally inferior to prior versions. It is speculated that the person responsible for the code didn't understand just what proper error recovery actual is! Newer still versions seem to have an even more degraded version of error recovery!) When the DECmate II was introduced, a hardware incompatibility in the design occurred which renders all existing RX handlers up to that point obsolete. (This includes all user-written variants, such as byte-oriented handlers, etc.) On the DECmate II, III, III+, attempts to use the standard RX code will instead reference the RX50 drives, and will not work due to the different geometry of the RX50 drives (and perhaps other differences, etc.). To access the RX01/02 on the RX78 option of the DECmate II requires an additional bit be set in the SEL (6750) instruction. Not only does bit[11] set the pair number, but bit[0] sets the RX78; clearing this bit selects the RX50 (as does power clear which selects RX50 pair 0). No existing RX01/02 code ever set that bit before. In some cases it is possible to revamp the handlers to properly maintain the extra bit(s), but in others the handlers are already compromised to the limit with other tradeoffs (performance, error recovery, etc.). To make matters worse, the designers of OS/278 "changed the rules"! Now, the done flag has to be *NOT* set between calls! If it should be found to be set, it's an error! (There is a sufficiently large error recovery count to make this not too much of a problem, but the physical drive pseudo-recalibration effort is made should the flag be up, etc.) When the handler leaves, no effort is made to raise the done flag again. Because of this, it is almost hopeless for any of the earlier handlers to be modified for use in OS/278. In some cases it is marginally possible, but it's not clear that it's even worth the effort! (Note: OS/8 Version 5 will maintain the original convention! Older handlers are welcome there!) Thus, most OS/278 users never install any user-written RX handlers. In the OS/278 handlers, pseudo-recalibration is used for no apparent reason; the drive is seeked between the highest track and track 0, then the operation is retried. I don't understand how that is supposed to clear a seek error! Clearly it violates all documentation for the RX01/02! (And the RX50 handlers do the same thing!) >Date: Fri, 2 Jun 89 08:00:51 EDT >From: "Christopher R. Zach" >Subject: RX8 vs. RX28. >To: BQT@KICKI.STACKEN.KTH.SE >cc: pdp8-lovers@MC.LCS.MIT.EDU >In-reply-to: Msg of 1-Jun-89 18:13:16 +0200 from Johnny Billquist > >Johnny: > Forget it. The RX02 uses a different controller because it is a DMA >device (RX01 used interrupts). Also, the RX01 control doesn't have the extra >registers to handle DD disks. > CZ Christopher Zach is apparently confusing the Omnibus and the UNIBUS! Only on the UNIBUS (and Q-buss, etc.) are RX02 controllers DMA. Moreover, he is wrong about the RX01 controller! There is support for an RX02 on the RX11! It just does things a byte at a time! The RX01 requires either 8 bit or 12 bit data/commands. The RX02 requires either 16 bit or 12 bit commands. Only the RX8E can set the 12-bit mode. Thus, in 12-bit mode, the commands for single density are identical. You just have to be careful not to set to one the density stuff in the high-order bits! If you use byte mode, then you have to wait for an extra TR flag and send 8 more bits, which contain the appropriate density info either way. (Note: -8 code has to carefully determine that the drive actually *is* an RX02 before doing this! On the RX01 you must *not* do this! Some confusion lies in the proper method of identification of whether a drive actually is an RX02; the RX02 manual gives a standard definition, however it is WRONG! On the RX02 the bit means "I am an RX02 even if the RX01 compatibility switch is thrown" while on an RX01 it means "I am an RX01 and the selected drive is either write-protected or not ready" which is inconsistent with the conclusions of the RX02 manual! You must use alternate means to determine this status!) So, on the -11, the same method the -8 uses to talk to byte-mode RX02 can be used, i.e., 16-bit commands are sent 8 bits at a time, and 8-bit data is used, etc. cjl From lasner@sunSITE.unc.edu Fri Mar 18 03:14:05 EST 1994 Article: 705 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Responses to old RX questions from June, 1989 Date: 18 Mar 1994 08:13:49 GMT Organization: University of North Carolina, Chapel Hill Lines: 46 Sender: lasner@sunsite.unc.edu Message-ID: <2mbnrt$m0e@bigblue.oit.unc.edu> References: <2m91ph$t6h@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu Here's another of those questions that came up almost four years ago that perhaps is worthy of a current answer: Date: Fri, 2 Jun 89 07:59:07 EDT From: "Christopher R. Zach" Subject: Expansion and memory... To: BQT@KICKI.STACKEN.KTH.SE cc: pdp8-lovers@MC.LCS.MIT.EDU In-reply-to: Msg of 31-May-89 22:48:46 +0200 from Johnny Billquist Johnny: Dec did a lot of that stuff with certian devices HAVING to be in certain places. I think the reason was so that field service would have an easier time of finding the different parts of the system. However, for best system results, it is a good idea to place the memory as close to the cpu as possible (this allows the cpu to work with the memory first, instead of going through a bunch of device controllers. CZ This seems again to be one of those UNIBUS versus Omnibus confusions. While Chris' reasoning makes sense on the UNIBUS, on the Omnibus there are different rules. In essence, the memory goes at the back of the box with the terminator just behind it. The CPU goes at the beginning of the buss. DMA peripherals are in the middle, as are all other cards except for two notable exceptions: the KA8E and KD8E. I suspect the main reason for the exceptions is that it's accounted for in the design timing, and additionally, the unweildy cables don't want to be brought into the trough area of the -8/e power supply unnecessarily. This would tend to make a messy area of cable pile-up even worse! Even if the machine is expanded into two boxes, as long as the memory is in the back box, the rule still applies. If using an 8/a and an 8/e box, then as long as the memory is 8/a type, it would still go into a low-numbered 8/a slot with the CPU terminator (M8320) in the top slot. Of course you cannot accomodate this if the memory is in the 8/e box, since then all of the cards in the 8/a box are past the inter-box cable. I'm not sure if DEC ever recommended this configuration. Clearly they would want you to have 8/a memory if you had an 8/a box! cjl From lasner@sunSITE.unc.edu Sat Mar 19 21:33:43 EST 1994 Article: 706 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Let's update this list! Date: 20 Mar 1994 02:31:55 GMT Organization: University of North Carolina, Chapel Hill Lines: 150 Message-ID: <2mgcir$e3n@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu I was going through the back posts of pdp8-lovers and found Mark Crispin's "authoritative" list of PDP's. In light of Doug Jones' FAQ's, etc. it would seem interesting to comment on it today! Date: Thu, 8 Jun 89 00:09:28 EDT From: "Robert E. Seastrom" Subject: What's a PDP-x ?? To: pdp8-lovers@MC.LCS.MIT.EDU If you folks have already seen this, please disregard it. If you haven't, keep it handy - it could come in handy some day. [Is today that day? - cjl] ---Rob PS: In case you didn't know (I didn't until 2 years ago), PDP stands for Programmed Data Processor... Date: Wednesday, 20 August 1986 03:42-EDT From: Mark Crispin To: TOPS-20@SU-SCORE.ARPA, Boken@RED.RUTGERS.EDU Re: DEC's PDP's A number of people have requested my list of all the DEC PDP's, so I thought I'd bore you all with it. The PDP-1 was an 18 bit machine. It was DEC's first computer, and some of the first timesharing systems were designed for it. It's also unique in being one's complement; all later DEC computers were two's complement. Some machines, such as one of MIT's PDP-1s, were in operation until the late '70s. [The LINC portion of the LINC-8 and PDP-12 are one's complement! - cjl] The PDP-2 was a designation reserved for a 24 bit machine, but as far as I can tell it was never even designed and definitely none were ever built. The PDP-3 was a 36 bit machine that was designed but never built by DEC. However, Scientific Engineering Institute built one in 1960. The PDP-4 was an 18 bit machine that was intended to be a cheaper, slower alternative to the PDP-1. It was so slow that it didn't sell well, although it was interesting for its auto-incrementing memory registers. It was not program-compatible with the PDP-1, but its instruction set was the basis of DEC's future 18 bit computers. The PDP-5 was a 12 bit machine designed to be a small laboratory system. It used many of the ideas in the LINC (Laboratory Instruction Computer, designed by Lincoln Labs at MIT, some of which were built by DEC). The PDP-6 was a 36 bit machine and the first machine to implement the most wonderful computer architecture known to man. [! - cjl] It was rather expensive and difficult to maintain, and not many were sold. As a result, DEC cancelled 36 bit computers for what was to be the first of many times. The PDP-7 was an 18 bit machine and the sucessor to the PDP-4. It was a major price/performance win over the PDP-4 and the first DEC computer to use wire-wrapping. The PDP-8 was a 12 bit machine and the sucessor to the PDP-8. [I assume he means -5! - cjl] It basically defined the term "minicomputer", and went through several incarnations. The original PDP-8 was followed by the extremely slow PDP-8/S (as bad as the PDP-4 was to the PDP-1, but at least the /S was program-compatible). [I wouldn't be too sure about that! - cjl] DEC recouped with the PDP-8/I (using MSI integrated circuits) and the smaller PDP-8/L, and somewhat later came out with the "Omnibus 8" machines -- the PDP-8/E, the PDP-8/F (a half-sized version of the PDP-8/E), the PDP-8/M (an OEM version of the PDP-8/F), and the final machine, the single board PDP-8/A. The PDP-8/A still exists after a fashion as a current DEC product. The PDP-9 was an 18 bit machine and the sucessor to the PDP-7. It had a faster memory than the PDP-7 and was the first microprogrammed DEC computer. Modulo a 300 wire(!) ECO required in the first machines, the PDP-9 was a reliable machine and some are still in operation today. There was a short-lived PDP-9/L. [Can someone explain what he means by "microprogrammed" ? -cjl] The PDP-10 was a 36 bit machine and the sucessor to the PDP-6. It is especially noted for its software, which represents the pinnacle of DEC software engineering and has never been equalled. The first KA10, largely installed in universities, created a whole generation of timesharing hackers. The follow-on KI10, with paging and using IC's instead of discrete components but otherwise unexciting, mostly was sold to commercial organizations. The KL10 went through several incarnations and is today the most representative of this marvelous machine. The KS10 was a small, low-speed (approximately KA10 performance) processor which was DEC's last successful implementation of this architecture. The PDP-11 was a 16-bit machine that went through more implementations and operating systems than can be counted. Presently it superceded the less powerful PDP-8 as the representative minicomputer. [Some of us might take exception to this statement! - cjl] While the PDP-11 used octal, it was in its deep heart of hearts a hexidecimal machine, and the first indicator of the creeping IBMification of DEC that took full fruit in the VAX. [I can hear the flames now...] Rather than fight it the customers loved it; more PDP-11's have been sold than any other DEC computer (possibly more than all the others combined). The PDP-12 was a 12 bit machine and the sucessor to the PDP-8. It combined a LINC and a PDP-8 type processor in the same box and basically was a new model of the LINC-8 which was the same thing. No PDP-13 was ever designed or built. Even DEC gets superstitious. The PDP-14 was a 12 bit machine with a 1 bit register. It was used as a process control engine in applications that were felt to be too rugged for a PDP-8, and basically replaced a set of relays. Later DEC made PDP-8's suitable for this sort of thing, but it didn't stop them from the ultimate silliness of building a PDP-14 that used a PDP-8 as its console processor! [I remember something about a KL8-JA-oriented diagnostic that was for checking out somesuch configuration! - cjl] The PDP-15 was an 18 bit machine and the final one of this design built by DEC. More PDP-15's were built and sold than any of the others, [I assume he means other 18-bit DEC machines! - cjl] and it went through several incarnations including some which used a PDP-11 as a front end. Apparently the cancellation of the PDP-15 came as a great surprise to the "Tiger Team" who worked on it, although considering its general ungainliness compared to comparable performance PDP-11's it wasn't surprising. In many ways the PDP-15 died for the same reason the PDP-10 did. [I for one want this elaborated on! - cjl] The PDP-16 was a "roll your own" 16 bit machine based on various "building blocks". Every PDP-16 was essentially custom-designed by the customer. It got a fair amount of attention when it was announced but evidentally didn't sell very well. There was no PDP-17 or any other designator. DEC apparently decided that "PDP" had a perjorative ring to it. _______ Any other comments out there in our PDP-8 Peanut Gallery? cjl From lasner@sunSITE.unc.edu Sun Mar 20 12:44:32 EST 1994 Article: 707 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Old RL questions Date: 20 Mar 1994 17:44:27 GMT Organization: University of North Carolina, Chapel Hill Lines: 242 Sender: lasner@sunsite.unc.edu Message-ID: <2mi21r$igh@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu Here's another one of those old questions that may still need a present-day comment or two (hundred) on, etc. >Date: 12-Jun-89 20:22:02 +0200 >From: Johnny Billquist >To: pdp8-lovers@mc.lcs.mit.edu >Subject: RL8A. >More questions on hardware. >The RL8A is for the RL01 drives, according to my manuals. >However, would it be possible to add RL02 to the controller also? >I know that on pdp-11 you can add both RL01 and RL02 to the same >controller, but I don't know about RL8A. >Note. I do not have the RL8A manual, only a manual on omnibus >options. The RL8A is indeed for both RL01 and RL02. The problem is that it's not for both of them at the same time. As far as I can tell, the reason is that the RL02 has exactly twice as many tracks, thus the track difference register has one additional significent bit. In hindsight, DEC apparently never set a standard as to what to set this bit to on the RL01, and instead there's a hardware jumper on the RL8A that makes that bit be ignored. Thus, sloppy code (relative to this bit) can be used on RL01 that could fail if the bit were thrown the other way to make all RL02 software function, etc. Can anyone shed any light on just what the correct value of this bit is? In theory, if we know what it's supposed to be, we can patch all code to conform to the requirement. If so, then the jumper can be set to the RL02 position, and then the RL buss can support mixed drives just like the -11, etc. Additionally, I understand that the obscure option for the DECmate I, the RL278, is for RL02 only, i.e., doesn't support that bit that makes the RL01 "happy" regardless of register value, etc. Thus, it would be possible for an RL01 to be hooked to a DM I, etc. The bit could be any of the following: 1) Always meant to be 0 2) Always meant to be 1 3) Always meant to be a sign extension of the bit immediately to its right 4) Some form of parity bit? Given the way the RL02 does it, I suspect the first case, but I would appreciate any authoritative input. >Does anyone know if it is easy to lay my hands on a RL8A by the >way. I think it would be great to have disks larger than the RK05. >Especially if I get an OS that support larger disks than 4095 blocks. >(OS/8). >Anybody cares to guess on the price? The RL is a lower-performance drive than the RK05, especially for OS/8 purposes. You may get more devices of 4095 records on it (especially RL02) but each is the same OS/8 limit of 4095. An RK05 is usually set to two devices each 3248 records, because that splits the device in half. It's actually quite easy to make RKA0: be 4096 records, and then have RKB0 be the rest, so you do get a full-size device. In any case, this is more of a matter of the limitation of OS/8 than the limitation of the RL drives, etc. >Also, what OS:es has different people tried. Could you give >me a summary of good and bad, and I'll put it together and >post it here if more people are interested. >I think that support for hardware, such as the FPP would >be interesting to know about, for example, also... On the -8, there really hasn't been much support for the RL other than the OS/8 and COS-310 handlers. I believe the multi-user WPS used the RL as the disk device. OS/8 support is kludged to fit within the confines of the traded-off OS/8 handler and its two-page limit. The RL drive has actual bad block tables, one factory and one user-written. OS/8 support is predicated on the existence of a utility (sometimes called up by the CCL FORMAT command) that divvies up the 40 sector/track RL drive into "wedges". The RL01 has two wedges, each of 16 sectors on every track, and an additional half-size wedge consisting of the remaining 8 sectors on each track. On the RL02, the outer wedges correspond to the RL01's wedges, but since there are twice as many tracks, there are also two additional inner wedges. The additional 8 sectors of the inner and outer half-wedges are combined to support a fifth device. Within each wedge there is a local bad block table that is written in a format that is more "friendly" to the handlers. Each table only contains bad block info about the particular wedge. Each wedge allows a maximum of 16 local bad blocks. (The overall drive allows many more! Thus, while a cartridge could be usable by other software, OS/8 could flunk an otherwise usable cartridge, etc.) To calculate a physical sector from a logical sector, the list is checked for any bad sector less than or equal to the requested logical sector. For any found entry, the requested sector is bumped by one. The final result is mapped into its relative position within the wedge, etc. Thus, bad sectors are "straddled" over. Notice that this calculation must be performed for each sector. This is part of why the fact that the RL hardware supports a multi-sector transfer word count mechanism is worthless to OS/8. The other reason is more insidious: For no reason that makes any sense, the RL word count hardware when used in 12-bit mode implements a bizarre transfer scheme. (Note: in 8-bit mode, it makes good sense - the word count is a byte transfer count; each byte goes right justified into a separate word of memory.) If you limit the word count to 128, then indeed an entire page is filled with data taken from the first 192 x 8 or 128 x 12 bits. But if the word count is extended, additional words are taken from the same physical sector. This prevents multi-page transfers! No useful purpose is served by this scheme. Indeed, as many as 170 words can be transferred by this method from any one sector. Note this doesn't even represent a complete sector image, as there is still an additional 8-bit byte that doesn't transfer! (If this was to be used as some form of image-copy mode, then it should have transferred 171 words where the last word has four dummy bits, etc.) Thus, because it's impossible to usefully setup a multi-page transfer, the bad-block testing is granularized to individual sectors in the wedge. Each page transfer involves checking for bad-block straddling, and must be setup as an independent event. Because of all of this overhead, it's impossible to transfer the physically adjacent sector without incurring a full-revolution latency penalty, thus, the contents of each wedge is mapped by a 2:1 interleave. In most designs, a 2:1 interleave just means that it takes two revolutions to transfer the entire track's data, but in this case it means it takes two revolutions to transfer only the 16 (or 8) sector wedge. Thus, it means there are twice as many cases of overall handler call that are involved with an entire revolution latency than otherwise might have been avoided. (Calls for 8 or less pages on good boundaries can avoid having to include the time of an entire revolution latency; without the interleave this could have been as many as 16. The relevant numbers for the half-wedges become 4 instead of 8, etc. The straddling scheme could have been modified to avoid whole tracks if necessary to preserve throughput at the expense of larger device size penalties for bad spots, similar to the "cluster" concept of MS-DOS, etc. Each full wedge is exactly the full size of an OS/8 4096 record device. One physical record is unavailable as it contains the local bad-block table itself. Each time a handler is loaded, that record is read into the handler using a word count of just 16; thus the bad-block table becomes addressable data within the page of code of the handler itself, etc.) >Should I add a disclaimer? Everybody else in any other list seems >to use them? Nah, what the heck... We don't need disclaimers! Here's some more on the same subject: >Date: Mon, 12 Jun 89 21:17:23 EDT >From: "Christopher R. Zach" >Subject: RL8A. >To: BQT@KICKI.STACKEN.KTH.SE >cc: pdp8-lovers@MC.LCS.MIT.EDU >In-reply-to: Msg of 12-Jun-89 20:22:02 +0200 from Johnny Billquist >Johnny: > My guess is that the Rl02 will work on the RL8A. When Dec made the >RL01, they left room for possible expansion (then the masses got the 02). >To tell you the truth, the Rl02 is just a RL01 with 2X the tracks. As far >as software goes, that's another story. You would have to hack the OS/8 >driver to be able to access those extra sectors. Check the sourcecode. >You might have to only change a few things (like #tracks). Once the driver >is patched, the rest should go smoothly. > CZ Chris's guess is pretty good about the hardware. But the software is another thing entirely! OS/8 RL02 handlers clearly are derived from the older RL01 code, but map everything differently, etc. The FORMAT utility must create twice as many localized bad-block tables to accomodate the additional OS/8 devices that appear on the RL02, etc. Johnny asked about how other systems would fare on the RL drives. Here is what P?S/8 would have to do to live on an RL: In P?S/8, there is enough room in the handler to accomplish bad-block handling using the real tables of the disk, thus avoiding the OS/8 "crutch" of the localized tables. However, it's marginally easier to mimic the OS/8 data scheme. (Note: if all bad-block tables are accurate and consistent, it wouldn't matter! The only advantage gained is the ability to access the data in the OS/8 equivalent of record 4095 since it wouldn't be reserved. P?S/8 can consider logical blocks of 0000 through 4095 while in this scheme OS/8 must only consider blocks 0000 through at most 4094. In actuality, this is only 0000 through 4079, since the last 16 records are reserved for straddling blocks in case of the maximal number of locally handled bad-blocks, etc.) P?S/8 allows devices with 4096 blocks by the simple expedient of being consistent to indicating the highest block, while OS/8 instead reckons size by the count of available blocks. This creates the headache of the case where the size would wrap from 7777 to 0000. Since all real devices always have a block 0000, it makes more sense to indicate the block number of the highest transferrable block. Thus, a 4096 block device can have an entry of 7777. But in OS/8, this case must be avoided, since it is indicated by a value of 0000, thus the notion of 4095, *not* 4096 as the largest size of an individual logical device, etc. In theory, when a P?S/8 handler is loaded, it's conceivable that the handler could determine what physical drive is being accessed (I assume that if you attempt to read past a certain physical sector, you get an error on an RL01 and a transfer on an RL02; merely seeking should suffice, etc.) and then setup all relevant mapping on the fly using the tables on the pack, etc. Since P?S/8 logical device sizes are 1/2 that of OS/8, instead of the 2.5 OS/8 devices on an RL01 (two and one additional that is .5 the size the others), there would be P?S/8 logical units 0 through 4 for a total of five devices. But in P?S/8, logical units are passed as part of the addressing space of any one handler. If the pack is discovered to be an RL02, then there would be the maximum of eight logical devices addressed through the system handler, and two additional that require a non-system handler to access. Thus, P?S/8 can address an entire RL01 with one system or non-system handler while OS/8 requires three handlers. P?S/8 can address 4/5 of an RL02 with one system or non-system handler and the remaining 1/5 with an additional non-system handler while OS/8 requires five handlers. In many ways, the RL was a major step backwards. Competing designs using the same overall form-factor as the RL pre-exist it by years. However, all of these previous designs share some improvements over the RL design - error-free devices, and hardware automatic seeking. Back-to-back transfers are normal! The only "advance" was that it used an early form of imbedded servo control. This makes the drive cheaper, not better. (And admittedly avoids problems such as drive alignment, etc.) The drawbacks that the software has to face are more important, unrelated, and were never necessary to the design. Because of the lack of a proper interrupt structure associated with the program-controlled primitive seek, interrupt-driven systems have to take special pains to live with an RL drive. (OS/8 and P?S/8 aren't interrupt driven in general.) For a great example, ask someone familiar with all of the major kludges in RT-11 just to get the beast to work at all! (Note: even the lowly RX01 uses automatic seek!) cjl From lasner@sunSITE.unc.edu Mon Mar 21 01:38:36 EST 1994 Article: 708 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: PDP-8 unix? Date: 21 Mar 1994 06:38:32 GMT Organization: University of North Carolina, Chapel Hill Lines: 56 Message-ID: <2mjfd8$e0b@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu Sifting through the dust of pdp8-lovers, I found this one: Date: 20-Jun-89 0:42:15 +0200 From: Robert Malmgren To: pdp8-lovers@mc.lcs.mit.edu Subject: Unix on the pdp8 I've found an very interesting list in a Unixbook I have, and quot some bits from it: "Just how transportable Unix is can be seen by looking at the wide range of machines that Unix already runs on. These are currently: - Amdahl 470 ... - Digital Equipment Corp. PDP/11 - Digital Equipment Corp. PDP/7 - Digital Equipment Corp. PDP/8 ...". Some pages later in the book is another interesting list giving a overview of what is abailable on the Unix market now: "System Type Machines Supplier ---------------------------------------------------------------------- Unix Very real PDP 11/8/7 VAX AT & T International P.O. Box 7000-8 Baskin Ridge, New Jersey 07920 USA ... " This is the book that Johnny Billquist talked about before. Is there anyone that have heard anything about *nix on the PDP-8, r have been in contact with it in the real_world? / Robert Malmgren I assume this book was eventually confirmed to have a typo in it, etc. Anyone know for sure? My understanding of early unix is that it first appeared on the -7 and -9 largely as a revolt against the ADSS crap that was DEC's usual system for those machines, etc. By implication, this eventually means that it runs on the PDP-15 as well. Then it was ported to the -11, and the rest is as they say ..... So, it might be interesting to trace the path of this misinformation, since mentioning the -11 sorta forces there to be four machines in that list, notwithstanding that the PDP-8 isn't one of them! cjl From ivie@cc.usu.edu Mon Mar 21 10:07:15 EST 1994 Article: 709 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Re: Let's update this list! Message-ID: <1994Mar20.204654.13799@cc.usu.edu> Date: 20 Mar 94 20:46:54 MDT References: <2mgcir$e3n@bigblue.oit.unc.edu> Organization: Utah State University Lines: 15 In article <2mgcir$e3n@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes: > The PDP-9 was an 18 bit machine and the sucessor to the PDP-7. > It had a faster memory than the PDP-7 and was the first > microprogrammed DEC computer. Modulo a 300 wire(!) ECO required in > the first machines, the PDP-9 was a reliable machine and some are > still in operation today. There was a short-lived PDP-9/L. > [Can someone explain what he means by "microprogrammed" ? -cjl] I presume he means that the machine code is interpreted by a controller driven by microcode. -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready' From lasner@sunSITE.unc.edu Mon Mar 21 10:07:34 EST 1994 Article: 710 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Let's update this list! Date: 21 Mar 1994 15:07:23 GMT Organization: University of North Carolina, Chapel Hill Lines: 36 Message-ID: <2mkd7b$m0h@bigblue.oit.unc.edu> References: <2mgcir$e3n@bigblue.oit.unc.edu> <1994Mar20.204654.13799@cc.usu.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <1994Mar20.204654.13799@cc.usu.edu>, wrote: >In article <2mgcir$e3n@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes: >> The PDP-9 was an 18 bit machine and the sucessor to the PDP-7. >> It had a faster memory than the PDP-7 and was the first >> microprogrammed DEC computer. Modulo a 300 wire(!) ECO required in >> the first machines, the PDP-9 was a reliable machine and some are >> still in operation today. There was a short-lived PDP-9/L. >> [Can someone explain what he means by "microprogrammed" ? -cjl] > >I presume he means that the machine code is interpreted by a controller >driven by microcode. Perhaps someone who really knows the answer can respond! I agree that's what it ought to be, but nothing I've ever heard about the 7/9/15 series would tend to support it. On the contrary, could this perhaps be a mangled reference to the way the PDP-8 and the 7/9/15 family handle micro-programmed operates? On the -8, there are distinct groups of operates; you can only combine operations within a group. On the 7/9/15, just about anything goes. Although I don't think the -8 is really lacking much by its restriction. But I suppose that there are those that would appreciate instructions like: SPA SNA CLL CML HLT Additionally, there is the issue of the fact that all operations only take one cycle regardless of the number of operations present, etc. So, anyone out there that can tell us what's the difference between the implementation of some form of -8 and the 7/9/15 series other than the obvious (word-length, DAC instead of DCA, etc.). cjl From bob@sed.csc.com Mon Mar 21 19:31:53 EST 1994 Article: 711 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!udel!MathWorks.Com!zombie.ncsc.mil!cs.umd.edu!prometheus!media!anagld!bob From: bob@sed.csc.com (Bob Smith) Subject: PDP-8/A questions Message-ID: Organization: Computer Sciences Corporation Date: Mon, 21 Mar 1994 02:44:39 GMT Lines: 16 I have questions for 8/A Hardware/Systems Gurus (anyone who can answer is a guru): M8315 has a switch pack toward the finger end of the board. What do the settings do for you? It looks like they are all wired in. I never worked with an 8/A with an M8315 processor, so I never looked at the docs (KK8E is a tick faster). M8317 (option board #2 for the /A) has two switch packs. Same question -what do they do/what are the "right settings"? M8417-BE (32K Semi Memory using 4027 chips) has one switch pack. Same question -what do the switches do/what are the "right settings"? thanks bob From jones@pyrite.cs.uiowa.edu Mon Mar 21 19:33:28 EST 1994 Article: 712 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Let's update this list! Date: 21 Mar 1994 18:32:24 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 33 Distribution: world Message-ID: <2mkp7o$or9@nexus.uiowa.edu> References: <2mgcir$e3n@bigblue.oit.unc.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2mgcir$e3n@bigblue.oit.unc.edu>, by lasner@sunSITE.unc.edu (Charles Lasner): > I was going through the back posts of pdp8-lovers and found Mark > Crispin's "authoritative" list of PDP's. A fun find. Thanks for reposting it! > The PDP-1 was an 18 bit machine... It's also unique in being > one's complement; all later DEC computers were two's complement. ... > [The LINC portion of the LINC-8 and PDP-12 are one's complement! - cjl] And limited support for one's complement was preserved in the remaining 18 bit machines, up to the very end. > The PDP-4 was an 18 bit machine that was intended to be a > cheaper, slower alternative to the PDP-1. It was so slow that it > didn't sell well, ... Dec used PDP-4 machines to control their first generation automatic wire-wrap equipment and possibly for other factory automation functions. > The PDP-16 was a "roll your own" 16 bit machine based on various > "building blocks". Every PDP-16 was essentially custom-designed by > the customer. It got a fair amount of attention when it was announced > but evidentally didn't sell very well. I was a user (as a student in an instructional lab). The machine used a UNIBUS subset, for the data part. Many of the standard PDP-16 options (and it was all options) were originally designed for the UNIBUS. The basic design was an alternative to microprogramming, but with the advent of inexpenisive ROM technology and bit-slice processor chips at about the same time as the PDP-16 was introduced, the PDP-16 turned out to be a poor choice. It was, however, great fun as an instructional toy. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Mon Mar 21 19:33:54 EST 1994 Article: 713 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8/A questions Date: 22 Mar 1994 00:31:56 GMT Organization: University of North Carolina, Chapel Hill Lines: 38 Message-ID: <2mle9s$h5h@bigblue.oit.unc.edu> References: NNTP-Posting-Host: calzone.oit.unc.edu In article , Bob Smith wrote: >I have questions for 8/A Hardware/Systems Gurus (anyone who can >answer is a guru): So, anyone who gives a bad answer is a bad guru :-). >M8315 has a switch pack toward the finger end of the board. >What do the settings do for you? It looks like they are all wired >in. I never worked with an 8/A with an M8315 processor, so I never >looked at the docs (KK8E is a tick faster). I may be able to dig up the specifics, but as I remember it, the KK-8/A CPU can have auto-restart enabled at the same addressses as the option board (redundantly, and presumably for limited systems without the ext memory board). Anything else on the board besides this? > >M8317 (option board #2 for the /A) has two switch packs. Same question >-what do they do/what are the "right settings"? >From memory, whether the boot function is enabled at all, whether it can boot while running (the M847 never does this in the -8/e!), and the ROM even address for the ROM function code for booting in one set, and restart in the other. > >M8417-BE (32K Semi Memory using 4027 chips) has one switch pack. >Same question -what do the switches do/what are the "right settings"? KT8A bank selections, if enabled. > >thanks >bob > cjl From bob@sed.csc.com Mon Mar 21 22:39:21 EST 1994 Article: 714 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!cs.umd.edu!anagld!bob From: bob@sed.csc.com (Bob Smith) Subject: Re: PDP-8 unix? Message-ID: Organization: Computer Sciences Corporation References: <2mjfd8$e0b@bigblue.oit.unc.edu> Date: Mon, 21 Mar 1994 22:59:35 GMT Lines: 7 It seems that pdp8 unix may not be that far off... it might seem like xinu could be ported to an 8 using the micro-c compiler as a basis. micro c compiler for pc execution can be found on oak.oakland.edu undr pub/msdos/c as mc302xxx.zip bob From lasner@sunSITE.unc.edu Tue Mar 22 00:11:12 EST 1994 Article: 715 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Just what exactly is PS/8? Date: 22 Mar 1994 05:10:18 GMT Organization: University of North Carolina, Chapel Hill Lines: 243 Sender: lasner@sunsite.unc.edu Message-ID: <2mlujq$b5i@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu Keywords: OS/8 PS/8 DS/8 TSS/8 DMS Here are a few more related moldy old posts from pdp8-lovers: >Date: 22-Jun-89 19:14:39 +0200 >From: Johnny Billquist >To: pdp8-lovers@mc.lcs.mit.edu >?Subject: PS/8 >What is PS/8. Is it a predecessor of OS/8, or what? >I've seen references to it, and some OS/8 software mumbles about >it, but I've never seen any paper concerning it specifically. >Anybody who knows? > Johnny As JB likely knows by now, PS/8 is just the original name of what we commonly refer to as OS/8. Names notwithstanding, this is just the same system, only an earlier version. Newer versions sometimes get newer features. Sometimes unwarranted incompatibilities creep in. Some management decisions sometimes make these incompatibilities into major issues. The user community *can* overcome all of this - OS/8 Version 5 will implement it! In any case, PS/8 had a V1 and a V2, and OS/8 had various V numbers, some not so clear. Also, when it was configured for a PDP-12 LINCtape, some people want to call it PS/12 and later OS/12. All of this makes no sense, since all that's changed is the particular system device handler. At the time of the popularity of the PDP-12, all of the other available PDP-8 disk peripherals could be attached to a PDP-12. So, is it OS/12 if the RF08 its on is hooked to a PDP-12 but the *same* exact software is OS/8 if the RF08 is hooked to an -8/i? >Date: Thu, 22 Jun 89 13:51:12 EDT >From: "Robert E. Seastrom" >Subject: [Johnny Billquist: What is PS/8. Is it a predecessor of OS/8, or what? ] >To: pdp8-lovers@MC.LCS.MIT.EDU >In-reply-to: Msg of 22-Jun-89 19:14:39 +0200 from Johnny Billquist >Yep. PS/8 was an OS/8 predecessor that would run with only 4Kwords >of memory. As I recall reading, it was pretty stripped, and (maybe) >would only run with a DF-32 (32Kword fixed head disk) or on TU-55 >DECtape. My descriptions come from a book called "Introduction to >Programming" (digital press, 1971). Anyone out there actually >used PS/8? >Moreover, does anyone out there have the tapes required to >generate an RK-05 based TSS/8 system? I have a partial TSS/8 >distribution on paper tape, and sources printed out (it is >about a 3" high stack of paper), and I'd really like to get it >up and running. Others are interested in TSS/8 stuff as well. Anyone have any parts of it available? > ---Rob It would appear that our fearless pdp8-lovers leader had latched onto some bad info! The only 4K systems for -8's are: 1) The DECtape Library System. Not likely the source of the info because it runs on TC01/08 only. 2) R-L Monitor System AKA MS/8. Not likely as it was never sold as a DEC product. 3) P?S/8. Definitely never made available to DEC to be sold, although it can run on the described hardware. 4) The Disk Monitor System. This system can only be run on the few devices supporting 129 word/block devices, such as TC01/08, DF32 and RF08. This is the most likely candidate for the base info used to mangle Rob's post, etc. However, there is no similarity whatsoever between the DMS and PS/8. (And of course PS/8 has always required 8K!) As an interesting historical factoid, PS/8 was distributed to people added to a list by various -8 hardware and software managers, and also by Richard Lary personally. Anyone who got (as I did) an original copy of the mailing has a release note addressed to "The Small Computer Buffer." It would appear that virtually everyone who wanted PS/8 Version 1 could get it for free, etc. Here's some more info about the alleged history of OS/8. >Date: Thu, 22 Jun 89 14:09:02 EDT >From: Clyde Roby >To: BQT@kicki.stacken.kth.se >Subject: Re: PS/8 >Cc: pdp8-lovers@mc.lcs.mit.edu, roby@ida.org >Johnny, > PS/8 was the precessor to OS/8. PS/8 stood for Programming >System for the PDP-8. It was initially not a DEC product and when it >was productized by DEC, the marketing people made the name change. Wrong. Simply not true. It was sold as both PS/8 and OS/8. The biggest difference between PS/8 V2 and OS/8 V1 was that BUILD was written to make it easier to reconfigure. With little change, BUILD could be used on PS/8. BUILD made it a whole lot easier to reconfigure! To make even small changes to the system required lots of assembly, including some stuff that didn't eventually need to change, etc. Before BUILD, people would put up with the system being not quite what they wanted. Also, BUILD made it possible to define a user-written handler without hacking into the (provided) source code. But other than BUILD, the first generation named OS/8 by the marketroids was hardly a different (running) system, etc. > There was a lot of work done by PS/8 predecessors at Georgia >Tech (Doug Wrege now at CDC Atlanta) and others. I worked on some >stuff at West Virginia University with Darryl Duffy and Tom McIntyre >(I think they both work at DEC nowadays). To the best of my knowledge, this isn't literally true either. However, I can explain the confusion of the past: The first system was PS/8, V1 and then V2. Then there was OS/8 V1 and quickly a V2. I'm not sure just how many people actually used V2, as it was quite transient, etc. When the first OS/8 V3 was announced as imminent, it became known that there indeed was a version worked on at WVU and Georgia Tech, and that it was called DS/8. However, it was not an original work, but rather work tacked on top of PS/8. Some of the features were: A central communications area on each device to hold info about the device. Originally (in DS/8) this was achieved by shortening the directory so it was dedicatedly in record 6. DEC people didn't like this at all. (Note: years later, an alternate was offered - a dedicated file had to be placed at record 7 by being the first file in the directory; deleting/moving it would cause great problems!) A SQUASH program that basically performed a "safe" form of SQUISH without using PIP. The idea was that it was performed more inefficiently, but much safer. Files were first copied to an alternate device before being written back to the device being squashed, etc. The worst thing that could happen would be the files wind up in unexpected places, but even if the hardware crashes, the contents aren't lost. PIP/SQUISH can easily crash the device if interrupted at the wrong moment! (Note: that's why PIP traps ^C aborts during a SQUISH!) An 8K form of BATCH that used the communications area for swapping, etc. Note that the official OS/8 BATCH forces a 12K requirement, even if the system device can run in 8K! I believe this program was usually known as HASP. The communications area contained attributes to guide the other programs, such as indicating whether or not it was safe to SQUASH this device, or to allow it to participate in the SQUASHing of another device, etc. This is the part of the story where what I heard gets muddy. Either the DS/8 code was offered to DEC or it was attempted to be sold to them. In any case, DEC management rejected it because it didn't fit in with their plans for OS/8 V3. They clearly didn't like the idea of shortening the directory; users with larger disks aren't happy with the current directory limitations. It would appear that the DS/8 philosophy stemmed from improving a tape-based system, where more likely the storage runs out befor the directory space does! Eventually, DS/8 become disused, because the user community wanted to go with DEC's flow. Much later, the DS/8 utilities were modified to work in the OS/8 V3 environment, i.e., requiring the unmovable dedicated file approach, but otherwise not violating anything DEC had specified, etc. It would appear that today, these utilities can be used; I doubt if they are anything but generic to any form of OS/8, unless unwittingly so. The requirement of the unmovable file can be accomodated, but admittedly isn't well protected, etc. Due to the way that the keyboard monitor works, it's likely that small changes have to be made to HASP to work within any particular version of OS/8, etc. > I can get more information when I get home (I think I've saved >some old PDP-8 stuff). > By the way, anybody remember the LINC and DEC's LINC-8??? Well, we have discussed those since 1989! >Clyde >================================================================= >Clyde G. Roby, Jr. Institute for Defense Analyses >roby@ida.org 1801 N. Beauregard Street >(703) 824-5536 Alexandria, VA 22311-1772 >================================================================= It would be nice for Clyde to respond to this, as he has resurfaced, only recently! And here's yet another one on vaguely the same subject: >Date: Thu, 22 Jun 89 14:17:23 EDT >From: Jonathan Dreyer - Sun ECD PC Distributed Systems >To: BQT@kicki.stacken.kth.se, pdp8-lovers@mc.lcs.mit.edu >Subject: Re: PS/8 >> What is PS/8. Is it a predecessor of OS/8, or what? >> I've seen references to it, and some OS/8 software mumbles about >> it, but I've never seen any paper concerning it specifically. >> Anybody who knows? >> Johnny >It is a predecessor of OS/8. When I was in college ('72 - '76) it was >considered highly cool to be able to bring down the 32K timesharing >PDP-8/I running TSS/8 and bring up PS/8 and have all that raw power to >yourself. OS/8 was just coming out then, if I remember, and it was >considered PS/8's successor. >Unfortunately I didn't use it enough to remember much about it now, but >I remember we were impressed that it had "device-independent i/o"; >TSS/8 programs had to read and write to specific devices; e.g. to >compile a program on a dectape you had to first run COPY to get it onto >the disk. (To get it from a paper tape, you had to run a different >utility, PIP!) With PS/8, this historical curiosity went away. Unfortunately, device-independent I/O has become eroded over the years. There are parts of OS/8 where you have to know that the LPT: is device 66, or is the DECmate 32/33 LPT: with ^S/^Q support required, but no handler (or you make a CP memory panel request to have it performed, as long as your code need not care about handling interrupts and/or doesn't mind not running for relatively long periods of time while CP memory routines run the CPU instead, etc.). Also, certain peripherals can only be identified by specific hacks, such as whether a device is RX01 or RX02 double-density media at the moment, etc. (Admittedly, as long as you stick to just the basics of file I/O, it all does work! But you can't quite assume anything about the LPT:, etc.) >Jon Anyone have any of the TSS/8 sources available? I myself would also like to get ahold of the TSS/8 BASIC, which I understand was a later development, etc. (Even the binary of BASIC would be acceptable; disassembly is always possible!) cjl From bob@sed.csc.com Tue Mar 22 13:23:14 EST 1994 Article: 716 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!zombie.ncsc.mil!cs.umd.edu!prometheus!media!anagld!bob From: bob@sed.csc.com (Bob Smith) Subject: Re: PDP-8 unix? Message-ID: Organization: Computer Sciences Corporation References: <2mjfd8$e0b@bigblue.oit.unc.edu> Date: Mon, 21 Mar 1994 19:12:26 GMT Lines: 40 lasner@sunSITE.unc.edu (Charles Lasner) writes: >Sifting through the dust of pdp8-lovers, I found this one: >Date: 20-Jun-89 0:42:15 +0200 >From: Robert Malmgren >Subject: Unix on the pdp8 > - Digital Equipment Corp. PDP/11 > - Digital Equipment Corp. PDP/7 > - Digital Equipment Corp. PDP/8 > ...". >"System Type Machines Supplier >---------------------------------------------------------------------- >Unix Very real PDP 11/8/7 VAX AT & T International > P.O. Box 7000-8 > Baskin Ridge, New Jersey 07920 >This is the book that Johnny Billquist talked about before. Is there anyone >that have heard anything about *nix on the PDP-8, r have been in contact with >it in the real_world? I checked this out and found that this is a typo. bob >I assume this book was eventually confirmed to have a typo in it, etc. >Anyone know for sure? >My understanding of early unix is that it first appeared on the -7 and -9 >largely as a revolt against the ADSS crap that was DEC's usual system for >those machines, etc. By implication, this eventually means that it runs >on the PDP-15 as well. Then it was ported to the -11, and the rest is as >they say ..... >So, it might be interesting to trace the path of this misinformation, >since mentioning the -11 sorta forces there to be four machines in that >list, notwithstanding that the PDP-8 isn't one of them! >cjl From mattis@elixir.e.kth.se Tue Mar 22 13:24:19 EST 1994 Article: 717 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!sunic!news.kth.se!news.kth.se!mattis From: mattis@elixir.e.kth.se (Mattis Andersson) Newsgroups: alt.sys.pdp8 Subject: Re: Let's update this list! Date: 22 Mar 94 08:30:01 Organization: School of EE, Royal Institute of Technology, Sweden Lines: 29 Message-ID: References: <2mgcir$e3n@bigblue.oit.unc.edu> <1994Mar20.204654.13799@cc.usu.edu> <2mkd7b$m0h@bigblue.oit.unc.edu> NNTP-Posting-Host: elixir.e.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: lasner@sunSITE.unc.edu's message of 21 Mar 1994 15:07:23 GMT Well, as my father owns a PDP-9, and I have been doing some maintenance on it I should know exactly how it works. Unfortunately I have forgot some details. The PDP-9 microprogram is real microprogram in any modern sense like in PDP-11 (except 11/20) or any other microprogrammed processor. It is used to decode minor-states of DEFER, FETCH, EXECUTE etc states. The PDP-9 fetches a new microinstruction every 212 ns or so. It is using a very complicated delay-line system to get this timing... The microprogram itself consists of 36 by 64 (if I remember right) E-cores. One selects one or zero in each cell by wiring a wire through one of the E-cores holes. One can say that it consists of transformers, depending of the way you enter the E-core you get a negative or poistive pulse from it. Anyway I could check up this more when I am able to take a look at the machine again. I am sorry for the lousy explanation, though it's hard to explain it Swedish too.. Also, I think that Computer Engineering mentions something about the PDP-9 microprogram. /Mattis Andersson mattis@elixir.e.kth.se From lasner@sunSITE.unc.edu Tue Mar 22 13:56:54 EST 1994 Article: 718 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: paper tape Date: 22 Mar 1994 18:54:52 GMT Organization: University of North Carolina, Chapel Hill Lines: 49 Sender: lasner@sunsite.unc.edu Message-ID: <2mnets$juh@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu Here's another small issue from the back pages of the lovers list. >Date: Fri, 4 Aug 89 19:51:36 EDT >From: "Robert E. Seastrom" >Subject: [jmbaldwi: I've got a pdp8 that I'd like to use.] >To: CZ%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu >cc: PDP8%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu, > PDP8-LOVERS%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu >In-reply-to: Msg of Fri 4 Aug 89 19:04:02 EDT from Christopher R. Zach >Re: papertape in boxes... >Last time I called DECdirect to inquire about this (was about >2 years ago), they were selling paper tape for $120/case. I >think that there are something like 20 boxes in a case - in other >words, this is not cheap stuff. If anyone out there knows where >we can get fan-folded, non-oiled, 1" paper tape for cheaper, I'd >really like to know about it. I've been kicking around the idea >of trying to get tyvek (yes, I know it's hard on the punch) tape >and putting things like RIM and BIN loaders on it, but I haven't >had the time to try to track this stuff down. Keep in mind that >I have a couple of boxes of 9 rolls each of oiled yellow paper tape >that we could use... the only reason not to use oiled paper tape >in a high speed reader is that the lint from the tape will gunk >up the photodiodes that actually read the tape... you can clean >these off; it is just a pain. > ---Rob Well, that's not the entire story: You shouldn't use oiled paper-tape on the high-speed reader because it won't work! Most oiled yellow tape is too translucent to use with the reader which works photo-electrically, not mechanically. Notice that oiled tape is usually yellow (and a cheaper grade of paper) while non-oiled is usually either grey or black (and clearly an opaque piece of paper). Fan-fold is preferable, but not absolutely required, although it's what you have to feed through the DEC punch if you don't want to resort to external spools, etc. I've also seen some green paper tape that some readers can/cannot read. Later vintage PC04/05 readers have an ECO which helps channel the light source, etc. I think these newer readers *cannot* read this marginal stuff! cjl From ard@siva.bris.ac.uk Wed Mar 23 02:56:20 EST 1994 Article: 719 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: paper tape Message-ID: <22MAR199420283108@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2mnets$juh@bigblue.oit.unc.edu> Date: Tue, 22 Mar 1994 19:28:00 GMT Lines: 46 In article <2mnets$juh@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >Here's another small issue from the back pages of the lovers list. >Well, that's not the entire story: > >You shouldn't use oiled paper-tape on the high-speed reader because it >won't work! Most oiled yellow tape is too translucent to use with the >reader which works photo-electrically, not mechanically. Notice that Now, I've not done much with my PC05 (OK, so it's a PDP11 system, but don't flame me too much), as I use the English Trend readers. I'm not sure if they made it across the Pond, but they're actually quite nice. There are 10 (not 9) photodiodes in the read head - 2 on the sprocket track 2.5 character spaces apart. The reader electronics uses the signals from these 2 sensors (one is light, the other dark when a character is being read) to determine a threshold for the data tracks (and I assume the sprocket track - but the service manual is not here). They are trivial to set up (put a filter in the light path, connect a multimeter to some pins on the board, and tweak for 0 voltage), and simple mechanically (the Unidirectional UDR350 and UDR700 (the numbers are the speed in chars/sec) have the capstan roller on the end of the motor spindle, a solenoid-controlled pinch roller under the chassis, and an electromacnetic break to stop the tape, while the bidirectional HSR500 has 2 capstans with a belt drive, but is otherwise similar). Yes, they can stop on a character, even going at full speed. They are (of course) photoelectric, and I've yet to find a tape they can't read. I really like them. Oh, and there was a PDP8 interface - the schematic was in one of the manuals I got with one of my 700's >I've also seen some green paper tape that some readers can/cannot read. I've seen green, red, and blue tape. Never had any trouble with it. Most of my tapes are white oiled stuff. >Later vintage PC04/05 readers have an ECO which helps channel the light >source, etc. I think these newer readers *cannot* read this marginal >stuff! What does this consit of, so I can find out if it was done to my poor PC05? > >cjl > -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From lasner@sunSITE.unc.edu Wed Mar 23 02:56:40 EST 1994 Article: 720 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: paper tape Date: 23 Mar 1994 07:55:45 GMT Organization: University of North Carolina, Chapel Hill Lines: 40 Message-ID: <2mosm1$nfi@bigblue.oit.unc.edu> References: <2mnets$juh@bigblue.oit.unc.edu> <22MAR199420283108@siva.bris.ac.uk> NNTP-Posting-Host: calzone.oit.unc.edu In article <22MAR199420283108@siva.bris.ac.uk>, PDP11 Hacker ..... wrote: >In article <2mnets$juh@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >>You shouldn't use oiled paper-tape on the high-speed reader because it >>won't work! Most oiled yellow tape is too translucent to use with the >>reader which works photo-electrically, not mechanically. Notice that >>I've also seen some green paper tape that some readers can/cannot read. >I've seen green, red, and blue tape. Never had any trouble with it. Most of my >tapes are white oiled stuff. >>Later vintage PC04/05 readers have an ECO which helps channel the light >>source, etc. I think these newer readers *cannot* read this marginal >>stuff! >What does this consit of, so I can find out if it was done to my poor PC05? The PC04 and PC05 are the same reader. The difference is in the interface block which you could transplant. The -12, -15, and -11 use the PC05, and all else use the 04. The 04 is able to be configured to more machines such as the 8/e, -8, -8/s, -8/i, -8/l, etc. It's a matter of "leaning" negative while the 05 is strictly positive, etc. (Some PC04 configurations are more negative than others; this also allows the machines where the ptr interface is built into the wrap such as the -8/i and -8/l, etc.) The newest 04/05's should have a form of fiber-optics light "funnel" over the light source that comes down close to the read station. Without it, the bulb orientation can be critical as well as the ability to adjust for reliable reading, etc. In fact, it becomes hard to *misadjust* when you have the ECO! But it also makes the reader pass too much light through translucent tape, such as oiled yellow or that light-green stuff. Thus, those tapes always read back all ones, etc. cjl From jones@pyrite.cs.uiowa.edu Wed Mar 23 19:43:13 EST 1994 Article: 721 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: paper tape Date: 23 Mar 1994 15:48:48 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 22 Distribution: world Message-ID: <2mpod0$d4g@nexus.uiowa.edu> References: <2mosm1$nfi@bigblue.oit.unc.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2mosm1$nfi@bigblue.oit.unc.edu>, by lasner@sunSITE.unc.edu (Charles Lasner): > > But it also makes the reader pass too much light through translucent > tape, such as oiled yellow or that light-green stuff. I have cases and cases of paper tape in storage, oiled black fanfold tape, rolls of black unoiled tape, and perhaps some unoiled black fanfold. If the only problem with oiled tape is translucency in a photoelectric reader, my stocks of oiled black tape should pose no problems. Are there problems with oil other than translucency? That is, when the manual says DO NOT USE OILED TAPE, are they afraid of the oil eating the plastic or something? Also, for commonly used tapes such as the BIN loader, the traditional material was mylar. I have the tag end of a spool of aluminized mylar tape that could be used to punch such things, but I don't know what punches are able to handle it (and I don't have any working punch of my own). Doug Jones jones@cs.uiowa.edu From ard@siva.bris.ac.uk Wed Mar 23 20:04:37 EST 1994 Article: 722 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!pavo.csi.cam.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: paper tape Message-ID: <23MAR199423114925@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2mnets$juh@bigblue.oit.unc.edu> <22MAR199420283108@siva.bris.ac.uk> <2mosm1$nfi@bigblue.oit.unc.edu> Date: Wed, 23 Mar 1994 22:11:00 GMT Lines: 31 In article <2mosm1$nfi@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >The newest 04/05's should have a form of fiber-optics light "funnel" over >the light source that comes down close to the read station. Without it, >the bulb orientation can be critical as well as the ability to adjust for >reliable reading, etc. In fact, it becomes hard to *misadjust* when you >have the ECO! OK, so I think mine is the other one - there's a tubular (festoon ?) bulb with one end cap located in the reader panel, the other in an insulated spring clip. Below the bulb there's a plastic cylinder parallel to the bulb, to focus the light on the tape. > >But it also makes the reader pass too much light through translucent >tape, such as oiled yellow or that light-green stuff. Thus, those tapes >always read back all ones, etc. Well, on my reader there's a resistor in series with the bulb, just inside the front panel. It consists of a wirewound resistor with an adustable clip on it, so that you can vary the resistance. It's currently set to minimum. Would increasing that resistor (so dimming the lamp) help on ECO'd readers? > >cjl > -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From lasner@sunSITE.unc.edu Wed Mar 23 20:04:55 EST 1994 Article: 723 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: paper tape Date: 24 Mar 1994 01:04:34 GMT Organization: University of North Carolina, Chapel Hill Lines: 43 Message-ID: <2mqov2$o66@bigblue.oit.unc.edu> References: <2mnets$juh@bigblue.oit.unc.edu> <22MAR199420283108@siva.bris.ac.uk> <2mosm1$nfi@bigblue.oit.unc.edu> <23MAR199423114925@siva.bris.ac.uk> NNTP-Posting-Host: calzone.oit.unc.edu In article <23MAR199423114925@siva.bris.ac.uk>, PDP11 Hacker ..... wrote: >In article <2mosm1$nfi@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >>The newest 04/05's should have a form of fiber-optics light "funnel" over >>the light source that comes down close to the read station. Without it, >>the bulb orientation can be critical as well as the ability to adjust for >>reliable reading, etc. In fact, it becomes hard to *misadjust* when you >>have the ECO! > >OK, so I think mine is the other one - there's a tubular (festoon ?) bulb with >one end cap located in the reader panel, the other in an insulated spring clip. >Below the bulb there's a plastic cylinder parallel to the bulb, to focus the >light on the tape. That's definitely the old one. You have to tinker with the focus to get it to work. It can be quite finicky, etc. > >> >>But it also makes the reader pass too much light through translucent >>tape, such as oiled yellow or that light-green stuff. Thus, those tapes >>always read back all ones, etc. > >Well, on my reader there's a resistor in series with the bulb, just inside the >front panel. It consists of a wirewound resistor with an adustable clip on it, >so that you can vary the resistance. It's currently set to minimum. Would >increasing that resistor (so dimming the lamp) help on ECO'd readers? I think minimum setting is too much even on the old reader! You are sacrificing bulb life for adjustment slop, etc. Considering the difficulty in getting another bulb, I would set it down regardless, etc. before you burn it out! On ECO'd readers, the bulb can be dimmed even more, since more of the light gets efficiently to the read station just where it's needed. I don't think the adjusting down is mandatory, just recommended in that case though. It's conceivable that the translucent tape can be read if the light level is trickily adjusted, but for best overall results, you want to favor the more common opaque variety, etc. cjl From ard@siva.bris.ac.uk Thu Mar 24 21:19:00 EST 1994 Article: 724 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!EU.net!uknet!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: paper tape Message-ID: <24MAR199410394378@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2mnets$juh@bigblue.oit.unc.edu> <22MAR199420283108@siva.bris.ac.uk> <2mosm1$nfi@bigblue.oit.unc.edu> <2mqov2$o66@bigblue.oit.unc.edu> Date: Thu, 24 Mar 1994 09:39:00 GMT Lines: 50 In article <2mqov2$o66@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... >That's definitely the old one. You have to tinker with the focus to get >it to work. It can be quite finicky, etc. OK. I read the description in the service manual, and it didn't seem _too_ bad. You needed a 'scope I think for some of the adjustments, but otherwise it seems OK. Is it really that touchy. It didn't seem to be after I reassembled my reader, but then again, I don't use it that much, so an intermittant read error would probably be undetected. [Lamp resistor] >I think minimum setting is too much even on the old reader! You are >sacrificing bulb life for adjustment slop, etc. Considering the >difficulty in getting another bulb, I would set it down regardless, etc. >before you burn it out! Right. I _think_ it's at minimum - it's certainly at one end, and I guess maximum resistance would read nothing. Is the bulb that hard to obtain? I can;t remember the rating, but I'm sure I found a supplier of them. That's another area where my favourite Trend readers score. The bulbs are standard car bulbs (12V 21W in the UDRs/self powered HSR, 24V 24W in the separately powered HSR/puch/reader station. The 12V bulbs are available from _any_ car shop over here, and the 24V ones are a standard lorry bulb.) > >On ECO'd readers, the bulb can be dimmed even more, since more of the >light gets efficiently to the read station just where it's needed. I >don't think the adjusting down is mandatory, just recommended in that >case though. If it would work, then I'm sure it would majorly increase lamp life. > >It's conceivable that the translucent tape can be read if the light level >is trickily adjusted, but for best overall results, you want to favor the >more common opaque variety, etc. Not for day-to-day use, but if someone gives you an unreadable tape, then it might be nice to adjust the reader to be able to copy it. > >cjl -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From bqt@Krille.Update.UU.SE Thu Mar 24 21:50:52 EST 1994 Article: 725 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8/A questions Date: 24 Mar 1994 15:10:57 +0100 Organization: Update Computer Club Lines: 112 Message-ID: <2ms71v$hm9@Krille.Update.UU.SE> References: NNTP-Posting-Host: krille.update.uu.se In bob@sed.csc.com (Bob Smith) writes: >I have questions for 8/A Hardware/Systems Gurus (anyone who can >answer is a guru): :-) Well, don't need to be a guru, just grabbed my copy of the pdp8/a miniprocessor users manual >M8315 has a switch pack toward the finger end of the board. >What do the settings do for you? It looks like they are all wired >in. I never worked with an 8/A with an M8315 processor, so I never >looked at the docs (KK8E is a tick faster). Switch Function (When in the ON position) S1-1 Start in field 7 (OFF position specifies Field 0) S1-2 Start at address 4000 S1-3 Start at address 4000 S1-4 Start at address 2000 S1-5 Start at address 1000 S1-6 Start at address 0200 S1-7 CPU Auto Start Disabled S1-8 ON for operating Normally S1-7 and S1-8 is ON and all others are OFF. Having more than one of S1-2 to S1-6 on will case CPU malfunction even if CPU Auto Start is disabled. >M8317 (option board #2 for the /A) has two switch packs. Same question >-what do they do/what are the "right settings"? This will require some space, so hold on... ---- Auto-Restart Select Switch Settings Restart Address S2-2 S2-3 S2-4 0 OFF OFF OFF 200 OFF ON OFF 2000 ON OFF OFF 4200 ON ON OFF ---- Bootstrap Select Switch Settings Program S2-5 S2-6 S2-7 S2-8 S1-1 S1-2 S1-3 Memory Address HI-LO RIM ON ON ON OFF ON ON ON 7737 RK8-E ON OFF ON OFF ON OFF ON 0024 TC08 ON OFF OFF ON OFF ON ON 7613 RF08/DF32D OFF ON ON ON ON OFF OFF 7750 TA8-E OFF ON ON OFF ON OFF OFF 4000 ---- Boostrap Select Switch Settings for ROMs Labeled 158A2 and 159A2 Program S2-5 S2-6 S2-7 S2-8 S1-1 S1-2 S1-3 Memory Address HI LO RIM ON ON ON OFF ON ON ON 7737 RK8-E ON OFF ON OFF ON OFF ON 0024 RX8-E ON OFF OFF ON OFF ON ON 0033 RF08 OFF ON OFF ON OFF ON OFF 7750 TA8-E OFF ON OFF OFF OFF ON OFF 4000 ---- Bootstrap/Auto-Restart Switch Settings Feature Start switch S1-6 S1-7 S1-8 or Activating Signal Bootstrap Enabled and BOOT Key OFF OFF ON Auto-Restart Disabled Bootstrap Enabled and BOOT Key ON ON ON Auto-Restart Enabled or AC OK Bootstrap Disabled and AC OK ON ON OFF Auto-Restart Enabled Bootstrap Enabled and AC OK ON OFF OFF Auto-Restart Disabled Bootstrap Enabled and AC OK or ON OFF ON Auto-Restart Disabled BOOT Key Bootstrap and OFF OFF OFF Auto-Restart Disabled S2-1 Timeshare Enabled OFF Timeshare Disbaled ON S1-4 Bootstrap Activated in Run or Stopped State OFF Bootstrap Activated in Stopped State Only ON Not Used S1-5 >M8417-BE (32K Semi Memory using 4027 chips) has one switch pack. >Same question -what do the switches do/what are the "right settings"? I don't have the documentation for that one around here, but I remember from the drawings that the switches are for the starting address of the memory. I think it is in 16K increments. To use above 32K you need the KT8-A. Note that the autostart feature of the CPU is separate from the autostart feature of the KM8-A (M8317). -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From wilsonj@alum01.its.rpi.edu Thu Mar 24 21:51:27 EST 1994 Article: 726 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!noc.near.net!usenet.elf.com!rpi!wilsonj From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: alt.sys.pdp8 Subject: PC04 reader bulb Date: 24 Mar 1994 17:08:38 GMT Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 13 Message-ID: <2mshem$9su@usenet.rpi.edu> NNTP-Posting-Host: alum01.its.rpi.edu Not like I've used my PC04/PC8E in a while but, back when I did regularly I noticed that the bulb (I have what I guess is the "old" style, semi- cylindrical lens deal) flickers very noticeably. The reader was always flakey (tends to stop/start a lot in use, now that I've finally got a scope I can finally test the stepper motor timing which is what I suspect), and I would feel a lot better if I could replace the bult with something more reliable. Is anyone aware of any problem with using a row of LEDs instead? I imagine I'd have to mount them a lot closer? Would any particular color be easier for the photodetectors to see? (I've been replacing the bulbs on my 8/E front panel with LEDs as they burn out, a different color each time, it looks like a christmas tree!) Thanks, John Wilson From lasner@sunSITE.unc.edu Thu Mar 24 21:52:09 EST 1994 Article: 727 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8/A questions Date: 25 Mar 1994 02:49:29 GMT Organization: University of North Carolina, Chapel Hill Lines: 44 Message-ID: <2mtjfp$h9s@bigblue.oit.unc.edu> References: <2ms71v$hm9@krille.update.uu.se> NNTP-Posting-Host: calzone.oit.unc.edu In article <2ms71v$hm9@krille.update.uu.se>, Johnny Billquist wrote: >S1-2 Start at address 4000 Isn't this one 6000? >0 OFF OFF OFF >200 OFF ON OFF >2000 ON OFF OFF >4200 ON ON OFF This part about the restart address isn't totally true! The organization of the 8/a ROM is 128x16 implemented out of two 256 x 4 82S126 chips. The switch settings form a three-bit pattern of pairs of addresses less than 16 decimal that can be specified as the starting address of the ROM for restart purposes. Thus, the lowest address is ROM address 000 and the highest available is 014. The boot addresses can be specified within any six-bit pattern of pairs of addresses. The contents of the ROM are PDP-8 12-bit switch register values and 4 bits of associated functions, which can be partially micro-coded. The four functions are Address Load, Extended Address Load, Start, and Deposit/Increment address. The four *usually* defined addresses are as you documented; these contain ROM instructions such as: 0000 Address Load 0000 Extended Address Load ! Start For field 0, change the Address Load value to 0200 or 2000 or 4200 or whatever as necessary, and pick the proper ROM starting address that contains the sequence you want. But some ROM's, such as the WPS-oriented one, only support the restart at 00000, using the ROM address 000. In such a ROM, the boot sequence starts at ROM address 004. cjl From lasner@sunSITE.unc.edu Fri Mar 25 01:21:08 EST 1994 Article: 728 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: RX boot code (shorter?) Date: 25 Mar 1994 06:20:13 GMT Organization: University of North Carolina, Chapel Hill Lines: 142 Sender: lasner@sunsite.unc.edu Message-ID: <2mtvqt$s7a@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu cjl> Here's some not-so moldy stuff from pdp8-lovers: Date: Fri 5 Jan 90 13:55:07 From: Johnny Billquist Subject: Software... To: pdp8-lovers@MC.lcs.mit.edu cjl> [Other stuff deleted...] I would like to get the bootstrap for RX01 and RL01. I can boot RX through the BOOT program, and has an ugly hack which boots an RL, but would like to get my hands on the official way to do this from the front panel. Johnny cjl> And then a response: Date: Sat, 06 Jan 90 14:48 CST From: RFLUKES%ccm.UManitoba.CA@mitvma.mit.edu To: pdp8-lovers@mc.lcs.mit.edu Subject: Minimal Bootstrap for RX8E I got this bootstrap code from a manual for an 8/e disk subsystem built by DSD. I have been using this bootstrap with my RX8E controller and find that it is shorter and easier to toggle into the 8/e than the DEC bootstrap. ------------------------------------------------------------------------ MINIMAL PDP-8 BOOTSTRAP PROGRAM (RX) The following is a minimal length boot program for both the RX01 and RX02 mode systems. This boot tries only the specified drive with the specified density. Start at location 32 to BOOT drive 0. Start at location 22 to boot drive 1. cjl> I've got a problem with this part of the boot code! First of all, cjl> unlike starting at 0032, this code *must* be entered only when the cjl> drive is no longer performing a self-test. Moreover, it's wasting cjl> the read performed by the self-test, which is the whole point of cjl> starting at 0032. Otherwise, this boot isn't much (if any!) shorter cjl> than DEC's, and does a whole lot less. / * THIS FIRST SECTION IS NECESSARY ONLY WHEN BOOTING ONTO DRIVE 1. / READS IN SECTOR 1 TRACK 1 ON SPECIFIED DRIVE 22*6755 BOTDV1, SDNF /START HERE TO BOOT DRIVE 1. 23*7000 NOP /SKIP THIS WHEN CLEARING FLAG cjl> Here's where it assumes the flag is stable. But if the self-test is cjl> in progress, this flunks! 24*7327 AC6 /SET AC=6 cjl> This makes it unnecessarily dependent on the post-8 instruction set. cjl> A better technique is to make the NOP above instead the constant 0006 cjl> then reference that constant with TAD .-1. The AC has to be clear cjl> because this is a boot situation, etc. 25*1061 TAD UNIT /MAKE INTO READ SECTOR COMMAND 26*6751 LCD /COMMAND = CONTROLLER 27*7301 CLA IAC /SET AC TO 1 FOR SECTOR, TRACK 30*4053 JMS LOAD /SEND SECTOR TO CONTROLLER 31*4053 JMS LOAD /SEND TRACK TO CONTROLLER / DOES NOT USE LOCATIONS 22-31 WHEN STARTED AT 32 / / START AT LOCATION 32 TO BOOT DRIVE 0. / USES INIT TO READ DRIVE 0 TRACK 1 SECTOR 1 / 32 7305 BOTDV0, CLA CLL IAC RAL /GENERATE THE EMPTY BUFFER COMMAN cjl> Again, an unnecessary dependancy on newer instructions. Just change cjl> it to CLA CLL CML RTL and it works on all models. cjl> Entering here you get the benefit of the figure-8 loop, so the flag cjl> need not yet be up, just pending, etc. 33 6755 CHKFLG, SDNF /WAIT FOR DONE FLAG UP 34 5054 JMP LOAD+1 /NO - CHECK FOR READY TRANSFER 35 1061 TAD UNIT /YES-PUT IN READ UNIT, DENSITY 36 6751 LCD /SEND EMPTY BUFFER COMMAND 37 5047 JMP BOTLP /START TO LOAD SECTOR BUFFER cjl> This is a *manual* boot! The 5047 isn't necessary; just put in cjl> 0000 until you get to 0046. //////// //////// 47 4053 BOTLP, JMS LOAD /READ NEXT WORD FROM SILO 50 3002 DCA 2 /START LOADING AT LOC. 2 51 2050 ISZ .-1 /BUMP LOAD ADDRESS 52 5047 JMP BOTLP /CONTINUE EMPTYING BUFFER / 53 **** LOAD, 0 /DATA TRANSFER SUBROUTINE cjl> This is a subroutine header; value unimportant. It could be used to cjl> load the 0006 above, etc. In any case, it's faster and less switch cjl> manipulation to put in 5047 here since that's the same as the previous. 54 6753 STRF / SKIP IF CONTROLLER WILL SPEAK 55 5033 JMP CHKFLG / NO - CHECK IF FINISHED 56 6752 XDR / TRANSFER DATA IN OR OUT 57 5453 JMP I LOAD / RETURN TO CALLER / 60 7004 (DY0) OR 7024 (DY1)/ USED BY SECONDARY BOOT / TO SELECT DRIVE 0 OR DRIVE 1 cjl> 0060 is only used by the RX01 boot. 61 0000 OR 0400 OR 0020 OR 0420/ DX0-SD, DX0-DD, DX1-SD, DX1-DD cjl> The 0061 info is partially redundant to that in 0060 and is only used cjl> by the RX02 boot. This bootstrap requires different values in locations 60 and 61 for single or double density, and drive 0 or drive 1 bootstrapping. These values are listed below. Drive 0, Single Density - Start at location 32 60/ 7004 61/ 0000 Drive 0, Double Density - Start at location 32 60/ 7004 61/ 0400 cjl> Forgot Drive 1, single density - Start at location 22 cjl> cjl> 60/ 7024 cjl> 61/ 0020 Drive 1, Double Density - Start at location 22 60/ 7024 61/ 0420 ------------ Richard cjl> cjl From lasner@sunSITE.unc.edu Fri Mar 25 01:30:16 EST 1994 Article: 729 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Progress in archiving pdp8-lovers Date: 25 Mar 1994 06:29:36 GMT Organization: University of North Carolina, Chapel Hill Lines: 26 Message-ID: <2mu0cg$eik@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu I have successfully archived the pdp8-lovers mailing list from its inception in February, 1989 well into 1990 (and still going!). Anyone is invited to see the pdp-8 back pages by anonymous ftp to sunsite.unc.edu and look in the directory: /pub/academic/computer-science/history/pdp-8/pdp8-lovers The files are stored by month with names such as 8902.lov for February, 1989, 9004.lov for April, 1990, etc. Please note that there are *no* articles for March, 1990! If anyone has any missed articles from this period, please examine what we have now and contact me for corrections, etc. Progress will tend to slow as I get closer to the present due to the increased volume of the list. (However, since the inception of our newsgroup, I think it's diminishing as more and more people get their PDP-8 info here instead!) Again, I ask for anyone with specific knowledge of how to logically tie the mailing list to alt.sys.pdp8. Some people cannot get one or the other, etc. cjl From jcook@epochsys.UUCP Sat Mar 26 14:41:10 EST 1994 Article: 730 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!agate!blanket.mitre.org!think.com!spdcc!merk!epochsys!jcook From: jcook@epochsys.UUCP (Jim Cook) Newsgroups: alt.sys.pdp8 Subject: Re: paper tape Summary: Don't use tyvek. Message-ID: <3299@epochsys.UUCP> Date: 25 Mar 94 16:36:58 GMT References: <2mnets$juh@bigblue.oit.unc.edu> Organization: Epoch Systems, Westboro MA Lines: 20 In article <2mnets$juh@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes: > >Date: Fri, 4 Aug 89 19:51:36 EDT > >From: "Robert E. Seastrom" > ... I've been kicking around the idea > >of trying to get tyvek (yes, I know it's hard on the punch) tape > >and putting things like RIM and BIN loaders on it, but I haven't > >had the time to try to track this stuff down. Don't use tyvek. It stretches and it deteriorates over time from ultraviolet light (the latter has become an issue for duPont in the housing industry). Many years ago, I saw some mylar stuff. Silver on one side and I don't know what (green?) on the other. It worked with teletypes. No idea where it came from. Jim From wilsonj@alum01.its.rpi.edu Mon Mar 28 08:36:02 EST 1994 Article: 731 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!noc.near.net!usenet.elf.com!rpi!wilsonj From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: alt.sys.pdp8 Subject: Re: paper tape Date: 27 Mar 1994 22:22:00 GMT Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 6 Message-ID: <2n50u8$fbu@usenet.rpi.edu> References: <2mnets$juh@bigblue.oit.unc.edu> <3299@epochsys.UUCP> NNTP-Posting-Host: alum01.its.rpi.edu Inmac used to sell the mylar stuff. They had quite a fine paper tape section in the catalog, back when there was a market for it. I never felt the need to order any, my 8/E came with 11.9 miles of DEC paper tape! John From lasner@sunSITE.unc.edu Mon Mar 28 19:47:27 EST 1994 Article: 732 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Pdp8-lovers archived into 1991 Date: 29 Mar 1994 00:47:07 GMT Organization: University of North Carolina, Chapel Hill Lines: 25 Sender: lasner@sunsite.unc.edu Message-ID: <2n7tqb$7oo@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu The archiving of the Pdp8-lovers list is going smoothly. Thanks to the combined archives of several different people, we now have a fairly accurate copy of all of the early posts of the list for all of 1989 and 1990. Newer posts will be added as time permits, etc. It would appear that the mailing list has occasionally had propagation problems, since the private archives didn't overlap 100% as would be expected. Some of the "outages" are coincident with certain posts complaining about lack of activity, etc. which clearly indicate the complaining party isn't getting what fortunately someone else *did* get! So, if anyone wants to catch up on their reading, these early posts are just what you need! As usual, the files are available on sunsite.unc.edu via anonymous ftp in the directory /pub/academic/computer-science/history/pdp-8/pdp8-lovers in the form of monthly files from 8902.lov for February, 1989 through 9012.lov for December, 1990. Of note is that 9003.lov is zero length, as apparently there was no activity that month as the list was being dismantled (the hardware it was running on was dismantled!) and it then was reformed on another machine, etc. cjl From jcook@epochsys.UUCP Mon Mar 28 23:46:37 EST 1994 Article: 733 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!swrinde!emory!gatech!taco.cc.ncsu.edu!hsdndev!spdcc!merk!epochsys!jcook From: jcook@epochsys.UUCP (Jim Cook) Newsgroups: alt.sys.pdp8 Subject: TSS/8 Based on RK05/RK8E Summary: I had an RK05/RK8E-based TSS/8. Keywords: OS/8 PS/8 DS/8 TSS/8 DMS Message-ID: <3301@epochsys.UUCP> Date: 28 Mar 94 18:00:32 GMT References: <2mlujq$b5i@bigblue.oit.unc.edu> Organization: Epoch Systems, Westboro MA Lines: 67 In article <2mlujq$b5i@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes: > Here are a few more related moldy old posts from pdp8-lovers: > > >Date: Thu, 22 Jun 89 13:51:12 EDT > >From: "Robert E. Seastrom" > >Subject: [Johnny Billquist: What is PS/8. Is it a predecessor of OS/8, or what? ] > >To: pdp8-lovers@MC.LCS.MIT.EDU > >In-reply-to: Msg of 22-Jun-89 19:14:39 +0200 from Johnny Billquist > ... > >Moreover, does anyone out there have the tapes required to > >generate an RK-05 based TSS/8 system? I have a partial TSS/8 > >distribution on paper tape, and sources printed out (it is > >about a 3" high stack of paper), and I'd really like to get it > >up and running. > > Others are interested in TSS/8 stuff as well. Anyone have any parts of it > available? > > > ---Rob > > Anyone have any of the TSS/8 sources available? I myself would also like > to get ahold of the TSS/8 BASIC, which I understand was a later > development, etc. (Even the binary of BASIC would be acceptable; > disassembly is always possible!) > > cjl A long story: When I was in High School in Westwood, MA , we had a PDP-8. For the 71/72 school year it was an 8/I with a DF-32. Somewhere around 72/73, we upgraded to an 8/E with an RK05 (I think the RK8E was the controller). What to run for software? TSS/8 ran on RF08's and maybe a DF32 (I knew of one site: Needham High School, MA), but not RK05's. To make a long story short, the non-profit organization running the computers for the area towns - Project Local - had a listing of version 8.21c TSS/8. Another plan to use the RK05 that had been passed on to me was not working, but hey, TSS/8 seemed to have a device driver! So I typed in all 24K of source on an ASR-33 to get a source (I later won the Typing-I award in my senior year). I then wrote a driver for the RK05 that made it appear to be a four-platter RF08 system. And it worked! DEC eventually traded us a source of it for a source of version 8.24b which I similarly modified. And it ran three 8/E's used by five or six towns! All this while I was in High School (thumping chest). I graduated in '75, but I have no idea what became of the 8's. Probably eventually replaced by PCs. As for the sources, I have some DECtapes in Mom's basement that are either in PDP-8 (OS/8) or PDP-10 format. I also have a magtape at home in PDP-10 format. There's a good chance there's some sort of source on them. No idea on how to read them (or where). This would only get you monitor sources which were traditionally built under OS/8. I doubt I have copies of TSS/8 Basic or any utilities. By the way, in case someone was interested, the author of TSS/8 Basic was not DEC. I had sources. It was some place in Dedham, MA, whose name escapes me now. Jim From sjm1@crux4.cit.cornell.edu Tue Mar 29 16:42:59 EST 1994 Article: 734 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!newsstand.cit.cornell.edu!travelers.mail.cornell.edu!tuba.cit.cornell.edu!crux4!sjm1 From: sjm1@crux4.cit.cornell.edu (Seth Morabito) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: "There once was a PDP 8..." Date: 29 Mar 1994 17:41:29 GMT Organization: Cornell University Lines: 17 Message-ID: <2n9p89$53d@tuba.cit.cornell.edu> NNTP-Posting-Host: 128.253.232.66 X-Newsreader: NN version 6.5.0 #6 (NOV) Xref: bigblue.oit.unc.edu alt.sys.pdp8:734 alt.folklore.computers:62042 A while back, while scanning through some old "Science" magazines, I came accross a couple of ads for PDP 8's (these were like 1966 or 1967 copies of "Science"), but I was on the job shelving said magazines and didn't get a chance to make any photocopies... it's a shame, because I seem to remember these particular ads were quite cute. One of them showed a PDP 8 (an 8/e, I think...) wearing a wedding veil, next to a bouquet of flowers, and the text was a limerick which began "There once was a PDP 8.." Does anyone remember these ads, or remember the rest of the limerick? I'm dying to know, and I don't have access to the old magazines any more :-/ -Seth Morabito sjm1@cornell.edu ---------------------------------------------------------------------- "Hey--What d'you want for $19.99 plus tax? Conversation, quantum theory, AND good toast?" -- Grant Naylor, _Better_Than_Life ---------------------------------------------------------------------- From lasner@sunSITE.unc.edu Tue Mar 29 17:02:25 EST 1994 Article: 735 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: "There once was a PDP 8..." Date: 29 Mar 1994 22:00:33 GMT Organization: University of North Carolina, Chapel Hill Lines: 42 Sender: lasner@sunsite.unc.edu Message-ID: <2na8e1$at9@bigblue.oit.unc.edu> References: <2n9p89$53d@tuba.cit.cornell.edu> NNTP-Posting-Host: calzone.oit.unc.edu Keywords: PDP-8 PDP-8/e Doctor Eliza Xref: bigblue.oit.unc.edu alt.sys.pdp8:735 alt.folklore.computers:62054 In article <2n9p89$53d@tuba.cit.cornell.edu>, Seth Morabito wrote: >A while back, while scanning through some old "Science" magazines, I >came accross a couple of ads for PDP 8's (these were like 1966 or 1967 >copies of "Science"), but I was on the job shelving said magazines >and didn't get a chance to make any photocopies... it's a shame, because >I seem to remember these particular ads were quite cute. One of them >showed a PDP 8 (an 8/e, I think...) wearing a wedding veil, next to >a bouquet of flowers, and the text was a limerick which began "There once >was a PDP 8.." Does anyone remember these ads, or remember the rest >of the limerick? I'm dying to know, and I don't have access to the >old magazines any more :-/ > In 1967 it wouldn't be the 8/e, since that was only introduced late '70. However, I do remember an ad campaign for the PDP-8/e which showed the little -8/e box and a larger picture behind it of its "mother", the original classic PDP-8 (table-top model). The ad patter went something like: The PDP-8/e: even its own mother doesn't know it. An amusing side-story: I went to a TOPS-10 installation to play Doctor (aka Eliza) and asked it for "advice" because "my own mother doesn't know me" essentially playing the part of the -8/e, etc. I elaborated the story to include my green cousin, the PDP-12, brown uncle -8/i, and retarded uncle -8/s, etc. As anyone who has ever played with Eliza can confirm, the program is rigged to respond to the key phrase "computer" or "machine". If triggered, it asks the standard question "do computers worry you?", etc. After several "rounds" with this particular Eliza program, where it randomly asks you questions such as "Earlier you mentioned your green cousin PDP-12" etc., eventually the notions of "computers" was mentioned. The Doctor asked if computers worry me? I responded with "No, I am one" and the program aborted with a push-down error! cjl (You seem a bit negative! No, my entire buss is negative. You seem quite positive about that! I have a positive buss convertor, etc.) From jones@pyrite.cs.uiowa.edu Wed Mar 30 13:43:43 EST 1994 Article: 736 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: "New" high speed paper tape reader Date: 29 Mar 1994 21:52:38 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 22 Distribution: world Message-ID: <2na7v6$10s@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu I just picked up an IOmech (Digitronics) Model 254 high speed paper tape reader at the Rockwell International surplus outlet in Cedar Rapids. This is good because I have an IOmech/OMNIBUS high speed paper tape reader interface card that came with my 8/F and because the reader only cost me $5 (and for an extra $2, I got a handfull of tungston carbide PC board drills and a stick of SN5474 chips), but I need to either waste a weekend doing reverse engineering or I need documentation. The problem? The paper tape reader was a peripheral on a General Radio I/O expander box of some kind -- or what was left of such a machine. The CPU is missing. Anyway, the connector that was mated with the GR interface card won't mate with the connector on the OMNIBUS interface card. The reader, by the way, is photoelectric, with removable fanfold feed and take-up hoppers, a cylindrical plexiglass lens, and a huge ballast resistor in series with the lightbulb that illuminates the tape. The front plate of the reader is about 1/4 inch thick (or even 5/16) aluminum, and the output from the reader is on a horizontal card-edge connector at the back. Any advice would be appreciated. Doug Jones jones@cs.uiowa.edu From ivie@cc.usu.edu Thu Mar 31 13:49:28 EST 1994 Article: 737 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!chpc.utexas.edu!cs.utexas.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Hi-tech RK05! Message-ID: <1994Mar30.100236.14667@cc.usu.edu> Date: 30 Mar 94 10:02:36 MDT Organization: Utah State University Lines: 9 In the latest "Processor", I saw an ad for a device that replaces several types of disk drives with a chunk of RAM. It's supposed to be plug-compatible; i.e., unplug the drive and plug this thing in its place. Among the drives it claims to replace is the RK05. -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready'