From vu0350@bingsuns.cc.binghamton.edu Tue Aug 3 05:09:31 EDT 1993 Article: 319 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!news.kei.com!ub!newserve!bingsuns.cc.binghamton.edu!not-for-mail From: vu0350@bingsuns.cc.binghamton.edu (alley cat) Newsgroups: alt.sys.pdp8 Subject: Free Kennedy 9600 tape unit (FWD) Date: 2 Aug 1993 08:15:12 -0400 Organization: Binghamton University, Binghamton, NY Lines: 34 Distribution: world Message-ID: <23j0gg$ov1@bingsuns.cc.binghamton.edu> NNTP-Posting-Host: bingsuns-gw.cc.binghamton.edu DO NOT RESPOND DIRECTLY TO THIS POSTING!!! ...i am simply forwarding it; please respond to the person whose name/address appears in the header below... =================================================================== >From newserve!ub!rutgers!cmcl2!plym.smusic.nyu.edu!user Mon Aug 2 08:12:48 EDT 1993 Article: 2058 of ny.forsale Path: newserve!ub!rutgers!cmcl2!plym.smusic.nyu.edu!user From: plym@nyu.edu (Don Plym) Newsgroups: ny.forsale Subject: Free Kennedy 9600 tape unit Message-ID: Date: 1 Aug 93 21:56:36 GMT Followup-To: ny.forsale Distribution: ny Organization: New York University Lines: 7 NNTP-Posting-Host: plym.smusic.nyu.edu Hi! We have a 5-year-old Kennedy 9600 9-track tape unit which used to be attached to a DEC PDP-11/44. We've scrapped the PDP-11, but the tape drive is in very good condition and has seen very little use. This is not something you attach to a PC (it weighs about 90 pounds and takes up a lot of rack space), but if you know of an organization which could use it, please contact me at (212) 998-5437. Thanks, Don Plym -- *************************************************************************** "There is nothing either good or bad, | allen h. lutins but thinking makes it so." | VU0350@bingsuns.cc.binghamton.edu Shakespeare (Hamlet II:2) | "Individualists of the world, Unite!" From sassth@beaune.unx.sas.com Mon Aug 9 23:35:17 EDT 1993 Article: 320 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!darwin.sura.net!news-feed-2.peachnet.edu!concert!sas!mozart.unx.sas.com!sassth From: sassth@beaune.unx.sas.com (Steve Hand) Subject: PDP-8 *core* memory wanted Originator: sassth@beaune.unx.sas.com Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: Date: Mon, 9 Aug 1993 13:19:31 GMT Nntp-Posting-Host: beaune.unx.sas.com Organization: SAS Institute Inc. Lines: 19 Do you have an unused PDP-8 *core* memory card (not solid-state) you would be willing to sell cheaply? I'd love to have a keepsake from the days back in school when I programmed PDP-8's for a chemistry lab (they controlled the X-ray diffractometers). I'd prefer one where you can see the little magnetic doughnuts... Please respond via e-mail... Thanks, Steve -- . . . Steven Hand sassth@unx.sas.com mcnc!rti!sas!sassth . _ \ SAS Institute Inc., SAS Campus Drive, Cary, NC 27513 | / \ | . (919) 677-8000 ext. 6936 (work) 467-0295 (home) \ | / . | (*) | Not officially representing SAS Institute Inc. --=*=-- | \_/ . A friend hears the song in my heart, / | \ \. . . and sings it to me when my memory fails me. | From jones@cs.uiowa.edu Tue Aug 10 00:24:08 EDT 1993 Article: 321 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.answers,news.answers Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: PDP-8 Frequently Asked Questions (posted every other month) Summary: Answers to common questions about antique DEC PDP-8 computers. Those posting to alt.sys.pdp8 should read this. Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug9.164507.22637@news.uiowa.edu> Approved: news-answers-request@MIT.Edu Date: Sun, 8 Aug 1993 08:08:08 GMT Expires: Tue, 8 Sep 1992 08:08:08 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Keywords: FAQ DEC PDP 8 Followup-To: alt.sys.pdp8 Lines: 835 Xref: news.columbia.edu alt.sys.pdp8:321 alt.answers:681 news.answers:11273 Archive-name: dec-faq/pdp8 Last-modified: August 3, 1993 Frequently Asked Questions about the DEC PDP-8 computer. By Douglas Jones, jones@cs.uiowa.edu (with help from many folks) Sites known to carry FTPable copies of this file: rtfm.mit.edu:/pub/usenet/news/answers/.../dec-faq/pdp8 Contents What is a PDP? What is a PDP-8? What is the PDP-8 instruction set? What does PDP-8 assembly language look like? What different PDP-8 models were made? What about the LINC-8 and PDP-12? Where can I get a PDP-8 today? Where can I get PDP-8 documentation? What operating systems were written for the PDP-8? What programming languages were supported on the PDP-8? Where can I get PDP-8 software? Where can I get additional information? What use is a PDP-8 today? Who's Who? What is a PDP? Digital Equipment Corporation (DEC) was founded in 1957, with facilities in an old woolen mill in Maynard Massachusetts, and initially, they sold transistorized "systems modules", plug-in circuit boards with a few digital logic gates per board. Starting in 1960, though, DEC began to experiment with computers, and in 1961, they had attracted enough attention that DECUS, the Digital Equipment Computer User's Society was founded. For over a decade, all programmable digital computers sold by Digital Equipment Corporation were sold as Programmed Data Processors (PDPs) instead of computers. I have DEC documentation that actually calls them "PDPs", so this is not improper usage. DEC's first computer, the PDP-1, had a selling price of only $120,000 at a time when competing machines were selling for over $1,000,000. Everyone (the government and DEC's stockholders included) knew that computers were big and expensive and needed a computer center and a large staff; DEC chose to avoid dealing with these stereotypes by entirely avoiding the term "computer". DEC built a number of different computers under the PDP label, with a huge range of price and performance. The largest of these are fully worthy of large computer centers with big support staffs. Many early DEC computers were not really built by DEC. With the PDP-3 and LINC, for example, customers built the machines using DEC parts and facilities. Here is the list of PDP computers: MODEL DATE PRICE BITS COMMENTS ===== ==== ======== ==== ===== PDP-1 1960 $120,000 18 DEC's first computer PDP-2 NA 24 Never built? PDP-3 36 One was built by a customer, not by DEC. PDP-4 1962 18 Predecessor of the PDP-7. PDP-5 1963 $27,000 12 The ancestor of the PDP-8. PDP-6 1964 $120,000 36 A big computer; 23 built, most for MIT. PDP-7 1965 ~$60,000 18 Widely used for real-time control. PDP-8 1965 $18,500 12 The smallest and least expensive PDP. PDP-9 1966 $35,000 18 An upgrade of the PDP-7. PDP-10 1967 $186,500 36 A PDP-6 successor, great for timesharing. PDP-11 1970 $10,800 16 DEC's first and only 16 bit computer. PDP-12 1969 $27,900 12 A PDP-8 relative. PDP-13 NA Bad luck, there was no such machine. PDP-14 A ROM-based programmable controller. PDP-15 1970 $16,500 18 A TTL upgrade of the PDP-9. PDP-16 1972 NA 8/16 A register-transfer module system. Corrections and additions to this list are welcome! The prices given above are the prices for minimal systems in the year the machine was first introduced. The bits column indicates the word size. It's worth noting that the DEC PDP-10 became the DECSYSTEM-20 as a result of marketing considerations, and DEC's VAX series of computers began as the Virtual Address eXtension of the never-produced PDP-11/78. It is worth mentioning that it is generally accepted that the the Data General Nova was originally developed as the PDP-X, a 16-bit multi-register version of the PDP-8. A prototype PDP-X was built at DEC before the design was rejected. This and a competing 16-bit design were apparently submitted to Harold McFarland at Carnegie-Mellon University for evaluation; McFarland (and also Gordon Bell, who was at C-MU at the time) evaluated the competing designs and rejected both in favor of the design now known as the PDP-11. (A less common variant on this story is that the reason that DEC never produced a PDP-13 was because this number was assigned to what became the Nova; this is unlikely because the PDP-X prototype predated the PDP-11.) Both DEC and Data General don't talk publically about these stories. Today, all of the PDP machines are in DEC's corporate past, with the exception of the PDP-11 family of minicomputers and microprocessors. Of course, occasionally, some lab builds a machine out of DEC hardware and calls it a PDP with a new number. For example, the Australian Atomic Energy Commission once upgraded a PDP-7 by adding a PDP-15 on the side; they called the result a PDP-22. What is a PDP-8? The PDP-8 family of minicomputers were built by Digital Equipment corporation between 1965 and 1990 (if you include the PDP-5, the starting date should be 1963). These machines were characterized by a 12 bit word, with no hardware byte structure, a 4K minimum memory configuration, and a simple but powerful instruction set. By 1970, the PDP-8 was the best selling computer in the world, and many models of the PDP-8 set new records as the least expensive computer on the market. The PDP-8 has been described as the model-T of the computer industry because it was the first computer to be mass produced at a cost that just about anyone could afford. C. Gordon Bell (who later was chief architect of the PDP-11 and who, as Vice President, oversaw the development of the VAX) says that the basic idea of the PDP-8 was not really original with him. He gives credit to Seymour Cray (of CDC and later Cray) for the idea of a single-accumulator 12 bit minicomputer. Cray's CDC 160 family, sold starting around 1959, certainly was a very similar 12 bit architecture, and the peripheral processors of Cray's first supercomputer, the CDC 6600, are also familiar to PDP-8 programmers. Note that the CDC 160 and CDC 6600 peripheral processors had 6 basic addressing modes, with variable length instruction words and other features that were far from the simple elegance of the PDP-8. Despite its many modes, the CDC architecture lacked the notion of current page addressing, and the result is that for examples that don't involve indexing, PDP-8 code is frequently just as effective as the code on the more complex CDC 12-bit minicomputers. What is the PDP-8 instruction set? The PDP-8 word size is 12 bits, and the basic memory is 4K words. The minimal CPU contained the following registers: PC - the program counter, 12 bits. AC - the accumulator, 12 bits. L - the link, 1 bit, commonly prefixed to AC as . It is worth noting that many operations such as procedure linkage and indexing, which are usually thought of as involving registers, are done with memory on the PDP-8 family. Instruction words are organized as follows: _ _ _ _ _ _ _ _ _ _ _ _ |_|_|_|_|_|_|_|_|_|_|_|_| | | | | | | op |i|z| addr | op - the opcode. i - the indirect bit (0 = direct, 1 = indirect). z - the page bit (0 = page zero, 1 = current page). addr - the word in page. The top 5 bits of the 12 bit program counter give the current page, and memory addressing is also complicated by the fact that absolute memory locations 8 through 15 are incremented prior to use when used for indirect addressing. These locations are called the auto-index registers (despite the fact that they are in memory), and they allow the formulation of very tightly coded array operations. The basic instructions are: 000 - AND - and operand with AC. 001 - TAD - add operand to (a 13 bit value). 010 - ISZ - increment operand and skip if result is zero. 011 - DCA - deposit AC in memory and clear AC. 100 - JMS - jump to subroutine. 101 - JMP - jump. 110 - IOT - input/output transfer. 111 - OPR - microcoded operations. The ISZ and other skip instructions conditionally skip the next instruction in sequence. The ISZ is commonly used to increment a loop counter and skip if done, and it is also used as an general increment instruction, either followed by a no-op or in contexts where it is known that the result will never be zero. The subroutine calling sequence involves putting the return address in relative word zero of the subroutine, with execution starting with relative word one. Return from subroutine is done with an indirect jump through the return address. Subroutines frequently increment their return addresses to index through inline parameter lists or to provide return codes by conditionally skipping the next instruction. The IOT instruction has the following form: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|t|c|s| | | | | | | device | op | The IOT instruction specifies one of up to 8 operations on one of 64 devices. Typically (but not universally), each bit of the op field evokes an operation as follows: If the s bit is set, the instruction causes a skip if the device is ready, if the c bit is set, the device ready status is reset and, for some devices, AC is also cleared, and if the t bit is set, data is either ored with AC or output from AC to the device. Prior to the PDP-8/E, there were severe restrictions on the interpretation of the t, c and s bits. IOT instructions may be used to initiate data break transfers from block devices such as disk or tape. The term "data break" was, for years, DEC's preferred term for cycle-stealing direct-memory- access data transfers. Some CPU functions are accessed only by IOT instructions. For example, interrupt enable and disable are IOT instructions, as are instructions controlling the optional memory management unit that is needed to address more than 4K words. A wide variety of operations are available through the OPR microcoded instructions: _ _ _ _ _ _ _ _ _ _ _ _ Group 1 |1|1|1|0|_|_|_|_|_|_|_|_| 1 - CLA - clear AC 1 - CLL - clear the L bit 1 - CMA - ones complement AC 1 - CML - complement L bit 1 - IAC - increment 1 0 0 - RAR - rotate right 0 1 0 - RAL - rotate left 1 0 1 - RTR - rotate right twice 0 1 1 - RTL - rotate left twice In general, the above operations can be combined by oring the bit patterns for the desired operations into a single instruction. If none of the bits are set, the result is the NOP instruction. When these operations are combined, they operate top to bottom in the order shown above. The exception to this is that IAC cannot be combined with the rotate operations on some models, and attempts to combine rotate operations have different effects from one model to another (for example, on the PDP-8/E, the rotate code 001 means swap 6 bit bytes in the accumulator, while previous models took this to mean something like "shift neither left nor right 2 bits"). _ _ _ _ _ _ _ _ _ _ _ _ Group 2 |1|1|1|1|_|_|_|_|_|_|_|0| 1 0 - SMA - skip on AC < 0 \ 1 0 - SZA - skip on AC = 0 > or 1 0 - SNL - skip on L /= 0 / 0 0 0 1 - SKP - skip unconditionally 1 1 - SPA - skip on AC >= 0 \ 1 1 - SNA - skip on AC /= 0 > and 1 1 - SZL - skip on L = 0 / 1 - CLA - clear AC 1 - OSR - or switches with AC 1 - HLT - halt The above operations may be combined by oring them together, except that there are two distinct incompatible groups of skip instructions. When combined, SMA, SZA and SNL, skip if one or the other of the indicated conditions are true, while SPA, SNA and SZL skip if all of the indicated conditions are true (logical and). When combined, these operate top to bottom in the order shown; thus, the accumulator may be tested and then cleared. Setting the halt bit in a skip instruction is a crude but useful way to set a breakpoint for front-panel debugging. If none of the bits are set, the result is an alternative form of no-op. A third group of operate microinstructions (with a 1 in the least significant bit) deals with the optional extended arithmetic element to allow such things as hardware multiply and divide, 24 bit shift operations, and normalize. These operations involve an additional data register, MQ or multiplier quotient, and a small step count register. On the PDP-8/E and successors, MQ and the instructions for loading and storing it were always present, even when the EAE was absent, and the EAE was extended to provide a useful variety of 24 bit arithmetic operations. What does PDP-8 assembly language look like? Here is an example: START, CLA CLL / Clear everything TAD X / Load X AND I Y / And with the value pointed to by Y DCA X / Store in X HLT / Halt X, 1 / A variable Y, 7 / A pointer Note that labels are terminated by a comma, and comments are separated from the code by a slash. There are no fixed fields or column restrictions. The "CLA CLL" instruction on the first line is an example of the microcoding of two of the Group 1 operate instructions. CLA alone has the code 7200 (octal), while CLL has the code 7100; combining these as "CLA CLL" produces 7300, the instruction to clear both AC and the link bit. As a general rule, except when memory reference instructions are involved, the assembler simply ors together the values of all blank separated fields between the label and comment. Indirection is indicated by the special symbol I in the operand field, as in the third line of the example. The typical PDP-8 assembler has no explicit notation to distinguish between page zero and current page addresses. Instead, the assembler is expected to note the page holding the operand and automatically generate the appropriate mode. If the operand is neither in the current page nor page zero, some assemblers will raise an error, others will automatically generate an indirect pointer to the off-page operand (This feature should be avoided!). Note, in the final two lines of the example, that there is no "define constant" pseudo-operation. Instead, where a constant is to be assembled into memory, the constant takes the place of the op-code field. The PDP-8 has no immediate addressing mode, but some assemblers provide an optional mechanism to allow the programmer to ignore this lack: TAD (3) / add 3, from memory on the current page. TAD [5] / add 5, from memory on page zero. JMP I (LAB) / jump indirect through the address of LAB. Assemblers that support this automatically fill the end of each page with constants defined in this way that have been accumulated during the assembly of that page. Arithmetic is allowed in operand fields and constant definitions, but expressions are evaluated in strict left-to-right order, as shown below: TAD X+1 / add the contents of the location after X. TAD (X-1) / add the address of the location before X. Other operators allowed included and (&), or (!), multiply (^) and divide (%), as well as a unary sign (+ or -). Unfortunately, one of the most widely used assemblers, PAL 8, has trouble when unary operators are mixed with multiplication or division. Generally, identifiers are not limited in length, but only the first 6 characters are significant. All numeric constants are in octal, unless a DECIMAL pseudo-op has been used to change number base (change back with the OCTAL pseudo-op). Other assembly language features are illustrated below: / Comments may stand on lines by themselves / Blank lines are allowed *200 / Set the assembly origin to 200 (octal) NL0002= CLA CLL CML RTL / Define new opcode NL0002. NL0002 / Use new opcode (load 0002 in AC) JMP .-1 / Jump to the previous instruction X1= 10 / Define X1 (an auto-index register address) TAD I X1 / Use autoindex register 1 IAC; RAL / Multiple instructions on one line $ / End of assembly The assembly file ends with a line containing a $ (dollar sign) not in a comment field. What different PDP-8 models were made? The total sales figure for the PDP-8 family is estimated at over 300,000 machines. Over 8500 of these were sold prior to 1970. During the PDP-8 production run, a number of models were made, as listed in the following table. Of these, the PDP-8/E is generally considered to be the definitive machine. If the PDP-8 is considered to be the Model T of the computer industry, perhaps the PDP-8/E should be considered to be the industry's Model A. MODEL DATES SALES COST TECHNOLOGY REMARKS PDP-5 63-65 Transistor Limited compatibility PDP-8 65-68 >1000 $18,500 Transistor Table-top or rack LINC-8 66-69 153 $38,500 Transistor Rack only PDP-8/S 66-70? >1000? $10,000 Transistor Incompatable, slow! PDP-8/I 68-70? >2000? $12,800 TTL Pedistal or rack PDP-8/L 68-70? >2000? $8,500 TTL Scaled down 8/I (1) PDP-12 69-71 3500 $27,900 TTL Followup to LINC-8 PDP-8/E 70-78 >10K? $7,390 TTL MSI Omnibus Table-top or rack PDP-8/F 72-78? >10K? <$7K TTL MSI Omnibus Based on 8/E CPU PDP-8/M 72-78? >10K? <$7K TTL MSI Omnibus OEM version of 8/F PDP-8/A 75-84? >10K? $1,317 TTL LSI Omnibus New CPU or 8/E CPU VT78 (2)78-80 <$10K Microprocessor Intersil IM6100 Dm I (3)80-84 Microprocessor Harris 6120 Dm II 82-86 $1,435 Microprocessor Harris 6120 Dm III 84-90 $2,695 Microprocessor Dm III+ 85-90 Microprocessor Notes (1) Memory upgrade to 32K words was eventually sold. (2) The VT78 was also known as the DECstation 78. (3) Dm stands for DECmate. When possible, the costs given in the above table are for a minimal system in the first year of production; for most PDP-8 systems, such a system would have 4K of main memory, a console teletype, and the minimal software needed to use the machine (FOCAL, BASIC, or a paper-tape based assembler). Additional information on costs and production is needed! The above list does not include many PDP-8 variants sold by DEC to meet the needs of various special users. For example, the Industrial-8 was really just a PDP-8/E with a different nameplate and color scheme. Burger King had thousands of PDP-8/M based point-of-sale systems with no standard peripherals. In addition, DEC made many peripheral controllers for the PDP-11 and PDP-15 that used IM6100 and 6120 microprocessors from Intersil and Harris. The last years of the PDP-8 family were dominated by the DECmate machines. DEC sold these primarily as word processing systems, and in the end, they chose to obscure the ability of the DECmate systems to run any software other than WPS, DEC's word processing system. The following PDP-8 compatible or semi-compatible machines were made and sold by others; very little is known about many of these: MODEL DATE MAKER, NOTES MP-12 6? Fabritek TPA 68? Hungarian, a PDP-8/L clone, ran FOKAL DCC-112 70-71 Digital Computer Controls DCC-112H 71 Digital Computer Controls 6100 Sampler 7? Intersil, their IM6100 promotional kit Intercept 7? Intersil, based on IM6100 Intercept Jr 7? Intersil, based on IM6100 PCM-12 7? Pacific CyberMetrix, based on Intercept bus SBC-8 84-88 CESI, Based on IM6120, SCSI bus What about the LINC/8 and PDP-12? Wesley Clark, then at Lincoln Labs, developed the LINC, or Laboratory INstrumentation Computer, as a personal laboratory computer in the early 1960's. He developed it in response to the needs of Mary Brazier, a neurophysiologist at MIT who needed better laboratory tools. When Lincoln Labs decided that the LINC did not fit their mission, a group at the the National Institute of Health funded an experiment to see if the LINC would be a productive tool in the life sciences. As a result of this project, 12 LINCs were built and debugged, each by its eventual user. The LINC was built using DEC's first family of logic modules, and along with the CDC 160, it paved the way for the PDP-5 and PDP-8. When compared with the PDP-8, the LINC instruction set was not as well suited for general purpose computation, but the common peripherals needed for lab work such as analog to digital and digital to analog converters were all bundled into the LINC system. Users judged it to be a superb laboratory instrument. One of the major innovations introduced with the LINC was the LINCtape. These tapes could be carelessly pocketed or dropped on the floor without fear of data loss, and they allowed random access to data blocks. DEC improved on this idea slightly to make their DECtape format, and DECtape was widely used with all DEC computers made in the late 1960's and early 1970's. Within a year of the introduction of the PDP-8, DEC released the LINC-8, a machine that combined a PDP-8 with a LINC in one package. This was not a general purpose dual processor, in the sense of allowing both machines to execute in parallel, but rather, a machine with the hardware of both but restrictions that effectively prevented more than one from running at a time. The sales success of the LINC-8 led DEC to re-engineer the machine using TTL logic in the late 1960's; the new version was originally developed as the LINC-8/I, but it was sold as the PDP-12; thousands were sold. Both the LINC-8 and the PDP-12 had impressive consoles, with full sets of lights and switches for the registers of each processor. These machines could run essentially any PDP-8 or LINC software, but because they included instructions for switching between modes, a third body of software was developed that required both instruction sets. One feature of LINC and LINC-8 software is the common use of the graphic display for input-output. These machines were some of the first to include such a display as a standard component, and many programs used the knobs on the analog to digital converter to move a cursor on the display in the way we now use a mouse. LAP, the Linc Assembly Program, was the dominant assembler used on the LINC. WISAL (WISconson Assembly Language) or LAP6-W was the version of this assembler that survived to run on the PDP-12. Curiously, this includes a PDP-8 assembler written in LINC code. LAP-6 DIAL (Display Interactive Assembly Language) evolved from this on the PDP-12 to became the dominant operating system for the PDP-12. The 8K version of this is DIAL MS (Mass Storage), even if it has only two LINCtape drives. These were eventually displaced by the OS/8 variant known as OS/12. Where can I get a PDP-8 today? The CESI machine may still be on the market, for a high price, but generally, you can't buy a new PDP-8 anymore. There are quite a few PDP-8 machines to be found in odd places on the used equipment market. They were widely incorporated into products such as computer controlled machine tools, X-ray diffraction machines, and other industrial and lab equipment. Many of them were sold under the EduSystem marketing program to public schools and universities, and others were used to control laboratory instrumentation. Reuters bought the tail end of the Omnibus based production run. If you can't get real hardware, you can get emulators. Over the years, many PDP-8 emulators have been written; the best of these are indistinguishable from the real machine from a software prespective, and on a modern high-speed RISC platform, these frequently outperform the hardware they are emulating. It is worth noting that the PDP-8, when it was introduced in 1965, was about as fast as was practical with the logic technology used at the time; only by using tricks like memory interleaving or pipelining could the machine have been made much faster. Finally, you can always build your own. The textbook "The Art of Digital Design," second edition, by Franklin Prosser and David Winkel (Prentice-Hall, 1987, ISBN 0-13-046780-4) uses the design of a PDP-8 as a running example. Many students who have used this book were required to build working PDP-8 systems as lab projects. Where can I get PDP-8 documentation? The 1973 Introduction to Programming was probably DEC's definitive manual for this family, but it is out of print, and DEC was in the habit of printing much of their documentation on newsprint with paperback bindings, which is to say, surviving copies tend to be yellow and brittle. DEC distributed huge numbers of catalogs and programming handbooks in this inexpensive paperback format, and these circulate widely on the second-hand market. When research laboratories and electronics shops are being cleaned out, it is still common to find a few dusty, yellowed copies of these books being thrown in the trash. Maintenance manuals are harder to find, but more valuable. Generally, you'll need to find someone who's willing to photocopy one of the few surviving copies. Fortunately, DEC has been friendly to collectors, granting fairly broad letters of permission to reprint obsolete documentation, and the network makes if fairly easy to find someone who has the documentation you need and can get copies. What operating systems were written for the PDP-8? A punched paper-tape library of stand-alone programs was commonly used with the smallest (diskless and tapeless) configurations from the beginning up through the mid 1970's. Many paper tapes from this library survive to the present at various sites! The minimum configuration expected by these tapes is a CPU with 4K memory, and a teletype ASR 33 with paper tape reader and punch. The DECtape Library System was an early DECtape oriented save and restore system that allowed a reel of tape to hold a directory of named files that could be loaded and run on a 4K system. Eventually, this supported a very limited tape-based text editor for on-line program development. This did not use the DECtape's block addressable character; the software was based on minimal ports of the paper-tape based software described above. The 4K Disk Monitor System provided slightly better facilities. This supported on-line program development and it worked with any device that supported 129 word blocks (DECtape, the DF32 disk, or the RF08 disk). MS/8 or the R-L Monitor System, developed starting in 1966 and submitted to DECUS in 1970. This was a disk oriented system, faster than the above, with tricks to make it run quickly on DECtape based systems. POLY BASIC, a BASIC only system submitted to DECUS and later sold by DEC as part of its EduSystem marketing program. P?S/8, developed starting in 1971 from an MS/8 foundation. Runs on minimal PDP-8 configurations, supports device semi-independant I/O and a file system on a random-access device, including DECtape. P?S/8 runs compatably on most PDP-8 machines including DECmates, excepting only the PDP-8/S and PDP-5. P?S/8 is still being developed! OS/8, developed in parallel with P?S/8, became the main PDP-8 programming environment sold by DEC. The minimum configuration required was 8K words and a random-access device to hold the system. For some devices, OS/8 requires 12K. There are a large number of OS/8 versions that are not quite portable across various subsets of the PDP-8 family. OS/78 was developed from OS/8 to support the DECmate I, and OS/278 was developed for the later DECmate machines. These have unnecessary incompatabilities with earlier versions of OS/8 and with pre-Omnibus machines. There are also stories that DEC included code in either OS/8 or one of its predecessors to make it incompatable with the DCC-112. OS8 (no slash) may still be viable. It requires 8K of main memory, an extended arithmetic unit, and DECtape hardware. Unlike most PDP-8 operating systems, it uses a directory structure on DECtape compatable with that used on the PDP-10. TSS/8 was developed in 1968 as a timesharing system. It required a minimum of 12K words of memory and a swapping device. It was the standard operating system on the EduSystem 50 which was sold to many small colleges and large public school systems. Each user gets a virtual 4K PDP-8; many of the utilities users ran on these virtual machines were only slightly modified versions of utilities from the Disk Monitor System or paper-tape environments. Other timesharing systems developed for the PDP-8 include MULTI-8, ETOS, MULTOS, and OMNI-8; some of these required nonstandard memory management hardware. By the mid 1970's, some of these were true virtual machine operating systems in the same spirit as IBM's VM-370; they could support some version of OS/8 running on a 32K virtual PDP-8 assigned to each user. Some could support different user operating systems on each virtual machine, others required OS/8 as the user system and only allowed code to execute from virtual field zero of a process's virtual memory. CAPS-8 was a cassette based operating system supporting PAL and BASIC. There are OS/8 utilities to manipulate CAPS-8 cassettes, and the file format on cassette is compatible with a PDP-11 based system called CAPS-11. WPS was DEC's word processing system that was widely used on the 1980's vintage machines with a special WPS keycaps replacing the standard keycaps on the keyboard. This was written in the 1970's, and was the primary system used on the DECmate systems. COS-310, DEC's commercial operating system for the PDP-8, supported the DIBOL language. COS-310 was a derivative of MS/8 and OS/8, but with a new text file format. The file system is OS/8 compatable, and a few applications can run under either COS or OS/8. What programming languages are supported on the PDP-8 The PAL family of assembly languages are as close to a standard assembly language as can be found for the PDP-8. These produce absolute object code and versions of PAL will run on minimally configured machines (but with a small symbol table). Assembly of large programs frequently requires far more memory for symbol table management. MACRO-8 was DEC's first macro assembly language for the PDP-8, but it was never used outside the paper-tape environment except under the OS8 operating system. MACREL and SABR are assembly languages that produce relocatable output. SABR is the final pass for the ALICS II FORTRAN compiler, and MACREL was developed in (unfulfilled) anticipation of similar use. MACREL was heavily used by the DECmate group at DEC. There was also RALF, the relocatable assembler supporting RTPS FORTRAN, and FLAP, an absolute assembler derived from RALF. Both SABR and RALF/FALP are assemblers that handle their intended applications but have quirky and incompatible syntax. A subset of FORTRAN was supported on both the PDP-5 and the original PDP-8. Surviving documentation describes a DEC compiler from 1964 and a compiler written by Information Control Systems from 1968. The latter, ALICS II FORTRAN, was originally a paper tape based compiler, but it forms the basis of the OS/8 8K FORTRAN compiler, and was also adapted to the Disk Monitor System. RTPS FORTRAN required 8K and a floating point processor; it had real-time extensions and was a full implementation of FORTRAN IV (also known as ANSI FORTRAN 66). OS/8 F4 is RTPS FORTRAN stripped of the requirement for hardware floating point (if the hardware is missing, it uses software emulation). FOCAL, an interpretive language comparable to BASIC was available on all models of the family, including the PDP-5 and PDP-8/S. Varsions of FOCAL run under PS/8, P?S/8 and other systems. BASIC was also available, and was widely used on PDP-8 systems sold under the EduSystem marketing program. A paper-tape version was available that ran in 4K, there were versions that ran under OS/8 and TSS/8, there was an 8K stand-alone time-sharing version, and there were many others. DIBOL was DEC's attempt at competing with COBOL in the commercial arena. It was originally implemented under MS/8 but most versions were sold to run under the COS operating system. Algol was available from a fairly early date. At least two Pascal compilers were developed for the PDP-8. One was a Pascal-S interpreter, written in assembler, the other was a Pascal-P compiler with a P-code interpreter written in assembler. At least two LISP interpreters were written for the PDP-8; one runs in 4K, the other can use up to 16K. TECO, the text editor, is available, and is also a general purpose language, and someone is working on a PDP-8 C. The story of TECO on the PDP-8 is convoluted. Russ Ham implemented TECO under his OS8 (without a slash) system. This version of TECO was pirated by the Oregon Museum of Science and Industry (OMSI), where the system was ported to PS/8. Richard Lary and Stan Rabinowitz made it more compatible with other versions of TECO, and the result of work is the version distributed by DECUS. RT-11 TECO for the PDP-11 is a port of this code. Where can I get PDP-8 software? DECUS, the DEC User Society, is still alive and well, and their submission form still lists PAL-8 and FOCAL as languages in which they accept submissions! The DECUS library is available on-line by anonymous FTP at acfcluster.nyu.edu in subdirectory DECUS. To quote the README file from the current on-line catalog, "Items from older DECUS Library catalogs are still also available (provided their media can still be read), but machine readable catalog information is not available for these." Direct questions by E-mail to INFORMATION@DECUS.ORG. There is a young but growing FTPable archive of PDP-8 software at ftp.telebit.com in directory /pub/pdp8. Another archive that contains considerable PDP-8 related material, along with material related to other DEC computers, is at sunsite.unc.edu in directory /pub/academic/computer-science/history/. Where can I get additional information? The file WHAT-IS-A-PDP8, by Charles Lasner contains considerable additional information; this file is included in the FTPable archive cited above. This file gives details of every model of the PDP-8, including the small quirks and incompatabilities that (to be generous) allow software to determine which model it is running on. These quirks also make it all too easy for careless programmers to write almost portable software with very obscure bugs. The mailing list pdp8-lovers@ai.mit.edu reaches a number of PDP-8 owners and users, not all of whom have USENET feeds. The USENET newsgroup alt.sys.pdp8 is fairly new, but someday, the newsgroup and mailing list should be gatewayed to each other. Many "archival" books have included fairly complete descriptions of the PDP-8; among them, "Computer Architecture, Readings and Examples" by Gordon Bell and Allen Newell is among the most complete (and difficult to read). Considering Bell's role in the design of the PDP-8 and the history of DEC, the description in this book should be accurate! What use is a PDP-8 today? What use is a Model T today? Collectors of both come in the same basic classes. First, there are antiquarians who keep an old one in the garage, polished and restored to new condition but hardly ever used. Once a year, they warm it up and use it, just to prove that it still works, but they don't have much practical use. PDP-8 systems maintained by antiquarians are frequently in beautiful shape. Antiquarians worry about dust, chipped paint, and missing switches, and they establish newsgroups and mailing lists to help them locate parts and the advice needed to fix their machines. In the second class are those who find old machines and soup them up, replacing major parts to make a hotrod that only looks like the original from the outside, or keeping the old mechanism and putting it to uses that were never intended. Some PDP-8 owners, for example, are building PDP-8 systems with modern SCSI disk interfaces! There is serious interest in some quarters in constructing an omnibus board that would support an IDE disk of the variety that was mass-produced for the IBM PC/AT. Last, there are the old folks who still use their old machines for their intended purposes long after any sane economic analysis would recommend such use. If it ain't broke, don't fix it, and if it can be fixed, why bother replacing it? Both Model T Fords and the classic PDP-8 machines are simple enough that end users can maintain and repair them indefinitely. All you need to keep a vintage -8 running are a stock of inexpensive silicon diodes and a stock of 2N3639B or better, 2N3640 transistors. Unlike most modern personal computers, PDP-8 systems were routinely sold with complete maintenance manuals; these included schematic diagrams, explanations of not only how to use the devices, but how they are built, and suggestions to those considering building their own peripherals. Compared with many so-called "open systems" of today, the PDP-8 seems to have been far better documented and far more open. Finally, the PDP-8 is such a minimal machine that it is an excellent introduction to how computers really work. Over the years, many students have built complete working PDP-8 systems from scratch as lab projects, and the I/O environment on a PDP-8 is simple enough that it is a very appropriate environment for learning operating system programming techniques. Who's Who? C. Gordon Bell is generally credited with the original design of the PDP-8. He was also involved with recommending what became the PDP-11 when that design was competing with the design that probably became the NOVA, and as vice president of research, he oversaw the development of the DEC VAX family. Alan Kotok worked with Bell in working up the original specifications of the PDP-8. Ben Gurley designed most of the big DEC machines, starting with the PDP-1. The actual design work on the -8, however, was done by Ed deCastro, who later founded Data General to build the Nova. Ken Olson ran DEC from the beginning. Ed Yourdon, who later became well known as a programming methodology gury, hacked up the PAL III assembler for the -8. Wesley Clark developed the LINC while working at Lincoln Labs; this was the first 12 bit minicomputer built with DEC parts. From jones@pyrite Tue Aug 10 00:24:21 EDT 1993 Article: 322 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: PDP-8 *core* memory wanted Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug9.195355.26024@news.uiowa.edu> Date: Mon, 9 Aug 1993 19:53:55 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 27 >From article , by sassth@beaune.unx.sas.com (Steve Hand): > > Do you have an unused PDP-8 *core* memory card (not solid-state) you > would be willing to sell cheaply? If I find an irreparably broken board, I'll let people know, but those of us trying to restore old PDP-8 systems to working order generally want to keep what core we have in working order so we can put programs in it! > the days back in school when I programmed PDP-8's for a chemistry lab > (they controlled the X-ray diffractometers). You'd enjoy knowing that the U of Iowa has two PDP-8/I controlled X-ray diffractometers sitting in mothballs right now! They aren't surplus, yet. > I'd prefer one where you can see the little magnetic doughnuts... Then you want an old core board, and not one of the new-fangled (post 1970) ones! The core DEC used in the 1970's was so tightly packed with such small cores that it looked like a black fabric of some kind. If you looked real close, you could see the herring-bone pattern of the cores, though. Doug Jones jones@cs.uiowa.edu From lasner@watsun.cc.columbia.edu Tue Aug 10 00:25:59 EDT 1993 Article: 323 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 *core* memory wanted Date: 10 Aug 1993 04:00:55 GMT Organization: Columbia University Lines: 65 Message-ID: <2476hn$o35@apakabar.cc.columbia.edu> References: NNTP-Posting-Host: watsun.cc.columbia.edu In article sassth@beaune.unx.sas.com (Steve Hand) writes: > >Do you have an unused PDP-8 *core* memory card (not solid-state) you >would be willing to sell cheaply? I'd love to have a keepsake from >the days back in school when I programmed PDP-8's for a chemistry lab >(they controlled the X-ray diffractometers). I'd prefer one where >you can see the little magnetic doughnuts... What's an *unused* PDP-8? Some of us have objected that the so-called Computer Museum in Boston is selling off its "artifacts" as it provides less of a look at the past of computing and more into the commercialistic side of running a business. There have been several reports of machines no longer displayed that formerly were not only displayed, but running, and (shudder!) rumors of machines with the insides gutted, and replaced with video screens simulating what the real machines may have looked like, or at least an unreasonable facsimile acceptable to an unknowledgeable public. The parts of PDP-8's and other machines wind up as trivial souvenirs of the visit sold at nominal prices at the place of business, etc. I wonder how many of us old-computer fans are unable to produce a specific result merely because they have sold off the last of some obscure module, etc. There are a lot of R-series modules that are pretty common admittedly, and it's pretty easy to repair such a simple card, requiring essentially only a supply of diodes and transistors. (An exception is the variant that only uses the FLIP-CHIP hybrid because they do occasionally fail, and these variant boards cannot "neatly" take the original passive components they replace as do the older boards. However, kludges have been constructed that can be used to replace the FLIP-CHIP in a pinch. Also, some boards with the dual etch have been cannibalized of FLIP-CHIP's to bail out a board that cannot have the separated diodes and capacitors, and in their place loose components have been installed, thus regaining the use of both modules.) But there are quite rare cards that are needed for various machine functions. A case in point is the R212. This module is needed in groups of six to implement either the LINC-8 "Z" register or the MQ of the EAE option of either the LINC-8 or PDP-8. Thus, a LINC-8 cannot be complete without at least six R212's and would want an optional six more. Not too many PDP-8's were ever made with EAE, and only about 150 LINC-8's were ever produced, so the total known population of these cards is quite small (even when including DEC's likely original spares count). Another one is the B684, which is needed to drive the PDP-8 Memory buss when a LINC-8 or PDP-8 gets more than 4K. Twelve such cards are needed. The module may also have other applications, such as in the KA-10. Perhaps we should make up an "endangered species" list for DEC modules for our machines, where a rarity quotient is calculated for these cards, and thus it becomes possible to "rate" their relative worth, etc., and perhaps can come up with a trader's equity rating or somesuch. This way would-be trades can be established to allow everyone an opportunity to upgrade the machine of their choice. (I myself have a plethora of certain cards that very well might be rare in general, and might want to trade for something else, or sell them, etc.) Perhaps someone should contact the museum itself, since likely they would be interested in someone trading expertise for hardware. That would be more "profitable" to them than getting incidental money selling PDP-8 parts as "trinkets" to non-serious non-collectors who are merely casual visitors of the museum. Depending on what was salvaged, this may allow them to not alienate groups such as our readership here, etc. cjl From ivie@cc.usu.edu Wed Aug 11 13:46:09 EDT 1993 Article: 324 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.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,alt.folklore.computers Subject: Happy PDP-5 day Message-ID: <1993Aug11.100431.71047@cc.usu.edu> Date: 11 Aug 93 10:04:31 MDT Organization: Utah State University Lines: 24 Xref: news.columbia.edu alt.sys.pdp8:324 alt.folklore.computers:49387 According to a magazine that I once encountered in the bowels of the university library, the PDP-5 was unveiled August 11, 1963 at WESCON. Here's to 30 years of small computers! Roger Ivie ivie@cc.usu.edu PS: For you MS-DOS guys, here's the lineage of MS-DOS as near as I can figure it. Please feel free to correct me if I'm wrong: LINC / \ PDP-4 PDP-5 | | Unix PDP-7 PDP-8 OS/8 \ / Unix PDP-11 RT-11 / \ | 8080 CP/M | | | 8086 MS-DOS 1.x \ / 8086 MS-DOS 2.x and up From danpop@cernapo.cern.ch Wed Aug 11 21:38:07 EDT 1993 Article: 325 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!mcsun!dxcern!cernapo!danpop From: danpop@cernapo.cern.ch (Dan Pop ) Subject: Re: Happy PDP-5 day Message-ID: Sender: news@dxcern.cern.ch (USENET News System) Organization: CERN European Lab for Particle Physics References: <1993Aug11.100431.71047@cc.usu.edu> Date: Wed, 11 Aug 1993 20:19:07 GMT Lines: 39 Xref: news.columbia.edu alt.sys.pdp8:325 alt.folklore.computers:49402 In <1993Aug11.100431.71047@cc.usu.edu> ivie@cc.usu.edu writes: >PS: For you MS-DOS guys, here's the lineage of MS-DOS as near as I can >figure it. Please feel free to correct me if I'm wrong: > LINC > / \ > PDP-4 PDP-5 > | | > Unix PDP-7 PDP-8 OS/8 > \ / > Unix PDP-11 RT-11 > / \ > | 8080 CP/M > | | > | 8086 MS-DOS 1.x > \ / > 8086 MS-DOS 2.x and up I'll leave to the PDP-8 experts to comment about the connections between OS/8 and RT-11 and I'll comment about the next step, RT-11 -> CP/M. The only connections that I can see between RT-11SJ and CP/M is that they were both single job, and they had a DIR command and a PIP utility. CP/M was by far more primitive than RT-11, in every respect, so it cannot be considered as an evolution from the latter. The underlying hardware was also more primitive. Even MS-DOS 6.0 can be considered as an involution from RT-11, both at the level of the user interface and at the level of system programming. Dan -- Dan Pop Tel: +41.22.767.2335 Email: danpop@cernapo.cern.ch Mail: CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland -- Dan Pop Tel: +41.22.767.2335 Email: danpop@cernapo.cern.ch Mail: CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland From ab401@freenet.carleton.ca Wed Aug 11 21:38:25 EDT 1993 Article: 326 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!utnut!nott!cunews!freenet.carleton.ca!ab401 From: ab401@freenet.carleton.ca (Paul Tomblin) Subject: Re: Happy PDP-5 day Message-ID: Reply-To: ab401@freenet.carleton.ca Organization: Tomblin Computer Consulting, Ottawa, Ontario References: <1993Aug11.100431.71047@cc.usu.edu> Date: Wed, 11 Aug 1993 21:56:09 GMT Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:326 alt.folklore.computers:49411 danpop@cernapo.cern.ch (Dan Pop ) writes: >single job, and they had a DIR command and a PIP utility. CP/M was by far >more primitive than RT-11, in every respect, so it cannot be considered as an >evolution from the latter. The underlying hardware was also more primitive. There is no law of computing, or even of biology, that states that all evolution has to go from less complex to more complex. One only has to look at mammals that went back to the sea, like whales and seals. Paul "I'm not a biologist, I just play one on the net" Tomblin -- Paul Tomblin - formerly {pt{omblin},news}@{geovision.}gvc.com "Ok dear, Want me to call the bike shop and see if they'll sponsor your mid-life crisis?" "Yeah. Ask 'em if they'll upgrade my shifters, too" - Calvin's mom and dad From ivie@cc.usu.edu Thu Aug 12 13:40:38 EDT 1993 Article: 327 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!overload.lbl.gov!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Message-ID: <1993Aug12.091041.71099@cc.usu.edu> Date: 12 Aug 93 09:10:41 MDT References: <1993Aug11.100431.71047@cc.usu.edu> Organization: Utah State University Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:327 alt.folklore.computers:49463 In article , danpop@cernapo.cern.ch (Dan Pop ) writes: > I'll leave to the PDP-8 experts to comment about the connections between OS/8 > and RT-11 and I'll comment about the next step, RT-11 -> CP/M. The only > connections that I can see between RT-11SJ and CP/M is that they were both > single job, and they had a DIR command and a PIP utility. CP/M was by far > more primitive than RT-11, in every respect, so it cannot be considered as an > evolution from the latter. The underlying hardware was also more primitive. > Even MS-DOS 6.0 can be considered as an involution from RT-11, both at the > level of the user interface and at the level of system programming. Gary Kildall is often quoted as saying the CP/M came out of RT-11, which is why I drew it that way. Personally, I consider CP/M to be closer to OS/8, but I didn't use any really early versions of RT-11. Roger "The first DEC machine I used was a VAX. Then I used a PDP-8." Ivie ivie@cc.usu.edu From lasner@watsun.cc.columbia.edu Thu Aug 12 13:52:18 EDT 1993 Article: 328 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 12 Aug 1993 17:51:16 GMT Organization: Columbia University Lines: 33 Message-ID: <24dvuk$8k5@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:328 alt.folklore.computers:49470 In article <1993Aug12.091041.71099@cc.usu.edu> ivie@cc.usu.edu writes: >Roger "The first DEC machine I used was a VAX. Then I used a PDP-8." Ivie Which is probably a unique event in the annals of DEC. It takes an observant individual to appreciate the distinction, etc. A side issue: How many people are there that actually appreciate a machine's architecture? I suspect that many self-proclaimed -11 lovers got that way merely because they liked the software for what it could do for them, not the underlying hardware that was being used to implement it, etc. A case in point could be RT-11. It is likely that a system mimicking RT-11 could have been done on the PDP-8. It would have required DEC to insist that the machine have 32K to accomplish this, instead of the relatively spartan attitude of just requiring 8K to run OS/8 (or 4K to run P?S/8!), but DEC never required any users to go for 32K until the DECmate I. (The VT78 is a fixed memory size of 16K; all older machines could be had in various sizes, although most 8/a memories tended to be either 16K or 32K.) So, if DEC had written "RT-8" and it's functionality was consistent with what most people get out of RT-11 over the years (this is doable), would there still be such an -11 following? Today, it's far too easy to lump together "unix boxen" as an extension of this notion. IMO most people *never* appreciate a computer's architecture under it all. cjl From danpop@cernapo.cern.ch Thu Aug 12 19:00:57 EDT 1993 Article: 329 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!rpi!uwm.edu!cs.utexas.edu!uunet!mcsun!dxcern!l3apollo8!danpop From: danpop@cernapo.cern.ch (Dan Pop) Subject: Re: Happy PDP-5 day Message-ID: Sender: news@dxcern.cern.ch (USENET News System) Organization: CERN European Lab for Particle Physics References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> Date: Thu, 12 Aug 1993 20:24:50 GMT Lines: 46 Xref: news.columbia.edu alt.sys.pdp8:329 alt.folklore.computers:49484 In <24dvuk$8k5@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >A side issue: > >How many people are there that actually appreciate a machine's architecture? > >I suspect that many self-proclaimed -11 lovers got that way merely because >they liked the software for what it could do for them, not the underlying >hardware that was being used to implement it, etc. > Well, those people programming in assembly (MACRO-11) definitely loved the the machine architecture, especially the addressing modes and the symmetry of the registers. They were not available on others mini's of the time. >A case in point could be RT-11. It is likely that a system mimicking RT-11 >could have been done on the PDP-8. It would have required DEC to insist that >the machine have 32K to accomplish this, instead of the relatively spartan Why? RT-11 could run on a 8K machine. It's true that the word had 4 extra bits, but this could hardly justify 32K on a PDP-8. >attitude of just requiring 8K to run OS/8 (or 4K to run P?S/8!), but DEC never >required any users to go for 32K until the DECmate I. (The VT78 is a fixed >memory size of 16K; all older machines could be had in various sizes, although >most 8/a memories tended to be either 16K or 32K.) > >So, if DEC had written "RT-8" and it's functionality was consistent with what >most people get out of RT-11 over the years (this is doable), would there >still be such an -11 following? > It's not clear if by "-11" you refer to PDP-11 or RT-11. The answer is yes, anyway (IMHO). PDP-11 was not designed primarily to run RT-11. And RT-11 was only one of the OS's designed for PDP-11, namely the one oriented towards the small configurations used in laboratory automation, amongst other many applications. They had the advantage that the software development could be done on bigger machines /45, /70, /34, /44 and the laboratory or factory machines could be equipped with just enough memory to run the application software (at the beginning, when memory and mass storage peripherals were expensive) or RT-11 and the application software (later). Dan -- Dan Pop Tel: +41.22.767.2335 Email: danpop@cernapo.cern.ch Mail: CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland From lasner@watsun.cc.columbia.edu Thu Aug 12 19:07:53 EDT 1993 Article: 330 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 12 Aug 1993 23:07:18 GMT Organization: Columbia University Lines: 35 Message-ID: <24eif6$ivc@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article danpop@cernapo.cern.ch (Dan Pop) writes: >Well, those people programming in assembly (MACRO-11) definitely loved the >the machine architecture, especially the addressing modes and the symmetry of >the registers. They were not available on others mini's of the time. Personally, I hate(d) it. But that's not the point. I would think that the people who programmed in macro-11 were a minority, and I am asking if there was a significent percentage of customers with only a software utility's-eye view of a machine. >Why? RT-11 could run on a 8K machine. It's true that the word had 4 extra bits, >but this could hardly justify 32K on a PDP-8. Well, perhaps 12K on an -8. The point is that you want about 8K for the user program on the -8, same as in OS/8. I figured that for a whole field to be available to the user, the system would steal about 4K for itself. But the point is that DEC only demanded 12K for problematic peripherals, and 8K otherwise since this is the OS/8 minimum, etc. >It's not clear if by "-11" you refer to PDP-11 or RT-11. The answer is yes, >anyway (IMHO). PDP-11 was not designed primarily to run RT-11. And RT-11 was >only one of the OS's designed for PDP-11, namely the one oriented towards >the small configurations used in laboratory automation, amongst other many >applications. They had the advantage that the software development could be >done on bigger machines /45, /70, /34, /44 and the laboratory or factory >machines could be equipped with just enough memory to run the application >software (at the beginning, when memory and mass storage peripherals were >expensive) or RT-11 and the application software (later). I meant that if there was an RT-8 that did what the -11 did, it could have predated RT-11, but they just weren't interested at the time. Picture a world without RT-11, but with RT-8. I suspect that for a goodly segment of the DEC-buying public, it woudn't have made a difference. cjl From secrist@kxovax.enet.dec.com Fri Aug 13 12:34:49 EDT 1993 Article: 331 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!wupost!howland.reston.ans.net!agate!ames!decwrl!pa.dec.com!crl.dec.com!jac.nuo.dec.com!kxovax.enet.dec.com!secrist From: secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) Subject: MS-DOS is NOT RT-11 ! Message-ID: <1993Aug13.021546.19921@jac.nuo.dec.com> Sender: news@jac.nuo.dec.com (USENET News System) Organization: Digital Equipment Corporation Date: Fri, 13 Aug 1993 03:12:36 GMT Lines: 16 RT-11 can be multitasking, multi-user (with TSX, COS-300, or MU-BASIC) and can do real time. DOS is none of those, and CP/M is certainly quite a deevolution. If you want to say the user interface drew its inspiration from the prior okay, but the resemblance ends there ! Besides, RT-11 V5.6 kicks butt compared to MS-DOS (this is not your father's RT-11) ! Regards, rcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Richard C. Secrist "The superior man understands +-+-+-+-+-+-+-+ Digital Equipment Corp. what is right; the inferior man |d|i|g|i|t|a|l| secrist@kxovax.enet.dec.com understands what will sell." +-+-+-+-+-+-+-+tm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From bqt@Minsk.docs.uu.se Fri Aug 13 13:00:00 EDT 1993 Article: 332 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 13 Aug 93 10:05:16 GMT Organization: Uppsala University Lines: 66 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> NNTP-Posting-Host: minsk.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:332 alt.folklore.computers:49507 In <24dvuk$8k5@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article <1993Aug12.091041.71099@cc.usu.edu> ivie@cc.usu.edu writes: >>Roger "The first DEC machine I used was a VAX. Then I used a PDP-8." Ivie >Which is probably a unique event in the annals of DEC. It takes an observant >individual to appreciate the distinction, etc. :-) Well, I went from pdp-11 to VAX to pdp-8 and pdp-10. :-) >A side issue: >How many people are there that actually appreciate a machine's architecture? Probably less that one would wish, and more than you suspect, Charles. I think you underestimate the appreciation some people have for the pdp-11 architecture. >I suspect that many self-proclaimed -11 lovers got that way merely because >they liked the software for what it could do for them, not the underlying >hardware that was being used to implement it, etc. No no no. The -11 has some really wonderful stuff. For one thing I *really* love that the PC is a general register. No special instructions for immediate mode, register->memory, memory->register, memory->memory or register->register. It is all the same instructions. I never have understood how anyone can like a processor which don't do it that way. (Such as the MC68xxx, which do *everything *wrong*). But the pdp8, pdp10 et al. does things a completely different way, which is beautiful in another way totally, but also extremely enjoyable. Who can resist an architecture where JUMP means do not jump. :-) >A case in point could be RT-11. It is likely that a system mimicking RT-11 >could have been done on the PDP-8. It would have required DEC to insist that >the machine have 32K to accomplish this, instead of the relatively spartan >attitude of just requiring 8K to run OS/8 (or 4K to run P?S/8!), but DEC never >required any users to go for 32K until the DECmate I. (The VT78 is a fixed >memory size of 16K; all older machines could be had in various sizes, although >most 8/a memories tended to be either 16K or 32K.) >So, if DEC had written "RT-8" and it's functionality was consistent with what >most people get out of RT-11 over the years (this is doable), would there >still be such an -11 following? Yes. In my opinion, DEC did do that. Have you ever used RTS8? OS/8 is a background job in RTS8. Seems to me like something very much moving towards RT-11, but I haven't used RT-11 much myself. The problem is, as usual, the memory limit of the pdp-8, it was probably the big killer of the architecture. The 8/a had the KT-8, but few were sold, it seems. >Today, it's far too easy to lump together "unix boxen" as an extension of this >notion. IMO most people *never* appreciate a computer's architecture under it >all. That is very true, especially for unix-jocks. 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 bqt@Minsk.docs.uu.se Fri Aug 13 13:40:49 EDT 1993 Article: 333 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 13 Aug 93 10:19:50 GMT Organization: Uppsala University Lines: 74 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24eif6$ivc@apakabar.cc.columbia.edu> NNTP-Posting-Host: minsk.docs.uu.se In <24eif6$ivc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article danpop@cernapo.cern.ch (Dan Pop) writes: >>Well, those people programming in assembly (MACRO-11) definitely loved the >>the machine architecture, especially the addressing modes and the symmetry of >>the registers. They were not available on others mini's of the time. >Personally, I hate(d) it. But that's not the point. I would think that the >people who programmed in macro-11 were a minority, and I am asking if there >was a significent percentage of customers with only a software utility's-eye >view of a machine. No, I think that a big majority programmed in assembler for the first years on the pdp-11. Especially if you used RT-11, since most high-level languages don't fit too good into realtime applications. Even to this say, I'd say that pretty many people program in assembler if they use a pdp-11, with the exception of those running unix. Especially those with RT-11 in mind, I think often were customers who wrote their own software, in assembler, and didn't bother much about anything else in the machine. The fact is that *very* many people really do like the pdp-11 architecture, and while I know you won't appreciate this point, many other preocessor manufacturers obviously thought it was good enough to copy, to get customers. (Think about the MC68xxx, or NS16xxx) (Hell, even the 6502 was inspired by the pdp-11 from what I've heard). >I meant that if there was an RT-8 that did what the -11 did, it could have >predated RT-11, but they just weren't interested at the time. Picture a >world without RT-11, but with RT-8. I suspect that for a goodly segment of >the DEC-buying public, it woudn't have made a difference. I'm not sure I agree. DEC would probably have sold more pdp8 for a while, and less pdp11, that much I agree upon. But the end would very probably have been the same anyway. The potential of the pdp8 was already being stretched, while the pdp-11 was starting at the low end, and there the pdp8 could be given an edge, but as usual, all development goes towards larger and more advanced. You can not get a pdp8 in the same size as the bigger pdp11, so in the end, the pdp8 would be the looser anyway. When prices of hardware drop, more people would be able to afford a bigger pdp11 instead, and have access to all the software on it, which could not be gotten to run on a pdp8, and be able to develop software on a fast machine, and then use a small, dedicated pdp11 on different tasks. One of the big problems with the pdp8, when you start building bigger systems, is the interrupt structure, which is very lame. It works very nice for small system, but not very good when it comes to large ones. And remember also, that in the early seventies, disks and tapes were bulky stuff, which required a lot of hardware to interface, which the pdp8 hadn't any space for either. Today, the pdp8 actually got better odds than in the early seventies. Imagine massbus on a pdp8? Also, Omnibus puts a limit on how much stuff you can throw into a pdp8, and the architecture limits you to 64 device adresses, each one able of pretty little. A normal terminal needs two devices. Sure, you could stretch it all some more, but it can get pretty expensive to put the limits all the time. The early pdp11 peripherials wasn't made by stretching things. Terminal controllers were made on whole backplanes, while using several adresses in the I/O page. But backplane size was not a big issue on the pdp11, and the I/O page was 8K. Makes it much cheaper to do peripherials for the pdp11 in the long run. And don't flame me for liking the pdp11, Charles. I think you know my general opinions on several DEC machines... -- 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 ivie@cc.usu.edu Fri Aug 13 13:41:32 EDT 1993 Article: 334 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.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: Re: MS-DOS is NOT RT-11 ! Message-ID: <1993Aug13.094851.71161@cc.usu.edu> Date: 13 Aug 93 09:48:51 MDT References: <1993Aug13.021546.19921@jac.nuo.dec.com> Organization: Utah State University Lines: 26 In article <1993Aug13.021546.19921@jac.nuo.dec.com>, secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) writes: > > RT-11 can be multitasking, multi-user (with TSX, COS-300, or MU-BASIC) > and can do real time. DOS is none of those, and CP/M is certainly > quite a deevolution. If you want to say the user interface drew its > inspiration from the prior okay, but the resemblance ends there ! Since I haven't used the 1975-era RT-11 that CP/M allegedly (according to Gary Kildall) drew, I can't say anything definitive about the resemblance of CP/M to RT-11. By the way, CP/M can be multitasking, multi-user, multithreaded (with MP/M), and networked (with CP/NET)... > Besides, RT-11 V5.6 kicks butt compared to MS-DOS (this is not your > father's RT-11) ! For that matter, 4.0 (the first version of RT-11 that I used) kicks butt compared to MS-DOS... What's new in 5.6? My ins to the hardware guys (that could sneak me distribution kits) ended with field test versions of 5.5. Of course, about 5.1 I was starting to think that RT-11 was getting too big and complicated... Roger "Don't get me wrong; device subsetting is a _great_ idea" Ivie ivie@cc.usu.edu From lasner@watsun.cc.columbia.edu Fri Aug 13 13:45:30 EDT 1993 Article: 335 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 13 Aug 1993 16:59:43 GMT Organization: Columbia University Lines: 125 Message-ID: <24gh9v$pqq@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:335 alt.folklore.computers:49520 In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >In <24dvuk$8k5@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >>How many people are there that actually appreciate a machine's architecture? > >Probably less that one would wish, and more than you suspect, Charles. >I think you underestimate the appreciation some people have for the >pdp-11 architecture. I think you are looking too closely for an answer to the question. See your own response about unix-jocks below. Maybe in your "sphere" some people like the -11, but I am speaking more globally. I think the bulk of people who purchased -11's did so merely for what the applications did for them indirectly, not for the underlying machine. And said applications were not something that came about from some claimed miraculous features unique to the -11. In any case, the main point is that when this abstractionis taken to extremes, the unix-jock phenomena is the end result. >>I suspect that many self-proclaimed -11 lovers got that way merely because >>they liked the software for what it could do for them, not the underlying >>hardware that was being used to implement it, etc. > >No no no. The -11 has some really wonderful stuff. >For one thing I *really* love that the PC is a general register. >No special instructions for immediate mode, register->memory, >memory->register, memory->memory or register->register. It is >all the same instructions. Regardless, I still want the global answer. However, I will freely concede that a lot of *current* -11 people agree with you completely. My question really has little to do with -11's per se. >I never have understood how anyone can like a processor which don't >do it that way. (Such as the MC68xxx, which do *everything *wrong*). >But the pdp8, pdp10 et al. does things a completely different way, >which is beautiful in another way totally, but also extremely >enjoyable. >Who can resist an architecture where JUMP means do not jump. :-) To answer that, I would say "JRST about anyone" :-). > >>A case in point could be RT-11. It is likely that a system mimicking RT-11 >>could have been done on the PDP-8. It would have required DEC to insist that >>the machine have 32K to accomplish this, instead of the relatively spartan >>attitude of just requiring 8K to run OS/8 (or 4K to run P?S/8!), but DEC never >>required any users to go for 32K until the DECmate I. (The VT78 is a fixed >>memory size of 16K; all older machines could be had in various sizes, although >>most 8/a memories tended to be either 16K or 32K.) > >>So, if DEC had written "RT-8" and it's functionality was consistent with what >>most people get out of RT-11 over the years (this is doable), would there >>still be such an -11 following? > >Yes. In my opinion, DEC did do that. Have you ever used RTS8? >OS/8 is a background job in RTS8. Seems to me like something very much >moving towards RT-11, but I haven't used RT-11 much myself. >The problem is, as usual, the memory limit of the pdp-8, it was probably >the big killer of the architecture. The 8/a had the KT-8, but few >were sold, it seems. Most of what became the software for the PDP-8 was a notion in Richard Lary's head years before he came to work from DEC, and was still in the group I am a proud member of back then at Brooklyn Polytech. Back then, RTS8 (formerly SRT8) was known as "TOY". We were running it in 4K from MS-8 and it handled our extra PT08 TTY: interface, etc. RTS8 ain't RT-11 or even like it. What the -8 wants to have to be on a par with an RT-11 is a system where you can dynamically load executables that are on the file structure initially, and come in and make system calls to the system resident interrupt handler/system routines, etc. This is not what RTS8 does, rather it's more like the original rigid definition of the early RSX-11 with fixed tasks, etc. Someone was even writing a task builder for it to help out, etc. But further, RTS8 doesn't rely on the PDP-8 timeshare trap either. Most of the other systems that do, are too busy emulating 4K machines and/or OS/8. There really isn't an RT-11-type system out there for the -8 that got anywhere completely. What would be required is a radical departure from OS/8, which perhaps included file system compatibility, but whose executable files are totally incompatibile with OS/8. Since OS/8 would still own the rights to boot the device, the RT-8 would then be constrained to live within OS/8's provinces further reducing the amount of available memory, etc. I would recommend dumping all of the OS/8 conventions, since they are too marginal for the purpose, and it wouldn't serve any purpose towards such a project. After all, an OS/8 conversion task could be written for it after the fact. I am open to suggestion for improvements to the P?S/8 "third" file structure which could be the home to such a system. Unlike OS/8, P?S/8 only requires 128 words resident in 07600-07777 to get started, and could be totally kicked out of memory once the RT-8 got up. (There are three file structures: one oriented towards users who prefer something like the original BASIC from eons ago, which is distinct from the second which is optimized for system program descriptions. Both of these are viable in 4K! The third structure is under development and will be used to entertain the notion of programs that can't run in 4K, as long as a basic set of copy/rename/delete utilities can access it in 4K, and said utilities themselves can reside in the second directory for the purposes of calling them up. Alternatively, it could be required that the second directory contain a shell program that needs more than 4K to run at all, and it would access the third directory completely, and some alternate 4K-only means could minimally exist to at least examine the third directory, etc. In any case, this third directory is the one where all of the new "action" goes. Tentative features include file protection bits, tree-structured directory segments, time as well as date stamps, file lengths in words/bytes as opposed to blocks like OS/8, execution restrictions meaning memory availability, block number boundary restriction capabilities, etc. Please contact me if anything conceptual ought to be considered, etc.) In any case, an RT-8 system ought to use traps to get at system services. This really hasn't been done outside of TSS8. >>Today, it's far too easy to lump together "unix boxen" as an extension of this >>notion. IMO most people *never* appreciate a computer's architecture under it >>all. > >That is very true, especially for unix-jocks. All too true. Sort of interesting to here something that sounds like: Eunuchs and jocks in the same sentence :-). cjl From lasner@watsun.cc.columbia.edu Fri Aug 13 13:45:43 EDT 1993 Article: 336 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 13 Aug 1993 17:40:29 GMT Organization: Columbia University Lines: 178 Message-ID: <24gjmd$r8s@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24eif6$ivc@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >In <24eif6$ivc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >>In article danpop@cernapo.cern.ch (Dan Pop) writes: >>>Well, those people programming in assembly (MACRO-11) definitely loved the >>>the machine architecture, especially the addressing modes and the symmetry of >>>the registers. They were not available on others mini's of the time. > >>Personally, I hate(d) it. But that's not the point. I would think that the >>people who programmed in macro-11 were a minority, and I am asking if there >>was a significent percentage of customers with only a software utility's-eye >>view of a machine. > >No, I think that a big majority programmed in assembler for the first years >on the pdp-11. Especially if you used RT-11, since most high-level >languages don't fit too good into realtime applications. >Even to this say, I'd say that pretty many people program in assembler >if they use a pdp-11, with the exception of those running unix. First of all, reading the end first, this ain't a flame :-). We are at cross-purposes here. I am attempting to illustrate that there is a class of user that is architecture ignorant, but either uses programs that others write, or alternatively programmed only in Fortran or whatever where the actual machine didn't matter. Some people make an argument that no matter how good the potential of a machine is, the lack of good software will kill it. I am making an inverse argument which is that if the software looks good to a user, they may never understand whether the underlying machine was good or bad, and whether the software was well written or was actually just a pile that happened to look good at the command level. > >Especially those with RT-11 in mind, I think often were customers >who wrote their own software, in assembler, and didn't bother much >about anything else in the machine. No doubt it applied to some, as it did with the -8 as well. But in my experience, I found customers who were ignorant of what was in their respective systems of both types. > >The fact is that *very* many people really do like the pdp-11 architecture, >and while I know you won't appreciate this point, many other preocessor >manufacturers obviously thought it was good enough to copy, to get >customers. (Think about the MC68xxx, or NS16xxx) >(Hell, even the 6502 was inspired by the pdp-11 from what I've heard). I don't want to get into the religious war over architecture, but remember that there is one for a whole bunch of features that there are those who lambast the -11 for. Some topics to be named, but please do not dwell on them: byte addressing, inconsistent condition codes, not fully symmetrical modes and operations, largely wasted addressing modes that have little statistical usage, etc. Please let's pursue this (if at all!) separately, but I didn't invent any of the references; most are the subject of some master's theses and journal articles, and there is nothing new here, etc. > >>I meant that if there was an RT-8 that did what the -11 did, it could have >>predated RT-11, but they just weren't interested at the time. Picture a >>world without RT-11, but with RT-8. I suspect that for a goodly segment of >>the DEC-buying public, it woudn't have made a difference. > >I'm not sure I agree. DEC would probably have sold more pdp8 for a while, >and less pdp11, that much I agree upon. But that's the only point I raise, that this would have been fine for the purposes the customers sought, etc. IMO every machine should have an RT-11 kind of a system, and for a while there was a clamor for an RT-32 for the VAX. > But the end would very probably >have been the same anyway. The potential of the pdp8 was already being >stretched, while the pdp-11 was starting at the low end, and there >the pdp8 could be given an edge, but as usual, all development goes >towards larger and more advanced. No, this is simply not true. DEC had a mindset that a PDP-8 was a 4K machine and it was a major step to get them to admit to needing 8K because for the original LINC-8 and -8 it was quite a bit of extra hardware. But from the 8/i onward it wasn't so big a deal. It was next to impossible to get DEC to spring for software that would have required 12K-16K and wanted 32K, which at the time was considered astronomical. The -11 came into a world where they realized that those 4K 11-20's were worthless, and they better get some memory into them in order to do anything useful with them. Thus, the -11 benefitted from the ability to support a project based on more memory being in the average customer's machine before hand. > You can not get a pdp8 in the >same size as the bigger pdp11, so in the end, the pdp8 would be >the looser anyway. When prices of hardware drop, more people would >be able to afford a bigger pdp11 instead, and have access to all >the software on it, which could not be gotten to run on a pdp8, >and be able to develop software on a fast machine, and then use a >small, dedicated pdp11 on different tasks. No, at the time the -11 was a 32K machine. The bigger machines came later. RT-11 runs on these "smaller" -11's. One-user machines don't really need the MMU stuff. If the -8 was considered a 32K machine instead of a 4K one, things could have been different. In any case the seeds of the relevant software predate any of these decisions. > >One of the big problems with the pdp8, when you start building >bigger systems, is the interrupt structure, which is very lame. >It works very nice for small system, but not very good when >it comes to large ones. That's simply not true. When the fancier peripherals started to come in, they supported vectored interrupts. The PDP-12 has API and is an older design. In fact, API was planned for the Omnibus and then dropped! But in any case, I have worked with the KL8A and SLZ8 which are one-device-vectored interrupt handling, and also the TELCON 32-channel multiplexors. Others have worked with the DC02 family of terminal multiplexors which come in sizes from 4 TTY's to 32 TTY's with one interrupt. I think you are assuming that the problem would be that if you had N terminals, you need N pollings to handle the interrupts. In real systems, N never gets to even 4. However, since there is no actual API hardware other than on the -12, you have to have a little overhead to fake it if necessary. I once wrote a series of real-time programs that did this, and the overhead wasn't really that much; mostly it was needing a real-time dedicated stack and auto-index register devoted to it, but it really wasn't more than a few instructions more than some mythical API hardware. There are more sources of overhead than merely the count of instruction fetches in an interrupt handler. However, I have heard of people who had to count their -11 instructions in interrupt handlers because the machines were too slow to keep up with the data! > And remember also, that in the early >seventies, disks and tapes were bulky stuff, which required >a lot of hardware to interface, which the pdp8 hadn't any space for >either. Today, the pdp8 actually got better odds than in the >early seventies. Imagine massbus on a pdp8? I don't understand this at all: I assume you are referring to the Omnibus being a physical real-estate problem if you are building the whole peripheral into the buss-box. But the -11's UNIBUS was more like the older positive buss where there is a separate backplane which can be as big as you need. To that way of thinking, the LSI/2 cards of the smallest Q-bus machines are more limited than the -8. In any case, I have had SCSI on my -8/a for years, so I still don't understand the problem. Regardless, all of us can perhaps take advantage of the fact that much peripheral hardware is a lot smaller! > >Also, Omnibus puts a limit on how much stuff you can throw into >a pdp8, and the architecture limits you to 64 device adresses, >each one able of pretty little. A normal terminal needs two >devices. Sure, you could stretch it all some more, but it >can get pretty expensive to put the limits all the time. See above. Each device address *can* be lame, but doesn't have to be. You really don't just replicate the console interface to add another TTY:! >The early pdp11 peripherials wasn't made by stretching things. >Terminal controllers were made on whole backplanes, while using >several adresses in the I/O page. But backplane size was not >a big issue on the pdp11, and the I/O page was 8K. And later they found that it was too big so lowered it to 4K. I don't understand the reference to stretching things since the normal -8 way isn't stretched. If neither machine stretches things, then fine. > >Makes it much cheaper to do peripherials for the pdp11 in the long run. No way. The -11 stuff was always more expensive. The problem is usually the -8 version got the short end of the hardware engineering stick. As to ultimate price, I think there is no significant price in a properly engineered solution, just that sometimes that became an unachievable goal. > >And don't flame me for liking the pdp11, Charles. I think you >know my general opinions on several DEC machines... As you know, I already know that. No flames per se intended. However, not everyone agrees with either me or you. My biggest problem with the -11 is "political" in that where DEC could have done better with -8's, they clumsily chose to use -11's, sometimes with negative consequences, such as the Disney contract they lost to DG for about $70M, etc. cjl From hshubs@cis.umassd.edu Sat Aug 14 18:03:16 EDT 1993 Article: 337 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!noc.near.net!nic.umass.edu!umassd.edu!hshubs From: hshubs@cis.umassd.edu (Howard S Shubs) Subject: Re: Happy PDP-5 day Message-ID: Sender: usenet@umassd.edu (USENET News System) Organization: University of Massachusetts Dartmouth References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> Date: Sat, 14 Aug 1993 06:42:45 GMT Lines: 20 Xref: news.columbia.edu alt.sys.pdp8:337 alt.folklore.computers:49555 In <24gh9v$pqq@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >>In <24dvuk$8k5@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >> >>>How many people are there that actually appreciate a machine's architecture? >> >>Probably less that one would wish, and more than you suspect, Charles. >>I think you underestimate the appreciation some people have for the >>pdp-11 architecture. >I think the bulk of people >who purchased -11's did so merely for what the applications did for them >indirectly, not for the underlying machine. That's true of any computer. Machines are purchased for a reason. OTOH, people who -get them for free- might like them for themselves. -- Howard S Shubs hshubs@bix.com For to win 100 victories in 100 The Denim Adept hshubs@cis.umassd.edu battles is not the acme of skill. From lasner@watsun.cc.columbia.edu Sat Aug 14 18:08:26 EDT 1993 Article: 338 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 14 Aug 1993 22:08:18 GMT Organization: Columbia University Lines: 14 Message-ID: <24jnoi$jcn@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:338 alt.folklore.computers:49579 In article hshubs@cis.umassd.edu (Howard S Shubs) writes: >That's true of any computer. Machines are purchased for a reason. OTOH, >people who -get them for free- might like them for themselves. That's the point I was making. I think JB is speaking for people in our group or similar, whereas I was referring to original purchasers/the people the marketroids are trying to reach. To that point, I am saying that it's unfortunate that DEC never tried to exploit the power of a PDP-8 with more than about 8K for the purposes of what RT-11 did/does well, since clearly such a system can be done for the -8, but unfortunately never was. (And apparently they repeated the mistake with the VAX as well, since there was an expected following of what was to be called RT-32, etc.) cjl From bqt@Sofia.docs.uu.se Mon Aug 16 01:07:44 EDT 1993 Article: 339 of alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Sofia.docs.uu.se!bqt From: bqt@Sofia.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 15 Aug 93 00:35:55 GMT Organization: Uppsala University Lines: 77 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> NNTP-Posting-Host: sofia.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:339 alt.folklore.computers:49584 In <24gh9v$pqq@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >I think you are looking too closely for an answer to the question. See your >own response about unix-jocks below. Maybe in your "sphere" some people >like the -11, but I am speaking more globally. I think the bulk of people >who purchased -11's did so merely for what the applications did for them >indirectly, not for the underlying machine. And said applications were not >something that came about from some claimed miraculous features unique to >the -11. In any case, the main point is that when this abstractionis taken to >extremes, the unix-jock phenomena is the end result. The places that bought pdp11's for UNIX was a clear minority! Most places bought pdp11 for process control, second after that was probably education, and many of those used RSTS/E. Admittedly, most people using RSTS/E never used macro-11, but for all other systems, and type of customers, macro-11 was the language of choice. >Most of what became the software for the PDP-8 was a notion in Richard Lary's >head years before he came to work from DEC, and was still in the group I am >a proud member of back then at Brooklyn Polytech. Back then, RTS8 (formerly >SRT8) was known as "TOY". We were running it in 4K from MS-8 and it handled >our extra PT08 TTY: interface, etc. >RTS8 ain't RT-11 or even like it. What the -8 wants to have to be on a par >with an RT-11 is a system where you can dynamically load executables that >are on the file structure initially, and come in and make system calls to >the system resident interrupt handler/system routines, etc. This is not >what RTS8 does, rather it's more like the original rigid definition of the >early RSX-11 with fixed tasks, etc. Someone was even writing a task builder >for it to help out, etc. True, RTS8 is maybe more like RSX is some ways, but the concept of foreground/background seems to me very familiar with the way RT-11 works. And you use OS/8 in RTS8... >But further, RTS8 doesn't rely on the PDP-8 timeshare trap either. Most of >the other systems that do, are too busy emulating 4K machines and/or OS/8. >There really isn't an RT-11-type system out there for the -8 that got anywhere >completely. What would be required is a radical departure from OS/8, which >perhaps included file system compatibility, but whose executable files are >totally incompatibile with OS/8. Since OS/8 would still own the rights to >boot the device, the RT-8 would then be constrained to live within OS/8's >provinces further reducing the amount of available memory, etc. Hmmm, I assume that you mean the trapping of IOT's when you're talking about timeshare trap, right? RTS8 do use that. Atleast in verion 3, which I have. It has to do things that way to keep OS/8 as a process. >I would recommend dumping all of the OS/8 conventions, since they are too >marginal for the purpose, and it wouldn't serve any purpose towards such a >project. After all, an OS/8 conversion task could be written for it after >the fact. I could agree with that. >In any case, an RT-8 system ought to use traps to get at system services. >This really hasn't been done outside of TSS8. Ummm, I could disagree with you. I have used MULTOS some, and it uses IOT's to get different system services, and it emulates several pdp8, each running OS/8. So each user has his own copy of OS/8, but there are some previously unused IOT's which can be used to get additional features. >All too true. Sort of interesting to here something that sounds like: >Eunuchs and jocks in the same sentence :-). :-) -- 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 bqt@Sofia.docs.uu.se Mon Aug 16 01:08:23 EDT 1993 Article: 340 of alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Sofia.docs.uu.se!bqt From: bqt@Sofia.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 15 Aug 93 01:08:03 GMT Organization: Uppsala University Lines: 21 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> NNTP-Posting-Host: sofia.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:340 alt.folklore.computers:49585 In hshubs@cis.umassd.edu (Howard S Shubs) writes: >In <24gh9v$pqq@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>I think the bulk of people >>who purchased -11's did so merely for what the applications did for them >>indirectly, not for the underlying machine. >That's true of any computer. Machines are purchased for a reason. OTOH, >people who -get them for free- might like them for themselves. Yes, but buying machines for a purpose isn't neccesarily the same thing as buying a machine for the applications. Sometimes you buy machines for doing stuff for which there are no prepackaged applications. You still buy the computer for a purpose, but the architecture becomes the deciding point. -- 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 bqt@Sofia.docs.uu.se Mon Aug 16 01:15:14 EDT 1993 Article: 341 of alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!pipex!sunic!corax.udac.uu.se!Sofia.docs.uu.se!bqt From: bqt@Sofia.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 15 Aug 93 01:17:09 GMT Organization: Uppsala University Lines: 38 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> NNTP-Posting-Host: sofia.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:341 alt.folklore.computers:49586 In <24jnoi$jcn@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article hshubs@cis.umassd.edu (Howard S Shubs) writes: >>That's true of any computer. Machines are purchased for a reason. OTOH, >>people who -get them for free- might like them for themselves. >That's the point I was making. I think JB is speaking for people in our group >or similar, whereas I was referring to original purchasers/the people the >marketroids are trying to reach. To that point, I am saying that it's >unfortunate that DEC never tried to exploit the power of a PDP-8 with more than >about 8K for the purposes of what RT-11 did/does well, since clearly such a >system can be done for the -8, but unfortunately never was. (And apparently >they repeated the mistake with the VAX as well, since there was an expected >following of what was to be called RT-32, etc.) No, you are missing my point. In the beginning of the seventies, the typical DEC customer was something completely different than today. At that time, it was technical people who sold and bought DEC stuff. Marketdroids hadn't been exported from IBM yet. (Especially not to DEC). The original purchasers of DEC equipment in the beginning of the pdp11 was people who wrote assembly language on it. You are trying to put them into todays suites. That was not the case. And I still stand by my claim that the pdp8 couldn't grow nicely that much more than it did. The pdp11 could, at that time. As for RT-32, yes, many people wanted other stuff on the VAX, than was eventually came out. TOPS-32 is another story, as is RSX-32, and *no*, VMS is not the same as RSX-11M(-PLUS). VMS feels more like RSTS/E from the outside. I understand it got more in common with IAS... 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 bqt@Sofia.docs.uu.se Mon Aug 16 02:22:07 EDT 1993 Article: 342 of alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!sunic!corax.udac.uu.se!Sofia.docs.uu.se!bqt From: bqt@Sofia.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 15 Aug 93 01:34:14 GMT Organization: Uppsala University Lines: 287 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <24eif6$ivc@apakabar.cc.columbia.edu> <24gjmd$r8s@apakabar.cc.columbia.edu> NNTP-Posting-Host: sofia.docs.uu.se In <24gjmd$r8s@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >>In <24eif6$ivc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >> >>>In article danpop@cernapo.cern.ch (Dan Pop) writes: >>>>Well, those people programming in assembly (MACRO-11) definitely loved the >>>>the machine architecture, especially the addressing modes and the symmetry of >>>>the registers. They were not available on others mini's of the time. >> >>>Personally, I hate(d) it. But that's not the point. I would think that the >>>people who programmed in macro-11 were a minority, and I am asking if there >>>was a significent percentage of customers with only a software utility's-eye >>>view of a machine. >> >>No, I think that a big majority programmed in assembler for the first years >>on the pdp-11. Especially if you used RT-11, since most high-level >>languages don't fit too good into realtime applications. >>Even to this say, I'd say that pretty many people program in assembler >>if they use a pdp-11, with the exception of those running unix. >First of all, reading the end first, this ain't a flame :-). Nope, this is getting to be an interesting discussion... >We are at cross-purposes here. I am attempting to illustrate that there is >a class of user that is architecture ignorant, but either uses programs that >others write, or alternatively programmed only in Fortran or whatever where >the actual machine didn't matter. Some people make an argument that no >matter how good the potential of a machine is, the lack of good software will >kill it. I am making an inverse argument which is that if the software looks >good to a user, they may never understand whether the underlying machine was >good or bad, and whether the software was well written or was actually just >a pile that happened to look good at the command level. While I fulle agree that there exist some people why are totally ignorant, I think that the number is constantly rising, and I believe it was much lower at the time the pdp-11 were introduced... >>Especially those with RT-11 in mind, I think often were customers >>who wrote their own software, in assembler, and didn't bother much >>about anything else in the machine. >No doubt it applied to some, as it did with the -8 as well. But in my >experience, I found customers who were ignorant of what was in their >respective systems of both types. If you are talking about nowadays, I would suspect that was the case even without you saying so. But did you really find that to be the case in say 1971? >>The fact is that *very* many people really do like the pdp-11 architecture, >>and while I know you won't appreciate this point, many other preocessor >>manufacturers obviously thought it was good enough to copy, to get >>customers. (Think about the MC68xxx, or NS16xxx) >>(Hell, even the 6502 was inspired by the pdp-11 from what I've heard). >I don't want to get into the religious war over architecture, but remember >that there is one for a whole bunch of features that there are those who >lambast the -11 for. Some topics to be named, but please do not dwell on >them: byte addressing, inconsistent condition codes, not fully symmetrical >modes and operations, largely wasted addressing modes that have little >statistical usage, etc. Please let's pursue this (if at all!) separately, >but I didn't invent any of the references; most are the subject of some >master's theses and journal articles, and there is nothing new here, etc. Well, I have to agree the the branch instruction isn't very logical in the way how the opcodes look. (Just semi-logical, which is far less than the pdp8 or pdp-10.) Byte-addressing isn't a problem in any way, possible that you are not allowed to address words at odd bytes could be considered illogical. The basic pdp-11 *is* fully symmetrical in addressing modes and operations. The EIS is not, unfortunately, and the reason is that they didn't have enough opcodes left. (They solved that in the VAX, which has been flamed even more because of it...) Nowadays, CISC is pretty unpopular, no surprise the pdp11 gets some fire because of that. But okay, there are a few ugly-looking things in the pdp11, but not that many, really. And in my opinion, the only that bothers me is the limits on the EIS instructions. >>>I meant that if there was an RT-8 that did what the -11 did, it could have >>>predated RT-11, but they just weren't interested at the time. Picture a >>>world without RT-11, but with RT-8. I suspect that for a goodly segment of >>>the DEC-buying public, it woudn't have made a difference. >> >>I'm not sure I agree. DEC would probably have sold more pdp8 for a while, >>and less pdp11, that much I agree upon. >But that's the only point I raise, that this would have been fine for the >purposes the customers sought, etc. IMO every machine should have an RT-11 >kind of a system, and for a while there was a clamor for an RT-32 for the VAX. The point I wanted to make that in the long run it might have been for the worse. We are talking about a short term gain for a long term lossage, in my mind. Sooner or later, the pdp8 would be on the loosing side, and the longer you put it off, it might turn for the worse. Mostly for DEC, since they needed to get money rolling on the pdp11 to get more development going, to get prices down, and stay competitive. Otherwise they would soon have to quit the arena. You have to try to keep the upper hand on your competitors, as well as trying to keep your customers satisfied. And those two goals are pretty hard to meet at the same time. >> But the end would very probably >>have been the same anyway. The potential of the pdp8 was already being >>stretched, while the pdp-11 was starting at the low end, and there >>the pdp8 could be given an edge, but as usual, all development goes >>towards larger and more advanced. >No, this is simply not true. DEC had a mindset that a PDP-8 was a 4K machine >and it was a major step to get them to admit to needing 8K because for the >original LINC-8 and -8 it was quite a bit of extra hardware. But from the >8/i onward it wasn't so big a deal. It was next to impossible to get DEC to >spring for software that would have required 12K-16K and wanted 32K, which >at the time was considered astronomical. The -11 came into a world where they >realized that those 4K 11-20's were worthless, and they better get some memory >into them in order to do anything useful with them. Thus, the -11 benefitted >from the ability to support a project based on more memory being in the >average customer's machine before hand. Yes, but once more extending the address size of the pdp8 would mean much trouble and headache. And it would have needed to be done to get things working for a longer period. Preferrably, you would have wanted to drop the KM8, and go for a real MMU more like the one in the pdp11. But that would have made it incompatible with all existing software. Double trouble. >> You can not get a pdp8 in the >>same size as the bigger pdp11, so in the end, the pdp8 would be >>the looser anyway. When prices of hardware drop, more people would >>be able to afford a bigger pdp11 instead, and have access to all >>the software on it, which could not be gotten to run on a pdp8, >>and be able to develop software on a fast machine, and then use a >>small, dedicated pdp11 on different tasks. >No, at the time the -11 was a 32K machine. The bigger machines came later. >RT-11 runs on these "smaller" -11's. One-user machines don't really need >the MMU stuff. If the -8 was considered a 32K machine instead of a 4K one, >things could have been different. In any case the seeds of the relevant >software predate any of these decisions. I think the 8 was thought of as a 32K machine. The problem was that that was the *upper* limit of the pdp8, while it was the basic design of the pdp11. The pdp11 addressed 32Kword without any additions, while the pdp8 had to use the KM8, which is just about an MMU for the pdp8. When you added an MMU to the pdp11, you got *much* more. >>One of the big problems with the pdp8, when you start building >>bigger systems, is the interrupt structure, which is very lame. >>It works very nice for small system, but not very good when >>it comes to large ones. >That's simply not true. When the fancier peripherals started to come in, >they supported vectored interrupts. The PDP-12 has API and is an older >design. In fact, API was planned for the Omnibus and then dropped! But >in any case, I have worked with the KL8A and SLZ8 which are one-device-vectored >interrupt handling, and also the TELCON 32-channel multiplexors. Don't know anything about the API, but I do know how the KL8A works, and you have to poll it. There is a special IOT which makes it jump if it was requestion an interrupt, but you don't get it to jump according to the programmed vector without that IOT, so you still have that problem. Then you have the problems of nested interrupts. The pdp8 isn't designed to handle that. You don't even have different priorities of interrupts in hardware. You can just poll peripherials in whatever order you want to, and that is your priorities. Noone can interrupt an interrupt, unless the interrupt service do some serious work to allow it. Much headache can come from that... (Do we need to go further into it?) > Others >have worked with the DC02 family of terminal multiplexors which come in sizes >from 4 TTY's to 32 TTY's with one interrupt. I think you are assuming that >the problem would be that if you had N terminals, you need N pollings to >handle the interrupts. In real systems, N never gets to even 4. Not so, I'm saying that you will need *at least* N polling for N devices, and probably a few more. > However, >since there is no actual API hardware other than on the -12, you have to have >a little overhead to fake it if necessary. I once wrote a series of real-time >programs that did this, and the overhead wasn't really that much; mostly it >was needing a real-time dedicated stack and auto-index register devoted to >it, but it really wasn't more than a few instructions more than some mythical >API hardware. There are more sources of overhead than merely the count of >instruction fetches in an interrupt handler. However, I have heard of people >who had to count their -11 instructions in interrupt handlers because the >machines were too slow to keep up with the data! Yes, some pdp11 are really slow. But some also are pretty fast. And I also can tell you that if you would connect those same peripherials to a pdp8, it wouldn't be able to keep up with the speed either. But you just never hooked up stuff with those speeds to pdp8's anyway. >> And remember also, that in the early >>seventies, disks and tapes were bulky stuff, which required >>a lot of hardware to interface, which the pdp8 hadn't any space for >>either. Today, the pdp8 actually got better odds than in the >>early seventies. Imagine massbus on a pdp8? >I don't understand this at all: I assume you are referring to the Omnibus >being a physical real-estate problem if you are building the whole peripheral >into the buss-box. But the -11's UNIBUS was more like the older positive >buss where there is a separate backplane which can be as big as you need. To >that way of thinking, the LSI/2 cards of the smallest Q-bus machines are more >limited than the -8. In any case, I have had SCSI on my -8/a for years, so >I still don't understand the problem. Regardless, all of us can perhaps take >advantage of the fact that much peripheral hardware is a lot smaller! SCSI didn't exist when the decision to move for the pdp11 was made! (Which I was trying to point out to you...) And yes, the Omnibus cannot be of any size you want to. And all lines are already defined, so you cannot build the things in the same free way you can in the Unibus. You just have Unibus in and out for an RH11, the rest is special stuff, and 6 slots wide even so. And HEX flip-chips at that. A massbus controller on Omnibus would probably be around 15 cards. (I have a TU-10 controller, and that one is 4 cards, and that device is pretty simple compared to a massbus) >>Also, Omnibus puts a limit on how much stuff you can throw into >>a pdp8, and the architecture limits you to 64 device adresses, >>each one able of pretty little. A normal terminal needs two >>devices. Sure, you could stretch it all some more, but it >>can get pretty expensive to put the limits all the time. >See above. Each device address *can* be lame, but doesn't have to be. You >really don't just replicate the console interface to add another TTY:! Agree on that one. With terminal multiplexors, you could stuff in many TTYs without using many I/O addresses. But how many I/O adresses do you think you would need for a Massbus device? Probably around 30 or so. (Or you would have to make it even bigger, and harder to use...) >>The early pdp11 peripherials wasn't made by stretching things. >>Terminal controllers were made on whole backplanes, while using >>several adresses in the I/O page. But backplane size was not >>a big issue on the pdp11, and the I/O page was 8K. >And later they found that it was too big so lowered it to 4K. I don't >understand the reference to stretching things since the normal -8 way isn't >stretched. If neither machine stretches things, then fine. The pdp8 would have been stretched if you wanted to expand it much further from where it was. >>Makes it much cheaper to do peripherials for the pdp11 in the long run. >No way. The -11 stuff was always more expensive. The problem is usually >the -8 version got the short end of the hardware engineering stick. As to >ultimate price, I think there is no significant price in a properly engineered >solution, just that sometimes that became an unachievable goal. The pdp11 peripherials were more expensive, and also much more advanced than there pdp8 counterparts, so a straight comparision of $$$ isn't that informative. To once more go back to the massbus, a massbus controller for the pdp8 would have been significantly more expensive than the pdp11 version. And if you didn't go with massbus, you really had no big disks to use on a pdp8 until the SDI comes along, from DEC. 3rd party would have been SMD, which isn't that much smaller or easier. SCSI has only become an option since the Macintosh came. Pretty new compared to the pdp8 or pdp11. >>And don't flame me for liking the pdp11, Charles. I think you >>know my general opinions on several DEC machines... >As you know, I already know that. No flames per se intended. However, not >everyone agrees with either me or you. My biggest problem with the -11 is >"political" in that where DEC could have done better with -8's, they clumsily >chose to use -11's, sometimes with negative consequences, such as the Disney >contract they lost to DG for about $70M, etc. DEC hasn't always been able to come out on top of their competitors, but obviously the have managed better than DG in the long run. -- 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 hshubs@cis.umassd.edu Mon Aug 16 02:22:29 EDT 1993 Article: 343 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!rpi!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!noc.near.net!nic.umass.edu!umassd.edu!hshubs From: hshubs@cis.umassd.edu (Howard S Shubs) Subject: Re: Happy PDP-5 day Message-ID: Sender: usenet@umassd.edu (USENET News System) Organization: University of Massachusetts Dartmouth References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> Date: Sun, 15 Aug 1993 06:44:56 GMT Lines: 24 Xref: news.columbia.edu alt.sys.pdp8:343 alt.folklore.computers:49596 In bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >In hshubs@cis.umassd.edu (Howard S Shubs) writes: >>In <24gh9v$pqq@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>>I think the bulk of people >>>who purchased -11's did so merely for what the applications did for them >>>indirectly, not for the underlying machine. >>That's true of any computer. Machines are purchased for a reason. OTOH, >>people who -get them for free- might like them for themselves. >Yes, but buying machines for a purpose isn't neccesarily the same thing >as buying a machine for the applications. Sometimes you buy machines >for doing stuff for which there are no prepackaged applications. >You still buy the computer for a purpose, but the architecture becomes >the deciding point. Then the deciding point becomes price and availability. Look at the 80n86 series. Certainly it's not popular due to its architecture. -- Howard S Shubs hshubs@bix.com For to win 100 victories in 100 The Denim Adept hshubs@cis.umassd.edu battles is not the acme of skill. From lasner@watsun.cc.columbia.edu Mon Aug 16 02:29:04 EDT 1993 Article: 344 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 16 Aug 1993 05:07:10 GMT Organization: Columbia University Lines: 106 Message-ID: <24n4lu$bav@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:344 alt.folklore.computers:49648 In article bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >In <24gh9v$pqq@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >>In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: > >>I think you are looking too closely for an answer to the question. See your >>own response about unix-jocks below. Maybe in your "sphere" some people >>like the -11, but I am speaking more globally. I think the bulk of people >>who purchased -11's did so merely for what the applications did for them >>indirectly, not for the underlying machine. And said applications were not >>something that came about from some claimed miraculous features unique to >>the -11. In any case, the main point is that when this abstractionis taken to >>extremes, the unix-jock phenomena is the end result. >The places that bought pdp11's for UNIX was a clear minority! No, I mean the notion of unix=unix=unix, not -11-based unix per se. >Most places bought pdp11 for process control, second after that was >probably education, and many of those used RSTS/E. Admittedly, most >people using RSTS/E never used macro-11, but for all other systems, and >type of customers, macro-11 was the language of choice. I think we need someone from DEC to confirm any of this, since I can't fathom your order at all. >>Most of what became the software for the PDP-8 was a notion in Richard Lary's >>head years before he came to work from DEC, and was still in the group I am >>a proud member of back then at Brooklyn Polytech. Back then, RTS8 (formerly >>SRT8) was known as "TOY". We were running it in 4K from MS-8 and it handled >>our extra PT08 TTY: interface, etc. >>RTS8 ain't RT-11 or even like it. What the -8 wants to have to be on a par >>with an RT-11 is a system where you can dynamically load executables that >>are on the file structure initially, and come in and make system calls to >>the system resident interrupt handler/system routines, etc. This is not >>what RTS8 does, rather it's more like the original rigid definition of the >>early RSX-11 with fixed tasks, etc. Someone was even writing a task builder >>for it to help out, etc. >True, RTS8 is maybe more like RSX is some ways, but the concept of >foreground/background seems to me very familiar with the way RT-11 >works. >And you use OS/8 in RTS8... Not really; you can configure a background task, that's all. The bulk of the system is totally non-configurable in the RTS8 sense, sort of like early RSX. >>But further, RTS8 doesn't rely on the PDP-8 timeshare trap either. Most of >>the other systems that do, are too busy emulating 4K machines and/or OS/8. >>There really isn't an RT-11-type system out there for the -8 that got anywhere >>completely. What would be required is a radical departure from OS/8, which >>perhaps included file system compatibility, but whose executable files are >>totally incompatibile with OS/8. Since OS/8 would still own the rights to >>boot the device, the RT-8 would then be constrained to live within OS/8's >>provinces further reducing the amount of available memory, etc. >Hmmm, I assume that you mean the trapping of IOT's when you're talking >about timeshare trap, right? Yes, the trapping of the switch register function so it can be faked, the trapping of HLT so it doesn't ever halt, and the trapping of IOT's so they can be used as executive requests for any and all system services. The idea is that if you do it this way, the code is modular, and could be "upgraded" to a more comprehensive system should it get redesigned. >RTS8 do use that. Atleast in verion 3, which I have. >It has to do things that way to keep OS/8 as a process. No, the point is that *only* the OS/8 background task uses it. And then, only to fake the non-interrupt environment of OS/8. >>I would recommend dumping all of the OS/8 conventions, since they are too >>marginal for the purpose, and it wouldn't serve any purpose towards such a >>project. After all, an OS/8 conversion task could be written for it after >>the fact. >I could agree with that. >>In any case, an RT-8 system ought to use traps to get at system services. >>This really hasn't been done outside of TSS8. >Ummm, I could disagree with you. I have used MULTOS some, >and it uses IOT's to get different system services, and >it emulates several pdp8, each running OS/8. So each user >has his own copy of OS/8, but there are some previously >unused IOT's which can be used to get additional features. Yes, but the main thrust is to simulate the inefficiency of stand-alone non-interrupt I/O, which is fine if you are not concerned with real-time or buffering when it's really done, and a grossly inefficient thing to simulate. Whether other system services are present or not, most of the usage is to slavishly fake how OS/8 bumbles along as if there are no actual interrupts and support multiples of only that. Clearly there is only rare usage of trapped I/O that allows good overlap, etc. >>All too true. Sort of interesting to here something that sounds like: >>Eunuchs and jocks in the same sentence :-). >:-) Perhaps this is an industry secret we uncovered! cjl From lasner@watsun.cc.columbia.edu Mon Aug 16 02:29:14 EDT 1993 Article: 345 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 16 Aug 1993 05:14:56 GMT Organization: Columbia University Lines: 45 Message-ID: <24n54g$bcc@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:345 alt.folklore.computers:49649 In article bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >No, you are missing my point. >In the beginning of the seventies, the typical DEC customer was something >completely different than today. At that time, it was technical people >who sold and bought DEC stuff. Marketdroids hadn't been exported from >IBM yet. (Especially not to DEC). I suggest your locale was isolated from the mainstream. I was already seeing what you refer to go away as early as 1972. By 1975 there wasn't much of a following for many DEC machines from a techical standpoint in many areas. And of course by 1980 it was non-existent. >The original purchasers of DEC equipment in the beginning of the pdp11 >was people who wrote assembly language on it. Yes, at the *very* beginning, since there wasn't yet anything else. But later that changed radically. >You are trying to put them into todays suites. That was not the case. No, today it's just worse, not different. >And I still stand by my claim that the pdp8 couldn't grow nicely that >much more than it did. The pdp11 could, at that time. Irrelevant. My point is that a 32K -8/e with an "RT-8" system on it would be powerful enough to be the system of choice of a goodly number of people who used RT-11 in the "superficial" way we have been discussing. If such a system existed, it could be 512K by 1985 using the CESI memory, and certainly would have been 128K with the KT8A. > >As for RT-32, yes, many people wanted other stuff on the VAX, than >was eventually came out. TOPS-32 is another story, as is RSX-32, and >*no*, VMS is not the same as RSX-11M(-PLUS). Sorry, VMS 1.0 *IS* RSX. >VMS feels more like RSTS/E from the outside. I understand it got >more in common with IAS... Can't say about later stuff, but the roots are what they are. cjl From lasner@watsun.cc.columbia.edu Mon Aug 16 02:29:39 EDT 1993 Article: 346 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 16 Aug 1993 06:21:50 GMT Organization: Columbia University Lines: 445 Message-ID: <24n91u$d78@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24gjmd$r8s@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >In <24gjmd$r8s@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >>In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >>We are at cross-purposes here. I am attempting to illustrate that there is >>a class of user that is architecture ignorant, but either uses programs that >>others write, or alternatively programmed only in Fortran or whatever where >>the actual machine didn't matter. Some people make an argument that no >>matter how good the potential of a machine is, the lack of good software will >>kill it. I am making an inverse argument which is that if the software looks >>good to a user, they may never understand whether the underlying machine was >>good or bad, and whether the software was well written or was actually just >>a pile that happened to look good at the command level. > >While I fulle agree that there exist some people why are totally ignorant, >I think that the number is constantly rising, and I believe it was much >lower at the time the pdp-11 were introduced... Agreed it was *lower*, but not all that low. Also, the -11/20 was introduced in 1970, so we are still talking about a few years down the road. And I would submit that your locale (from DEC marketroid's point of view) is a sales "backwater" not where they were attempting to manipulate the average customer's perceptions. (Also, a lot of customers were "corporate", etc.) So, perhaps your local collection of users represented a different "mindset" from the one that DEC was "shooting" for, and got, primarly in the USA, and especially in NYC, home of many large corporate DEC accounts, etc. >>No doubt it applied to some, as it did with the -8 as well. But in my >>experience, I found customers who were ignorant of what was in their >>respective systems of both types. > >If you are talking about nowadays, I would suspect that was the case even >without you saying so. But did you really find that to be the case in say >1971? Nowadays this argument doesn't exist for the -11 and the -8. They are both dead as far as business is concerned. Had DEC's current attitude existed a few years ago, the -8 and -11 would be handled as "ghosts" instead of only the -11 currently. But any case, I am saying that around 1972 it was already showing true that way :-(. The years just upped the numbers even more. In fact, I was consulting for a few people who had the demented notion that the pre-packaged software consisting of OS/8 release software, combined with the crappy paper-tape software was sufficient to get their job done totally! (Note: DEC had been hired on as a consultant to certain endeavors, and produced programs for a specific application for specific customers. Then, they would market the same programs, often not even modified, to the general audience as alleged viable solutions for the newer customers' problems. This was largely wishful thinking, and the overall quality of these applications was poor. Some were even totally incompatible with disk systems because they were to specifically "intimate" with paper-tape conventions, and were written for machines with 4K or possible 8K where the only peripherals beyond those for the application was the high-speed reader. In these situations, the BIN and RIM loaders could be counted on as being present, not the resident of a disk-based O/S, etc.) They had to rebudget to hire on me and people like me, etc. There was a whole early "network" of us who met at DECUS conventions who were hired on essentially "after the fact" because the software was essentially worthless for applications they counted on, etc. The earliest I can relate to this is actually 1970, just about when the -11 was announced, but on the -8 at the time. > >>>The fact is that *very* many people really do like the pdp-11 architecture, >>>and while I know you won't appreciate this point, many other preocessor >>>manufacturers obviously thought it was good enough to copy, to get >>>customers. (Think about the MC68xxx, or NS16xxx) >>>(Hell, even the 6502 was inspired by the pdp-11 from what I've heard). > >>I don't want to get into the religious war over architecture, but remember >>that there is one for a whole bunch of features that there are those who >>lambast the -11 for. Some topics to be named, but please do not dwell on >>them: byte addressing, inconsistent condition codes, not fully symmetrical >>modes and operations, largely wasted addressing modes that have little >>statistical usage, etc. Please let's pursue this (if at all!) separately, >>but I didn't invent any of the references; most are the subject of some >>master's theses and journal articles, and there is nothing new here, etc. > >Well, I have to agree the the branch instruction isn't very logical >in the way how the opcodes look. (Just semi-logical, which is far less >than the pdp8 or pdp-10.) And the loop counters were so kludgic that they added an asymmetrical one just to get reasonable performance. >Byte-addressing isn't a problem in any way, possible that you are not >allowed to address words at odd bytes could be considered illogical. Byte-addressing disease has always been harmful. The presumption of a fixed byte size is truly idiotic. Only the -10 solves this elegantly, and with no compromise of the address space. In the case of the -11, it's cut in half for no good reason. >The basic pdp-11 *is* fully symmetrical in addressing modes and >operations. The EIS is not, unfortunately, and the reason is that >they didn't have enough opcodes left. I suggest you read some scholarly ACM articles that point out why this is untrue. Take a look at the INC and DEC operations and then compare to adding and subtracting #1 for a trivial example. >(They solved that in the VAX, which has been flamed even more because >of it...) >Nowadays, CISC is pretty unpopular, no surprise the pdp11 gets some >fire because of that. To my mind, not enough. The VAX is treated is if it's the only three-headed monster, but the head count may be different here, but still not normal. > >But okay, there are a few ugly-looking things in the pdp11, but not that >many, really. And in my opinion, the only that bothers me is the >limits on the EIS instructions. Whether it bothers you or not, the "horns" are still there. Maybe you never were "burned" by some of them; others weren't so fortunate, and they wrote articles about the experiences, etc. >The point I wanted to make that in the long run it might have been for >the worse. We are talking about a short term gain for a long term >lossage, in my mind. >Sooner or later, the pdp8 would be on the loosing side, and the longer >you put it off, it might turn for the worse. How can more software availability be bad for DEC? The amount of people who were hired to write RT-11, COS-310, OS/8, etc. was a real tiny group at the beginning. They could have afforded $100K more at the time. >Mostly for DEC, since they needed to get money rolling on the pdp11 >to get more development going, to get prices down, and stay competitive. >Otherwise they would soon have to quit the arena. Essentially, they threw in a lot of money into the -11 money pit. They had made a desparate committment to it, often counterproductive in that to succeed, it had to backstab other architecture's resources, machines that for some of the applications were more suitable. >You have to try to keep the upper hand on your competitors, as well as >trying to keep your customers satisfied. >And those two goals are pretty hard to meet at the same time. Wrong. At the time, DEC "could do no wrong". That attitude hurt them quite a few years later, and deeply so. (Some would say rightfully so!) Competition was internally generated, not an industry problem. I referred to the Disney contract where $70M was lost to DG because a problem that later could, and eventually was done by a micro, was presented on an -11, not an -8. They spent research money on the wrong machine, and predictably lost the contract because it was way overpriced. DG's bid wasn't cheap, but an -8-based one could have beat DG, even with DEC's internal overhead, etc. > >>> But the end would very probably >>>have been the same anyway. The potential of the pdp8 was already being >>>stretched, while the pdp-11 was starting at the low end, and there >>>the pdp8 could be given an edge, but as usual, all development goes >>>towards larger and more advanced. > >>No, this is simply not true. DEC had a mindset that a PDP-8 was a 4K machine >>and it was a major step to get them to admit to needing 8K because for the >>original LINC-8 and -8 it was quite a bit of extra hardware. But from the >>8/i onward it wasn't so big a deal. It was next to impossible to get DEC to >>spring for software that would have required 12K-16K and wanted 32K, which >>at the time was considered astronomical. The -11 came into a world where they >>realized that those 4K 11-20's were worthless, and they better get some memory >>into them in order to do anything useful with them. Thus, the -11 benefitted >>from the ability to support a project based on more memory being in the >>average customer's machine before hand. > >Yes, but once more extending the address size of the pdp8 would mean much >trouble and headache. And it would have needed to be done to get things >working for a longer period. No, the KT8A was planned and built anyway. There was to be a Fortran compiler written that would generate MACREL code that would load into it so that a system akin to the VAX stand-alone system (forget its name) could be built on the -8. The compiler was canned, but MACREL was finished for no pay by Stan Rabinowitz. >Preferrably, you would have wanted to drop the KM8, and go for a real MMU >more like the one in the pdp11. But that would have made it incompatible with >all existing software. Double trouble. No need to. The KT8A or CESI system is fine for an RT-8. Not quite as elegant in some spots, but not blecherous either. > >>> You can not get a pdp8 in the >>>same size as the bigger pdp11, so in the end, the pdp8 would be >>>the looser anyway. When prices of hardware drop, more people would >>>be able to afford a bigger pdp11 instead, and have access to all >>>the software on it, which could not be gotten to run on a pdp8, >>>and be able to develop software on a fast machine, and then use a >>>small, dedicated pdp11 on different tasks. There's no way that at any point in engineering history, an -8 costs more to make than a corresponding -11. The LSI-8 was produced by Richard Lary, and was dropped by management for non-technical reasons, etc. > >>No, at the time the -11 was a 32K machine. The bigger machines came later. >>RT-11 runs on these "smaller" -11's. One-user machines don't really need >>the MMU stuff. If the -8 was considered a 32K machine instead of a 4K one, >>things could have been different. In any case the seeds of the relevant >>software predate any of these decisions. > >I think the 8 was thought of as a 32K machine. The problem was that that >was the *upper* limit of the pdp8, while it was the basic design of the pdp11. >The pdp11 addressed 32Kword without any additions, while the pdp8 had >to use the KM8, which is just about an MMU for the pdp8. When you added >an MMU to the pdp11, you got *much* more. At the beginning, the -11 was a 32K machine, and the -8 was thought to aspire to 32K, but never get there. IT was a 4K machine and making it 8K took some mindset alteration of management. Note that PS/8 was released for 8K -8's at the same time as they were making 4K 11/20's with a TTY: and nothing else. > >>>One of the big problems with the pdp8, when you start building >>>bigger systems, is the interrupt structure, which is very lame. >>>It works very nice for small system, but not very good when >>>it comes to large ones. > >>That's simply not true. When the fancier peripherals started to come in, >>they supported vectored interrupts. The PDP-12 has API and is an older >>design. In fact, API was planned for the Omnibus and then dropped! But >>in any case, I have worked with the KL8A and SLZ8 which are one-device-vectored >>interrupt handling, and also the TELCON 32-channel multiplexors. > >Don't know anything about the API, but I do know how the KL8A works, and >you have to poll it. There is a special IOT which makes it jump if it >was requestion an interrupt, but you don't get it to jump according >to the programmed vector without that IOT, so you still have that >problem. Yes, semi-polling. But the SLZ8 is an 8-channel version of a KL8A, so it cuts the polling overhead in half. The TELCON cards I used needed only a single IOT set to tell you which channel you needed to deal with. Similarly, the DC02 hardware does the same up to 32 channels as well. Various real-time systems on the PDP-12 needed to do that correctly and did so. I think you'll find that only some much later -11's could keep up with an API-capable -12 with a 32 channel DC02. >Then you have the problems of nested interrupts. The pdp8 isn't designed >to handle that. You don't even have different priorities of interrupts >in hardware. You can just poll peripherials in whatever order you want >to, and that is your priorities. Noone can interrupt an interrupt, unless >the interrupt service do some serious work to allow it. >Much headache can come from that... >(Do we need to go further into it?) Yes, as I said, API does all that, and is a standard feature of the -12 (KF-12B). It was planned, then later dropped, from the Omnibus. In any case, I have written real code with an interrupt stack, and you are overblowing the seriousness of the problem. > >> Others >>have worked with the DC02 family of terminal multiplexors which come in sizes >>from 4 TTY's to 32 TTY's with one interrupt. I think you are assuming that >>the problem would be that if you had N terminals, you need N pollings to >>handle the interrupts. In real systems, N never gets to even 4. > >Not so, I'm saying that you will need *at least* N polling for N devices, >and probably a few more. Yes, but the point is that on a real system, N is quite small. The actual difference isn't that great on practical applications, some of which I have already written, etc. > >> However, >>since there is no actual API hardware other than on the -12, you have to have >>a little overhead to fake it if necessary. I once wrote a series of real-time >>programs that did this, and the overhead wasn't really that much; mostly it >>was needing a real-time dedicated stack and auto-index register devoted to >>it, but it really wasn't more than a few instructions more than some mythical >>API hardware. There are more sources of overhead than merely the count of >>instruction fetches in an interrupt handler. However, I have heard of people >>who had to count their -11 instructions in interrupt handlers because the >>machines were too slow to keep up with the data! > >Yes, some pdp11 are really slow. But some also are pretty fast. >And I also can tell you that if you would connect those same peripherials >to a pdp8, it wouldn't be able to keep up with the speed either. >But you just never hooked up stuff with those speeds to pdp8's anyway. That's patently false! The transfer speed of most of the peripherals on the -8 is comparable to that on the -11. Some of the -11's were so slow, they couldn't keep up with the family spec, such as why the RX02 got designed with DMA because LSI's couldn't keep up with an RX01! > >>> And remember also, that in the early >>>seventies, disks and tapes were bulky stuff, which required >>>a lot of hardware to interface, which the pdp8 hadn't any space for >>>either. Today, the pdp8 actually got better odds than in the >>>early seventies. Imagine massbus on a pdp8? > >>I don't understand this at all: I assume you are referring to the Omnibus >>being a physical real-estate problem if you are building the whole peripheral >>into the buss-box. But the -11's UNIBUS was more like the older positive >>buss where there is a separate backplane which can be as big as you need. To >>that way of thinking, the LSI/2 cards of the smallest Q-bus machines are more >>limited than the -8. In any case, I have had SCSI on my -8/a for years, so >>I still don't understand the problem. Regardless, all of us can perhaps take >>advantage of the fact that much peripheral hardware is a lot smaller! > >SCSI didn't exist when the decision to move for the pdp11 was made! SCSI was being used on *my* PDP-8 in 1981. >(Which I was trying to point out to you...) >And yes, the Omnibus cannot be of any size you want to. And all lines >are already defined, so you cannot build the things in the same free way >you can in the Unibus. You just have Unibus in and out for an RH11, the rest >is special stuff, and 6 slots wide even so. And HEX flip-chips at that. >A massbus controller on Omnibus would probably be around 15 cards. >(I have a TU-10 controller, and that one is 4 cards, and that device >is pretty simple compared to a massbus) Not quite true. The Omnibus "grew" a fifth foot to gain more signals in the 8/a. A sixth foot could've been added on easily if required. Physical size is irrelevant, since you can package things -11 style if need be off of cables that plugged into Omnibus first-card controllers. Most of the logic of a TU-10 and TM8E system is in the drive, not the Omnibus. Later peripherals got smaller, not larger. There really isn't much call for peripherals that aggregate more logic real estate than something as gross as the FPP-8/A on two hex Omnibus cards. > >>>Also, Omnibus puts a limit on how much stuff you can throw into >>>a pdp8, and the architecture limits you to 64 device adresses, >>>each one able of pretty little. A normal terminal needs two >>>devices. Sure, you could stretch it all some more, but it >>>can get pretty expensive to put the limits all the time. > >>See above. Each device address *can* be lame, but doesn't have to be. You >>really don't just replicate the console interface to add another TTY:! > >Agree on that one. With terminal multiplexors, you could stuff in >many TTYs without using many I/O addresses. But how many I/O adresses >do you think you would need for a Massbus device? >Probably around 30 or so. >(Or you would have to make it even bigger, and harder to use...) Probably about 1 set. There exists a 256 channel I/O card for the -8 with one set of IOT's. That's what multiplexors are for, etc. You are assuming a trivial interface where one IOT does one thing only, not a multi-functional device. > >>>The early pdp11 peripherials wasn't made by stretching things. >>>Terminal controllers were made on whole backplanes, while using >>>several adresses in the I/O page. But backplane size was not >>>a big issue on the pdp11, and the I/O page was 8K. > >>And later they found that it was too big so lowered it to 4K. I don't >>understand the reference to stretching things since the normal -8 way isn't >>stretched. If neither machine stretches things, then fine. > >The pdp8 would have been stretched if you wanted to expand it >much further from where it was. I still don't understand what you mean by stretching. The memory concept can be extended to 2^24 words, and the IOT's to 2^18 operations. Where's the stretch other than being imaginative beyond the simple interfaces used for the console I/O which was never the model for anything else? > >>>Makes it much cheaper to do peripherials for the pdp11 in the long run. > >>No way. The -11 stuff was always more expensive. The problem is usually >>the -8 version got the short end of the hardware engineering stick. As to >>ultimate price, I think there is no significant price in a properly engineered >>solution, just that sometimes that became an unachievable goal. > >The pdp11 peripherials were more expensive, and also much more advanced >than there pdp8 counterparts, so a straight comparision of $$$ isn't >that informative. Other than Massbus adaptors, which wasn't the main thrust, I don't know what you're talking about. Generally, the -8 version of a peripheral they both had was cheaper, and paid a price of having to have klduged software to get around avoidable problems, etc. The RK8E was a lot cheaper than the multitudes of RK11's, etc. (Not to be confused with what they wanted to *charge* for either!) >To once more go back to the massbus, a massbus controller for the pdp8 >would have been significantly more expensive than the pdp11 version. > >And if you didn't go with massbus, you really had no big disks to >use on a pdp8 until the SDI comes along, from DEC. 3rd party would have >been SMD, which isn't that much smaller or easier. I was already using a 10-Meg disk on the -8 years before either. Had anyone wanted to interface the slightly larger packs, the basic interface would be virtually the same. The disks simply cost more, beyond most people's budgets, so they never bothered. Interface costs weren't the driving force though. >SCSI has only become an option since the Macintosh came. Pretty new >compared to the pdp8 or pdp11. Wrong, see above. 1981 predates the Mac. BTW, the MAC version of SCSI is not really SCSI, and it uses no data state purpose. Essentially, it uses a program-transfer kind of interface to shovel bytes down a lame digital I/O interface. The PDP-8 and any other sane design uses the command/data state of the SCSI buss to initiate a DMA operation at the appropriate time so that the I/O speed is reasonable. I have been in contact with a few SCSI peripheral manufacturers who admitted that they "bent" a few rules so that their disks would actually be MAC compatible, as opposed to merely being compatible with the spec on paper. But from the beginning, the -8 version of the interface, the CESI MDC8 card, was always playing by the rules. My first SCSI controller was an SMS ripoff of the Shugart actual disk interface card. Back then they didn't know anything about common command sets or anything, so they replicated just about everything except some hack commands that allowed the controller to copy between devices without intervention from the host. The reason was that the host could do a device-host, host-device copy faster, and if you had no other disks, what would you do on the host anyway? :-). > >>>And don't flame me for liking the pdp11, Charles. I think you >>>know my general opinions on several DEC machines... > >>As you know, I already know that. No flames per se intended. However, not >>everyone agrees with either me or you. My biggest problem with the -11 is >>"political" in that where DEC could have done better with -8's, they clumsily >>chose to use -11's, sometimes with negative consequences, such as the Disney >>contract they lost to DG for about $70M, etc. > >DEC hasn't always been able to come out on top of their competitors, >but obviously the have managed better than DG in the long run. I'm not so sure about that! In any case, there were many situations where, without benefit of hindsight, DEC lost out as predicted. Also, remember, that had DEC done things right, there never would've been a DG at all, just a moderately larger DEC. Perhaps today they would be faring better that way, etc. cjl From rwh@CS.CMU.EDU Mon Aug 16 13:57:59 EDT 1993 Article: 347 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!rwh From: rwh@CS.CMU.EDU (Robert Harper) Subject: Re: Happy PDP-5 day In-Reply-To: lasner@watsun.cc.columbia.edu's message of 16 Aug 1993 06:21:50 GMT Message-ID: Originator: rwh@GOTTLOB.TIP.CS.CMU.EDU Sender: news@cs.cmu.edu (Usenet News System) Nntp-Posting-Host: gottlob.tip.cs.cmu.edu Organization: School of Computer Science, Carnegie Mellon University References: <1993Aug11.100431.71047@cc.usu.edu> <24gjmd$r8s@apakabar.cc.columbia.edu> <24n91u$d78@apakabar.cc.columbia.edu> Date: Mon, 16 Aug 1993 14:00:36 GMT Lines: 14 Rather than enter into a tired old -8 vs -11 debate, let me just remark that the core DEC Alpha architecture is _remarkably_ like the -8. Most -11'isms have been dropped entirely: back to fixed instruction length, skip instructions, "operate" instructions, and so forth. Some backward compatibility support is provided (mainly for VMS), but in the main the new architecture harkens back to the old, an implicit recognition of the failure of the -11/VAX lineage. -- Robert Harper From ivie@cc.usu.edu Mon Aug 16 13:59:03 EDT 1993 Article: 348 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.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: Re: Happy PDP-5 day Message-ID: <1993Aug16.091544.71248@cc.usu.edu> Date: 16 Aug 93 09:15:44 MDT References: <1993Aug11.100431.71047@cc.usu.edu> <24gjmd$r8s@apakabar.cc.columbia.edu> <24n91u$d78@apakabar.cc.columbia.edu> Organization: Utah State University Lines: 15 In article <24n91u$d78@apakabar.cc.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > No, the KT8A was planned and built anyway. There was to be a Fortran compiler > written that would generate MACREL code that would load into it so that a > system akin to the VAX stand-alone system (forget its name) could be built > on the -8. The compiler was canned, but MACREL was finished for no pay by > Stan Rabinowitz. VAXeln. On the subject of interrupt schemes, have you seen how Alpha does interrupts? Processor jumps to a fixed location with mapping disabled and software gets to sort it out. The PDP-8 interrupt scheme ain't dead yet... Roger Ivie ivie@cc.usu.edu From lasner@watsun.cc.columbia.edu Mon Aug 16 14:13:25 EDT 1993 Article: 349 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 16 Aug 1993 18:12:56 GMT Organization: Columbia University Lines: 37 Message-ID: <24oin8$d22@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24n91u$d78@apakabar.cc.columbia.edu> <1993Aug16.091544.71248@cc.usu.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <1993Aug16.091544.71248@cc.usu.edu> ivie@cc.usu.edu writes: > >On the subject of interrupt schemes, have you seen how Alpha does interrupts? >Processor jumps to a fixed location with mapping disabled and software gets to >sort it out. The PDP-8 interrupt scheme ain't dead yet... JB was trying to point out that the -11-style interrupt can be superior, and I countered with the existence of the KF-12B API hardware, and the tentative Omnibus version that was canned, etc. Sometimes, depending on the CPU instruction set, the extra complexity of the hardware can be counter-productive thus a simpler structure allows software to tailor the interrupt service to what's required, whereas a complicated one could actually be more overhead. I once wrote -8 code where the interrupt priority was not according to the norms. In essence, the priority is to not lose any interrupts, as opposed to the notion that any of them had priority over another unconditionally. To accomplish this merely required an interrupt stack and reorganizing the traditional interrupt structure so that essentially every foreground operation was operating "in the background" meaning the source of interrupt had already been dismissed, but the code is still grinding out the consequences in a way equivalent (in priority) to background processing. When it's actually completed that code, it is officially dismissed and true background processing is restored, but during that portion of the code, interrupts from other sources are allowed. This minimizes interrupt latency, but does not get described by conventional API means, etc. I guess the Alpha people wanted to allow software to tailor its own structure in a like manner. Incidentally, the 6121 support chips for the 6120 support vectored interrupts where you issue one IOT and you wind up in the appropriate interrupt handler without polling. To do what I had to do on the -8 were this the hardware present, I seriously think the latency would have been longer and the code more complicated, not less so. The KF12B API most definitely would have been worse. (I opted not to use it.) cjl From root@foobar.hanse.de Mon Aug 16 20:03:03 EDT 1993 Article: 350 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!math.fu-berlin.de!news.rrz.uni-hamburg.de!lutzifer!wolfhh!foobar!root From: root@foobar.hanse.de (Jens Stark) Subject: Re: Happy PDP-5 day References: <1993Aug11.100431.71047@cc.usu.edu> Organization: Just another Linux site! Date: Mon, 16 Aug 1993 10:10:11 GMT Message-ID: <1993Aug16.101011.2261@foobar.hanse.de> Lines: 34 Xref: news.columbia.edu alt.sys.pdp8:350 alt.folklore.computers:49682 ivie@cc.usu.edu writes: >According to a magazine that I once encountered in the bowels of the university >library, the PDP-5 was unveiled August 11, 1963 at WESCON. >Here's to 30 years of small computers! >Roger Ivie >ivie@cc.usu.edu >PS: For you MS-DOS guys, here's the lineage of MS-DOS as near as I can >figure it. Please feel free to correct me if I'm wrong: > LINC > / \ > PDP-4 PDP-5 > | | > Unix PDP-7 PDP-8 OS/8 > \ / > Unix PDP-11 RT-11 > / \ > | 8080 CP/M > | | > | 8086 MS-DOS 1.x > \ / > 8086 MS-DOS 2.x and up Hmm - there must be some missing link. The first time I booted MS-DOS, I looked for PIP. DOS claimed not to know what PIP was supposed to be. A program loader without PIP ? I could not imagine that DOS could be successful at all. Jens From bqt@Oslo.docs.uu.se Mon Aug 16 20:26:22 EDT 1993 Article: 351 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Oslo.docs.uu.se!bqt From: bqt@Oslo.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 17 Aug 93 00:01:36 GMT Organization: Uppsala University Lines: 32 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug12.091041.71099@cc.usu.edu> <24dvuk$8k5@apakabar.cc.columbia.edu> <24gh9v$pqq@apakabar.cc.columbia.edu> NNTP-Posting-Host: oslo.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:351 alt.folklore.computers:49697 In hshubs@cis.umassd.edu (Howard S Shubs) writes: >In bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >>In hshubs@cis.umassd.edu (Howard S Shubs) writes: >>>That's true of any computer. Machines are purchased for a reason. OTOH, >>>people who -get them for free- might like them for themselves. >>Yes, but buying machines for a purpose isn't neccesarily the same thing >>as buying a machine for the applications. Sometimes you buy machines >>for doing stuff for which there are no prepackaged applications. >>You still buy the computer for a purpose, but the architecture becomes >>the deciding point. >Then the deciding point becomes price and availability. Look at the >80n86 series. Certainly it's not popular due to its architecture. No, in that specific case it *is* a question of the applications available. But just because it is so in that case, does not mean that it is so in every case, just as the opposite doesn't apply all the time. However, there is always a purpose. Did it enter your mind that different types of customers have different purposes? (Sorry if I'm sounding a bit irritated, but I think the above comment was a little too much a reaction from the backbone, with no thinking involved) -- 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 bqt@Oslo.docs.uu.se Mon Aug 16 20:29:10 EDT 1993 Article: 352 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Oslo.docs.uu.se!bqt From: bqt@Oslo.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 17 Aug 93 00:06:49 GMT Organization: Uppsala University Lines: 72 Message-ID: References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g$bcc@apakabar.cc.columbia.edu> NNTP-Posting-Host: oslo.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:352 alt.folklore.computers:49699 In <24n54g$bcc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >In article bqt@Sofia.docs.uu.se (Johnny Billquist) writes: >>No, you are missing my point. >>In the beginning of the seventies, the typical DEC customer was something >>completely different than today. At that time, it was technical people >>who sold and bought DEC stuff. Marketdroids hadn't been exported from >>IBM yet. (Especially not to DEC). >I suggest your locale was isolated from the mainstream. I was already >seeing what you refer to go away as early as 1972. By 1975 there wasn't >much of a following for many DEC machines from a techical standpoint in >many areas. And of course by 1980 it was non-existent. Well, can't say I got that much firsthand experience from it as you have, so I won't try to argue on that one. But also, your view is more extreme than mine. >>The original purchasers of DEC equipment in the beginning of the pdp11 >>was people who wrote assembly language on it. >Yes, at the *very* beginning, since there wasn't yet anything else. But later >that changed radically. Yes, we are mostly arguing about what is meant by "later". When we are talking RT11 and RSX, MACRO-11 is still the language of choice for many things to do. >>You are trying to put them into todays suites. That was not the case. >No, today it's just worse, not different. I think we also agree on that one. However, at the time I'm tlaking about, my view is that the problem was small enough to not be a problem at the time. It has grown immensly since then. >>And I still stand by my claim that the pdp8 couldn't grow nicely that >>much more than it did. The pdp11 could, at that time. >Irrelevant. My point is that a 32K -8/e with an "RT-8" system on it would >be powerful enough to be the system of choice of a goodly number of people >who used RT-11 in the "superficial" way we have been discussing. If such a >system existed, it could be 512K by 1985 using the CESI memory, and certainly >would have been 128K with the KT8A. By 1985, The pdp-11 had already become to small, and we were talking big VAXen with several megs of memory. 512K is nothing compared to that, and still much less than the 4Mbyte of the pdp11, which was realized already in 1975. And it is not irrelevant in the long run, only in the short run, and I think I have said it enough times, that in she short view, DEC could have pushed more for the pdp8, at the expense of the pdp11, instead of the other way around, but they probably would have lost on it in the longer run. And by loosing I mean that overall sales would have mounted to less. >>As for RT-32, yes, many people wanted other stuff on the VAX, than >>was eventually came out. TOPS-32 is another story, as is RSX-32, and >>*no*, VMS is not the same as RSX-11M(-PLUS). >Sorry, VMS 1.0 *IS* RSX. No. It is not. Perhaps IAS, but definitely not RSX-11M. Apart from the obious difference that they had a new file structure, there are some stuff in VMS, that is clearly not in RSX-11M, but which is in IAS, wuch as priorities in I/O requests. Much stuff differ, and some stuff works different ways, and always have. They do have the same ancestor, though, since RSX-11M also comes from IAS in a way. -- 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 jebright@magnus.acs.ohio-state.edu Tue Aug 17 01:59:46 EDT 1993 Article: 353 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!jebright From: jebright@magnus.acs.ohio-state.edu (James R Ebright) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 17 Aug 1993 05:43:38 GMT Organization: The Ohio State University Lines: 25 Message-ID: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> References: <24n54g$bcc@apakabar.cc.columbia.edu> NNTP-Posting-Host: bottom.magnus.acs.ohio-state.edu Xref: news.columbia.edu alt.sys.pdp8:353 alt.folklore.computers:49713 In article bqt@Oslo.docs.uu.se (Johnny Billquist) writes: >In <24n54g$bcc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>Sorry, VMS 1.0 *IS* RSX. > >No. It is not. Perhaps IAS, but definitely not RSX-11M. Oh, come on. VMS V1.0 was so much like 11-M I used 11-M handbooks. It wasn't at all like RSTS (V6C was current when the VAX-11/780 was introduced and it didn't look a bit like VMS). >Apart from the obious difference that they had a new file structure, there >are some stuff in VMS, that is clearly not in RSX-11M, but which is >in IAS, wuch as priorities in I/O requests. Much stuff differ, and >some stuff works different ways, and always have. They do have the same >ancestor, though, since RSX-11M also comes from IAS in a way. BTW, IAS is RSX-11D with a few diferences... 11M was a lot different from 11D but IAS was not. -- Information farming at... For addr&phone: finger A/~~\A THE Ohio State University jebright@magnus.acs.ohio-state.edu ((0 0))____ Jim Ebright e-mail: jre+@osu.edu \ / \ Support Privacy: Support Encryption (--)\ From Geoff@equinox.gen.nz Tue Aug 17 14:28:34 EDT 1993 Article: 354 of alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!wupost!waikato!comp.vuw.ac.nz!canterbury.ac.nz!equinox.gen.nz!equinox!Geoff From: Geoff@equinox.gen.nz (Geoff Mccaughan) Subject: Re: Happy PDP-5 day Newsgroups: alt.sys.pdp8,alt.folklore.computers Followup-To: alt.sys.pdp8,alt.folklore.computers References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g X-Newsreader: TIN [version 1.2 PL1] Message-ID: Date: 17 Aug 93 21:57:10 +1200 Organization: Equinox Networks Lines: 15 Xref: news.columbia.edu alt.sys.pdp8:354 alt.folklore.computers:49726 Johnny Billquist (bqt@Oslo.docs.uu.se) wrote: >In <24n54g$bcc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >> [...] >But also, your view is more extreme than mine. Cjl's view is more extreme than *everyone's* -- Geoff, Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 [6 Lines] "If you have to run heating in winter, you don't own enough computers." Vote SPQR Ski Nix Olympica Freedom for Axolotls From minow@apple.com Tue Aug 17 15:00:06 EDT 1993 Article: 355 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!rpi!uwm.edu!spool.mu.edu!olivea!apple.com!goofy.apple.com!mumbo.apple.com!gallant.apple.com!minow.apple.com!user From: minow@apple.com (Martin Minow) Subject: Re: Happy PDP-5 day Sender: news@gallant.apple.com Message-ID: Date: Tue, 17 Aug 1993 15:02:05 GMT References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g Organization: Macintosh Developer Services Followup-To: alt.sys.pdp8,alt.folklore.computers Lines: 46 Xref: news.columbia.edu alt.sys.pdp8:355 alt.folklore.computers:49742 If I may be so bold as to interrupt... RT11 was done by many of the same people who had worked on OS/8. It used some of the OS/8 ideas, but wasn't very similar inside. Its primary goals were to provide a usable operating system with very small memory/processor requirements. RT11 V1 ran comfortably in 4 K-words, as I recall, and could compile large Fortran programs in an 8 K-word machine. It was a wonderful advance from the other PDP-11 operating system of that era, DOS (of which the less said the better). CP/M used many design ideas from RT11, but these would have been apparent to anyone who read the manuals. At the introduction of Vax/VMS, the PDP-11 family supported a number of semi-compatible operating systems: -- RT11 for low-end single-user machines. -- RSTS/E for timesharing (educational and commercial) -- RSX-11M and RSX-11D for real-time process control -- IAS (a high-end RSX-11D) -- Mumps (a task-specific database system) -- various task-specific executives (RSX-11A, for example). Eventually, RSX-11M absorbed RSX-11D and all of the systems presented a common command language (each with minor quirks). Also, RSTS/E could run most non-real-time programs developed for RT11 and RSX-11M. A rough o.s. lineage for the PDP-11 would be as follows: pre-1972: Paper-tape (IOX) DOS-11 RSTS-11 post-1972 (introduction of the 11/45) RT-11 DOS-11 -> DOS-Batch (dead end) RSTS-11 V4 -> RSTS/E RSX11D -> IAS RSX11A -> RSX-11M Mumps post-1978 (introduction of Vax) RSX-11M -> VMS RSX11D, IAS merged with RSX-11M Martin Minow minow@apple.com From asporner@fndp2.fnal.gov Tue Aug 17 15:00:24 EDT 1993 Article: 356 of alt.sys.pdp8 Path: news.columbia.edu!rpi!ees1a0.engr.ccny.cuny.edu!fnnews.fnal.gov!fndp2.fnal.gov!asporner From: asporner@fndp2.fnal.gov () Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 17 Aug 1993 16:08:07 GMT Organization: Fermi National Accelerator Laboratory, Batavia IL Lines: 26 Distribution: world Message-ID: <24qvp7$9dr@fnnews.fnal.gov> References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g NNTP-Posting-Host: fndp2.fnal.gov Xref: news.columbia.edu alt.sys.pdp8:356 alt.folklore.computers:49746 Martin Minow writes !A rough o.s. lineage for the PDP-11 would be as follows: ! !pre-1972: Paper-tape (IOX) ! DOS-11 ! RSTS-11 !post-1972 (introduction of the 11/45) ! RT-11 ! DOS-11 -> DOS-Batch (dead end) ! RSTS-11 V4 -> RSTS/E ! RSX11D -> IAS ! RSX11A -> RSX-11M ! Mumps !post-1978 (introduction of Vax) ! RSX-11M -> VMS ! RSX11D, IAS merged with RSX-11M ! What about UNIX!? :-) I actually am curious about DOS-11. The only hear about it in obscure places in RSTS/E manuals. Did the file format carry over from DOS to RSTS tapes? Disk files? Andy From lasner@watsun.cc.columbia.edu Tue Aug 17 15:15:01 EDT 1993 Article: 357 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 17 Aug 1993 18:28:11 GMT Organization: Columbia University Lines: 31 Message-ID: <24r7vr$37g@apakabar.cc.columbia.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <24n54g NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:357 alt.folklore.computers:49758 In article Geoff@equinox.gen.nz (Geoff Mccaughan) writes: >Cjl's view is more extreme than *everyone's* Well, remember who I am: I am the author of the only O/S that wasn't an official DEC system for the -8. The fact that it was offered to them and turned down has little to do with it. (Note: the reason was that since it *could* be made to run in only 4K that it "might lower memory sales" :-(.) I am part of a group that predates the PDP-11. I was using TOPS-10 before there was a PDP-11. I was using TOPS-10 sometimes to develop PDP-8 software on PAL-10 using TECO as far back as 1968. This group largely consists of the people who became the core portion of the PDP-8 software development group, and partially the -11 equivalent. Most of the members of this group believe the -11 was a lame machine, which repeated some of IBM's mainframe mistakes (byte addressing) and was influenced by the later ACM articles, and also a few master's theses, which quantified what members of the group were aware of from experience. Additionally, posts with my signature on them sometimes represents the opinions of others without usenet access. Usenet access is sometimes not as available as one might think, etc. So, if it seems intense, it ought to be! Divide the intensity by N, where N=2,3,4 or so, and see if then it is more reasonable :-). (BTW, if you think *i'm* intense, you should here some of the others who are just not net.people!) cjl From minow@apple.com Tue Aug 17 19:27:14 EDT 1993 Article: 358 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!torn!news2.uunet.ca!apple.com!goofy.apple.com!mumbo.apple.com!gallant.apple.com!minow.apple.com!user From: minow@apple.com (Martin Minow) Subject: Re: Happy PDP-5 day Sender: news@gallant.apple.com Message-ID: Date: Tue, 17 Aug 1993 21:41:45 GMT References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g <24qvp7$9dr@fnnews.fnal.gov> Organization: Macintosh Developer Services Followup-To: alt.sys.pdp8,alt.folklore.computers Lines: 45 In article <24qvp7$9dr@fnnews.fnal.gov>, asporner@fndp2.fnal.gov () wrote about my PDP-11 OS lineage: > > What about UNIX!? :-) > Sorry, I was thinking about "developed at Dec" operating systems. > I actually am curious about DOS-11. The only hear about it in obscure > places in RSTS/E manuals. Did the file format carry over from DOS to > RSTS tapes? Disk files? DOS-11 (later Dos-Batch) was used to deliver RSTS/E to customers in the V4/V5 timeframe. RSTS/E was compiled on-site to configure it for the customer's particular hardware. After the disk image was built, DOS-11 was never seen again. Somewhere around the, umm, V6A of B timeframe, RSTS/E became able to build itself without a separate support operating system. The tape format (extended to comply with the ANSI tape minimum record length) carried over to RSTS and other PDP-11 O.S. The disk format, fortunately, did not. On a memory-limited mini, one of the most difficult problems for the O.S. designer lies in organizing the on-disk file system. At the time Dos-11 was being developed, RF disks amd DECtapes had 512 Kbytes, with 2.5 and 5 Mbyte RK-series in the future. RT-11 ignored the problem: you created a file at its maximum size and truncated it to the actual size when the file was closed. Then, you periodically defragmented the disk to regain contiguous space. RSTS and RSX allocated disk areas in chunks (RSTS clusters) and used a pointer records (MFD/UFD) to locate the pieces of a disk file (Unix uses a similar arrangement). (I'm using the RSTS terminology as I never got as familar with the Files-11 disk format internals.) DOS-11 could either allocate a fixed-size contiguous disk area (fast and efficient), or a sequential stream area. The latter stored data in 510 bytes in a sector, and used the other two bytes to point to the next sector. The disadvantage here is that, to delete a file, you had to read the entire file one sector at a time. This made Fortran compilations extremely slow. Martin Minow minow@apple.com ps: apologies to the alt.sys.pdp8 people -- my newsreader apparently doesn't let me redirect the followup. From bqt@Minsk.docs.uu.se Wed Aug 18 09:24:03 EDT 1993 Article: 359 of alt.sys.pdp8 Path: news.columbia.edu!rpi!uwm.edu!cs.utexas.edu!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 93 10:16:38 GMT Organization: Uppsala University Lines: 19 Message-ID: References: <24n54g$bcc@apakabar.cc.columbia.edu> <24pr6a$cog@charm.magnus.acs.ohio-state.edu> NNTP-Posting-Host: minsk.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:359 alt.folklore.computers:49810 In <24pr6a$cog@charm.magnus.acs.ohio-state.edu> jebright@magnus.acs.ohio-state.edu (James R Ebright) writes: >In article bqt@Oslo.docs.uu.se (Johnny Billquist) writes: >>In <24n54g$bcc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>>Sorry, VMS 1.0 *IS* RSX. >> >>No. It is not. Perhaps IAS, but definitely not RSX-11M. >Oh, come on. VMS V1.0 was so much like 11-M I used 11-M handbooks. >It wasn't at all like RSTS (V6C was current when the VAX-11/780 was >introduced and it didn't look a bit like VMS). Well, you could use 11-M handbooks for IAS and survive too. That don't make them the same. -- 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 lasner@watsun.cc.columbia.edu Wed Aug 18 09:31:32 EDT 1993 Article: 360 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 1993 13:30:07 GMT Organization: Columbia University Lines: 34 Message-ID: <24tasv$cb6@apakabar.cc.columbia.edu> References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:360 alt.folklore.computers:49823 In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: > >In <24pr6a$cog@charm.magnus.acs.ohio-state.edu> jebright@magnus.acs.ohio-state.edu (James R Ebright) writes: > >>In article bqt@Oslo.docs.uu.se (Johnny Billquist) writes: >>>In <24n54g$bcc@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >>>>Sorry, VMS 1.0 *IS* RSX. >>> >>>No. It is not. Perhaps IAS, but definitely not RSX-11M. > >>Oh, come on. VMS V1.0 was so much like 11-M I used 11-M handbooks. >>It wasn't at all like RSTS (V6C was current when the VAX-11/780 was >>introduced and it didn't look a bit like VMS). > >Well, you could use 11-M handbooks for IAS and survive too. >That don't make them the same. You are using guesswork; I am using fact. VMS 1.0 was a quick and dirty hack on RSX. I used it on an in-house machine. It never really was a product sold. This was at the dawn of the VAX era. Other than the I/O which was native mode code, literally all of that early version was RSX as various people loved/hated it. Over the years, all of the code was removed/revamped. They barely made it through by the time VAXen came out without the -11 emulator present. In fact, TECO was deleted because there was no budget to convert it over. (It got done anyway, but later.) The -11 emulator was incomplete, but did all you needed other than the I/O module, etc. VMS 1.0 looked little like what it eventually turned into. Don't use any more recent usage experience as a guide towards how it happened. I was there at the beginning. cjl From jebright@magnus.acs.ohio-state.edu Wed Aug 18 15:16:45 EDT 1993 Article: 361 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!jebright From: jebright@magnus.acs.ohio-state.edu (James R Ebright) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 1993 13:40:32 GMT Organization: The Ohio State University Lines: 26 Message-ID: <24tbgg$ett@charm.magnus.acs.ohio-state.edu> References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> NNTP-Posting-Host: bottom.magnus.acs.ohio-state.edu Xref: news.columbia.edu alt.sys.pdp8:361 alt.folklore.computers:49824 In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >In <24pr6a$cog@charm.magnus.acs.ohio-state.edu> jebright@magnus.acs.ohio-state.edu (James R Ebright) writes: > >>Oh, come on. VMS V1.0 was so much like 11-M I used 11-M handbooks. >>It wasn't at all like RSTS (V6C was current when the VAX-11/780 was >>introduced and it didn't look a bit like VMS). > >Well, you could use 11-M handbooks for IAS and survive too. >That don't make them the same. True... but, for example, the Fortran compiler was actually RSX-11M's running under the PDP-11 emulation mode. The emulation mode was where they got their 'layered products' -- a term not in use at that time -- and they were all RSX-11M products. There was a good reason for this. Dave Cutler, the architect/developer of RSX-11M was one of the five people(!) who wrote VAX/VMS 1.0 Dave is now honchoing NT for Microsoft... Good career move as nothing is doing at DEC anymore :( except for Supnik's group. -- Information farming at... For addr&phone: finger A/~~\A THE Ohio State University jebright@magnus.acs.ohio-state.edu ((0 0))____ Jim Ebright e-mail: jre+@osu.edu \ / \ Support Privacy: Support Encryption (--)\ From bqt@Minsk.docs.uu.se Wed Aug 18 15:19:21 EDT 1993 Article: 362 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 93 14:57:47 GMT Organization: Uppsala University Lines: 16 Message-ID: References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> <24tasv$cb6@apakabar.cc.columbia.edu> NNTP-Posting-Host: minsk.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:362 alt.folklore.computers:49829 In <24tasv$cb6@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >You are using guesswork; I am using fact. VMS 1.0 was a quick and dirty hack >on RSX. I used it on an in-house machine. It never really was a product >sold. This was at the dawn of the VAX era. Other than the I/O which was >native mode code, literally all of that early version was RSX as various >people loved/hated it. But the I/O is one of the things that really differs between RSX-11M and VMS! RSX don't care about priorities on I/O requests, IAS does, and so do VMS! -- 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 bqt@Minsk.docs.uu.se Wed Aug 18 15:19:55 EDT 1993 Article: 363 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 93 15:01:08 GMT Organization: Uppsala University Lines: 38 Message-ID: References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> <24tbgg$ett@charm.magnus.acs.ohio-state.edu> NNTP-Posting-Host: minsk.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:363 alt.folklore.computers:49830 In <24tbgg$ett@charm.magnus.acs.ohio-state.edu> jebright@magnus.acs.ohio-state.edu (James R Ebright) writes: >In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >>Well, you could use 11-M handbooks for IAS and survive too. >>That don't make them the same. >True... but, for example, the Fortran compiler was actually RSX-11M's >running under the PDP-11 emulation mode. The emulation mode was where >they got their 'layered products' -- a term not in use at that time -- >and they were all RSX-11M products. The same compiler is also used in IAS. The reason it's called RSX-11M's is because that had the largest installed base of customers. RSX-11M products and IAS products are very often the same. Not that many differs. The same programs can run, but the OS in the bottom differs. However, I'll concede as much as that VMS is a hybrid. >There was a good reason for this. Dave Cutler, the architect/developer >of RSX-11M was one of the five people(!) who wrote VAX/VMS 1.0 I know. >Dave is now honchoing NT for Microsoft... Good career move as nothing is >doing at DEC anymore :( except for Supnik's group. Don't kow if I agree with it being a good move. I think that anything that MS gets involved in, eventually will be a joke, no matter who the individuals involved are. As for what DEC's doing now, don't ask me. -- 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 jones@pyrite Wed Aug 18 15:20:40 EDT 1993 Article: 364 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Repost: Junk Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug18.151901.2473@news.uiowa.edu> Date: Wed, 18 Aug 1993 15:19:01 GMT Distribution: na References: <24lf7kINNiba@rave.larc.nasa.gov> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 14 This is a repost! Do not reply to me! >From article <24lf7kINNiba@rave.larc.nasa.gov>, by kludge@grissom.larc.nasa.gov (Scott Dorsey): > I'm cleaning out the garage, and I have a couple of ... > DECMATE II processor boards, and possibly some other junk. I'm not going > to ship it, so you'll have to pick it up in Williamsburg, VA, but if > you're in the neighborhood, give me a ping. Someone who's into DECmate stuff should snag this stuff before it's lost to the world! Doug Jones jones@cs.uiowa.edu From yankus@ITD.Sterling.COM Wed Aug 18 15:21:26 EDT 1993 Article: 365 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!sparky!yankus From: yankus@ITD.Sterling.COM (Mike Yankus) Subject: Re: Happy PDP-5 day Message-ID: <1993Aug18.155601.28710@sparky.sterling.com> Sender: news@sparky.sterling.com (News Admin) Organization: Sterling Software References: Date: Wed, 18 Aug 1993 15:56:01 GMT Lines: 31 X-Md4-Signature: 0d1e02951cd5a97baae4d79ed767d07a Xref: news.columbia.edu alt.sys.pdp8:365 alt.folklore.computers:49835 In article minow@apple.com (Martin Minow) writes: > RSTS-11 V4 -> RSTS/E > RSX11D -> IAS > RSX11A -> RSX-11M > Mumps >post-1978 (introduction of Vax) > RSX-11M -> VMS > RSX11D, IAS merged with RSX-11M > IAS is a direct descendant of RSX-11D. IAS release 3.0 merged RSX-11D and IAS 2.0 into a single product. (I am a previous user of RSX-11D, going back to release 4, and currently use IAS 3.5.) I think you will find that RSX-11M was built directly from RSX-11D. As I vaguely recall, the original RSX-11M was advertised as "a proper subset of RSX-11D." After RSX-11M became more widely used than IAS or RSX-11D, due to lower license cost, DEC was adding new features to RSX-11M/RSX-11M+ faster than to IAS. Memory management directives come to mind. Thus the appearance that there was some "merging." Currently, IAS and RSX share the same source code for the file system and many utilities. In this respect, they are more alike than different (PIP is PIP!). >From a user perspective, the big difference is support of DCL. RSX-11D never had it. The earlier IAS releases had nothing but. Current IAS (since 3.0) supports either DCL or MCR command language interpreters (CLIs). -- Mike Yankus UUCP: uunet!sparky!yankus PRC Inc. INTERNET: yankus@sparky.ITD.Sterling.COM 1410 Wall St. Phone: (402) 291-8300 Bellevue, NE. 68005-3687 FAX: (402) 291-4362 From jones@pyrite Wed Aug 18 15:22:45 EDT 1993 Article: 366 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: New? PDP-8/L Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug18.181224.6595@news.uiowa.edu> Date: Wed, 18 Aug 1993 18:12:24 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 30 I'm tired of all this crossposting of PDP-11 nitpicking from Alt Folklore Computers, so I thought I'd inject something more germane: I now have a good start at a complete PDP-8/L with 8K and dual TU55 DECtape drives! The system is in pieces, and cabling it together will be a challenge, but I think I have most of the pieces! I've gotten my hands on copies of the TU55 and TC01 documentation, and the junk pile I got from the U of Chicago also had the necessary posibus to negibus converter. I've got the PDP-8/L handbook (falling apart, but perhaps I'll do the same to it as I did to the 1973 Intro to Programming -- that is, photocopy and archival binding). I don't have any PDP-8/L maintenance documentation, and the machine is missing a very important piece -- the console TTY interface! I also have no documentation for how to attach the expander box for the second 4K. The expander box came from the U of Chicago junk pile, while the CPU came from the Iowa State U junk pile. I have a minor nit to fix before I try front-panel debugging of the CPU, the fuse holder is smashed. Also, some of the switch handles are broken off, but I have the handles, and they're easy to drill out and fix with a bit of brass wire. So, does anyone have CPU maintenance documents for the machine? I'll gladly trade something for them, for example, I'll trade a bound reprint of the 1973 Intro to Programming. If you press me, I can also start work on a reprint of the PDP-8/L user's guide, or I can copy any classic -8 CPU documentation you want. Doug Jones jones@cs.uiowa.edu From lasner@watsun.cc.columbia.edu Wed Aug 18 15:23:54 EDT 1993 Article: 367 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 18 Aug 1993 19:19:10 GMT Organization: Columbia University Lines: 12 Message-ID: <24tvbe$ou4@apakabar.cc.columbia.edu> References: <24tasv$cb6@apakabar.cc.columbia.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:367 alt.folklore.computers:49852 In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >But the I/O is one of the things that really differs between RSX-11M and VMS! >RSX don't care about priorities on I/O requests, IAS does, and so do VMS! No, not on *that* VMS! This is V 1.0 we're talking about! All you know about VMS was to come later as a 100% rewrite, and in some cases, even more than that as it was changed several times! I mean the literal input and output disk and terminal operations level and no more are native VAX code at that early point. cjl From root@foobar.hanse.de Wed Aug 18 18:34:46 EDT 1993 Article: 368 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!math.fu-berlin.de!news.rrz.uni-hamburg.de!lutzifer!wolfhh!foobar!root From: root@foobar.hanse.de (Jens Stark) Subject: Re: Happy PDP-5 day References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g Organization: Just another Linux site! Date: Wed, 18 Aug 1993 13:32:33 GMT Message-ID: <1993Aug18.133233.4684@foobar.hanse.de> Lines: 25 Xref: news.columbia.edu alt.sys.pdp8:368 alt.folklore.computers:49856 minow@apple.com (Martin Minow) writes: >A rough o.s. lineage for the PDP-11 would be as follows: >pre-1972: Paper-tape (IOX) > DOS-11 > RSTS-11 >post-1972 (introduction of the 11/45) > RT-11 > DOS-11 -> DOS-Batch (dead end) > RSTS-11 V4 -> RSTS/E > RSX11D -> IAS > RSX11A -> RSX-11M > Mumps >post-1978 (introduction of Vax) > RSX-11M -> VMS > RSX11D, IAS merged with RSX-11M > What about the PDP-15 ? I remember that I used a mag tape ( oops. dectape ) based operating system once, which even swapped to tape. Can anybody confirm that and give more info on that thing ? Greetings, Jens From forsyth@decus.com.au Wed Aug 18 23:25:11 EDT 1993 Article: 369 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!decus!forsyth Newsgroups: decus.pdp11,decus.rt11,alt.sys.pdp8,comp.sys.dec Subject: 128kb drawers - bits need a good home... Message-ID: <1993Aug18.184217.14635@decus.com.au> From: forsyth@decus.com.au Date: 18 Aug 93 18:42:17 AEST Organization: DECUS, South Pacific Chapter Lines: 14 Xref: news.columbia.edu alt.sys.pdp8:369 comp.sys.dec:16090 I have two dual RX01 units which I am pulling apart to turn into drawers. Yes Drawers; the DECdatasystem desk I use as a desk has an LSI11 inside it and four Rx01 drives where I need to store my papers. If anyone wants any bits please let me know "real soon". Already, one of the RXV11 controllers has gone and one part of the Q-Bus backplane (it had three 4-slots backplanes) but four functional drives, two floppy controllers etc still to be saved from oblivion..... Graham Forsyth Ph +61 3 5553186 (Business hours 6477558) or fax 6461565. Moorabbin Victoria Australia From dave%gilly@speedway.net Wed Aug 18 23:25:51 EDT 1993 Article: 370 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news!news.world.net!speedway.net!gilly!dave Message-ID: <93233211804.dave.182@gilly.UUCP> Date: Tue, 17 Aug 93 21:18:06 EDT Reply-To: dave%gilly@speedway.net Organization: Flat Earth Liberation Front Against Television From: dave@gilly.UUCP Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day References: Lines: 12 Xref: news.columbia.edu alt.sys.pdp8:370 alt.folklore.computers:49882 bqt@Oslo.docs.uu.se (Johnny Billquist) writes: >By 1985, The pdp-11 had already become to small, and we were talking >big VAXen with several megs of memory. 512K is nothing compared to that, >and still much less than the 4Mbyte of the pdp11, which was realized already >in 1975. PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no? ------------------------ uunet!quack!gilly!dave ------------------------ ================= Dave Fischer - Nature's Perfect Food ================= ----------------------- dave%gilly@speedway.net ------------------------ From jones@pyrite Thu Aug 19 16:42:15 EDT 1993 Article: 371 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: PDP-15 (Was: Happy PDP-5 day) Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug19.135240.5200@news.uiowa.edu> Date: Thu, 19 Aug 1993 13:52:40 GMT References: <1993Aug18.133233.4684@foobar.hanse.de> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 35 Xref: news.columbia.edu alt.sys.pdp8:371 alt.folklore.computers:49917 >From article <1993Aug18.133233.4684@foobar.hanse.de>, by root@foobar.hanse.de (Jens Stark): > > What about the PDP-15 ? I remember that I used a mag tape ( oops. dectape ) > based operating system once, which even swapped to tape. > Can anybody confirm that and give more info on that thing ? The PDP-15 was not related to the PDP-11, except in the sense that both used a UNIBUS to handle peripheral interfacing. Specifically, the PDP-11 was a 16 bit machine, and the PDP-15 was an 18 bit machine (ever wonder why the UNIBUS allowed for 18 bits -- it wasn't just to support the memory management unit on the 11/45!). Thep PDP-15 was upward compatable from the PDP-9, which was upward compatable from the PDP-7, which was upward compatable from the PDP-4, which hit the market in 1962. The PDP-1 was also an 18 bit machine, but I don't think it was compatable with this series. In any case, the PDP-7 and PDP-9 both supported DECtape, and DECtape based operating systems were originally developed on those machines, and they moved naturally to the PDP-15. I don't know the particulars of the PDP-15 operating system, but I suspect that, like other contemporaneous systems on computers sold for real-time process control, it allowed a single interactive user in the background while it ran real-time process control tasks in the foreground. The PDP-15 was the last of a pround lineage of 18 bit computers made by DEC, and that lineage included some machines used in very important real-time control applications. Among these, at least one PDP-4 seems to have lasted for years running the computer controlled wire-wrap machines that were used to wire the backplanes for the original PDP-8 and other late second generation machines built by DEC. Doug Jones jones@cs.uiowa.edu From scw@ollie.seas.ucla.edu Thu Aug 19 17:00:07 EDT 1993 Article: 372 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!ucla-cs!ucla-se!ollie.seas.ucla.edu!scw From: scw@ollie.seas.ucla.edu (Stephen C. Woods) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Message-ID: <11373@lee.SEAS.UCLA.EDU> Date: 19 Aug 93 16:10:38 GMT References: <24qvp7$9dr@fnnews.fnal.gov> Sender: news@SEAS.UCLA.EDU Followup-To: alt.sys.pdp8 Organization: School of Engineering and Applied Sciences, UCLA Lines: 31 Xref: news.columbia.edu alt.sys.pdp8:372 alt.folklore.computers:49932 #!pre-1972: Paper-tape (IOX) #! DOS-11 #! RSTS-11 #!post-1972 (introduction of the 11/45) #! RT-11 #! DOS-11 -> DOS-Batch (dead end) #! RSTS-11 V4 -> RSTS/E #! RSX11D -> IAS #! RSX11A -> RSX-11M #! Mumps #!post-1978 (introduction of Vax) #! RSX-11M -> VMS #! RSX11D, IAS merged with RSX-11M Causing much grief and discontent among IAS programmers. RSX-11M had the most Baroque tty driver it has ever been my misfortunate to have to deal with. >I actually am curious about DOS-11. The only hear about it in obscure >places in RSTS/E manuals. Did the file format carry over from DOS to >RSTS tapes? Disk files? Interestingly enough, Dec PDP-11 diagnostics ran/run on DOS-11 (a fate worse that death, I assure you). -- ----- Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (310)-825-8614 UUCP: ...{ibmsupt,ncar!cepu}!ollie}!scw Internet:scw@SEAS.UCLA.EDU From lasner@watsun.cc.columbia.edu Thu Aug 19 17:00:37 EDT 1993 Article: 373 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: PDP-15 (Was: Happy PDP-5 day) Date: 19 Aug 1993 20:59:36 GMT Organization: Columbia University Lines: 85 Message-ID: <250pjo$hon@apakabar.cc.columbia.edu> References: <1993Aug18.133233.4684@foobar.hanse.de> <1993Aug19.135240.5200@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:373 alt.folklore.computers:49949 In article <1993Aug19.135240.5200@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >From article <1993Aug18.133233.4684@foobar.hanse.de>, >by root@foobar.hanse.de (Jens Stark): >> >> What about the PDP-15 ? I remember that I used a mag tape ( oops. dectape ) >> based operating system once, which even swapped to tape. >> Can anybody confirm that and give more info on that thing ? > >The PDP-15 was not related to the PDP-11, except in the sense that both >used a UNIBUS to handle peripheral interfacing. Specifically, the PDP-11 >was a 16 bit machine, and the PDP-15 was an 18 bit machine (ever wonder >why the UNIBUS allowed for 18 bits -- it wasn't just to support the memory >management unit on the 11/45!). Yes, certain -15 memory options used UNIBUS memory. There never was any peripheral handling for the UNIBUS with one notable exception: the UNICHANNEL. This was an actual PDP-11/05 with a fudged UNIBUS device that was 18 bits wide in the -11. There is a small mod to the RK11-D that makes it an RK11-E which is 18-bits transfer and the data is slightly "crowded" compared to the normal data rate on the RK05 pack. It can't use regular 16-bit RK05 packs due to the different recording rate, but you can freely reformat the disk packs and then use them. I know someone who runs RT-11 on this machine with no problems. The data is available to the -15 as 18-bit data, and the -11 CPU only sees 16-bits of that in its shared window memory. The -11 is normally the slave, and runs a dedicated serving program called PYREX. The -15 makes I/O requests by poking into the shared memory into the bits the -11 can see changes in, and it then acts on them, accomplishing some I/O operation and then reporting it back by also poking into the same memory, etc. Thus, the -11 can cause DMA to happen into memory it can't (completely) access. This system also supports more conventional UNIBUS peripherals for the benefit of the -15 such as an RX01/02 or even a DZ-11. Thus, it is also a front-end for the -15 if need be. (For something like multi-user MUMPS or a third-party version thereof, etc., or even RSX-15, which predates RSX-11, and possibly unix.) All of the memory has to be 18-bits on the 18-bit UNIBUS, similar to and compatible with the UNIBUS memory which might be attached to the -15 itself, etc. >In any case, the PDP-7 and PDP-9 both supported DECtape, and DECtape based >operating systems were originally developed on those machines, and they >moved naturally to the PDP-15. I don't know the particulars of the PDP-15 >operating system, but I suspect that, like other contemporaneous systems >on computers sold for real-time process control, it allowed a single >interactive user in the background while it ran real-time process control >tasks in the foreground. Like the PDP-8, the -15 has the PDP-9 negative buss, and its own positive buss, so it has the TC02 and TC15 DECtape controllers (instead of TC01 and TC08 respectively). The guts of both are remarkably similar to their respective -8 counterparts, and are programmed as similarly, etc. The ADSS system is quite awful, and is in part *why* unix got written, since it about the most abominable thing ever run on DECtape. Knowledgeable users don't call it "ADSS" since it's proper abbreviation should come from its name: Advanced Software System - ASS, which is an appropriate name. Some marketroid saw this and added the unwarranted "D" in there to avoid that problem :-). This system gets extended to a disk version and is then known as DOS-15. The -15 version can be made to run as a PDP-9 subset or a PDP-15 to change the addressing mode to either have double-size pages (9) or index register activity (15). Most -15 systems were physically quite large, more like -10 systems. This was the lowest DEC machine where an entire machine room was considered acceptable, even though the machine could be only a 32K 18-bit cousin of the PDP-8, with mostly software much inferior to its 12-bit cousin. There exists a PDP-8 simulator that boots actual PDP-8 bootable DECtapes on a PDP-15 directly. Speed is about 10% of actual PDP-8, but the DECtape I/O is full-speed due to emulation as opposed to inst-x-inst simulation for the tape I/O. The simulator can run OS/8 and P?S/8 configured specifically for TC01/08 DECtape. It also supports the -15's console terminal as the device 03/04 console completely, as well as the reader/punch as a PDP-8 PC04/05 reader/punch completely. At a certain installation I knew, the users admitted that the PDP-8 simulator running PDP-8 software was the most effective use of the machine they had ever seen :-). We also used it to get line-printer listings. (Most -15's had magtapes and large line-printers, etc.) cjl From don@zl2tnm.gen.nz Fri Aug 20 08:51:22 EDT 1993 Article: 374 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!spool.mu.edu!wupost!waikato!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Message-ID: <7368231@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 20 Aug 93 08:32:26 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <93233211804.dave.182@gilly.UUCP> Distribution: world Organization: The Wolery Lines: 32 Xref: news.columbia.edu alt.sys.pdp8:374 alt.folklore.computers:49991 dave@gilly.UUCP writes: > PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no? Yes pdp11s went to (nearly) 4MB in the 11/70, /23, /24, /73, /83, /84, /53, /93 and /94 models (in roughly chronological order). 22 bits worth of addressability is an architectural limit, based on the layout of the page address registers. Putting more memory on a pdp11 would require either re-writing the OS routines associated with memory management or doing nasty hacks that left the OS thinking it had only 4MB available. The VAX 11/780 could go to (I think) 16MB, maybe more -- I can't remember how big the physical address paths were and what reason for the limit was (ie could third party boards take it up). It was certainly somewhat more than 2MB... Mind you, the /780 came out with memory sizes of 512k or less. OTOH, I was trying to track down a problem in my VSII while rebuilding the machine in two BA23s, and to attempt to isolate the problem, put a KA630 (processor board) into the slot where the bus extender would (and now does) go, and attempted to boot. The KA630 has 1MB of memory onboard -- VMS V5.3 took one look at the size of its available memory and refused to go any further. Last time I ran VMS in 1MB it was under V4.1 on a uVAX I. I did have VMS V5.1-1 going in 3MB on a uVAX I with a 30MB disk. They don't write OS code like they used to... -- Don Stokes, CSC Network Manager, Victoria University of Wellington, New Zealand Ph+64 4 495-5052 Fax+64 4 471-5386 Work:don@vuw.ac.nz Home:don@zl2tnm.gen.nz From danpop@cernapo.cern.ch Fri Aug 20 11:37:39 EDT 1993 Article: 376 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!mcsun!dxcern!l3apollo6!danpop From: danpop@cernapo.cern.ch (Dan Pop) Subject: Re: Happy PDP-5 day Message-ID: Sender: news@dxcern.cern.ch (USENET News System) Organization: CERN European Lab for Particle Physics References: <93233211804.dave.182@gilly.UUCP> <7368231@zl2tnm.gen.nz> Date: Fri, 20 Aug 1993 14:58:01 GMT Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:376 alt.folklore.computers:50012 In <7368231@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes: >dave@gilly.UUCP writes: >> PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no? > >Yes pdp11s went to (nearly) 4MB in the 11/70, /23, /24, /73, /83, /84, /53, >/93 and /94 models (in roughly chronological order). > I don't see the /44 in this list. Why? Dan -- Dan Pop Tel: +41.22.767.2335 Email: danpop@cernapo.cern.ch Mail: CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland From ivie@cc.usu.edu Sat Aug 21 03:37:24 EDT 1993 Article: 377 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: PDP-15 (Was: Happy PDP-5 day) Message-ID: <1993Aug20.153817.71413@cc.usu.edu> Date: 20 Aug 93 15:38:16 MDT References: <1993Aug18.133233.4684@foobar.hanse.de> <1993Aug19.135240.5200@news.uiowa.edu> Organization: Utah State University Lines: 13 Xref: news.columbia.edu alt.sys.pdp8:377 alt.folklore.computers:50038 In article <1993Aug19.135240.5200@news.uiowa.edu>, jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > > The PDP-15 was not related to the PDP-11, except in the sense that both > used a UNIBUS to handle peripheral interfacing. Specifically, the PDP-11 > was a 16 bit machine, and the PDP-15 was an 18 bit machine (ever wonder > why the UNIBUS allowed for 18 bits -- it wasn't just to support the memory > management unit on the 11/45!). Yes, but where did they get the data lines? Did they take over the parity signals? Roger Ivie ivie@cc.usu.edu From bqt@Minsk.docs.uu.se Sat Aug 21 13:22:39 EDT 1993 Article: 378 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 21 Aug 93 13:27:42 GMT Organization: Uppsala University Lines: 23 Message-ID: References: <93233211804.dave.182@gilly.UUCP> NNTP-Posting-Host: minsk.docs.uu.se Xref: news.columbia.edu alt.sys.pdp8:378 alt.folklore.computers:50063 In <93233211804.dave.182@gilly.UUCP> dave@gilly.UUCP writes: >bqt@Oslo.docs.uu.se (Johnny Billquist) writes: >>By 1985, The pdp-11 had already become to small, and we were talking >>big VAXen with several megs of memory. 512K is nothing compared to that, >>and still much less than the 4Mbyte of the pdp11, which was realized already >>in 1975. >PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no? Yes. The pdp-11/70 was (I think) the first 22-bit address pdp-11, and it came in 1975. At that time, to get all 4 megs, you needed an additional memory cabinet, and a total of 8 MK-11 boxes. Later, when the 256Kbyte memory cards came for the MJ-11 memory box, one memory box for the 11/70 could hold all 4 megs. Where did you get the idea that the 11/780 only went to 2 megs??? -- 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 lasner@watsun.cc.columbia.edu Fri Sep 3 16:54:05 EDT 1993 Article: 379 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: comp.sys.dec.micro,alt.sys.pdp8 Subject: Re: Rainbow & DECmate Followup-To: alt.sys.pdp8 Date: 20 Aug 1993 14:26:53 GMT Organization: Columbia University Lines: 146 Message-ID: <252mvd$n0d@apakabar.cc.columbia.edu> References: <1993Aug20.082314.26388@infodev.cam.ac.uk> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: samba.oit.unc.edu comp.sys.dec.micro:2055 alt.sys.pdp8:311 In article <1993Aug20.082314.26388@infodev.cam.ac.uk> nec10@cus.cam.ac.uk (N.E. Cole) writes: >I also have a chance to get a DECmate (no number after it), what is this? I have >the specs for a DECmate III+ but obviously I suspect it won't be quite as good as >that! Is it possible to fit a HD, upgrade memory etc..??? For more specific info, post to alt.sys.pdp8. Other than for a few specific options, DECmates are not upgradable in the sense that you usually reference: DECmate {no designator} means what is now referred in retrospect as DECmate I. The system is 32K, and is the 6120 micro implementation of the venerable PDP-8 where 32K is the normal limit for all of the usual software. Just enough of the alternate control memory of 32K is also implemented to handle the peripherals, but only to the extent of implementing overall control/status, and booting options, and a built-in terminal emulator only if the comm board is present. Thus, the only options are whether there are one or two pairs of RX01/02 (I don't think it was sold with less than RX02, but it can take RX01 or a pair of 01 and a pair of 02 or two pairs 02), the DP278{A or B, where B supports bit-stuffing protocols and is an upgrade later for A} dual comm board, and the RL-278 disk controller for 1-4 RL02's which of course puts this VT-100-like box next to a very large cabinet or two. A printer port is built-in DECmate II is by far the most flexible of the family, and consists of a repackaged machine which is the same overall case as the PRO-325 and Rainbow. Internally an RX50 is an option technically, but is always present. Options include an additional pair of RX50, the RX78 external RX01/02 board {which can control one or two pairs of mixed RX01 or RX02 drives, neither of which can be booted to directly, and are programmed in a slightly incompatible manner to all previous designs which were totally compatible with each other!}, a graphics board, possibly with the VR-241 DEC color monitor {yes, a second monitor; there is no official one-color-monitor version, but the graphics can be directed at the non-optional VR-201 mono monitor}, and a HD controller which can connect one MFM hard disk. {Note that the hard disk controller precludes the RX78 option entirely, and usually the hard disk itself is mounted within the case which precludes the second floppy pair. While in theory you could cable up an external hard disk, thus allowing a second RX50 pair at the same time, some of the software cannot be configured to support the second RX50 pair and HD at the same time.} The HD size can be up to a formatted 64 MB since all DEC HD controllers of this vintage reserve dedicated alternate sectors at the beginning of the disk (which is required to be error-free in that area) and each track has 16 sectors of 512 bytes, a maximum of 8 (not 16!) heads. There is some debate over whether disks beyond 1024 cylinders are supported, but in any case they are rare in the industry anyway. (For example, I use an ST-4096 which is 1024 cylinders, but actually has 9 heads, one of which is wasted, but the 1024 cylinders are otherwise totally used.) There was a case upgrade for all of these machines so that larger hard disks wouldn't overburden the power supply due to the large start-up current of many hard disks, so you can't just drop in a hard disk without checking the power supply ECO! The only other option for the DECmate II is a CPU and memory board that adds either a Z80 and 64K or a Z80, 8086, and 256K {or alternatively 512K, not an upgrade, an alternate board!} where the Z80 can access 64K of the memory only. The 6120 is only indirectly interfaced to this board, and the usual software environment is that the 6120 runs as a server for whatever is running in the APU or XPU board itself when they are active. The only exception is that a portion of DEC's WPS software actually is run in the Z80 while the 6120 waits for the results (DECspell, footnote formatting). All other software runs without the optional CPU and memory boards in 32K only, however the control-panel memory is totally implemented to 32K. However, virtually all of it is dedicated to functions associated with the built-in terminal emulator, etc. The software environment on a DECmate II disk is such that each application owns its own volume or volumes, and can be sub-booted from Master Menu. This is necessary due to the myriad number of O/S'es that can run on the machine which can have up to three CPU's. {Some applications can be called up as separate bootable entities, but most of these are actually bootable OS/278 systems that are dedicated to running a specific application program. In theory, it's possible to revamp them into manually invocable utilities called up from one copy of OS/278, but this isn't what's done normally. In fact, Master Menu itself is one of these! However, there are legitimately several families of O/S for the machine that are distinct, and Master Menu can accommodate all of them, such as WPS, COS, CP/M-80, MS-DOS, OS/278, etc.} The DECmate III is a reworked smaller version of the DECmate II which can only have one pair of RX50 and no hard disk. The only options are a reworked APU board with a Z80 and 64K, and a graphics board. This system must have one monitor but it could be a VR-241 color monitor as well as the standard VR-201 mono monitor. All systems from the DECmate II up use the LK-201 keyboard, usually sold with the WPS keycaps, which in turn implies the blue color scheme for the keyboard as opposed to the more likely red, etc. In theory, there is also an obscure modem option whereby some specially adapted DEC "scholar" modem of the era can be plugged into a dedicated connector on the motherboard. I've never heard of anyone ever seeing the actual board, but it's known that it would be compatible with an appropriate DF modem that was 300 baud and 1200 baud only. Some newer DECmate III cases even lack the little slide-out case section where the modem's modular phone connector would poke through, or even the little telephone symbol that is used to label the connector. Early cases come with a 78W power supply, but newer ones are rated at 150W. In a startling display of retro-engineering, this system uses mono-voltage power supplies, which means that, including the DECmate III+ supplies, DEC bothered to reinvent so many wheels that there are at least six different power supplies to be found in this box! The DECmate III+ superficially looks like a DECmate III, but is quite different inside. The main board now sports an optional hard disk controller on an plug-in daughter board, indicating the likelihood that the system was designed to be a replacement of sorts for the original DECmate III board, but in fact it was never marketed that way. This hard disk controller is compatible with the one from the DECmate II, but due to case restrictions, mounting an internal hard disk requires it to be half-height; only the ST-225 20 MB disk was ever sold with it. The built-in modem connection of the DECmate III is still present, but they don't even implement the chips to drive the connector! The floppy support has been revamped to use RX33 (TEAC HD) drives, but only mimicking the RX50 at 300 RPM. It should be noted that the DECmate III+ can only use RX33, and the DECmate II and DECmate III can only use RX50, since the earlier machines require device-ready drives, and the DECmate III+ requires device-change drives. (Although the TEAC drives can be strapped to signal ready instead of change, they are not seek-ganged as is the RX50!) The DECmate III+ supports two RX33 drives, but due to case limitations, they were marketed with only one drive bolted onto the ST-225 HD. It appears that a contingency plan could have been to sell revamped DECmate III units by deleting the hard disk controller daughter board and adding a second RX33, but this configuration was never sold. The same two APU and graphics option boards of the DECmate III can also be used in the DECmate III+ however, CP/M-80 will have problems getting implemented, since it relies on the present of the second floppy drive, even when getting installed. (To install CP/M-80 on the machine, you have to at least temporarily hook up an additional floppy drive. To do this requires an alternate floppy cable, although the wiring is totally straight-forward and industry compatible. Note that an IBM-PC or PC-clone is *not* a straight-through cable and cannot be used!) There is rumor that there was some form of XPU board for the DECmate III and DECmate III+, possibly with more than the 8086 w/256K or 512K of the DECmate II XPU, rumored to contain an 80286, but none have surfaced, and it certainly wasn't sold. It is known that the RX33 floppy implementation is slightly deficient, in that the RX50 versions are capable of reading-*only* one-sided IBM-PC 40-track disks, while the RX33 cannot. Thus, it's not possible to write a utility to convert from IBM-PC 160K or 180K diskettes. On the DECmate II with XPU, this is a standard feature of MS-DOS to read one-sided IBM diskettes, etc. DECmate III+ comes with a 160W power supply. The only seeming difference is that there is an additional 4-prong power connector ganged into the power wiring, as opposed to potentially different innards from the DECmate III supply. As in the DECmate III boxes, the supplies come in 110V and 220V variants, instead of a switchable version as most equipment usually is constructed. cjl From dave%gilly@speedway.net Fri Sep 3 16:54:45 EDT 1993 Article: 380 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!news!news.world.net!speedway.net!gilly!dave Message-ID: <93633160646.dave.29806@gilly.UUCP> Date: Sat, 21 Aug 93 16:06:48 EDT Reply-To: dave%gilly@speedway.net Organization: Flat Earth Liberation Front Against Television From: dave@gilly.UUCP Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day References: <7368231@zl2tnm.gen.nz> Lines: 19 Xref: samba.oit.unc.edu alt.sys.pdp8:314 alt.folklore.computers:45923 don@zl2tnm.gen.nz (Don Stokes) writes: >The VAX 11/780 could go to (I think) 16MB, maybe more -- I can't remember >how big the physical address paths were and what reason for the limit was >(ie could third party boards take it up). It was certainly somewhat more >than 2MB... Oh. I was looking at the original "VAX Architecture Handbook" that announced the VAX-11/780, and it specified a 2 meg limit. Was this fixed with higher capacity RAM chips, or what? >Mind you, the /780 came out with memory sizes of 512k or less. OTOH, I Tha handbook says the minimum config was 128K. Now THAT would have benn painfull! Did any 128K VAXen actually ship? ------------------------ uunet!quack!gilly!dave ------------------------ ================= Dave Fischer - Nature's Perfect Food ================= ----------------------- dave%gilly@speedway.net ------------------------ From whit@carson.u.washington.edu Fri Sep 3 16:54:54 EDT 1993 Article: 381 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!olivea!hal.com!decwrl!usenet.coe.montana.edu!netnews.nwnet.net!news.u.washington.edu!carson.u.washington.edu!whit From: whit@carson.u.washington.edu (John Whitmore) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 23 Aug 1993 10:17:50 GMT Organization: University of Washington Lines: 27 Message-ID: <25a5ge$44d@news.u.washington.edu> References: <7368231@zl2tnm.gen.nz> <93633160646.dave.29806@gilly.UUCP> NNTP-Posting-Host: carson.u.washington.edu Xref: samba.oit.unc.edu alt.sys.pdp8:315 alt.folklore.computers:45956 In article <93633160646.dave.29806@gilly.UUCP> dave%gilly@speedway.net writes: >don@zl2tnm.gen.nz (Don Stokes) writes: >>The VAX 11/780 could go to (I think) 16MB, maybe more -- There was an upgrade (hardware rewiring and new memory controller board) at one point; the before-upgrade limit may have been 2 Mbytes. >Oh. I was looking at the original "VAX Architecture Handbook" that announced >the VAX-11/780, and it specified a 2 meg limit. Was this fixed with higher >capacity RAM chips, or what? >Tha handbook says the minimum config was 128K. Now THAT would have benn >painfull! Did any 128K VAXen actually ship? Yes. I have some of their memory boards here; the date is Nov 1977, and the boards are 11" by 16" and hold 144 memory chips each. The chips are MK4027 type. That's a whopping 64k bytes (with parity) per board. The old MK4027 is a 4kbit dynamic RAM. John Whitmore From zrepachol@cc.curtin.edu.au Fri Sep 3 16:55:45 EDT 1993 Article: 382 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 24 Aug 93 07:42:26 +0900 Organization: Curtin University of Technology Lines: 13 Message-ID: <1993Aug24.074226.1@cc.curtin.edu.au> References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> <24tasv$cb6@apakabar.cc.columbia.edu> NNTP-Posting-Host: cc.curtin.edu.au Xref: samba.oit.unc.edu alt.sys.pdp8:316 alt.folklore.computers:46004 In article , bqt@Minsk.docs.uu.se (Johnny Billquist) writes: > In <24tasv$cb6@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: ... > But the I/O is one of the things that really differs between RSX-11M and VMS! > RSX don't care about priorities on I/O requests, IAS does, and so do VMS! check the code. M uses the task priority for io, and ignores what you put in the QIO. D and IAS use the QIO value iff <>0, else task. Hey Charles, do you know the Zigglet story? ~Paul From dave%gilly@speedway.net Fri Sep 3 16:56:09 EDT 1993 Article: 383 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!news!news.world.net!speedway.net!gilly!dave Message-ID: <93134090623.dave.10889@gilly.UUCP> Date: Mon, 23 Aug 93 09:06:24 EDT Reply-To: dave%gilly@speedway.net Organization: Flat Earth Liberation Front Against Television From: dave@gilly.UUCP Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day References: Lines: 17 Xref: samba.oit.unc.edu alt.sys.pdp8:317 alt.folklore.computers:46020 bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >Where did you get the idea that the 11/780 only went to 2 megs??? "MOS memory may be added in increments of 128K byte units to a maximum of 1 million bytes per controller. Two memory controllers may be connected to a VAX-11/780 system, for a total of 2 million bytes of physical memory. (The minimum memory requirement is 128K bytes.)" - _VAX11/780_Architecture_Handbook_, digital, 1977. So, how did they get past that? ------------------------ uunet!quack!gilly!dave ------------------------ ================= Dave Fischer - Nature's Perfect Food ================= ----------------------- dave%gilly@speedway.net ------------------------ From bqt@Minsk.docs.uu.se Fri Sep 3 16:56:19 EDT 1993 Article: 384 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 25 Aug 93 00:39:37 GMT Organization: Uppsala University Lines: 25 Message-ID: References: <93134090623.dave.10889@gilly.UUCP> NNTP-Posting-Host: minsk.docs.uu.se Xref: samba.oit.unc.edu alt.sys.pdp8:318 alt.folklore.computers:46054 In <93134090623.dave.10889@gilly.UUCP> dave@gilly.UUCP writes: >bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >>Where did you get the idea that the 11/780 only went to 2 megs??? > "MOS memory may be added in increments of 128K byte units to a > maximum of 1 million bytes per controller. Two memory controllers > may be connected to a VAX-11/780 system, for a total of 2 million > bytes of physical memory. (The minimum memory requirement is > 128K bytes.)" > - _VAX11/780_Architecture_Handbook_, digital, 1977. >So, how did they get past that? Typical DEC vaporware. Just because DEC didn't make bigger memory cards than 128Kbytes, they said the maximum memory on the machine was 2 megs. But many more address lines exist, so just by using larger memory cards, you get more memory into the machine. -- 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 bqt@Minsk.docs.uu.se Fri Sep 3 16:56:35 EDT 1993 Article: 385 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 25 Aug 93 00:41:36 GMT Organization: Uppsala University Lines: 20 Message-ID: References: <24pr6a$cog@charm.magnus.acs.ohio-state.edu> <24tasv$cb6@apakabar.cc.columbia.edu> <1993Aug24.074226.1@cc.curtin.edu.au> NNTP-Posting-Host: minsk.docs.uu.se Xref: samba.oit.unc.edu alt.sys.pdp8:319 alt.folklore.computers:46055 In <1993Aug24.074226.1@cc.curtin.edu.au> zrepachol@cc.curtin.edu.au (Paul Repacholi) writes: >In article , bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >> In <24tasv$cb6@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >... >> But the I/O is one of the things that really differs between RSX-11M and VMS! >> RSX don't care about priorities on I/O requests, IAS does, and so do VMS! >check the code. M uses the task priority for io, and ignores what you >put in the QIO. D and IAS use the QIO value iff <>0, else task. *Sigh*. Final comment from my side. Yes, M uses the task priority, ie. it *don't* care about priorities in I/O reuqests. D and IAS do, as do VMS. (Or is my memory wrong on this?) -- 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 bellman@lysator.liu.se Fri Sep 3 16:56:48 EDT 1993 Article: 386 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!sunic!lunic!my!omega!lysator.liu.se!bellman From: bellman@lysator.liu.se (Thomas Bellman) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Message-ID: Date: 26 Aug 93 11:48:01 GMT References: <93134090623.dave.10889@gilly.UUCP> Sender: news@lysator.liu.se Organization: Lysator ACS at Linkoping University Lines: 14 Xref: samba.oit.unc.edu alt.sys.pdp8:320 alt.folklore.computers:46123 bqt@Minsk.docs.uu.se (Johnny Billquist) writes: > Typical DEC vaporware. Just because DEC didn't make bigger memory cards > than 128Kbytes, they said the maximum memory on the machine was 2 megs. > But many more address lines exist, so just by using larger memory cards, > you get more memory into the machine. Now that's a new variant of vaporware. Most computer manufacturers promise *more* than they can deliver, but DEC obviously promised *less* than they delivered. Pity that so few companies do this... -- Thomas Bellman, Lysator Computer Club, Linkoping University, Sweden Email: Bellman@Lysator.LiU.Se Phone (home): +46 - 13 177780 From bennett@dstos3.dsto.gov.au Fri Sep 3 16:57:04 EDT 1993 Article: 387 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!dstos3.dsto.gov.au!bennett From: bennett@dstos3.dsto.gov.au Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Followup-To: alt.sys.pdp8,alt.folklore.computers Date: 27 Aug 93 12:50:44 +0930 Organization: Defence Science and Technology Organisation Lines: 11 Message-ID: <1993Aug27.125044.1@dstos3.dsto.gov.au> References: <1993Aug11.100431.71047@cc.usu.edu> <24jnoi$jcn@apakabar.cc.columbia.edu> <24n54g NNTP-Posting-Host: dstos3.dsto.gov.au Xref: samba.oit.unc.edu alt.sys.pdp8:321 alt.folklore.computers:46163 In article , minow@apple.com (Martin Minow) writes: > > RT11 was done by many of the same people who had worked on OS/8. It > used some of the OS/8 ideas, but wasn't very similar inside. Its One difference that seemed significant to me at the time I used these things, was that OS/8 turned interrupt of, RT11 of course had it on. Regards, John Bennett bennett@scm.dsto.gov.au From zrepachol@cc.curtin.edu.au Fri Sep 3 16:57:24 EDT 1993 Article: 388 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 28 Aug 93 23:46:56 +0900 Organization: Curtin University of Technology Lines: 16 Message-ID: <1993Aug28.234656.1@cc.curtin.edu.au> References: <7368231@zl2tnm.gen.nz> <93633160646.dave.29806@gilly.UUCP> NNTP-Posting-Host: cc.curtin.edu.au Xref: samba.oit.unc.edu alt.sys.pdp8:322 alt.folklore.computers:46250 In article <93633160646.dave.29806@gilly.UUCP>, dave@gilly.UUCP writes: > don@zl2tnm.gen.nz (Don Stokes) writes: ... > >>Mind you, the /780 came out with memory sizes of 512k or less. OTOH, I > > Tha handbook says the minimum config was 128K. Now THAT would have benn > painfull! Did any 128K VAXen actually ship? The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives a *MAXIMUM* of 256KW. ie, 8k more than a 34... It also said 398 users! ~Paul From williamc@aifh.ed.ac.uk Fri Sep 3 17:10:37 EDT 1993 Article: 389 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!festival!aifh!aifh!williamc From: williamc@aifh.ed.ac.uk (William Chesters) Subject: Re: Happy PDP-5 day Message-ID: <1993Aug28.163702.16525@aifh.ed.ac.uk> Sender: news@aifh.ed.ac.uk (Network News Administrator) Reply-To: williamc@aifh.ed.ac.uk (William Chesters) Organization: Dept of AI, University of Edinburgh, Scotland References: <7368231@zl2tnm.gen.nz> <93633160646.dave.29806@gilly.UUCP> <1993Aug28.234656.1@cc.curtin.edu.au> Date: Sat, 28 Aug 93 16:37:02 GMT Lines: 10 Xref: samba.oit.unc.edu alt.sys.pdp8:323 alt.folklore.computers:46253 In article <1993Aug28.234656.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au (Paul Repacholi) writes: # The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives # a *MAXIMUM* of 256KW. ie, 8k more than a 34... I've seen the jokes about space heaters, but this is ridiculous. -- William "now *that* might stop us running out of hot water" Chesters `/usr/games/fortune` From erd@kumiss.cmhnet.org Fri Sep 3 17:40:12 EDT 1993 Article: 390 of alt.sys.pdp8 Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!mstar!n8emr!jcnpc!kumiss!erd From: erd@kumiss.cmhnet.org (Ethan Dicks) Subject: Re: Happy PDP-5 day Newsgroups: alt.sys.pdp8,alt.folklore.computers Followup-To: alt.sys.pdp8,alt.folklore.computers References: <1993Aug28.234656.1@cc.curtin.edu.au> X-Newsreader: TIN [version 1.1 PL9] Message-ID: Date: 28 Aug 93 23:13:19 EDT Organization: Not an Organization Lines: 32 Xref: news.columbia.edu alt.sys.pdp8:390 alt.folklore.computers:50479 Paul Repacholi (zrepachol@cc.curtin.edu.au) wrote: : In article <93633160646.dave.29806@gilly.UUCP>, dave@gilly.UUCP writes: : > don@zl2tnm.gen.nz (Don Stokes) writes: : ... : > : >>Mind you, the /780 came out with memory sizes of 512k or less. OTOH, I : > : > Tha handbook says the minimum config was 128K. Now THAT would have benn : > painfull! Did any 128K VAXen actually ship? I worked for a company that bought a VAX-11/750 (S/N BT000254) that shipped with 512K (on two cards). That machine was in active service until about two weeks ago. Mind you, it was upgraded to 8Mb a few years ago. : The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives : a *MAXIMUM* of 256KW. ie, 8k more than a 34... The SPD for v1.0 had a restriction of that nature. I can't easily reference my copy of it because my VAX/VMS v1.0 manuals are packed in storage. They make for humorous reading when viewed with hindsight. Also, The 11/34 had to share memory space with an I/O page. The VAX architecture allowed for a full power-of-two RAM space with I/O space residing entirely outside the area available for RAM. To access I/O, you had to be in kernel mode or have a kernel mode process map the I/O page into the 4Gb virtual space of your process. Since very few processes actually had to hammer I/O registers directly (unlike PDP-11 programs), this does not normally represent a problem. -ethan From don@zl2tnm.gen.nz Fri Sep 3 17:40:16 EDT 1993 Article: 391 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!wupost!waikato!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Message-ID: <7729241@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 30 Aug 93 10:29:30 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <1993Aug29.205124.57@cc.usu.edu> Distribution: world Organization: The Wolery Lines: 14 Xref: news.columbia.edu alt.sys.pdp8:391 alt.folklore.computers:50530 ivie@cc.usu.edu writes: > Nope, all it takes is the PFNMAP privilege. This allows a process to create > and map a section to a physical address range. > Mind you, catching an interrupt in a user program is evil nasty under VMS... Nah. You need a kernel mode handler, but that can be small and just declare an AST to the process. If you're running around with PFNMAP, getting CMKRNL is just a (very) small matter of programming.... 8-) (And yes, I _can_ demonstrate this. 8-) -- Don Stokes, CSC Network Manager, Victoria University of Wellington, New Zealand Ph+64 4 495-5052 Fax+64 4 471-5386 Work:don@vuw.ac.nz Home:don@zl2tnm.gen.nz From russ@cs.indiana.edu Fri Sep 3 17:40:19 EDT 1993 Article: 392 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!psinntp!psinntp!nstn.ns.ca!news.cs.indiana.edu!russ@cs.indiana.edu From: "J Russ" Subject: Re: PDP8/I Give away! Message-ID: <1993Aug31.023134.28313@news.cs.indiana.edu> Organization: Computer Science, Indiana University References: <25ivq5INNju@darkstar.ucsc.edu> Distribution: us Date: Tue, 31 Aug 1993 02:31:28 -0500 Lines: 27 In article <25ivq5INNju@darkstar.ucsc.edu>, Sync wrote: > > >I have 3 PDP8/i systems that I have to get rid of. If you want >them they're yours for the taking. But as you probably know, >taking these beasts is not a trivial undertaking! It will >require at least a good sized pickup truck. Add to that the >that I'm located on a mountain top about 20 miles from San Jose, >California. If you are interested in these systems please >let me know before I find a hole in the ground big enough for >them. > >The systems are complete with DM01, TC01, 2 TU55 drives, our >own 8" floppy disc (TU55 work alike), and LA36 DecWriter. I >don't feel like stripping down the systems so if you only want >the TU55's, for instance, you'll have to take a whole system! Is anybody going for these systems? If they were closer to Indiana I'd pick them up. If nobody is interested in them is there anyone in the area who could strip them, box the stuff up and ship it via UPS? The boards, core memories, TC01 controllers and TU55 drives are too useful to goto waste. ---------------------------------------------------------------------------- Jeff Russ russ@silver.ucs.indiana.edu University Computing Services PHONE: (812) 855-2733 Indiana University, Bloomington, IN I want to buy old PDP[4-9] systems. From jones@cs.uiowa.edu Fri Sep 3 17:40:24 EDT 1993 Article: 393 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers,sci.electronics Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!wupost!crcnis1.unl.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: Computer History Association of California Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug31.145000.24130@news.uiowa.edu> Date: Tue, 31 Aug 1993 14:50:00 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 138 Xref: news.columbia.edu alt.sys.pdp8:393 alt.folklore.computers:50649 sci.electronics:54396 I've just discovered an interesting organization, the Computer History Association of California, and it's clear that their goals are very much in keeping with the goals of many of the readers who follow these newsgroups. As near as I can figure, they're the first general membership association devoted to historic preservation of computers. Thus, they may be able to provide the kind of hacker-centered orientation that is lacking in places like the Computer Museum and the Smithsonian. Here's a quote from their newsletter, the Analytical Engine, Volume 1, Number 1: Ever since the days of ENIAC, the rallying cry of computing has been _Let's chuck the old stuff to make room for the new stuff!!_ and hardware is scrapped, with the hardware goes the documentation, goes the information, leaving only the thin thread of memory which snaps too. Leaving aside dubious precursors, electronic computing is fifty-five years old, microcomputing is less than twenty years old, and we're shedding the pertinent history by the dumpsterful. The history of digital computing -- one of the newest core sciences in the world -- is being destroyed as fast as it's being made. On April 19, 1993, a few people decided to take a stand by founding the Computer History Association of California, an organization that exists to do these things: * Create awareness of the history of computing as a real, evolving and valuable phenomenon. * Prevent the destruction of historically significant hardware, software and documentation. * Strengthen the cooperation among existing institutions that safeguard the history of computing. * Begin discussions among developers and computer-related manufacturers about setting up an overall archive -- or at least agreeing on archiving conventions. * Ultimately, to help build a coalition that can build and endow a library and museum for the history of computing in California. These people are doing the right thing, with essentially the same goals that led to the formation of alt.sys.pdp8, but with a broader charter and a more formal organization. They clearly have a regional focus, but at the same time, the job they're talking about needs to be done nationally and internationally. I feel that we preservationists should support them actively, either by joining their organization (particularly, those of us in the bay area), or by referring California hardware and documentation rescue work to them. They've picked up a significant membership outside of California, but my long-term hope is that we can get similar local organizations running on the east coast and in the midwest. We've got the critical mass in both places, but here in the midwest, we may not have the critical density. Doug Jones jones@cs.uiowa.edu P.S. Here's the CHAC membership form: ------------------------------------------------- The ANALYTICAL ENGINE, newsletter of the Computer History Association of California, is published four times a year -- in January, April, July and October -- at El Cerrito, California. Subscriptions are available with Association membership at $25 per year. Use the coupon below to subscribe, or contact the Association at: US Mail: 1001 Elm Court, El Cerrito, CA 94530-2602 Internet: kcrosby@crayola.win.net America Online: kcrosby CompuServe: 72341,2763 FAX: 510/528-5138 ------------------------------------------------- SUBSCRIBE * SUBSCRIBE * SUBSCRIBE * SUBSCRIBE and share fascinating insights into the vital story of computing while you build an organization that safeguards our unique scientific and technical heritage. Just $25 will bring you four issues of the ANALYTICAL ENGINE -- filled with non-partisan, technically and historically accurate articles -- and the satisfaction of preserving the history that you work to create. ____ Yes! I enclose $25. Please enroll me in the Computer History Association of California for the next year and send four issues of the ANALYTICAL ENGINE to ____ Internet address: ________________________________________ ____ CompuServe ID#: __________________________________________ ____ Other gateway: ___________________________________________ ____ I would prefer to receive paper copies of the ANALYTICAL ENGINE. (A paper edition will be produced if the membership shows sufficient interest.) My mailing address is: Name: _________________________________________________________ Company: ______________________________________________________ Suite, Box, Mail stop: ________________________________________ Street: _______________________________________________________ City: _____________________ Zip/postcode: ___________________ Country: ______________________________________________________ ____ I will submit an article to the ANALYTICAL ENGINE. (Please refer to the guidelines for submission, above.) ____ I will help produce the ANALYTICAL ENGINE or do other work for the Association. Please contact me at: ______________________________________________________________ ***** NOTE: This issue of THE ANALYTICAL ENGINE is being distributed on the honor system. Please subscribe if you wish to, but for the moment we can only accept checks or other depositable types of payment. We hope that, by the end of 1993, we will have con- cluded arrangements with various online services to accept payment by VISA or MasterCard. We appreciate your patience. From secrist@kxovax.enet.dec.com Fri Sep 3 17:40:30 EDT 1993 Article: 394 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!decwrl!decwrl!pa.dec.com!jac.nuo.dec.com!kxovax.enet.dec.com!secrist From: secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) Newsgroups: alt.sys.pdp8 Subject: Post the remainder of CHAC newsletter ! Date: 31 AUG 93 12:31:32 Organization: Digital Equipment Corporation Lines: 12 Message-ID: <25vug7$6lp@jac.nuo.dec.com> NNTP-Posting-Host: KXOVAX Thank you for posting the Computer History Association of California information. Would you post the rest of the newsletter, please ? Regards, rcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Richard C. Secrist "The superior man understands +-+-+-+-+-+-+-+ Digital Equipment Corp. what is right; the inferior man |d|i|g|i|t|a|l| secrist@kxovax.enet.dec.com understands what will sell." +-+-+-+-+-+-+-+tm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From jones@cs.uiowa.edu Fri Sep 3 17:40:36 EDT 1993 Article: 395 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!destroyer!newsrelay.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu Subject: The Analytical Engine (CHAC newsletter!) Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug31.175000.28969@news.uiowa.edu> Date: Tue, 31 Aug 1993 17:50:00 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 622 Xref: news.columbia.edu alt.sys.pdp8:395 alt.folklore.computers:50662 >From article <25vug7$6lp@jac.nuo.dec.com>, by secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.): > > Thank you for posting the Computer History Association of California > information. Would you post the rest of the newsletter, please ? Here it is: -------------------------------------------------------------------- Analytical Engine V1#1, July 1993 Page 1 The ANALYTICAL ENGINE Newsletter of the Computer History Association of California ISSN pending Volume 1, Number 1, July 1993 Kip Crosby, Managing Editor Jude Thilman, Telecommunications Editor ------------------------------------------------- EDITORIAL Welcome to the Analytical Engine, volume one, number one. This document has three purposes: To present a small sample of computer history. To convince you that computer history is worth exploring and preserving. To persuade you that a modest commitment of your time or money, or both, will help build an institution and protect some of the most important scientific information in the world today. Let me give you one concise example. Remember the Pong machine? It wasn't much to look at; a black-and-white CRT in a squat, screaming-yellow plywood box, with a couple of black knobs. But in the early Seventies it introduced thousands of people -- and, beyond them, the world -- to the interactive video game. It was one of the first computer-driven devices to become a memorable part of our culture. Of the perhaps 15,000 Pong machines that Atari built, _there are fewer than a dozen left_ and they are substantially priceless. Collectors compete to buy them. What happened to the others? They were displaced, replaced, thrown away. Junked. Ever since the days of ENIAC, the rallying cry of computing has been _Let's chuck the old stuff to make room for the new stuff!!_ and hardware is scrapped, with the hardware goes the documentation, goes the information, leaving only the thin thread of memory which snaps too. Leaving aside dubious precursors, electronic computing is fifty-five years old, microcomputing is less than twenty years old, and we're shedding the pertinent history by the dumpsterful. The history of digital computing -- one of the newest core sciences in the world -- is being destroyed as fast as it's being made. Nor can we depend on the voices of the pioneers to fill gaps. Many of the originators of electronic computing, like Alan Turing, Atanasoff and Berry, John Mauchly, Wallace Eckert, Admiral Hopper, and even Bob Noyce and William Shockley, can no longer be interviewed. The British journalist Chris Evans, who wanted to be _the_ popular historian of the microcomputer, died with one of his books half-finished. Computer science has become a freestanding discipline comparable in stature to almost any other physical science, and yet its public record lags far behind the evolving fact. Worthy exceptions like the BBC Press Analytical Engine V1#1, July 1993 Page 2 book The Dream Machine (reviewed next issue) only underscore the scale of the general flow into oblivion. A handful of concerned organizations, like the Association for Computing Machinery, and individual historians -- Ted Nelson, Jon Palfreman, James Cortada, for example -- are trying to preserve an irreplaceable historical record, and frankly fighting a losing battle. On April 19, 1993, a few people decided to take a stand by founding the Computer History Association of California, an organization that exists to do these things: * Create awareness of the history of computing as a real, evolving and valuable phenomenon. * Prevent the destruction of historically significant hardware, software and documentation. * Strengthen the cooperation among existing institutions that safeguard the history of computing. * Begin discussions among developers and computer-related manufacturers about setting up an overall archive -- or at least agreeing on archiving conventions. * Ultimately, to help build a coalition that can build and endow a library and museum for the history of computing in California. A tall order! But the people who attended the first meeting left, thought it over, and told friends. The idea went out in CompuServe mail and Internet mail and voice. And within days we had -- Projects. Urgent messages about hardware slated to be scrapped, software in filing cabinets in storerooms, manuals on pallets waiting to be recycled. Right now, today, we have almost no space, almost no money, a few members, a lot of work to do and a lot of enthusiasm. The Computer History Association of California could take off and do its part for the history of science. Or it could end up as a good idea in a filing cabinet in a storeroom. The difference is up to me, to us, and to you. If we can make a good case for ourselves, we won't be alone. Companies and managers who share our wish to preserve this history -- their history -- will lend a hand to a serious effort. The wider public will contribute through annual dues or subscriptions to this newsletter. Our potential membership is large, and growing. Computing -- personally and institutionally -- is moving from a Analytical Engine V1#1, July 1993 Page 3 devil-may-care adolescence to a maturity that embraces social responsibility. Recycling, waste control, power consumption and other "green" issues are developing broad constituencies. These people are the same ones who will recognize, in and through our Association, steps that can be taken now to prevent a lot of regret in the next century. The sooner we can alert them to the need for preservation, the more we can accomplish. To those of you who want to share in that accomplishment, the Computer History Association of California makes five promises: * We will be non-partisan and nonjudgmental. We will strive to be accurate, interesting and innovative. Our aim must be to enrich the history of science without distorting it. * We will work to preserve hardware, software and documentation, as it becomes available to us, from the full spectrum of the history of computing. * We will make the Association's property accessible to all interested parties as a professional and educational resource. * We will aggressively pursue funding from the corporations that made the computer into a fact of modern life -- inviting them to safeguard the history that they themselves created. * We will have professional counsel on how to build up and broaden this organization; how to make time and money most effective; how to choose and manage exhibits and resources, and protect them for future generations. If we succeed in these ambitions, we will do our small part of a big -- of a great -- job. We will help to affirm the history of a core science while we live surrounded by its turbulent origins. Someday, when our descendants respect the pioneers of computing as they do Galileo, Edison and Goddard, that affirmation will pay off. But we are those pioneers. We know this story as no one else ever will. And we must keep it as our children's heritage -- and as our own. ------------------------------------------------- PROGRAMMING THE 1401: An Interview with Leo Damarodas by Roger Louis Sinasohn [Author's note: Leo Damarodas has been a programmer since the days of room-sized computers filled with vacuum tubes. We first met in the mid '80s when we both worked for Noesis Computing Company, then known as one of the premier software Analytical Engine V1#1, July 1993 Page 4 houses in the Hewlett-Packard marketplace. Today, Leo is an independent consultant, and lives on a sailboat south of San Francisco. I was recently able to pin him down and convince him to reminisce about his work with one of the earliest commercially available mid-size computers, the IBM 1401. ] _When and how did you get into computers?_ Let's see.... My actual first job was in 1965. I started off from high school as an electronic technician in the early '60s,when they were a dime a dozen, and in a period of three years, I was laid off 18 months. I got a job in one of the local mills, and went to school nights studying computer programming, circuitry and design, figuring that if I got a job in either maintenance or programming, that's where I'd work. And the mill that I was working at knew of my interest in computers and moved me into their office as a programmer, once I graduated. _Over the years, what have been the biggest changes in the computer industry?_ (Laughs) Well, let's see. Going from vacuum tubes to solid-state magnetic core memory -- this is where the expression core memory comes from. Another big one's interactive programming; getting away from punched cards. It affected the way I was working, anyway. _What has stayed the same?_ The need for programmers. That's never changed. And I don't think it's ever going to. _Why do you say that?_ Because I've been hearing as long as I've been in this business that computers would start programming themselves in the near future. It hasn't happened yet. I don't really think it will. _You don't think that artificial intelligence will become intelligent enough?_ Not with the way computers are being built currently. I mean, programmers will be put out of business when computers become sentient. They're going to have to know what they're doing, and machines don't. It's as if we worried about cars driving themselves around the streets. Even artificial intelligence requires programming. _When I've been working, I've cursed my computer for not doing what I wanted it to..._ Analytical Engine V1#1, July 1993 Page 5 (Laughs) You want my poem? Is that what you're asking for? [Quotes:] "I really hate this gosh-darned thing, I think I'm gonna sell it. It never does just what I want, but only what I tell it." _In that connection you've said that you shouldn't want it to start guessing what you want. You want it to do what you tell it._ Right. _Why do you say that?_ If it starts trying to second-guess me, and it guesses wrong....if anything goes wrong with the computer, I'd rather blame myself than the computer, because to me the computer is a tool -- nothing more than a glorified screwdriver. And when the tools start running themselves, then it's time to worry. Because if computers start doing what they think we want done, the next step is them doing what they think is best for us. It is getting to the point where computers become intelligent, but with present-day circuitry, no matter how many processors you hook up, it still can't think for itself. It still needs a program to run. _You worked on the IBM 1401._ Yeah. _What was that like?_ Well, at the time, it seemed great, because it was the only thing I knew -- the first computer I ever worked on. It was a hundred per cent vacuum tubes....the logic circuitry, the memory, everything was vacuum tubes. The addressing structure of the machine only allowed for 16K of memory, and there was no operating system in the modern sense. The way into the machine was through reading the machine instructions. Each instruction portion was a letter, a readable character, and they made sense. Take some examples, M was Move; W was Write a print line; P was Punch a card; R was Read a card. When you executed these instructions, you didn't need an address, because the card read/punch always worked memory locations 1 through 80. And the printer always used memory locations 101 through 232 as the I/O buffer. It was a really simple machine to work with and a lot of fun in a way. The only way you could get the machine to do something was put a deck of cards in the card reader and hit the start button. And that would read the card deck, load the program into memory, and Analytical Engine V1#1, July 1993 Page 6 start executing it. It was slow; there was no multi-processing, no nothing. Just a really simple machine. _So it was basically one thing at a time, and mostly written in machine language._ Basically, yeah, but we had ways around that. There was a COBOL compiler on the program, but we tried to avoid using it, because to compile a 16K program and get a program deck out would take something like an hour. But because we could read the machine instructions, if we had an error, we didn't really have to go through the compilation. You could take the program deck and modify the actual machine code, load the program and run it again. It saved a lot of time. We also had a language called Autocoder which was a kind of assembler. It expanded the machine instructions out to more readable mnemonics, and allowed you to use labels for addresses and stuff -- use real names. It made the programming a lot easier. The thing that was really interesting was the COBOL compiler, which was the only other language, that I knew about -- I think there was a FORTRAN available too, but I coded business applications, so FORTRAN wasn't used that much. One of the features of the COBOL was an ENTER instruction, so that while you were writing your COBOL code, you could say ENTER AUTOCODER and start writing Autocoder code right in your COBOL source, then say ENTER COBOL and start writing COBOL code again. This was possible because the COBOL compiler didn't generate machine language -- it generated Autocoder code, and then called the Autocoder, which converted the COBOL output into machine language. So it just substituted the Autocoder code in your COBOL source for the output. _What sort of applications were you working on?_ Payroll, Accounts Payable, Accounts Receivable, General Ledger -- straight business applications. And it was next to impossible to write any major program without going over 16K. So you either broke it down into steps -- 16K steps, or you wrote program overlays. There were instructions that would allow you to read in the next part of the program. But the overlays had to be set up in such a way that you performed one step for all the data, loaded the next step and performed it for all the data. You couldn't go back and forth between overlays because the programs had to run from card decks. Data resided on disk, but not programs. All the data would come in initially on cards, be transferred to the disk drives on the system, and the programs could process disk. _So, for example, a run to print the payroll, how long would it take that program to produce checks?_ Honestly I don't remember, but a long time, because the only time we could use for testing was between midnight and eight in Analytical Engine V1#1, July 1993 Page 7 the morning. The machine was being used the rest of the day to do production work, and about all they were doing was Accounts Receivable, Accounts Payable, General Ledger, payroll and some inventory. Not too much more than that. _What happened if you had a deck that's data to be input, and you have a deck that's a program -- what happens if you mix them up? That is, you put the data in as if it were a program?_ One of the things that would happen, if you tried to load the data in without having the program loaded, was that it would choke on the first card. You've got to remember there was no operating system, and this machine's just sitting there, waiting for a bootstrap program that had to be in the first card. When you pressed the start button on the console, it read the bootstrap card and branched to location one. If there wasn't a valid instruction there for it to execute, it wouldn't do a thing. The bootstrap program read the rest of the cards in, and when it got an end-of-cardfile, it branched to the location where the program was loaded; I forget exactly what part of memory that was. _Punched cards had 80 columns, so you could, in theory, have up to eighty instructions per card. Is that correct?_ In theory you could, if they were instructions that didn't require addresses. They were single-byte instructions. _So a small program might fit on a single card?_ Yes, in fact the bootstrap program didn't even take a whole card. The bootstrap program was about a dozen characters long. Somewhere I have a framed white poster, about four inches high and ten or twelve inches long, with that program written on it. I got it at an HP user group meeting where I walked by a booth with a sign outside that said "If you know what this is, you're showing your age." It was the 1401 bootstrap program. It looked familiar but I couldn't quite remember what it was, and I said "I don't know what it is, but I should." The guy who was running the booth knew me and my background, and he said "I know you should." Maybe three or four weeks after the meeting, the poster showed up in my mailbox. _How long did you work with the 1401?_ Only about a year, and I think the machine I worked on was actually a 1410. 1410's were the ones that had disk drives. I came in just as they were doing a conversion from the 1401 series to an IBM 360. _And 360's are still being used today._ I would imagine so. [Editor's note: Our best information is that at least two System/360s are currently used in California, Analytical Engine V1#1, July 1993 Page 8 both by private corporations in Greater Los Angeles.] As for the 1401 series, last I heard, the Department of the Navy was still running an application on a 1410 a good eight or nine years ago... In the early eighties, anyway. [Concluded next issue] ------------------------------------------------- I Played the ORIGINAL Video Game! a recollection by Scott Robinson I went to work at Bolt Beranek and Newman (no comma, please) in the summer of 1966, as an instrumentation engineer. In those days the company's activities were roughly equally divided between acoustics -- both architectural and underwater -- and computer science. The computer group's main machine was a PDP-1, which consisted of about six 6 foot racks full of hardware. It may have had a Remington Rand Fastrand drum memory; I'm not sure. The company certainly had one of these beasts later on, a drum about five feet long and two feet in diameter with a large number of heads. All this was housed on the lower floor of the (then) new split-level building, adjacent to the kitchen and the reception area. The control console for this machine was on the end of the row of racks; it had a monochrome CRT, about 12 or 14 inch size, and a row of miniature metal-handled toggle switches to enter data and addresses when necessary. These switches were used as the controls for Spacewar. This game was not a time-shared activity; I suspect that we used the whole machine! When a game was started, the screen would light up with two different ship icons against a random background of stars. There could, optionally, be a sun in the middle exerting gravitational influence on matter. The gravitational constant was also players' choice, I think in two steps, "fast" or "slow." The screen was topologically connected side-to-side and top-to-bottom; if you exited screen left, you reappeared screen right, and so on. Each ship could be rotated clockwise or counterclockwise, fire reaction engines that eventually ran out of fuel, and fire missiles of finite range and finite number. The ship obeyed Newton's laws, accelerating and decelerating under the influence of its engines and of solar gravitation, if any. Rotation could be either easy to control (when you had a switch on, the ship rotated,) or more difficult and realistic (the switches applied angular acceleration, so that rotation increased or decreased gradually depending on switch settings). The object, of course, was to blow the other ship up. If you were hit, you were dead meat! Falling onto the sun was comparably ill-advised. Collision of two ships produced a Analytical Engine V1#1, July 1993 Page 9 vivid, graphically depicted explosion on screen, and both players were out, whereupon the game restarted. For those in desperate circumstance, faced perhaps with a barrage of missiles incoming and too close to dodge, there was an escape...hyperspace! By rotating in both directions simultaneously, the ship could be made to vanish and reappear with unpredictable position and velocity. Your situation might be improved...but with a catch. The ship might explode upon re-entry into normal space, and the likelihood increased each time hyperspace was invoked. I don't think I ever saw anyone use hyperspace four times in one game without blowing up. The display was a vector-type CRT and the quality of the graphics exceptional. The motion was perfectly smooth, with no aliasing artifacts noticeable. Although I and others spent many enjoyable evenings playing Space War, the test word toggle switches used as controls enjoyed the game much less than we did, and failed with some regularity. Ultimately the computer folks got tired of replacing the switches and threw us off the machine. Nonetheless I take a certain satisfaction in having played one of the first computer games, an innovative and engaging game with rigorous simulation of physics in action. As for the hyperspace feature, haven't you ever felt that you were about to go off into hyperspace when you tried to rotate both directions at once? ------------------------------------------------- NEXT ISSUE * NEXT ISSUE * NEXT ISSUE * NEXT ISSUE INITIATIVE 1999: Why a lot of hardware will be scrapped at the turn of the century. Why six years is barely long enough to prepare for the consequences. Plus: Programming the 1401, part 2. Smalltalk Then and Now. Palfreman and Swade's Dream Machine. More.... Downloadable October first -- don't miss it! ------------------------------------------------- GUIDELINES FOR SUBMISSION The ANALYTICAL ENGINE solicits manuscripts of 600 to 1000 words on the general topic of the history of computing. Articles should be tightly focused on one interesting or illuminating episode and should be written for a technically literate general audience. Submissions are welcome from both members and non-members of the CHAC and a one-year membership, or extension, will be given for each article published. Article deadlines are the first of each month prior to publication: June 1 for the Analytical Engine V1#1, July 1993 Page 10 July issue, September 1 for the October issue, December 1 for the January issue, and March 1 for the April issue. Decision of the editors is final but copyright of all published material will remain with the author. The preferred document file format is Microsoft Word for DOS or Windows, but almost any DOS or Macintosh word processor file will be acceptable. Alternatively, please provide an ASCII file. Submit manuscripts on DOS 5.25" or DOS or Mac 3.5" diskettes, or by modem as a file attached to an Internet message. Please avoid submitting on paper unless absolutely necessary. ------------------------------------------------- Can you spare a few minutes a month? The ANALYTICAL ENGINE urgently needs volunteer help for administration, subscription fulfillment, proofing and keying. Help keep the ENGINE spinning -- reply to our Internet or mailing address today. ------------------------------------------------- The ANALYTICAL ENGINE, newsletter of the Computer History Association of California, is published four times a year -- in January, April, July and October -- at El Cerrito, California. Subscriptions are available with Association membership at $25 per year. Use the coupon below to subscribe, or contact the Association at: US Mail: 1001 Elm Court, El Cerrito, CA 94530-2602 Internet: kcrosby@crayola.win.net America Online: kcrosby CompuServe: 72341,2763 FAX: 510/528-5138 ------------------------------------------------- SUBSCRIBE * SUBSCRIBE * SUBSCRIBE * SUBSCRIBE and share fascinating insights into the vital story of computing while you build an organization that safeguards our unique scientific and technical heritage. Just $25 will bring you four issues of the ANALYTICAL ENGINE -- filled with non-partisan, technically and historically accurate articles -- and the satisfaction of preserving the history that you work to create. Analytical Engine V1#1, July 1993 Page 11 ____ Yes! I enclose $25. Please enroll me in the Computer History Association of California for the next year and send four issues of the ANALYTICAL ENGINE to ____ Internet address: ________________________________________ ____ CompuServe ID#: __________________________________________ ____ Other gateway: ___________________________________________ ____ I would prefer to receive paper copies of the ANALYTICAL ENGINE. (A paper edition will be produced if the membership shows sufficient interest.) My mailing address is: Name: _________________________________________________________ Company: ______________________________________________________ Suite, Box, Mail stop: ________________________________________ Street: _______________________________________________________ City: _____________________ Zip/postcode: ___________________ Country: ______________________________________________________ ____ I will submit an article to the ANALYTICAL ENGINE. (Please refer to the guidelines for submission, above.) ____ I will help produce the ANALYTICAL ENGINE or do other work for the Association. Please contact me at: ______________________________________________________________ ***** NOTE: This issue of THE ANALYTICAL ENGINE is being distributed on the honor system. Please subscribe if you wish to, but for the moment we can only accept checks or other depositable types of payment. We hope that, by the end of 1993, we will have con- cluded arrangements with various online services to accept payment by VISA or MasterCard. We appreciate your patience. From minow@apple.com Fri Sep 3 17:40:39 EDT 1993 Article: 396 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!usenet.coe.montana.edu!decwrl!decwrl!apple!mumbo.apple.com!gallant.apple.com!minow.apple.com!user From: minow@apple.com (Martin Minow) Subject: Re: The Analytical Engine (CHAC newsletter!) Sender: news@gallant.apple.com Message-ID: Date: Tue, 31 Aug 1993 19:38:55 GMT References: <1993Aug31.175000.28969@news.uiowa.edu> Organization: Macintosh Developer Services Followup-To: alt.sys.pdp8,alt.folklore.computers Lines: 55 In article <1993Aug31.175000.28969@news.uiowa.edu>, jones@cs.uiowa.edu wrote: > > From article <25vug7$6lp@jac.nuo.dec.com>, > by secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.): > -------------------------------------------------------------------- > Analytical Engine V1#1, July 1993 Page 1 > ... > > PROGRAMMING THE 1401: > An Interview with Leo Damarodas > > by Roger Louis Sinasohn ... > _You worked on the IBM 1401._ > > Yeah. > > _What was that like?_ > > Well, at the time, it seemed great, because it was the only > thing I knew -- the first computer I ever worked on. It was a > hundred per cent vacuum tubes....the logic circuitry, the > memory, everything was vacuum tubes. The addressing structure > of the machine only allowed for 16K of memory, and there was no > operating system in the modern sense. Pardon me, but I also programmed the 1401 and ours was a transistorized machine with ferrite core memory. It was the "minicomputer" of its day. In addition to Autocoder (assember), ours could be programmed in RPG (which might be seen as an emulator for a 407 accounting machine). As an accounting machine, it was quite fast (1000 cards/minute, 1200 line/minute printer). It was never intended as a number cruncher. However, as it had no defined numeric word length (words were addressed at one end and had an "end of record" mark at the other end), you could do "infinite-precision" calculation with some effort. A 1401 emulator was available for the PDP-11 (under RSTS/E) for many years. It probably still works. > ------------------------------------------------- > > I Played the ORIGINAL Video Game! > a recollection by Scott Robinson > > I went to work at Bolt Beranek and Newman (no comma, please) in > the summer of 1966, as an instrumentation engineer. In those Sorry, there were video games in the 1950's on Illiac (I played one in 1962). And I was told there was a quite interesting game on SAGE (Air Defense Computers) that involved an image of a dancing woman and a light pen. Someone else will have to explain that one further. Martin Minow minow@apple.com From jones@pyrite Fri Sep 3 17:40:42 EDT 1993 Article: 397 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: The Analytical Engine (CHAC newsletter!) Sender: news@news.uiowa.edu (News) Message-ID: <1993Aug31.215837.4918@news.uiowa.edu> Date: Tue, 31 Aug 1993 21:58:37 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 25 Xref: news.columbia.edu alt.sys.pdp8:397 alt.folklore.computers:50685 There were indeed more than a few errors in that newsletter! 1) The IBM 1401 was not a vacuum tube machine! It was transistorized. 2) Pong was not a computer game! It was a video game implemented with TTL logic, with no computer. 3) Spacewar wasn't a video game! Video encoding of data was not used to paint the image on the face of the CRT. Instead, the software drove a pair of ADC's to handle deflection in the X and Y directions, and the software painted each dot on the screen. The resolution was far better than standard video, but the number of dots that could be painted without causing flicker was limited. (By the way, I have played spacewar myself on a DDP 224 computer at the University of Michigan -- that machine was a nice 24 bit minicomputer, and their version of spacewar used two joysticks on the graphics display.) In any case, the folks at CHAC clearly have their hearts in the right place, and the kinds of errors they made in their newsletter only serve to prove the point of their opening editorial! History is indeed being lost and forgotten at an impressive rate! Doug Jones jones@cs.uiowa.edu From wtyler@adobe.com Fri Sep 3 17:40:46 EDT 1993 Article: 398 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!darwin.sura.net!news-feed-2.peachnet.edu!concert!decwrl!adobe!wtyler From: wtyler@adobe.com (William Tyler) Subject: Re: The Analytical Engine (CHAC newsletter!) Message-ID: <1993Aug31.231934.8000@adobe.com> Followup-To: alt.folklore.computers Sender: wtyler Organization: Adobe Systems Inc., Mountain View, CA References: <1993Aug31.175000.28969@news.uiowa.edu> Distribution: na Date: Tue, 31 Aug 1993 23:19:34 GMT Lines: 50 Xref: news.columbia.edu alt.sys.pdp8:398 alt.folklore.computers:50693 In article <1993Aug31.175000.28969@news.uiowa.edu> jones@cs.uiowa.edu writes: >Here it is: > >-------------------------------------------------------------------- > Analytical Engine V1#1, July 1993 Page 1 > ......... > > PROGRAMMING THE 1401: > An Interview with Leo Damarodas > > by Roger Louis Sinasohn > ......... > _You worked on the IBM 1401._ > > Yeah. > > _What was that like?_ > > Well, at the time, it seemed great, because it was the only > thing I knew -- the first computer I ever worked on. It was a > hundred per cent vacuum tubes....the logic circuitry, the > memory, everything was vacuum tubes. The addressing structure > of the machine only allowed for 16K of memory, and there was no > operating system in the modern sense. This is incorrect. The 1401 used discrete transistors. (I also worked on one, and know whereof I speak.) ......... > _How long did you work with the 1401?_ > > Only about a year, and I think the machine I worked on was > actually a 1410. 1410's were the ones that had disk drives. I > came in just as they were doing a conversion from the 1401 > series to an IBM 360. Disk drives were actually also available on the 1401. Mine had two. Bill Tyler -- Bill Tyler wtyler@adobe.com