|This is the talk page for discussing improvements to the PDP-10 article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing||(Rated Start-class)|
MIT and BBN KA-10 pagers
According to Tom Knight:
- Holloway designed the pager for ITS long before Tenex existed. They asked us what instructions we used, so that the XCTR instruction is semi-compatible, at least in opcode.
in case anyone wants to know what the support data is for this claim. Noel 12:50, 26 Oct 2004 (UTC)
Failure of the Jupiter project???
I was working at DEC Marlboro in 1983, when Jupiter was cancelled and the end of LCG was mandated. The Jupiter project was progressing well at that point; problems in the new system development were not the cause for the cancellation of the project or the end of LCG. I'm about to edit the page to reflect this, since there doesn't seem to have been any previous discussion of the issue here (I wanted to check in case it was controversial). Dd-b 21:51, 11 Mar 2005 (UTC)
- What was the name of the Jupiter processor? Someone just edited KC10 (which sounds right) into the article and someone else reverted it right back out.
- Atlant 17:49, 25 January 2006 (UTC)
- To the very best of my knowledge, KC10 was the designation for what would have been the Jupiter processor/2080 (or possibly 4050 - see http://groups.google.co.uk/group/alt.sys.pdp10/browse_thread/thread/ccb4757495e65a4a/a1054421a0f21923?hl=en&ie=UTF-8&q=KC10+group:alt.sys.pdp10#a1054421a0f21923). The wise heads of the 36-bit community say so, at least, and they ought to know, many having been DEC techies back in the day. There's also plenty of documentation available about the KC10: for example, ftp://ftp.stacken.kth.se/pub/pdp10/KC10.pdf (see the Dept: header for the mention of Jupiter).
- For example, take a look at Phil Budne's list of PDP-10 devices (http://www.ultimate.com/phil/pdp10/10periphs):
- KA10 Original PDP-10 CPU; used in 1010/1020/1030/1040/1050/1055
- KC10 "Jupiter" CPU [cancelled] to be used in 2080 (later 4050)
- KI10 Second PDP-10 CPU ("I" for Integrated Circuits); used in 1070/1077
- KL10 Third PDP-10 CPU (ECL logic) used in 108x/109x/2040/2050/206x
- KO10 "Minnow" deskside CPU (cancelled before TOPS-20 debug complete)
- KS10 Fourth PDP-10 CPU ("Small") used in 2020
- On rummaging around, I've also found mention of "Dolphin", which was probably designated the KXF-10 (http://bitsavers.org/pdf/dec/pdp10/KXF10_Dolphin/Dolphin_Diagnostic_Plan_Feb78.pdf); and you might find this interesting (http://groups.google.co.uk/group/alt.sys.pdp10/browse_thread/thread/1dd9f4d09329411c/cc3450caeed66dcc?hl=en&ie=UTF-8&q=Dolphin+group:alt.sys.pdp10#cc3450caeed66dcc), since it mentions "Unicorn" (unknown designation) which preceded Dolphin.
- At the time of the Jupiter cancellation, however, the word-of-mouth among long-time users of PDP-10s was that there was a serious design defect. Supposedly the person primarily responsible for the Jupiter's design had been hired from IBM and didn't realize the extensive use of the indirect addressing bit. As a result, the performance of instructions using it was, umm, less than optimal and the overall system performance was only slightly better than that of a KL-10.
- Seldenball 20:15, 21 August 2007 (UTC)
- As owner of a both a DECSystem10 and a VAX I was participating in a non-disclosure presentation of Jupiter. My very first feeling was that the lack of extending the directly addressable memory (without memory management) would give the killing stroke to the whole product line. According to the rumours I head before I had expected a step as courageously trend-setting as that from PDP-11 to VAX.
Capitalization of title of system reference manual
I'm not convinced that the change in capitalization of the title of the system reference manual was appropriate; the manual cover gives the title starting with "decsystem10". The capitalization and hyphenation varied over the years. --Brouhaha 07:28, 6 September 2005 (UTC)
- You may be right, now that I think of it. (It's been a long time since I JRST'ed). --Rogerd 17:39, September 6, 2005 (UTC)
- I was also certain that at least some of the documentation and logos used the "decsystem" form as well, but then again, the overall form of the logo varied a lot among the -10s and -20s, and I can never remember exactly which ones used which styles ('cept that '10s were blue and 20s were "China Red" which is really orange).
- Maybe someone can Google-up some pictures and check for sure?
- Atlant 17:11, 7 September 2005 (UTC)
Wire wrap panels
From the article "with automated wire-wrap back panels." The back panels would be more properly called backplanes and they were made with a semi-automated process.
The backplane was positioned in front of an assembler. Between the assembler and the backplane was an arm running on an X-Y positioning system. The arm had a V-shaped groove on its end. The operator would touch a foot pedal and the arm would move to the coordinates of the first wire-wrap pin. At the same time, a lamp would light above one of many bins of different lengths of precut and stripped wire. She would take a length of wire, insert it into her wire wrap gun, place the gun onto the pin pointed to by the arm and install the wire. She would then touch the foot pedal again and the arm would move to the wire endpoint where she would secure it. She would repeat the process until the backplane was done.
I don't know if any of this is relevant to the article. Someone might find it useful. I'd like to change back panels to backplanes and automated to semi-automated if there are no objections.
I'd also point out the the phrase Wire-Wrap is a trademark of what was then Gardner-Denver, now Cooper Group and as such should at least be capitalized and hyphenated. -- Grumpyoldgeek 17:33, 13 November 2005 (UTC)
- Automated wire-wrap did exist. I don't know whether DEC used automated or semi-automated. "Panel" was standard terminology for something you wire-wrapped; in this case I think either term is acceptable, but backplane is probably slightly more meaningful. --Brouhaha 07:46, 13 November 2005 (UTC)
- "Automated wire-wrap did exist." No doubt. OTOH, what I described is the way the machines were built at the Mill in 1972 and that's what the article discusses. I spent several lunch breaks watching and chatting with the assemblers as they wired the backplanes. --Grumpyoldgeek 17:33, 13 November 2005 (UTC)
Can we see about getting some free-use images of PDP-10 and assorted goodies? Anyone have any to share? /Blaxthos 03:07, 31 March 2007 (UTC)
The page introduction says "The first model was delivered in 1966", while the first section of the article says "The original PDP-10 processor was the KA10, introduced in 1968". Can someone with access to contemporary records provide an unambiguous timeline? If those two dates had been reversed, I might suspect that the product was announced in one year, then delivered two years later, but the current text precludes that interpretation. 126.96.36.199 (talk) 11:42, 26 September 2010 (UTC)
- This PDP_Tree_Poster_1980.jpg published by Gordon Bell suggests that 1966 is the better choice.--Jkbw (talk) 01:50, 27 September 2010 (UTC)
unique byte instructions
The spirit of the statement in the intro about the pdp10 having a unique set if byte-within-word instructions is certainly correct, but it needs a note to point out that other machines have instructions that operate on bitfields within machine words, the Vax for example iirc, albeit without the sequential bitfield iteration support of the pdp10. Is there a way I could put in a suitable footnote, without disturbing the intro as it stands?CecilWard (talk) 15:06, 1 March 2012 (UTC)
- In case anyone else is still interested in this old question, there is an article on Bolt, Beranek, and Newman, although the name of the company has changed in the decades since they helped create the ARPAnet. 16:04, 17 June 2014 (UTC)
Communications I/O and data paths
IIRC, asynchronous serial communications (for terminal displays, printers, and modems) was handled by the PDP-11/40 front-end in behalf of the KL10 processor. The MassBus channel was used for disk and tape transfers, and was connected directly to a controller on the KL10, bypassing the front-end. As of this writing, the article glosses over the I/O architecture and data paths, and doesn't mention async serial communications at all. I don't have access to the tech ref manuals any more, so this is just my recollection from managing a KL10 installation a quarter-century ago. If somebody has a clear diagram of the basic data paths, adding it to the article would make this more understandable. Reify-tech (talk) 03:49, 27 September 2015 (UTC)
- Sounds fine to me, but that still leaves the I/O paths for the KA10, KI10, and KS10 to write about. Do all interrupt on every character of serial I/O? Gah4 (talk) 01:49, 29 September 2015 (UTC)
- That would depend on the serial interface in question. The DZ11, an early Unibus multiport serial interface, did have some small FIFO buffers for both transmit and recieve, much like an 8250 or 16550 (if I remember those numbers correctly), so even the poor beleagured 11/40 was not coping with an interrupt per character except for manually-typed input... which would generally be too slow for those interrupts to matter much. I don't know if they had similarly FIFOd serial interfaces for the earlier Kx10's. But certainly it was possible to build FIFO-equipped serial interfaces even in those primitive times. :) Jeh (talk) 01:54, 29 September 2015 (UTC)