From news.columbia.edu!watsun.cc.columbia.edu!lasner Wed Dec 2 22:54:21 EST 1992 Article: 107 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34615 alt.sys.pdp8:107 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Me and my PDP... (long) Message-ID: <1992Dec2.140917.3073@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: Date: Wed, 2 Dec 1992 14:09:17 GMT In article lape@me.chalmers.se (Lars Persson) writes: > >Here the two major bus types. UNIBUS and QBUS. The UNIBUS is a >replacement of the OMNIBUS (!) from the forerunner the PDP8. The UNIBUS Wrong: PDP-8 Positive buss: 1968. Cables between wire-wrapped assemblies. The cables are coax or flat ribbon only if run short. Buss is always synchronous. UNIBUS for 11/20 et al. 1969 (in prototypes). Wide flat ribbon cables between wire-wrapped assemblies. Buss is asynchronous to allow longer lengths. OMNIBUS for PDP-8/e et al. 1970. Buss is made from the same module blocks as the other busses but has a printed circuit board to interconnect all fingers in all slots; there are *no* exceptions, thus no dedicated slots (save the fact that the CPU stuff has to be at one end and the terminator at the other end more or less; newer configurations could even redefine which end was the "front"). Total buss length is 20 slots of module blocks. Similar to UNIBUS M920 buss jumpers (for short UNIBUS runs) are the M935 OMNIBUS jumpers which of course jumper all fingers (M920 do not; typical for UNIBUS it has exception cases and jumpered fingers, etc.). Two M935's are used to extend the buss when it is housed in the PDP-8/e box to a total of 40 slots (38 due to the overhead of the M935's themselves). (The smaller PDP-8/f and /m cannot be extended as such.) Several years later, the first attempt to expand this to a second box using BC08H cables. (BC08H is electrically an M935 only it looks like a UNIBUS cable, because all of these are made from the same wide flat stiff ribbon cable; again, BC08H is one-for-one on connection fingers whereas UNIBUS is not; had DEC rethought the implication of the few inconsistencies of the UNIBUS here, there would not have been two similar families of cables.) Many ECO's later, the attempt is actually viable thus allowing *reliable* operation of two boxes connected by cables. OMNIBUS is synchronous, which is part of the reason for all the problems with extending it. Later versions appear (PDP-8/a) with various similar cabling systems between boxes. The boxes get smaller (10,12,20 maximum) as the peripherals get smaller (but likely packaged on hex boards to give a theoretical boost of "real estate" of 50% if applicable, which often is *not* the case). The BC80C cable is created to connect between a hex box and a quad box. (BTW, this is the scheme of my own system.) Still later, the Q-bus appears in various formats. It is clearly a mechanical cousin of the OMNIBUS using a printed circuit board on the same blocks. The Q-BUS can be defined in two slots, but is often quad (while OMNIBUS is always quad). cjl From news.columbia.edu!sol.ctr.columbia.edu!eff!ssd.intel.com!prp Wed Dec 2 22:54:42 EST 1992 Article: 108 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!eff!ssd.intel.com!prp From: prp@ssd.intel.com (Paul Pierce) Subject: Re: Federated Consultants? Message-ID: Sender: usenet@SSD.intel.com Nntp-Posting-Host: nautilus Organization: Intel References: <1992Nov30.222516.2661@news.uiowa.edu> Date: Wed, 2 Dec 1992 18:44:51 GMT In article <1992Nov30.222516.2661@news.uiowa.edu>, jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: |> I tried mail and phone contact with Federated Consultants, and failed to |> make contact (the mail was returned as undeliverable, and the 800 number |> got me to some men's journal). Have they gone the way of the dinosaur? I just got mail from them. It lists a new phone number: 1-800-256-6732 I tried it, it works. They list Omnibus boards at $75 and up (way up). |> ESS Limited is still out there, and they list many Omnibus boards at |> $75 each (I just phoned them). Whats their contact info? |> Doug Jones |> jones@cs.uiowa.edu -- Paul Pierce prp@ssd.intel.com Intel From news.columbia.edu!sol.ctr.columbia.edu!emory!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!eddie.mit.edu!eplunix!ijs Thu Dec 3 19:00:07 EST 1992 Article: 109 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!emory!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!eddie.mit.edu!eplunix!ijs From: ijs@eplunix.UUCP (Ishmael J. Stefanov-Wagner) Newsgroups: alt.sys.pdp8 Subject: PDP8 Manuals available Message-ID: <1314a@eplunix.UUCP> Date: 3 Dec 92 14:47:15 GMT Organization: Eaton-Peabody Lab, Boston, MA Lines: 25 Available in Boston, Massachusetts - historic DEC PDP-8 manuals! You pick up... We have four boxes, approximately 1 cubit x 0.75 cubit x 0.5 cubit, full of historic DEC manuals, including various versions of the Small Computer Handbook from the late '60s and early '70s, Introduction to Programming, Programming Languages, Logic Handbook (detailed descriptions of the modules which make up PDP8s) etc. In addition there are some PDP-11/40 /35 etc paperbacks, plus software and peripherals manuals. These are an absolute must for the serious Digital Equ. Co. collector, but due to circumstances are bound for the dumpster unless someone rescues them before the Solstice! Possibly also available - DECUS PDP-8 dectapes, TU55 logic. Inquiries - Tel: 617-573-3748 / Fax: 617-720-4408 or via e-mail. |\___/| Ishmael J. Stefanov-Wagner |/. .\| Eaton-Peabody Laboratory, Boston, MA \=^=/ eplunix!ijs or ijs@eddie.mit.edu "If DEC can get their act together and start shipping them [the Alpha machine] in quantity, I think they've got a serious compute box on their hands for the first time since the PDP-8." --Steve P. Lamont From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Thu Dec 3 19:00:53 EST 1992 Article: 110 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: PDP8 Manuals available Sender: news@news.uiowa.edu (News) Message-ID: <1992Dec3.210824.5718@news.uiowa.edu> Date: Thu, 3 Dec 1992 21:08:24 GMT References: <1314a@eplunix.UUCP> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 23 >From article <1314a@eplunix.UUCP>, by ijs@eplunix.UUCP (Ishmael J. Stefanov-Wagner): > Available in Boston, Massachusetts - historic DEC PDP-8 manuals! > You pick up... I've got a growing collection of documentation, but I need more. Unfortunately, I can't get up to Boston before the solstace, but I'll gladly pay postage for some of the more choice manuals! If someone in the Boston area can help pick these up and mail them out, I'm looking for PDP-8/E and F documenation (1973 date on the cover is what I'm targeting), and I'm looking for peripheral equipment documentation from 1965 and 1966, specifically, for the DEC A-D converter, model 138E and for the high speed paper-tape reader punch interfaces from that era (Type 750C Perforated Tape Reader and Control, and Type 75E Perforated Tape Punch and Control). If DECtape hardware becomes available, I'd sure like to know, but the shipping to Iowa might be a bit steep. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Dec 7 22:25:40 EST 1992 Article: 111 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34884 alt.sys.pdp8:111 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec6.214758.3004@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Dec4.212403.10103@news.columbia.edu> <3633339@zl2tnm.gen.nz> Date: Sun, 6 Dec 1992 21:47:58 GMT In article <3633339@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes: > >> >True. Data General is interesting to DECaholics because of its origins; >> >earlier DG machines are in some ways what DEC machines might have been. >> >> It is interesting that Tracey Kidder steered away from this issue in the >> Soul of a New Machine book. Perhaps we should state our own versions of >> the tale as we see it. > >Well, my version of the tale, gleaned from multiple sources (including >Kidder) goes something like this: > >Edson de Castro worked on the PDP-8. When the call came for a 16 bit >machine, de Castro's group started work on what amounted to a 16 bit PDP-8 >(single word, single operand instructions, word oriented addressing etc). Edson de Castro was Chief Engineer of the original negative logic PDP-8. He wanted to work on the newer TTL that had just emerged as the obvious direction the industry was going in, and had little interest in the PDP-8/i project; he wanted something more challenging, such as a 16-bit machine that was in the "family" of machines such as the -8, but newer hardware. Apparently his "group" was as large as several hundred people working on what amounts to the NOVA as it became known later. Also, this design was partially serial, and thus vaguely reminiscent of this notion as carried out in the PDP-8/s, a losing totally serial version of an -8 that wasn't entirely compatible with it, and as such, is incapable of running the vast majority of PDP-8 software no matter how slowly it attempts it, etc. (It is curious that even years later there was a NOVA micro that was two-bit serial on the outside. These guys are hung up on the trade-off towards non-parallel designs!). Some quirky aspects of the NOVA are taken straight from the PDP-8, such as the special disposition of the auto-index registers, etc., so yes, the short-form of this discussion could be that the design was for a 16-bit follow-on to the PDP-8 family. > >Sometime after de Castro's group got started, another development got under >way, developing a 16 bit architecture with a multiple word two-operand >instruction set and half word oriented addressing. This group also had the >VP of Engineering's ear and blessing. As I heard it, it ain't as clean as that: C. Gordon Bell was technical god at DEC just then. He could do no wrong and had KO's ear for any purpose. Bell was into writing books at that time, and "Digital Press" was created as the outlet for his work, etc. Bell had designed a register-description notation as part of a book he was working on. It is a separate matter as to whether this notation is useful for describing machine architecture, but the relevant point is that *he* thought so. Apparently, two young relative newbies in DEC engineering read his work and used it to toy around with a new machine design (which eventually became the -11). Their work is not fully polished, and suffers from some inconsistencies. (Such as the condition codes aren't exactly the same as a result of an increment or decrement as opposed to adding or subtracting 1, or that byte forms of instructions don't quite set the same results as the word forms of the same instructions. The point is that a carefully planned work of architecture design would have located these shortcomings and corrected them. Much has been published about these issues elsewhere, etc.) It apparently came down to the fact that the "green light" had been given for the NOVA project, and sub-design teams formed, etc. Note that one of the design goals for this project was to use larger boards to overcome the limitations of FLIP-CHIP modules which can't have much functionality per card because of lack of fingers. Back in the negative logic days, a one-sided card with 18 fingers was generally adequate because you could only put so much discrete logic on a module. But de Castro realized that with the advent of TTL, merely making the cards double-sided wouldn't be enough. His idea has been vindicated since the next few DEC machines all suffer from the same problem: lots of little cards with mostly empty space on them. Using only two or three chips uses up all of the fingers, so you shortchange TTL's ability to downsize the design and only achieve 2-3 times the shrinking as compared to discrete negative logic using the same size cards with 36 fingers total. By using much larger cards, the chips interconnect, not the modules. Thus, the larger cards usefully are constructed from a decent number of TTL packages, and only a buss approach goes off the cards onto a goodly number of fingers. This eliminates a lot of wire-wrap and opens the possibility of making a pc-board buss such as the later OMNIBUS of the PDP-8/e. > >It came to a contest between the two architectures to produce what would be >the PDP-11. de Castro's group lost, and the PDP-11 became the two-operand >architecture we know and love. de Castro resigned immediately to set up >Data General. The first computer was the Nova, the architecture of which >looked *suspiciously* like that of the 16 bit computer he developed at >DEC..... The Nova became the Eclipse and then the 32 bit Eclipse MV series >in response to the release of the VAX 11/780 by DEC in 1977. The story is >taken up in detail from 1977 by Tracy Kidder's book. Bell's ego was stroked by the hasty work of the two newbies. He pulled all the strings he was capable of, including telling KO to pull the plug on the NOVA project because this was so much better than it wasn't worth persuing it anymore, even though hundreds of people were committed to it, etc. As a result of this politicizing, the -11 design was pushed through hurriedly, and didn't stop for any analysis of the design for holes, etc., so it was produced, horns and all, as originally specified, and onto a typical inefficient design with lots of little cards as the 11/20. (Admittedly some of the modules were a little bigger than the typical small M-series module, but then again this size also exists on certain PDP-8 peripherals as the "double-height" card in R-series, etc.) In fact, some of the mechanical parts of the 11/20 are identical to the 8/l and 8/e, proving that the details of the project were expediently handled, instead of doing a complete ground-up design as in the past. > >As to whether the pdp11 succeeded soley because the VP liked the guy >behind it, we'll never really know. That depends on the veracity of the story. Human nature being what it is, it is likely that some of the way it was retold to me is exaggerated. What is true, is that de Castro and 200 or so people quit DEC simultaneously and quickly formed DG and produced NOVAs from then onward. > However, the architecture *is* nice; >I'd say it has a lot less warts than the PDP-8 or PDP-10, given that it >is a 16 bit minicomputer architecture. Your opinion isn't a given, although I really don't want to open the topic about the -11 versus the -8 and company. However, it is sufficient to say that there are debatable issues about 16 bit machines in general, byte versus word addressing, and specifics regarding inconsistencies in the -11 design specifically, and whether or not a lot of its popularity stems from the usefullness of the software as opposed to the underlying architecture. (There are many people enamoured of RT-11, not the -11 per se. In fact, they want RT-32 or RT-64 for their favorite 32 or 64 bit designs, not -11 compatibility at all.) Moreover, it is clear that DEC imposed the -11 into some situations where clearly the -8 was more than adequate. In one infamous example, DG underbid DEC in selling a large number of systems to Disney because the NOVA systems were cheaper than DEC's -11-based offerings, and clearly the -8 could have brought in a more competitive system for the project. (From what I understand about the requirement, a modern version of this project would specify something akin to hundreds of 8051-class 8-bit controller micros, but they didn't exist back then.) > Competition is basically the way >development is done within DEC -- products fly or die on their merits (or >by favourably impressing an appropriate VP). People do resign over these >decisions; de Castro's case is only remarkable because he went and set up >a reasonably successful company in quite direct competition with DEC. True, but not useful; it's one of DEC's long-term major shortcomings that each project attempts to get funded by backstabbing everything else, and attempting snow jobs on technically incompetent upper management types. A notable example: the VAXmate, which was undeliverable for over two years, yet caused the cancellation of other viable projects while it stalled and eventually burned. > >Kidder does avoid the question of de Castro's departure, but he does >allude to some of the conflicts between DG and other parts of the computer >industry, especially DEC. It would be interesting to expand on these issues. Maybe DEC will not repeat their mistaken patterns of the past. > > >-- >Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) >Network Manager, Computing Services Centre don@vuw.ac.nz (work) >Victoria University of Wellington, New Zealand +64-4-495-5052 cjl From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don Mon Dec 7 22:29:33 EST 1992 Article: 112 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34915 alt.sys.pdp8:112 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <3250341@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 7 Dec 92 11:02:56 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <1992Dec6.214758.3004@news.columbia.edu> Distribution: world Organization: The Wolery Lines: 149 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > Edson de Castro was Chief Engineer of the original negative logic PDP-8. He [...] > C. Gordon Bell was technical god at DEC just then. He could do no wrong [...] > Bell's ego was stroked by the hasty work of the two newbies. He pulled all > the strings he was capable of, including telling KO to pull the plug on the > NOVA project because this was so much better than it wasn't worth persuing That basically gels with my rather wooly recollection. > >As to whether the pdp11 succeeded soley because the VP liked the guy > >behind it, we'll never really know. > That depends on the veracity of the story. Human nature being what it is, > it is likely that some of the way it was retold to me is exaggerated. What > is true, is that de Castro and 200 or so people quit DEC simultaneously and > quickly formed DG and produced NOVAs from then onward. One thing DEC always has been pretty good at is keeping its politics behind its doors; only when something genuinely visible happens (eg de Castro's departure, Jupiter's cancellation) does the brown stuff fly outside. > Your opinion isn't a given, although I really don't want to open the topic > about the -11 versus the -8 and company. However, it is sufficient to say Well, I do, since I'm a nit more in my depth... 8-) > that there are debatable issues about 16 bit machines in general, byte > versus word addressing, and specifics regarding inconsistencies in the -11 > design specifically, and whether or not a lot of its popularity stems from > the usefullness of the software as opposed to the underlying architecture. There are a lot of people who would put their hands on their hearts and say the -11 architecture is the nicest they've used. I'd be one of them. Personally, I feel the pdp11 instruction set has fewer warts on it than the VAX set in terms of overall consistency (if you ignore the FIS & CIS sets which were bags added to the side of the arhitecure later on). Bell's "golden boys" did a surprisingly good job, even if it was a bit rushed. The pdp11 also marked a noticable change in direction for instruction set architecures; up to then, all DEC machines had been word oriented and single word instructions. This development led on to the VAX architecture, which took multiple part instructions rather to extremes. Basically, DEC had gone for instructions that looked like: +--------+--------------------+ | opcode | operand | +--------+--------------------+ Now they were splitting the operand from the opcode: +-----------------------------+ | opcode | +-----------------------------+ | operand | +-----------------------------+ | operand | +-----------------------------+ They also did away with special registers and other warts on the architecture required when all the information about an instruction, *including* literals, was crammed into one word. Allowing for separate literals also means that you don't need to do segmentation to get a decent address space, which was a problem on all previous machines. It's interesting to note that many of the techniques used in the word- oriented machines are re-introduced in today's RISCs. However, there are differences: - RISCs generally do not use special registers for actions such as auto-increment. - RISCs usually have full-sized addressing once addresses are fetched into registers. On early DEC computers, the size of the operand literal field was also the limit of the virtual address space. - Many RISCs still use byte-oriented addressing. - On early DEC machines, the word orientation was to simplify the instruction decode; on RISCs the fixed instruction sizes are to keep the pipeline filling at a constant rate. Basically, the fact that the architectures "converged" again is largely co-incidence -- the reasons for doing it that way were very different in the 1960s to the reasons of the late 80s. It's hard to say if the movement of architectures towards multiple word multiple operand instruction sets throughout the 70s was spearheaded by the pdp11, or whether the pdp11 just rode the wave of development that culminated in the VAX. > (There are many people enamoured of RT-11, not the -11 per se. In fact, they > want RT-32 or RT-64 for their favorite 32 or 64 bit designs, not -11 There was always a cry for an "RT32" when the VAX came out as the pdp11's "successor". DEC almost supplied it in VAXeln, but it had the snag that development had to be done on a host (usually) VAX/VMS system; you could develop under VMS and reboot into VAXeln, but this proved unworkable for most developers, who either splashed out on an extra VAX, or (more often) stuck with their RSX or RT11 systems where they could both write and test their systems on the same box. The VAX never did "hard" realtime as well as the pdp11 either, largely because of the somewhat more baroque interrupt handling. > compatibility at all.) Moreover, it is clear that DEC imposed the -11 into > some situations where clearly the -8 was more than adequate. In one infamous DEC are good at that; as are others. Let's face it, DEC always pushed their latest snaziest boxes -- put yourself in the place of the salesdroid; would you say: "Here it is, it's been around for a while, it'll do the job." or "Here's our latest hot box!" (Remember, this is a salesdroid!) I suspect many "DEC blunders" have been just cases of the salesthing not quite reading the territory and getting it wrong. > True, but not useful; it's one of DEC's long-term major shortcomings that > each project attempts to get funded by backstabbing everything else, and > attempting snow jobs on technically incompetent upper management types. A > notable example: the VAXmate, which was undeliverable for over two years, yet > caused the cancellation of other viable projects while it stalled and > eventually burned. Whether the technique works or not depends a lot on the personalities; but I'd challenge you to demostrate any R&D management technique that doesn't have shortcomings, particularly that one. A project may get killed, but often the deveoplement work is put into practice eventually. For example, DEC actually had a RISC architecture going before they decided to go to MIPS chips; that work was not lost, but found its way into Alpha. > >Kidder does avoid the question of de Castro's departure, but he does > >allude to some of the conflicts between DG and other parts of the computer > >industry, especially DEC. > It would be interesting to expand on these issues. Maybe DEC will not > repeat their mistaken patterns of the past. I haven't followed DG much, but I often got the feeling they were soley after DEC's market, sort of like a small yappy dog (the kind you just want to step on) going for their heels, and largely leaving everyone else alone. It's a fairly common theme in Kidder that Eagle is soley an attempt to go after the VAX; the development is reactive rather than proactive. -- Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) Network Manager, Computing Services Centre don@vuw.ac.nz (work) Victoria University of Wellington, New Zealand +64-4-495-5052 From news.columbia.edu!rpi!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie Mon Dec 7 22:29:45 EST 1992 Article: 113 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34929 alt.sys.pdp8:113 Path: news.columbia.edu!rpi!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu (CP/M lives!) Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec7.102534.61745@cc.usu.edu> Date: 7 Dec 92 10:25:34 MDT References: <1992Dec6.214758.3004@news.columbia.edu> <3250341@zl2tnm.gen.nz> Distribution: world Organization: Utah State University Lines: 11 In article <3250341@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes: > For example, > DEC actually had a RISC architecture going before they decided to go to > MIPS chips; that work was not lost, but found its way into Alpha. A joke that I heard at a DEC site was that AXP stands for Almost eXactly Prism. -- Roger Ivie "My God! That computer is full of Pentium! ivie@cc.usu.edu It's a wonder that you haven't been turned into mutants!" From news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!stanford.edu!rock!concert!sas!mozart.unx.sas.com!sch Mon Dec 7 22:31:16 EST 1992 Article: 114 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34936 alt.sys.pdp8:114 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!stanford.edu!rock!concert!sas!mozart.unx.sas.com!sch From: sch@unx.sas.com (Steve Holzworth) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: Date: Mon, 7 Dec 1992 19:56:55 GMT References: <1992Dec6.214758.3004@news.columbia.edu> <3250341@zl2tnm.gen.nz> Nntp-Posting-Host: gargoyle.unx.sas.com Organization: SAS Institute Inc. Lines: 56 don@zl2tnm.gen.nz (Don Stokes) writes: >lasner@watsun.cc.columbia.edu (Charles Lasner) writes: stuff deleted >> >As to whether the pdp11 succeeded soley because the VP liked the guy >> >behind it, we'll never really know. >> That depends on the veracity of the story. Human nature being what it is, >> it is likely that some of the way it was retold to me is exaggerated. What >> is true, is that de Castro and 200 or so people quit DEC simultaneously and >> quickly formed DG and produced NOVAs from then onward. >One thing DEC always has been pretty good at is keeping its politics >behind its doors; only when something genuinely visible happens (eg de >Castro's departure, Jupiter's cancellation) does the brown stuff fly >outside. stuff deleted To further complicate things: I was told once that there used to be yet a THIRD group within DEC working on the "future PDP" who also lost out, and spun off into a company called GRI. They made a system called the GRIP. The only reason I heard this was that I used to work for a company that was involved in a triple merger, one component of which was GRI. It was mostly in decline, and was eventually shut down by the new parent company (Fulcrum Computer Group). Fulcrum was eventually sold to Adage, Inc., whose main goal was to acquire the Ikonas Graphics Systems component thereof (Ikonas was a high-end graphics hardware vendor in the late 70s, early 80s; sort of that era's Silicon Graphics...). Anecdote: Adage was a graphics vendor from the early/mid seventies. They had vector graphics with hardware transformations. The machine was also ONE'S COMPLEMENT math. Those negative zeros are a pain :-). >I haven't followed DG much, but I often got the feeling they were soley >after DEC's market, sort of like a small yappy dog (the kind you just want >to step on) going for their heels, and largely leaving everyone else alone. Several people here used to work at DG in Research Triangle Park. They actually had lots of innovative hardware in development. Invariably, the idiots in the front office wouldn't understand the signifigance of the advance and would shut down the effort before it hit the market. >-- >Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) >Network Manager, Computing Services Centre don@vuw.ac.nz (work) >Victoria University of Wellington, New Zealand +64-4-495-5052 -- Steve Holzworth sch@unx.sas.com "Do not attribute to poor spelling x6872 That which is actually poor typing..." SAS Institute - Open Systems R & D - me Cary, N.C. From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf Mon Dec 7 22:32:25 EST 1992 Article: 115 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:34946 alt.sys.pdp8:115 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec7.222047.3069@dptg.att.com> Organization: AT&T/NCR, Lincroft, NJ, USA References: <1992Dec4.212403.10103@news.columbia.edu> <3633339@zl2tnm.gen.nz> <1992Dec6.214758.3004@news.columbia.edu> Distribution: na Date: Mon, 7 Dec 1992 22:20:47 GMT Lines: 32 In article <1992Dec6.214758.3004@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >Apparently, two young relative newbies in DEC engineering read his work and >used it to toy around with a new machine design (which eventually became the >-11). Their work is not fully polished, and suffers from some inconsistencies. >(Such as the condition codes aren't exactly the same as a result of an >increment or decrement as opposed to adding or subtracting 1, or that ^^^^^^^^^^^^^^^^^^^^^^ >byte forms of instructions don't quite set the same results as the word forms >of the same instructions. The point is that a carefully planned work of >architecture design would have located these shortcomings and corrected them. >Much has been published about these issues elsewhere, etc.) > There is actually more thought invested in the 11's instruction set than meets the eye. The reason 'inc' and 'dec' don't modify the Carry bit is to allow for inc's and dec's on loop counters in multi-word arithmetic routines that need to propogate the C-bit and shouldn't have to waste time saving and restoring it. After an add #1, or sub #1, the C- and Z-bits are always the same. BNE is equivalent to BCC after an increment or decrement. This "feature" caused me a bit of pain at a little after 18:00 hours one day back in 1975 in the basement of the "mill". My check for overflow after an inc on the low order word of the "seconds since midnite" counter was a BCC that would _always_ branch. Noto Bne! bob. | Heap big trouble in the land of plenty. Were these more than just my opinions, they would have cost a bit more. From news.columbia.edu!rpi!usc!enterpoop.mit.edu!eff!world!iecc!johnl Mon Dec 14 04:05:28 EST 1992 Article: 116 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35277 alt.sys.pdp8:116 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!enterpoop.mit.edu!eff!world!iecc!johnl From: johnl@iecc.cambridge.ma.us (John R. Levine) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Organization: I.E.C.C. Date: Sun, 13 Dec 1992 19:09:31 GMT Message-ID: <1992Dec13.190931.18700@iecc.cambridge.ma.us> References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> Lines: 39 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >It apparently came down to the fact that the "green light" had been given >for the NOVA project, and sub-design teams formed, etc. Note that one of >the design goals for this project was to use larger boards to overcome the >limitations of FLIP-CHIP modules which can't have much functionality per >card because of lack of fingers. ... Actually, there was a sensible reason that DEC used small cards. The PDP-6 (the machine that the PDP-10 was almost as good as) used great big cards with lots of pins per connector. Unfortunately, the connectors didn't work very well. A standard diagnostic technique when a PDP-6 was flaking was to open the back and hit all the modules with a rubber mallet. For that among other reasons the PDP-6 was a marketing failure and they only built 20 of them. The later KA10, the first PDP-10, used small Flip-Chip modules the same size as the ones used in the wildly successful original PDP-8. (The -10 was mostly B series modules, which were faster than the R and S series used in the PDP-8.) It wasn't until the PDP-11/45 that DEC found large connectors in which they had confidence, and even then, the 11/45's cards had little latches that you used to force the connectors very firmly into their sockets. As far as the Nova ripping off DEC goes, I have a copy of ``How to use the Nova and the Supernova,'' the programmer's manual for DG's first two machines, dated 1970. The design and typography are exactly the same as in the DEC PDP-10 manual. It was written by William English, who wrote the PDP-10 manual. On page 2-44, when discussing the memory protection feature, it says ``In particular, do not execute a JSR into a protected page,'' a piece of advice that also appears almost verbatim in the PDP-10 manual. But the Nova's JSR saved its return address in a register, causing no problem when jumping into a read-only segment, while the PDP-10's JSR stored the return address at the jumped-to location, which doesn't work in read-only memory. Oops. Wrong computer. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl "Time is Money! Steal some today!" From news.columbia.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Mon Dec 14 04:06:27 EST 1992 Article: 117 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35278 alt.sys.pdp8:117 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Hammers (Was: The NOVA and the PDP-11) Sender: news@news.uiowa.edu (News) Message-ID: <1992Dec13.210542.26834@news.uiowa.edu> Date: Sun, 13 Dec 1992 21:05:42 GMT References: <1992Dec13.190931.18700@iecc.cambridge.ma.us> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 36 >From article <1992Dec13.190931.18700@iecc.cambridge.ma.us>, by johnl@iecc.cambridge.ma.us (John R. Levine): > > Actually, there was a sensible reason that DEC used small cards. The > PDP-6 (the machine that the PDP-10 was almost as good as) used great big > cards with lots of pins per connector. Unfortunately, the connectors > didn't work very well. A standard diagnostic technique when a PDP-6 was > flaking was to open the back and hit all the modules with a rubber mallet. The PDP-11/20 may have been made with small cards, but this didn't fix the problem. We had an 11/20 at the University of Illinois, and as it aged, cards began to get loose, and the common fix was to gently kick the underside of the machine to reseat the cards. On failure, you'd kick it and reboot, and only if that failed was it worth trying anything more impressive. Kicking seemed to work about 90% of the time. The machine was rack-mounted, but there was nothing under the CPU, and the blank panels had long since been removed from that space by 1973 when this story takes place. To understand why it worked, you have to know that the PDP-11/20 was mounted with the wire-wrapped backplane on top and the cards pushed in from the bottom. The mounting slides were tiltable, so you could pull the box out of the rack and tilt it up to face the boards towards you, or tilt it down to face the backplane towards you. The boards were retained in their slots by the foam lining on the inside of the bottom cover of the CPU. This foam was stiff grey stuff, a type still commonly used for padding electronics. The problem is, the stuff ages, particularly in a warm environment, and as it ages, it looses its spring and becomes mushy. The CPU was in a high noise environment (a card reader and line printer were right there), and I gather that the vibrarion was enough to work cards loose after the foam lost its spring. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sol.ctr.columbia.edu!eff!world!dp Mon Dec 14 04:07:55 EST 1992 Article: 118 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35289 alt.sys.pdp8:118 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sol.ctr.columbia.edu!eff!world!dp From: dp@world.std.com (Jeff DelPapa) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> Date: Mon, 14 Dec 1992 00:38:48 GMT Lines: 53 In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>It apparently came down to the fact that the "green light" had been given >>for the NOVA project, and sub-design teams formed, etc. Note that one of >>the design goals for this project was to use larger boards to overcome the >>limitations of FLIP-CHIP modules which can't have much functionality per >>card because of lack of fingers. ... > >Actually, there was a sensible reason that DEC used small cards. The >PDP-6 (the machine that the PDP-10 was almost as good as) used great big >cards with lots of pins per connector. Unfortunately, the connectors >didn't work very well. A standard diagnostic technique when a PDP-6 was >flaking was to open the back and hit all the modules with a rubber mallet. >For that among other reasons the PDP-6 was a marketing failure and they >only built 20 of them. One peice of (likely) apocrapha regarding the nova board size... It seems that a number of people at dec had pdp-8's in their basement built in the same mode as the Cadillac in that old country standard "one peice at a time". DG as cost conscious as it ever was, supposedly designed Nova boards such that they wouldn't fit in breifcases, printouts, or under the coat (no matter how fat the wearer of the coat). the following are supposedly not apocrapha: DG didn't want cloned memory boards, and had one trace on their memory board that had an inconspicious break - the sort that someone trying to copy the board would assume was a bad spot on the copy and fix - this would connect the +12 supply line to the core stacks sense wire - powering up such a board would let all of the magic smoke out of the core stack. On the nova 1200's, there was a power supply crowbar module. It was potted, they were assembled by a single technician, and no prints of the thing were available. This module was also the source of some of the timing signals. It was a $500 part from field service. I saw one that the potting had been carefully removed from - it contained 6 chips. (numbers were removed, possibly by the removal of the potting, so I cannot give an accurate actual cost estimate) The novas had power fail restart as a $250 option. It was implemented (on the 1200 anyway) by two chips (a comparator and a latch I think, tho it may have been a one-shot and a gate) on one of the CPU cards. By default the chips were installed on all boards manufactured, and diked out if not ordered. The going rate for a bootleg installation from the field service techs was $50 (the chips cost about $0.45). From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Dec 14 04:08:32 EST 1992 Article: 119 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35306 alt.sys.pdp8:119 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec14.090519.6278@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> Date: Mon, 14 Dec 1992 09:05:19 GMT In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>It apparently came down to the fact that the "green light" had been given >>for the NOVA project, and sub-design teams formed, etc. Note that one of >>the design goals for this project was to use larger boards to overcome the >>limitations of FLIP-CHIP modules which can't have much functionality per >>card because of lack of fingers. ... > >Actually, there was a sensible reason that DEC used small cards. The >PDP-6 (the machine that the PDP-10 was almost as good as) used great big >cards with lots of pins per connector. Unfortunately, the connectors >didn't work very well. A standard diagnostic technique when a PDP-6 was >flaking was to open the back and hit all the modules with a rubber mallet. >For that among other reasons the PDP-6 was a marketing failure and they >only built 20 of them. Two things: First of all, those big connectors don't really have more pins, they have bigger pins, and they're gold-plated, but because they are short, they can be flakey, especially with a massive card on the other end of the connector, so it's a matter of bad choice of connector mechanism, not quantity of connections. Also, the PDP-6 and KA-10 era doesn't have the problems I'm talking about, namely when TTL came into vogue. Now you had too much logic and not enough local interconnect if the only way to interconnect was at a module level with only 36 pins total. So, bigger cards allows for more pins to interconnect with, and encourages local chip interconnections that are not brought out to the connector at all. Second, I heard they made 20 PDP-6's, yet someone else insists 23. > >The later KA10, the first PDP-10, used small Flip-Chip modules the same >size as the ones used in the wildly successful original PDP-8. (The -10 >was mostly B series modules, which were faster than the R and S series >used in the PDP-8.) It wasn't until the PDP-11/45 that DEC found large >connectors in which they had confidence, and even then, the 11/45's cards >had little latches that you used to force the connectors very firmly into >their sockets. Wrong, the Omnibus predates the 11/45, and uses multiple connectors of the small variety on a big card. The hex boards were used in those -11's and then the 8/a. I'm not sure if hex boards predate Q-bus, but in any case the Omnibus is older than both of them, and was being developed at about the same time as the UNIBUS itself, although not made out of hex boards back then. [good stuff deleted] Since they had the "style" of the 36-bits, and the "guts" of the 12-bits, DG was a "generic" DEC rip-off. In any case, that's what happens when you pull the plug of a carefully planned project over a hastily formed weekend. cjl From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!sinshan.citi.umich.edu!sarr Mon Dec 14 21:37:35 EST 1992 Article: 120 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35315 alt.sys.pdp8:120 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!sinshan.citi.umich.edu!sarr From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson) Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Date: 14 Dec 1992 14:24:29 GMT Organization: University of Michigan, CITI Lines: 18 Distribution: world Message-ID: <1gi5etINNoa1@terminator.rs.itd.umich.edu> References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> NNTP-Posting-Host: sinshan.citi.umich.edu In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: > >Actually, there was a sensible reason that DEC used small cards. The >PDP-6 (the machine that the PDP-10 was almost as good as) used great big >cards with lots of pins per connector. Unfortunately, the connectors >didn't work very well. A standard diagnostic technique when a PDP-6 was >flaking was to open the back and hit all the modules with a rubber mallet. >For that among other reasons the PDP-6 was a marketing failure and they >only built 20 of them. > Some of this, of course, was due to DEC's fondness for using vertical backplanes where the connector was the _only_ mechanical support the cards had. I once watched some slighly inebriated movers run a KA-10 up a ramp a little too hard; some of the noards just popped out. Of course after we put them back in it worked fine. (Sarr Blumson) From news.columbia.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol Wed Dec 16 23:41:14 EST 1992 Article: 121 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35394 alt.sys.pdp8:121 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec16.213124.1@cc.curtin.edu.au> Lines: 15 Sender: news@cujo.curtin.edu.au (News Manager) Organization: Curtin University of Technology References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> Date: Wed, 16 Dec 1992 12:31:24 GMT In article <1992Dec13.190931.18700@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes: > Actually, there was a sensible reason that DEC used small cards. The > PDP-6 (the machine that the PDP-10 was almost as good as) used great big > cards with lots of pins per connector. Unfortunately, the connectors > didn't work very well. A standard diagnostic technique when a PDP-6 was > flaking was to open the back and hit all the modules with a rubber mallet. > For that among other reasons the PDP-6 was a marketing failure and they > only built 20 of them. > Bzzzt. You are thinking of the CDC6x00 and Cybers. The prob with the 6's cards was that they where SOLDERED in, some on BOTH sides... ~Paul From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!rose.eecs.nwu.edu!holmer Sat Dec 19 04:14:03 EST 1992 Article: 123 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!rose.eecs.nwu.edu!holmer From: holmer@rose.eecs.nwu.edu (Bruce Holmer) Subject: Request for benchmark programs Message-ID: <1992Dec18.171533.28557@eecs.nwu.edu> Sender: usenet@eecs.nwu.edu (Mr. Usenet) Organization: EECS Department, Northwestern University Date: Fri, 18 Dec 1992 17:15:33 GMT Lines: 19 This might sound strange, but does anyone have PDP-8 assembly code for some smallish benchmark programs? I can write these myself, but I thought I might check to see if they already exist.... I'm looking for things like the old Byte benchmarks (circa 1981) or the benchmarks used in the first RISC articles (e.g. Patterson/Sequin, Computer Magazine, Sept. 1982). Things like sieve, sort (quicksort, heapsort, etc.), string move, string search, ackerman, simple puzzle solvers, matrix operations, software floating point, etc. I'll be running these on a simulator, so I'll just initialize the memory, run the code, and look at the results in memory (that is to say, I can do with just subroutines for most of the simple stuff). Thanks, --Bruce Holmer holmer@eecs.nwu.edu From news.columbia.edu!rpi!uwm.edu!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!tyzuk Sat Dec 19 04:14:23 EST 1992 Article: 124 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35524 alt.sys.pdp8:124 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!tyzuk From: tyzuk@cs.UAlberta.CA (Tyzuk William N) Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: Sender: news@cs.UAlberta.CA (News Administrator) Nntp-Posting-Host: manning.cs.ualberta.ca Organization: University of Alberta, Edmonton, Canada References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> <1992Dec16.213124.1@cc.curtin.edu.au> Date: Fri, 18 Dec 1992 21:22:58 GMT Lines: 22 zrepachol@cc.curtin.edu.au writes: >In article <1992Dec13.190931.18700@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes: >> Actually, there was a sensible reason that DEC used small cards. The >> PDP-6 (the machine that the PDP-10 was almost as good as) used great big >> cards with lots of pins per connector. Unfortunately, the connectors >> didn't work very well. A standard diagnostic technique when a PDP-6 was >> flaking was to open the back and hit all the modules with a rubber mallet. >> For that among other reasons the PDP-6 was a marketing failure and they >> only built 20 of them. >> >Bzzzt. You are thinking of the CDC6x00 and Cybers. The prob with the 6's cards >was that they where SOLDERED in, some on BOTH sides... Lessee now... I think it was a CDC1700 mini that had a 256k word (??) drum (actually a disk but they called it a drum) which came with a plastic hammer and maintenance manual which prescribed tapping the cards with the hammer to cure intermittant faults! This was an actual recommended and authorized maintenance procedure! Sigh.... the good ol' days :-) NOT. From news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!cunixb.cc.columbia.edu!slb22 Sat Dec 19 04:14:37 EST 1992 Article: 125 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35527 alt.sys.pdp8:125 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!cunixb.cc.columbia.edu!slb22 From: slb22@cunixb.cc.columbia.edu (Seth "the Lesser") Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) References: <1992Dec13.190931.18700@iecc.cambridge.ma.us> <1992Dec16.213124.1@cc.curtin.edu.au> Sender: nobody@ctr.columbia.edu Organization: Generic American College Kids (G.A.C.K.) Date: Fri, 18 Dec 1992 22:35:34 GMT Message-ID: <1992Dec18.223534.19725@sol.ctr.columbia.edu> Reply-To: slb22@cunixb.cc.columbia.edu (Seth "the Lesser") X-Posted-From: cunixb.cc.columbia.edu NNTP-Posting-Host: sol.ctr.columbia.edu Lines: 17 tyzuk@cs.UAlberta.CA (Tyzuk William N) writes: > >Lessee now... I think it was a CDC1700 mini that had a 256k word (??) >drum (actually a disk but they called it a drum) which came with a plastic >hammer and maintenance manual which prescribed tapping the cards with >the hammer to cure intermittant faults! This was an actual recommended and >authorized maintenance procedure! Sigh.... the good ol' days :-) NOT. Good ol' days my bleeding arse. We have a pack of Sun SPARCstations here at CTR with cut-rate hard drives that freeze up whenever we power down. The best way to unfreeze them (saith my boss, and I've seen him do it with excellent results) is to tap them with a hammer. Lightly, of course. Seth L. Blumberg \ Warning: This posting has been determined to cause slb22@columbia.edu (play) \ cancer in laboratory animals. Please make sure sethb@ctr.columbia.edu (work) \ that no white mice are allowed to read it. > No one I know shares my opinions, least of all Columbia University. < From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!delta!holmer Sat Dec 19 04:14:52 EST 1992 Article: 126 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!delta!holmer From: holmer@eecs.nwu.edu (Bruce Holmer) Subject: Request for instruction cycle counts Message-ID: Sender: usenet@eecs.nwu.edu (Mr. Usenet) Organization: EECS Department, Northwestern University, Evanston, Il., USA Date: Fri, 18 Dec 1992 23:42:07 GMT Lines: 9 Does someone have a table of instruction cycle counts for a high-end PDP-8? I'd need to know about how many cycles the different addressing modes require and how to calculate the cycle count for the OPR instructions. Thanks, --Bruce From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Dec 19 04:39:47 EST 1992 Article: 127 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Request for instruction cycle counts Message-ID: <1992Dec19.093750.7276@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: Date: Sat, 19 Dec 1992 09:37:50 GMT In article holmer@eecs.nwu.edu (Bruce Holmer) writes: > >Does someone have a table of instruction cycle >counts for a high-end PDP-8? I'd need to know >about how many cycles the different addressing >modes require and how to calculate the cycle >count for the OPR instructions. > >Thanks, >--Bruce It's interesting timing that you ask for benchmarks as there is another simulator soon to make the light of day. This one is for a *real* PDP-8 meaning it supports peripherals including disks. It's specifically for 80286 and up machines with HD diskette drives. The author cannot currently post to usenet but can e-mail, etc. He wants representative code so that he can determine the ratio of PDP-8 to simulator performance using a wide variety of programs, etc. Not counting the 6120 cycle time, which is somewhat erratic depending on which instructions specifically we call out, it's best to stick to the 8/e processor with static memory for timing. This is the most common configuration anyway. All OPR instructions are 1.2 microseconds each regardless of group or outcome of any test. All internal IOT instructions are also 1.2 microseconds unless "stretched" by a peripheral using the NOT LAST TRANSFER line on the OMNIBUS. If the cycle is external, and there actually is a KA8E installed, the cycle will be stretched my an amount determined by the KA8E, and can be adjusted to many microseconds to accomodate very long (over 50 foot) external positive and/or negative busses. All other instructions are two-cycle and thus take 2.6 microsends, or if indirect are 3.8 microseconds unless auto-indexed in which case make that 4.0 microseconds. If EAE is present, various group 3 instructions are implemented that take a varying amount of time such as long shifts which are shift-count dependent for total execution time, and there are many different timings for each of the different instructions. In some cases, instruction timing can also be affected by auto-indexing operations, such as when the EAE diagnostic places a MUY instruction into location 00007 so that the operand pointer is in location 00010 thus causing an auto-index as a "feature". All of these timings assume no memory collisions such as occur when the MOS memory cards (DRAM) are used, or if DMA is occuring simultaneously. There is no pipelining used, although the architecture would easily allow it. There is some instruction prefix optimization in the 6120 implementation, thus instruction times widely vary with respect to the 8/e. Some are marginally faster, yet others are quite a bit slower. By using a short buss, it is possible to "tweak" the CPU timing to get speeds about 20% better than this accurate nominal speed (crystal-controlled). CESI is/was marketing a replacement VLSI processor that was/is quite a bit faster, etc. cjl From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Mon Dec 21 06:34:13 EST 1992 Article: 129 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: Request for instruction cycle counts Sender: news@news.uiowa.edu (News) Message-ID: <1992Dec20.234924.16714@news.uiowa.edu> Date: Sun, 20 Dec 1992 23:49:24 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 28 >From article , by holmer@eecs.nwu.edu (Bruce Holmer): > > Does someone have a table of instruction cycle > counts for a high-end PDP-8? I'd need to know > about how many cycles the different addressing > modes require and how to calculate the cycle > count for the OPR instructions. There were two different memory cycle times on the PDP-8/E (that was probably the highest of the high-end PDP-8 machines): 1200ns and 1400ns. An instruction fetch was one short cycle. Indirect addressing cost one short cycle, unless it was through an autoindex register, in which case you pay for a long cycle. Operand fetch for AND and TAD cost one long cycle. Operand fetch/increment/store for ISZ cost one long cycle. Operand store for DCA and JMS cost one long cycle. JMP cost nothing other than the instruction fetch and indirect cycles. IOT to omnibus peripherals cost nothing beyond the instruction fetch cycle. OPR for non EAE instructions cost nothing beyond the instruction fetch cycle. These figures are for the standard PDP-8 memory, and must be adjusted if you want to talk about the various strange things that happened when they abandoned core, particularly, it should be noted that the ROM technology of the mid 1970's was a bit on the slow side. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!spool.mu.edu!olivea!uunet!unislc!thayne Mon Dec 21 18:36:57 EST 1992 Article: 130 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:35621 alt.sys.pdp8:130 Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!spool.mu.edu!olivea!uunet!unislc!thayne From: thayne@unislc.uucp (Thayne Forbes) Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11) Message-ID: <1992Dec20.000558.23826@unislc.uucp> Date: 20 Dec 92 00:05:58 GMT References: <1992Dec18.223534.19725@sol.ctr.columbia.edu> Organization: HomeVax Lines: 27 X-Newsreader: TIN [version 1.1 PL6] Seth the Lesser (slb22@cunixb.cc.columbia.edu) wrote: : tyzuk@cs.UAlberta.CA (Tyzuk William N) writes: : > : >Lessee now... I think it was a CDC1700 mini that had a 256k word (??) : >drum (actually a disk but they called it a drum) which came with a plastic : >hammer and maintenance manual which prescribed tapping the cards with : >the hammer to cure intermittant faults! This was an actual recommended and : >authorized maintenance procedure! Sigh.... the good ol' days :-) NOT. : : Good ol' days my bleeding arse. We have a pack of Sun SPARCstations here at : CTR with cut-rate hard drives that freeze up whenever we power down. The best : way to unfreeze them (saith my boss, and I've seen him do it with excellent : results) is to tap them with a hammer. Lightly, of course. : This time honored maintenance technique was in real danger of becoming a lost art a few years ago, but Apple came to our rescue and rejuvinated it with the introduction of Quantum 40 (and I think Quantum 80) drives, which regularly refused to spin up after cold boot. At the time we (Unisys) were about to use the same drives in a $1 Billion PC contract, and I can tell you we didn't know whether to snicker about Apple, or sweat bullets because we couldn't figure out why they worked so well for us. Turns out to have been an electrical problem (which some electrically literate Mac user will have to explain) which we didn't suffer from because of our monster power supplies. We did suffer a few very nervous days investigating tho. -- Thayne Forbes thayne@unislc.slc.unisys.com