From levy@levy.fnal.gov Wed Feb 2 06:42:57 EST 1994 Article: 634 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!convex!news.ssc.gov!fnnews.fnal.gov!fndcd.fnal.gov!levy From: levy@levy.fnal.gov (Mark E. Levy, ext. 8056) Newsgroups: alt.sys.pdp8 Subject: Desperately seeking a PDP8A Date: 1 Feb 94 14:22:03 -0600 Organization: Fermilab Computing Division Lines: 16 Message-ID: <1994Feb1.142203.1@levy.fnal.gov> NNTP-Posting-Host: levy.fnal.gov I have a client with a numerically controlled punch press that has a PDP8A as it's controller. The '8 is randomly halting. We've been through all of the normal tests; i.e. P/S, backplane, clean connectors, etc. and at this point, we're looking for a replacement '8A. So, I need the names of any dealers that might have an 8A available with a bare minimum of options (none, actually). Modules required consist of the CPU, CPU options 1 & 2, and 8K core memory (the application requires *core* memory!). I want to buy the entire box, including the P/S, not just the modules. Any help is greatly appreciated. -- Mark E. Levy LEVY@FNAL.GOV From jones@cs.uiowa.edu Tue Feb 8 13:21:39 EST 1994 Article: 636 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Newsgroups: alt.sys.pdp8,alt.answers,news.answers Subject: PDP-8 Frequently Asked Questions (posted every other month) Followup-To: alt.sys.pdp8 Date: Fri, 8 Feb 94 08:08:08 GMT Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Lines: 987 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 8 Apr 1994 08:08:08 GMT Message-ID: <2j87ug$hnv@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Summary: Answers to common questions about antique DEC PDP-8 computers. Those posting to alt.sys.pdp8 should read this. Keywords: FAQ DEC PDP 8 Xref: bigblue.oit.unc.edu alt.sys.pdp8:636 alt.answers:1708 news.answers:16977 Archive-name: dec-faq/pdp8 Last-modified: Jan 18, 1994 Frequently Asked Questions about the DEC PDP-8 computer. By Douglas Jones, jones@cs.uiowa.edu (with help from many folks) The most recent version of this file is available by anonymous FTP from: rtfm.mit.edu:/pub/usenet/alt.sys.pdp8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc 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 character sets does the PDP-8 support? 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? In 1957, Ken Olson and Harlan Anderson founded Digital Equipment Corporation (DEC), capitalized at $100,000, and 70% owned by American Research and Development Corporation. The founders wanted to call the company Digital Computer Corporation, but the venture capitalists insisted that they avoid the term Computer and hold off on building computers. With facilities in an old woolen mill in Maynard Massachusetts, DEC's first product was a line of transistorized digital "systems modules", plug-in circuit boards with a few logic gates per board. Starting in 1960, DEC finally began to sell computers (the formal acceptance of the first PDP-1 by BBN is reported in Computers and Automation, April 1961, page 8B). Soon after this, there were enough users that DECUS, the Digital Equipment Computer User's Society was founded. DEC's first computer, the PDP-1, sold for only $120,000 at a time when other computers sold for over $1,000,000. (A good photo of a PDP-1 is printed in Computers and Automation, Dec. 1961, page 27). DEC quoted prices as low as $85,000 for minimal models. The venture capitalist's insistance on avoiding the term computer was based on the steriotype that computers were big and expensive, needing a computer center and a large staff; by using the term Programmable Data Processor, or PDP, DEC avoided this stereotype. For over a decade, all digital computers sold by DEC were called PDPs. (In early DEC documentation, plural form "PDPs" is used as a generic term for all DEC computers.) In the early 1960's, DEC was the only manufacturer of large computers without a leasing plan. IBM, Burroughs, CDC and other computer manufacturers leased most of their machines, and many machines were never offered for outright sale. DEC's cash sales approach led to the growth of third party computer leasing companies such as DELOS, a spinoff of BB&N. 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 NA 36 One was built by a customer, not by DEC. PDP-4 1962 $60,000 18 Predecessor of the PDP-7. PDP-5 1963 $27,000 12 The ancestor of the PDP-8. PDP-6 1964 $300,000 36 A big computer; 23 built, most for MIT. PDP-7 1965 $72,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 $110,000 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 are for minimal systems in the year the machine was first introduced. The bits column indicates the word size. Note that the DEC PDP-10 became the DECSYSTEM-20 as a result of marketing considerations, and DEC's VAX series of began as the Virtual Address eXtension of the never-produced PDP-11/78. It is worth mentioning that it is generally accepted that the Data General Nova (see photo, Computers and Automation, Nov. 1968, page 48) 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 perhaps Gordon Bell, who was at C-MU at the time) evaluated the competing designs and rejected both in favor of what we know as the PDP-11. (A less common version of this story is that the reason that DEC never produced a PDP-13 was because the number 13 was assigned to what became the Nova; this is unlikely because the PDP-X prototype came before the PDP-11.) Both DEC and Data General are quiet about these stories. Today, all of the PDP machines are in DEC's corporate past, with the exception of the PDP-11 family of mini and microcomputers. 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, although it is worth noting that the term minicomputer first came into prominence in early 1968. (See Interdata ad, Computers and Automation, May 1968, page 10). The PDP-8 was largely upward compatable with the PDP-5, a machine that was unveiled on August 11, 1963 at WESCON, and the inspiration for that machine came from two earlier machines, the LINC and the CDC 160. All of these machines were characterized by a 12 bit word with no hardware byte structure, a 4K minimum memory configuration, and simple but powerful instruction sets. Although some people consider the CDC 160 the first minicomputer, the PDP-8 was the definitive minicomputer. By late 1973, the PDP-8 family was the best selling computer in the world, and it is likely that it was only displaced from this honor by the Apple II and later, the IBM PC. Most models of the PDP-8 set new records as the least expensive computer on the market at the time of their introduction. 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 has said 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 (see CACM, march 1961, photo on page 244, text on page 246) was such a machine, and in addition to the hundreds of CDC 160 systems sold as stand-alone machines, a derivative 12 bit architecture was used for the I/O processors on Cray's first great supercomputer, the CDC 6600. Note that Cray's 12 bit machines 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 generally as tight as the code on Cray's machines. 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 as indirect addresses. These locations are called auto-index registers (despite the fact that they are in memory); 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 JMS instruction stores the return address in relative word zero of the subroutine, with execution starting with relative word one. Subroutine return is done with an indirect JMP through the return address. Subroutines commonly increment their return addresses to index through inline parameter lists or to perform conditional skips over instructions following the call. The IOT instruction has the following form: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| | | | | | | 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, and these can be microcoded in left to right order. Prior to the PDP-8/E, there were severe restrictions on the interpretation of the op field. As an example of the use of IOT instructions, consider the console terminal interface. On early PDP-8 systems, this was always assumed to be an ASR 33 teletype, complete with low-speed paper tape reader and punch. It was addressed as devices 03 (the keyboard/reader) and 04 (the teleprinter/punch): _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 1 1|0 0 1 - KSF - keyboard skip if flag |0 0 0 0 1 1|0 1 0 - KCC - keyboard clear flag |0 0 0 0 1 1|1 0 0 - KRS - keyboard read static The keyboard flag is set by the arrival of a character. The KCC instruction clears both the flag and the accumulator. KRS ors the 8 bit input data with the low order 8 bits of AC. The commonly used KRB instruction is the or of KCC and KRS. To await one byte of input, use KSF to poll the flag, then read it with KRB. _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 1 0 0|0 0 1 - TSF - teleprinter skip if flag |0 0 0 1 0 0|0 1 0 - TCF - teleprinter clear flag |0 0 0 1 0 0|1 0 0 - TPC - teleprinter print static The teleprinter flag is set by the completion of the TPC operation (as a result, on startup, many applications use TPC to print a null in order to get things going). TCF clears the flag, and TPC outputs the low order 8 bits of the accumulator. The commonly used TLS instruction is the or of TCF and TPC. To output a character, first use TSF to poll the flag, then write the character with TLS. 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: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 0 0|0 0 1 - ION - interrupts turn on |0 0 0 0 0 0|0 1 0 - IOF - interrupts turn off An interrupt was requested when any device raised its flag. The console master clear switch would reset all flags and disable interrupts. Effectively, an interrupt is a JMS instruction to location zero, with the side effect of disabling interrupts. The interrupt service routine would test flags and perform the operations needed to reset them, and then return using ION immediately before the indirect return JMP. The effect of ION is delayed so that interrupts are not enabled until after the JMP. The instructions controlling the optional memory management unit are also IOT instructions. This unit allows the program to address up to 23K of main memory by adding a 3 bit extension to the memory address. Two extensions are available, one for instruction fetch and direct addressing, the other for indirect addressing. 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? There are many different assemblers for the PDP-8, but most use a compatable basic syntax; 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. 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 most assemblers provide a notation 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. Note that the variants "(3" and "[5" (with no closing parentheses) are usually allowed but the use of this sloppy form is discouraged. Furthermore, the widely used PAL8 assembler interprets "(3)+1" as being the same as "(3+1)". Arithmetic is allowed in operand fields and constant definitions, with expressions evaluated in strict left-to-right order, as: 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, PAL8, has trouble when unary operators are mixed with multiplication or division. Generally, only the first 6 characters of identifiers are significant and numeric constants are evaluated in octal. 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. The $, * and = syntax used by most PDP-8 assemblers replace functions performed by pseudo-operations on many other assemblers. In addition, PAL8, the most widely used PDP-8 assembler supports the following pseudo-operations: DECIMAL / Interpret numeric constants in base 10 OCTAL / Interpret numeric constants in base 8 EJECT / Force a page eject in the listing XLIST / toggle listing PAGE / Advance location counter to next page FIELD N / Assemble into extended memory field N TEXT STRING / Pack STRING into consecutive 6 bit bytes ZBLOCK N / Allocate N words, initialized to zero IFDEF S / Assemble C if symbol S is defined IFNDEF S / Assemble C if symbol S is not defined IFZERO E / Assemble C if expression E is zero IFNZRO E / Assemble C if expression E is not zero Conditonally assembled code must be enclosed in angle brackets. The conditionally assembled code may extend over multiple lines. What character sets does the PDP-8 support? With its 12 bit word, the PDP-8 is somewhat awkward in its support for modern 7 and 8 bit character sets. Nonetheless, from the beginning, PDP-8 software has generally assumed that text I/O would be in 7 bit ASCII. Most early PDP-8 systems used teletypes as console terminals; as sold by DEC, these were configured for mark parity, so most older software assumes 7 bit ASCII, upper case only, with the 8th bit set to 1. On output, lines are generally terminated with both CR and LF; on input, CR is typically (but not always) the line terminator and LF is typically ignored. In addition, the tab character (HT) is generally interpreted in terms of a tab-stop every 8 spaces. Most of the better engineered PDP-8 software tends to fold upper and lower case on input, and it ignores the setting of the 8th bit. Internally, PDP-8 programmers are free to use other character sets, but the TEXT pseudo-operation strongly encourages the 6 bit character set called "stripped ASCII". To map from upper-case-only ASCII to stripped ASCII, each 8 bit character is anded with octal 77 and then packed 2 characters per word, left to right. Many programs use a semi-standardized scheme for packing mixed upper and lower case into 6 bit TEXT form; this uses ^ to flip from upper to lower case or lower to upper case, % to encode CR-LF pairs, and @ (octal 00) to mark end of string. Note that this scheme makes no provision for encoding the %, ^ and @ characters, nor does it allow control characters other than the CR-LF pair. Files under the widely used OS/8 system consist of sequences of 256 word blocks. When used for text, each block holds 384 bytes, packed 3 bytes per pair of words as follows: aaaaaaaa ccccaaaaaaaa bbbbbbbb CCCCbbbbbbbb ccccCCCC Control Z is used as an end of file marker. Because most of the PDP-8 system software was originally developed for paper tape, binary object code is typically stored in paper-tape image form using the above packing scheme. What different PDP-8 models were made? The total sales figure for the PDP-8 family is estimated at over 300,000 machines. Over 7000 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-67 116 Transistor PDP-8 65-69 1450 $18,500 Transistor LINC-8 66-69 142 $38,500 Transistor PDP-8/S 66-70 1024 $10,000 Transistor PDP-8/I 68-71 3698 $12,800 TTL PDP-8/L 68-71 3902 $8,500 TTL Scaled down 8/I PDP-12 69-73? 3500? $27,900 TTL Followup to LINC-8 PDP-8/E 70-78 >10K? $7,390 TTL MSI Omnibus 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 78-80 <$10K Intersil IM6100 Dm I 80-84 Harris 6120 Dm II 82-86 $1,435 Harris 6120 Dm III 84-90 $2,695 Harris 6120 Dm III+ 85-90 Harris 6120 Additional information is available in part two of this FAQ, where all known models of the PDP-8, along with variants, alternate marketing names, and other peculiarities are given. The last years of the PDP-8 family were dominated by the PDP-8 compatable microprocessor based VT78 and DECmate (Dm in the above table) machines. DEC also used the Intersil IM6100 and Harris 6120 microprocessors in many peripheral controllers for the PDP-11 and PDP-15. While all of the earlier PDP-8 systems were open architecture systems, the DECmates had closed architectures with an integrated console terminals and limited peripheral options. 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 (a surviving example runs FOCAL). TPA 68? Hungarian, a PDP-8/L clone, ran FOKAL Electrotechnica-100I ? Russian, a PDP-8/I? clone. Saratov-2 ? Russian, a slow clone, perhaps PDP-8/S Voronezh ? Russian, another PDP-8/? clone SPEAR u-LINC ? SPEAR, Inc, Waltham Mass. DCC-112 70-71 Digital Computer Controls DCC-112H 71 Digital Computer Controls 6100 Sampler 7? Intersil, their IM6100 promotional kit Intercept I 7? Intersil, based on IM6100 Intercept Jr 7? Intersil, based on IM6100 PCM-12 7? Pacific CyberMetrix, based on Intercept bus PCM-12A 7? Pacific CyberMetrix, fixed to clock at 4MHz 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. Over 24 LINC systems were built by customers before late 1964 when DEC began selling a commercial version (see Computers and Automation, Nov. 1964, page 43). By the time DEC introduced the LINC-8, 43 LINC systems had been installed (see Computers and Automation, Mar. 1966, page 34). 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 the first 12 bit minicomputer built using DEC hardware. Like the PDP-5 and other early DEC computers, it was built with system modules, DEC's first family of logic modules. 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. The motives behind the development of LINCtape were the same motivives that led IBM to develop the floppy disk almost a decade later, and in fact, DECtape survived as a widely used medium until DEC introduced the RX01 8 inch floppy disk drive around 1975. 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. The 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 to be called the LINC-8/I, but it was sold as the PDP-12. Both the LINC-8 and the PDP-12 had impressive consoles, with separate sets of lights and switches for the LINC and PDP-8 halves. The success of the LINC-8 also led to the development of a clone, the SPEAR micro-LINC. This machine used Motorola MECL integrated circuits and was available for delivery in (June 1965? this date must be wrong!). The LINC-8 and PDP-12 could run essentially any PDP-8 or LINC program, but because they had instructions for switching between modes, a body of software was developed that required both modes. 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. LAP6-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. After about 1976, Reuters bought as many as 10,000 OMNIBUS based machines per year, with perhaps 2000 per year going to other customers. 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. 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? Part II of this FAQ cites the key documents published by DEC describing each model of the PDP-8. These are all 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 out. Douglas Jones has made a small number of bound photocopies of DEC's 1973 introduction to programming, perhaps the definitive introduction to the PDP-8, and the other early DEC handbooks need similar treatment before they all crumble. Maintenance manuals are harder to find, but more valuable. If you need one, you usually need to find someone willing to photocopy one of the few surviving copies. 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, was 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 was a BASIC only system submitted to DECUS and later sold by DEC as part of its EduSystem marketing program. P?S/8 was developed starting in 1971 from an MS/8 foundation. It runs on minimal PDP-8 configurations, supports somewhat device independant I/O and requires a random-access device for the file system (DECtape is random-access!). 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 typically supported 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 supported addressing of more than 4K for data, but limited code to 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. RTS/8 was a real-time system developed by DEC and shipped around 1978. Curiously, for a system developed so late, paper-tape and DECtape were still supported by this system. WPS was DEC's word processing system, developed on the 8/E and widely used on the 1980's vintage machines with a special WPS keycaps replacing the standard keycaps on the keyboard. It was heavily promoted on the VT-78, and when the DECmates came out, DEC began to suppress knowledge that DECmates could run anything else. WPS-11 was a curious distributed system using a PDP-11 as a file server for a cluster of VT-78 WPS 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 almost the same as OS/8, but dates are recorded differently, and a few applications can even run under both COS and OS/8. COS was the last operating system other than WPS promoted by DEC for the DECmates. What programming languages are supported on the PDP-8 The PAL family of assembly languages, particularly PAL III and PAL8 are as close to a standard assembly language as can be found for the PDP-8. These produce absolute object code and there are versions of PAL for minimally configured machines, although these have sever symbol table limitations. MACRO-8 was DEC's first macro assembly language for the PDP-8, but it was rarely used outside the paper-tape environment. 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. Many versions of BASIC were also available, from DEC and other sources. DEC BASIC was widely used on PDP-8 systems sold under the EduSystem marketing program. A paper-tape version was available that ran in 4K, versions for OS/8 and TSS/8, an 8K stand-alone time-sharing version, and 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. POLY SNOBOL was a version of SNOBOL that was somewhere between Griswald's definitions of SNOBOL 3 and SNOBOL 4. 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 PAL8 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. The following anonymous FTP sites contain publically accessable archives of PDP-8 software and other information: ftp.telebit.com:/pub/pdp8 ftp.update.uu.se:/pub/pdp8 nickel.ucs.indiana.edu:/pub/DEC/PDP8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8. The latter archive also maintains an archive of traffic in alt.sys.pdp8 in the directory ...pdp8/usenet. The archive at Indiana contains source code for many PDP-8 compilers and interpreters, as well as common utilities and games. 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 telebit.com archive cited above. This file gives details of every PDP-8 model 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 needs to be gatewayed to this mailing list. 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 accurate and complete (but difficult to read). 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 make much practical use of it. 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, have built 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 was 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 guru, hacked up the PAL III assembler for the -8, based on PAL II. Richard Merrill invented FOCAL and wrote the original (1968) and classic FOCAL-69 interpreters for the PDP-8. Charles Lasner developed P?S/8, and he is widely known as the grand old man of the movement to preserve these historic machines. Wesley Clark developed the LINC while working at Lincoln Labs; this was the first 12 bit minicomputer built with DEC parts. Mary Allen Wilkes Clark developed the early LAP programs for the LINC. Douglas W. Jones wrote this FAQ, but prior to the summer of 1992, he'd never used a PDP-8. He has also written a report on how to photocopy and archivally bind ailing paperback books such as DEC's handouts, a PAL-like cross assembler in C, and a UNIX-based PDP-8 emulator. From jones@cs.uiowa.edu Tue Feb 8 13:22:57 EST 1994 Article: 637 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!overload.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Newsgroups: alt.sys.pdp8,alt.answers,news.answers Subject: PDP-8 Summary of Models and Options (posted every other month) Followup-To: alt.sys.pdp8 Date: Tue, 8 Feb 94 08:08:08 GMT Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Lines: 1203 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 8 Apr 1994 08:08:08 GMT Message-ID: <2j882t$hpm@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Summary: Descriptions of all models of the DEC PDP-8 computer. Those posting to alt.sys.pdp8 should read this. Keywords: FAQ DEC PDP 8 Xref: bigblue.oit.unc.edu alt.sys.pdp8:637 alt.answers:1715 news.answers:16984 Archive-name: dec-faq/pdp8-models Last-modified: Jan 10, 1994 Frequently Asked Questions about DEC PDP-8 models and options. 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/alt.sys.pdp8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc Contents What is this FAQ? What is a PDP-5? What is a PDP-8? What is a LINC-8? What is a PDP-8/S? What is a PDP-8/I? What is a PDP-8/L? What is a PDP-12? What is a PDP-8/E? What is a PDP-8/F? What is a PDP-8/M? What is a PDP-8/A? What is a VT78? What is a DECmate I? What is a DECmate II? What is a DECmate III? What is a DECmate III+? What is this FAQ? The purpose of this document is to supplement the material in the primary "Frequently Asked Questions about the PDP-8" file with more detailed information about the hardware and options of the different models of the PDP-8 sold by DEC. Although this document is something of a history of the DEC PDP-8 family, the primary purpose of this document is as a guide and general outline to the PDP-8 models and options likely to be encountered by those involved in collecting and restoring systems. What is a PDP-5? Date of introduction: Aug 11, 1963, unveiled at WESCON. Date of withdrawal: early 1967. Price: $27,000 Technology: Built with DEC System Modules, the original line of transistorized logic modules sold by DEC. Supply voltages of +10 and -15 volts; the logic levels -3 (logic 1) and 0 (logic 0). Logic packaged on boards that were about 4.75 inches wide with each card mounted in a metal frame with a 22 pin edge connector. Input output devices were connected to the daisy-chained I/O bus using military-style armored cables and connectors. Use of toggle switches (as opposed to slide switches) on the front panel was another vestige of military-style design. Reason for introduction: This machine was inspired by the success of the CDC-160, Seymour Cray's 12 bit minicomputer, and by the success of the LINC, a machine that was built by DEC customers out of System modules. These demonstrated that there was a market for a small inexpensive computer, and from the start, DEC's advertisements were aimed at this market. "Now you can own the PDP-5 computer for what a core memory alone used to cost: $27,000", ran one 1964 ad. Reason for withdrawal: The PDP-8 outperformed the PDP-5, and did so for a lower price. Compatability: The core of the PDP-8 instruction set is present, but memory location zero is the program counter, and interrupts are handled differently. The Group 1 OPR rotate instructions cannot be combined with IAC or CMA; this limits the ability of the PDP-5 to support code from later models. The machine did not support 3 cycle data-break (DMA transfers using memory to hold buffer address and word-count information), so many later PDP-8 peripherals could not be used on the PDP-5. In addition, DMA transfers are not allowed outside the program's current 4K data field, severely limiting software compatability on systems with over 4K of memory where either interrupts or software initiated changes to the data field during a transfer would cause chaos. Standard configuration: CPU with 1K or 4K of memory (2K and 3K versions were not available). Peripherals: An extended arithmetic element (EAE) was available; this was an I/O device, using IOT instructions to evoke EAE operations. As a result, it was not compatable with the later PDP-8 EAEs. In addition, machines with the EAE option had a different front panel from those without. The type 552 DECtape control and type 555 DECtape transports were originally developed for the PDP-5. After the PDP-8 was introduced, DEC offered a bus converter that allowed the PDP-5 to support standard PDP-8 negibus peripherals, so long as they avoided using 3-cycle data break transfers. The standard 804 PDP-8 expander box was frequently sold as an upgrade to PDP-5 systems. What is a PDP-8? Date of introduction: 1965 (Unveiled March 22, in New York) Date of withdrawal: 1968. Also known as: Classic PDP-8 (to point out lack of a model suffix) Straight-8 (Again, points out the lack of a model suffix) PCP-88, an OEM label, used Foxboro Corporation. Price: $18500 Technology: Mostly DEC R-series logic modules; these were originally discrete component transistor logic, but around the time the PDP-8 was introduced, DEC introduced the Flip Chip, a hybrid diode/resistor "integrated circuit" on a ceramic substrate. These could directly replace discrete components on the PC boards, and DEC began to refer to their R-series modules as flip-chip modules and they even advertised the PDP-8 as an integrated circuit computer. A typical flip-chip module, the R111, had three 2-input nand gates and cost $14, with no price change from 1965 to 1970. S-series logic modules were also used; these are essentially the same as their R-series cousins, but with different pull-up resistors for higher speed at lower fanout. Many R and S series modules have trimmers that must be tuned to the context, making replacement of such modules more complex than a simple board swap. As with the system modules used in the PDP-5, the supply voltages were +10 and -15 volts and the logic levels were -3 (logic 1) and 0 (logic 0). Logic was packaged on boards that were 2.5 inches wide by 5 inches high. The card edge connector had 18 contacts on 1/8 inch centers. Some double width cards were used; these had two card edge connectors and were 5 1/8 inches wide. Machine wrapped wire-wrap technology was used on the backplane using 24-gauge wire. The "negibus" or negative logic I/O bus used -3 and 0 volt logic levels in 92 ohm coaxial cable, with 9 coaxial cables bundled per connector card and 6 bundles making up the basic bus. 4 (originally 5) more bundles were required to support data-break (DMA) transfers. Bus termination was generally kluged in with 100 ohm resistors clipped or wrapped into the backplane, although a bus terminator card was occasionally used. Some time after the first year of production, flat ribbon cable made of multiple coaxial cables was used, and later still, flat mylar stripline cable was used (but never recommended because it lacked necessary shielding). Core memory was used, with a 1.5 microsecond cycle time, giving the machine an add time of 3 microseconds. 4K of core occupied an aluminum box 6 inches on a side and needed numerous auxiliary flip-chips for support. It is worth noting that the PDP-8 was about as fast as was practical with the logic technology used; only by using tricks like memory interleaving or pipelining could the machine have been made much faster. Reason for introduction: This machine was inspired by the success of the PDP-5 and by the realization that, with their new Flip-Chip technology, DEC could make a table-top computer that could be powered by a single standard wall outlet; of course, adding any peripherals quickly increased the power requirement! Reason for withdrawal: The PDP-8/I was less expensive, and after initial production difficulties, it equalled the performance of the PDP-8. Compatability: The core of the PDP-8 instruction set is present, but the Group 1 OPR instruction IAC cannot be combined with any of the rotate instructions. If RAR and RAL or RTR and RTL are combined, the results are unpredictable (simultaneous set and reset of bits of AC results in metastable behavior). The IOT 0 instruction was used for the internal type 189 ADC, and not for the later CAF (clear all flags) instruction. As a result, if the ADC option was not present, IOT 6004 (or microcoded variants) would hang the machine. If the extended arithmetic element is present, the SWP (exchange AC and MQ) instruction does not work. This works on later models when the EAE is present, although it was only documented with the introduction of the PDP-8/E. Finally, the EAE lacks the SCL (shift count load) instruction that is present on later models. On machines with 8K or more, an attempt to change the data field to a non-existant field caused a bizarre double- indirect and skip instruction execution that must be accounted for in memory diagnostics. Standard configuration: The PDP-8 was sold as a CPU with 4K of memory, a 110 baud current loop teletype interface and an ASR 33 Teletype. In addition, the standard in-cabinet logic includes support for the full negibus interface, including data-break (DMA) transfers. Both a rack-mount model with rosewood trim and an elegant plexiglass enclosed table-top configuration were standard. Under the skin, basic machine occupied a volume 33 inches high by 19 inches wide by 22 inches deep. The two halves of the backplane were mounted vertically, like the covers of a book, with the spine in back and circuit modules inserted from the two sides. Sliding the CPU out of the relay rack or removing the plexiglass covers allows the backplane to swung open for access to the wires. Expandability: In-cabinet options include the type 182 extended arithmetic element (EAE), the type 183 memory extension control subsystem, and the type 189 low performance analog to digital converter (ADC). Prewired backplane slots were reserved for all of these. Expansion beyond 4K of memory requires rack space for the rack-mounted type 184 memory module; each such module adds one 4K field of memory, up to a maximum of 32K. The rack-mount CPU occupied a large part of one rack, allowing room for a single type 184 memory expansion module below the CPU; generally, a second rack was needed for added peripherals or memory. At the end of the production run, some PDP-8 systems were sold with PDP-8/I memory, allowing room for an additional 4K without need for an expansion chassis. These nonstandard machines were very difficult to maintain! Peripherals: At the time of introduction, the following negibus peripherals were offered. -- Type 750C high speed paper tape reader and control. -- Type 75E high speed paper tape punch and control. -- Type 138E analog to digital converter and multiplexor. -- Type 34D oscilloscope display (dual digital to analog). -- Type 350B incremental (CalComp) plotter control. -- Type 451 card reader and control. -- Type 450 card punch control for IBM Type 523 punch. -- Type 64 (later 645) Mohawk line printer and control. -- Type RM08 serial magnetic drum system (up to 256K words). -- Type 552 DECtape control (for type 555 DECtape drives). -- Type 57A magnetic tape control (IBM type 729 drive). -- Type 580 magnetic tape system. By 1967, the following peripherals had been added to the line: -- Type TC01 DECtape control for up to 8 TU55 transports. -- Type AF01 analog to digital converter and multiplexor. -- Type AA01A 3 channel digital to analog (scope display). -- Type AX08 parallel digital input port. -- Type 338 Programmed Buffered Display (vector graphics). By 1968, the following new peripheral had been added: -- Type DF32 fixed head disk system (up to 256K words). -- Type BE01 OEM version of the TC01 (no blinking lights). -- Type BE03 dual TU55 drive for the TC01 or BE01. Finally, as DEC abandoned the negibus, they introduced the DW08B negibus to posibus converter so newer posibus peripherals could be used on older negibus machines. What is a LINC-8? Date of introduction: 1966 (during or before March) Date of withdrawal: 1969 (displaced by PDP-12) Price: $38,500 Technology: DEC Flip Chip modules, as in the PDP-8, with a LINC CPU partially reimplemented in Flip Chips and partially emulated with PDP-8 instructions. (The original LINC was built from the same System Modules used in the PDP-5.) Compatability: Identical to the PDP-8. Standard configuration: The combined PDP-8/LINC CPU, plus 4K of memory was central to the system. The set of peripherals bundled with the machine was impressive: -- An ASR 33 Teletype modified for the LINC character set. -- Two LINCtape drives. -- 8 analog to digital converter channels with knob inputs. -- Another 8 ADC channels with jack inputs. -- 6 programmable relay outputs, good up to 60 Hz. -- 1 Tektronix 560 oscilliscope, somewhat modified. The X and Y axis control for the scope came from DACs attached to the LINC's AC and MB registers, respectively. Expandability: In addition to standard PDP-8 peripherals, up to 3 additional pairs of LINCtape drives could be added, for a total of 8 drives. Each pair of drives cosmetically resembled the type BE03 dual DECtape transport, but single drives were not available. Up to 2 additional ranks of 8 ADC channels could be added. A second oscilliscope could be added. What is a PDP-8/S? Date of introduction: 1966 (Unveiled, Aug 23, WESCON, Los Angeles). Date of withdrawal: 1970. Price: $10,000 Technology: DEC Flip Chip modules and core memory, as in the PDP-8. Unlike the PDP-8, the PDP-8/S memory was mounted on quad-height single-width boards that plugged into the standard flip-chip sockets. Reason for introduction: This machine was developed as a successful exercise in minimizing the cost of the machine. It was the least expensive general purpose computer made with second generation (discrete transistor) technology, and it was one of the smallest such machines to be mass produced (a number of smaller machines were made for aerospace applications). It was also incredibly slow, with a 36 microsecond add time, and some instructions taking as much as 78 microseconds. By 1967, DEC took the then unusual step of offering this machine for off the shelf delivery, with one machine stocked in each field office available for retail sale. Reason for withdrawal: The PDP-8/L vastly outperformed the PDP-8/S, and it did so at a lower price. Compatability: The core of the PDP-8 instruction set is present, but there are a sufficient number of incompatabilities that, as with the PDP-5, many otherwise portable "family of 8" programs will not run on the PDP-8/S. Perhaps the worst incompatability is that the Group 1 OPR instruction CMA cannot be combined with any of the rotate instructions; as with the PDP-8, IAC also cannot be combined with rotate. Standard configuration: CPU with 4K of memory, plus PT08 110 baud current loop teletype interface and teletype. Both a rack-mount table-top versions were sold (both 9" high by 19" wide by 20"? deep). The rack mount could be slid out of the rack on slides for for maintenance. Expandability: The CPU supported the standard PDP-8 negibus, but I/O bandwidth was 1/5 that of the PDP-8. Thus, most, but not all PDP-8 peripherals could be used. A few DEC peripherals such as the DF32 came with special options such as interleaving to slow them down for compatability with the PDP-8/S. The speed problems were such that there was never any way to attach DECtape to this machine. What is a PDP-8/I? Date of introduction: 1968 (announced before December '67) Date of withdrawal: 1971. Technology: DEC M-series logic modules, called M-series flip-chips as the term flip-chip was applied to the module format instead of to DEC's hybrid integrated circuits. M-series modules used TTL chips, with a +5 supply, packaged on the same format board as was used with the original flip-chips, but with double-sided card-edge connectors (36 contacts instead of 18). Modules were limited to typically 4 SSI ICs each. The M113, a typical M-series module, had 10 2-input nand gates and cost $23 in 1967 (the price fell to $18 in 1970). Wire-wrapped backplanes used 30-gauge wire. The PDP-8/I, as originally sold, supported the then-standard PDP-8 negibus. 4K words of core were packaged in a 1 inch thick module made of 5 rigidly connected 5 by 5 inch two-sided printed circuit boards. Connectors and support electronics occupied an additional 32 backplane slots. Nominally, the core memory (which, curiously, used a negative logic interface!) was supposed to run at a 1.5 microsecond cycle time, but many early PDP-8/I systems were delivered running at a slower rate because of memory quality problems. DEC went through many vendors in the search for good memory! The memory interface was asynchronous, allowing the CPU to delay for slow memory. DEC continued to make the classic PDP-8 until the problems with memory speed were solved. Reason for introduction: This machine was developed in response to the introduction of DIP component packaging of TTL integrated circuits. This allowed a machine of about the same performance as the original PDP-8 to fit in about half the volume and sell for a lower price. Reason for withdrawal: The PDP-8/E made slight performance improvements while undercutting the price of the PDP-8/I. Compatability: The core of the PDP-8 instruction set is present, and unlike the original PDP-8, IAC can be combined with rotate in a single microcoded Group 1 OPR instruction. Combined RAR and RAL or RTR and RTL produce the logical and of the expected results from each of the combined shifts. If the extended arithmetic element is present, the SWP (exchange AC and MQ) instruction works, but this was not documented. On large memory configurations, memory fetches from a nonexistant memory field take about 30 microseconds (waiting for a bus timeout) and then they return either 0000 or 7777 depending on whether the fetch was from an even or odd field. Standard configuration: CPU with 4K of memory, plus 110 baud current loop teletype interface. Pedestal, rack-mount and table-top versions were made. In the pedestal version, the logic filled the body of the pedestal, with the console lights and switches on top. In one rack-mount version, the machine was built on a backplane that was bolted to the back of the rack, while the front panel hung from the front (unlike all other rack-mounted PDP-8 models, this version could not be swung out for maintenance on chassis slides). Finally, a boxed version was sold that could be used on table-top or mounted on chassis slides. Expandability: 4K of memory could be added internally, and additional memory could be added externally using a rack-mounted MM8I memory expansion module for each 4K or 8K addition over 8K. The backplane of the PDP-8/I was prewired to hold a Calcomp plotter interface, with the adjacent backplane slot reserved for the cable connection to the plotter. Initially, the CPU was sold with bus drivers for the PDP-8 negibus, allowing this machine to support all older DEC peripherals, but later machines were sold with posibus interfaces, and DEC made an effort to convert earlier machines to the posibus in the field. A posibus to negibus converter, the DW08A, allowed use of all older PDP-8 peripherals, with small modifications. The change from negibus to posibus during the period of PDP-8/I production leads to confusion because surviving systems may have any of three I/O bus configurations: Negibus, early posibus, or final posibus. The early posibus used the same connectors and cables as the negibus, with only 9 conductors per connector, while the final posibus used both sides of the connector paddles, for 18 bus lines per connector. To add to this confusion, some negibus PDP-8/I systems were rewired to use 18 conductor posibus cables while still using negative logic! Eventually, an add-on box was sold that allowed PDP-8/E (OMNIBUS) memory to be added to a PDP-8/I. Additionally, Fabritek sold a 24K memory box for the 8/I. What is a PDP-8/L? Date of introduction: 1968 (announced before August '68) Date of withdrawal: 1971. Price: $8,500 Technology: DEC M-series flip Chip modules, as in the PDP-8/I, with the same core memory as the 8/I, but the memory cycle cycle time was downgraded to 1.6 microseconds to avoid the speed problems of the -8/I. The positive I/O bus, or posibus, was a 100 ohm bus clamped between 0 and 3 volts with TTL drivers and receivers. This was packaged with 18 signal lines per 2-sided interconnect cable, using mylar ribbon cable in most cases. Electrically, coaxial cable could be used, but the slots in the CPU box were too small to allow convenient use of this option. Reason for introduction: This machine was developed as a moderately successful exercise using M-series logic to produce a lower cost but moderately fast machine. The idea was to cut costs by limiting provisions for expansion. Reason for withdrawal: The PDP-8/E made performance improvements while slightly undercutting the price of the PDP-8/L. Compatability: The core of the PDP-8 instruction set is present, but all Group 3 OPR instructions are no-ops, even the Group 3 version of the CLA instruction. This is because there was no provision made for adding an EAE to this machine. Microcoding RAR and RAL together works as in the PDP-8/I. Finally, a new front panel feature was added, the protect switch. When thrown, this makes the last page of the last field of memory read-only (to protect your bootstrap code). The instruction to change the data field on an 8/L becomes a no-op when the destination data field is non-existant; on all other machines, attempts to address non-existant fields are possible. One option for expanding the 8/L was to add a box that allowed 8/E memory modules to be added to the 8/L; when this was done, access to nonexistant data fields becomes possible and always returns 0000 on read. Standard configuration: A CPU with 4K of memory, plus 110 baud current loop teletype interface was standard. Both rack-mount and table-top versions were sold (both 9" high by 19" wide by 21" deep). The backplane was on top, with modules plugged in from the bottom. The rack-mount version could be slid out for maintenance. Expandability: The CPU supported a new bus standard, the PDP-8 posibus. There is little space for in-box peripherals, but an expander box with the same volume as the CPU was available, the BA08A; this was prewired to hold an additional 4K of memory and to support in-box peripheral interfaces for such devices as the PDP-8/I Calcomp plotter interface. DEC eventually offered the BM12L, an 8K expansion box, allowing 12K total memory on a PDP-8/L. Curiously, this contains precisely the modules needed to upgrade a 4K PDP-8/I or PDP-12 to an 8K machine, or to populate an MM8I box to add 8K of additional memory to an 8/I or PDP-12. Finally, DEC eventually offered a box allowing PDP-8/E (OMNIBUS) memory to be used with the PDP-8/L. PDP-8/L configurations with over 8K of memory were awkward because the front panel only showed one bit of the extended memory address. As a result, extra lights and switches for the additional bits of the memory address were mounted on the front of the memory expander boxes for the large configurations. A variety of posibus peripherals were introduced, most of which were built with the option of negibus interface logic (the -P and -N suffixes on these new peripherals indicated which was which). Many early PDP-8/L systems were sold with DW08A bus level converters to run old negibus peripherals. Posibus peripherals introduced after the PDP-8/L (and also used with posibus versions of the PDP-8/I) included: -- The TC08P DECtape controller (for 8 TU55 or 4 TU56). -- The DF32D-P fixed head disk controller (a posibus DF32). -- The FPP-12 floating point processor. -- The TR02 simple magnetic tape control. -- The RK08 disk subsystem, 4 disk packs, 831,488 words each. What is a PDP-12? Date of introduction: 1969 (February or earlier). Date of withdrawal: 1973. Price: $27,900 Technology: DEC M-series flip Chip modules, as in the PDP-8/I. Reason for introduction: This machine was developed as a follow-up to the LINC-8. Originally it was to be called the LINC-8/I, but somehow it got its own number. In effect, it was a PDP-8/I with added logic to allow it to execute most of the LINC instruction set, with trapping and software emulation used more selective than on the LINC-8. Reason for withdrawal: The LAB-8/E and the LAB-11 (a PDP-8/E and a PDP-11/20 with lab peripherals) eventually proved the equal of the PDP-12 in practice, and LINC compatability eventually proved to be of insufficient value to keep the machine alive in the marketplace. Compatability: This machine is fully compatable with the PDP-8/I, with additional instructions to flip from PDP-8 mode to LINC mode and back. IOT 0 could enable the API, causing trouble with later PDP-8 code that assumes IOT 0 is "Clear all flags". Also, the DECtape instruction DTLA (6766) becomes part of a stack-oriented extension to the instruction set, PUSHJ, on late model (or field updated) machines with the KF12-B backplane. Standard configuration: PDP-8/LINC CPU with 4K of memory, plus 110 baud current loop interface, plus output relay registers. In addition, the standard configuration included either two TU55 or one TU56 drive, with a PDP-12 only controller allowing it to handle LINCtape. In additoon, a 12" scope was always included, with a connector that can connect to a second scope. Expandability: An analog to digital converter and multiplexor was needed to fully support knob-oriented LINC software. Other options included: -- the KW12 programmable lab clock. -- additional TU55 or TU56 drives (up to 8 transports). -- the PRTC12F option to allow DECtape as well as LINCtape. -- the PC05 paper tape reader punch. What is a PDP-8/E? Date of introduction: 1970 (during or before August). Date of withdrawal: 1978. Also known as: Industrial-8 (with a red color scheme) LAB-8/E (with a green color scheme) Price: $7,390 Technology: Nominally made from DEC M-series flip Chip modules, but in a new format, quad-wide (10.5 inches wide), double- height (9 inches, including card-edge connector, excluding handles). SSI and MSI TTL logic were used on these boards, and the entire CPU fit on 3 boards. Interconnection between boards was through a new bus, the OMNIBUS. This eliminated the need for a wire-wrapped backplane, since all slots in the bus were wired identically. A new line of peripheral interfaces was produced, most being single cards that could be plugged directly into the inside the main enclosure. These included a set of posibus adapters allowing use of older peripherals on the new machine. Interboard connectors were needed for some multiboard options, including the CPU and memory subsystems. These used standard 36 pin backplane connectors on the opposite side of the board from the backplane. Some boards, notably memory boards, had a total of 8 connector fingers, 4 for the omnibus and 4 for interboard connectors. The core memory cycle time was 1.2 or 1.4 microseconds, depending on whether a read-modify-write cycle was involved. A 4K core plane was packaged on a single quad-wide double- high board, with most of the drive electronics packed onto two adjacent boards. Soon after the machine was introduced, an 8K core plane was released in the same format. Reason for introduction: The cost of the PDP-8/I and PDP-8/L was dominated by the cost of the interconnect wiring, and this cost was a result of the use of small circuit boards. By packing a larger number of chips per board, similar function could be attained in a smaller volume because less interboard communication was required. The PDP-8/E exploited this to achieve a new low in cost while attaining a new high in performance. Reason for withdrawal: This machine was slowly displaced by the PDP-8/A as the market for large PDP-8 configurations declined in the face of pressure from 16 bit mini and microcomputers. Compatability: As with the PDP-8/I and PDP-8/L, there are no limits on the combination of IAC and rotate instructions. Unlike the early machines, basic Group 3 OPR operations for loading and storing the MQ register work even if there is no extended arithmetic element. Finally, a new instruction was added, BSW; this swaps the left and right bytes in AC, and is encoded as a Group 1 OPR instruction using the "double the shift count bit". An odd quirk of this machine is that the RAL RAR combination ands the AC with the op-code, and the RTR RTL combination does an effective address computation loading the high 5 bits of AC with the current page and the lower bits of AC with the address field of the OPR instruction! The EAE has a new mode, mode B. Previous EAE designs were single-mode. Mode B supports a large set of 24 bit operations and a somewhat more rational set of shift operations than the standard EAE. All prior EAE designs would hang on the microcoded CLA NMI (clear/normalize) instruction applied to a nonzero AC. This instruction is redefined to be a mode changing instruction on the 8/E. Standard configuration: A CPU with 4K of memory, plus 110 baud current loop teletype interface. Both a rack-mount table-top versions were sold (both 9" high by 19" wide by 21" deep). The rack mount version was mounted on slides for easy maintenance. The OMNIBUS backplane was on the bottom, with boards inserted from the top. The standard OMNIBUS backplane had 20 slots, with no fixed assignments, but the following conventional uses: -- KC8E programmer's console (lights and switches) -- M8300 \_ KK8E CPU registers -- M8310 / KK8E CPU control -- -- -- M833 - Timing board (system clock) -- M865 - KL8E console terminal interface. -- -- -- -- space for more peripherals -- -- -- M849 - shield to isolate memory from CPU -- G104 \ -- H220 > MM8E 4K memory -- G227 / -- -- -- space for more memory -- -- M8320 - KK8E Bus terminator Most of the early boards with 3 digit numbers were defective in one way or another, and the corrected boards added a trailing zero. Thus, the M833 was generally replaced with an M8330, and the M865 was replaced with the M8650. Expandability: The following are among the OMNIBUS boards that could be added internally: -- M8650 - KL8E RS232 or current loop serial interface. -- M8340 \_ Extended arithmetic element. -- M8341 / (must be attached in two slots adjacent to CPU. -- M8350 - KA8E posibus interface (excluding DMA transfers). -- M8360 - KD8E data break interface (one per DMA device). -- M837 - KM8E memory extension control (needed for over 4K). -- M840 - PC8E high speed paper tape reader-punch interface. -- M842 - XY8E X/Y plotter control. -- M843 - CR8E card reader interface. There were many other internal options. There was room in the basic box for another 20 slot backplane; taking into account the 2 slots occupied by the M935 bridge between the two backplanes, this allowed 38 slots, and a second box could be added to accomodate another 38 slot backplane, bridged to the first box by a pair of BC08H OMNIBUS extension cables. Given a M837 memory extension control, additional memory could be added in increments of 4K by adding G104, H220, G227 triplets. The suggested arrangement of boards on the OMNIBUS always maintained the M849 shield between memory other options. The one exception was that the M8350 KA8E and M8360 KD8E external posibus interfaces were typically placed at the end of the OMNIBUS right before the terminator. The following options were introduced later, and there were many options offered by third party suppliers. -- G111 \ -- H212 > MM8EJ 8K memory -- G233 / -- M8357 -- RX8E interface to RX01/02 8" diskette drives. -- M7104 \ -- M7105 > RK8E RK05 Disk Interface -- M7106 / -- M8321 \ -- M8322 \ TM8E Magtape control for 9 track tape. -- M8323 / -- M8327 / At one point, DEC packaged a PDP-8/E in a desk with no front panel controls other than power and bootstrap switch, along with an RX01 accessable from the front and a VT50 on top. This was sold as the Class-ic system, with an intended market in the classroom (hence the name); it was the forerunner, in terms of packaging, of many later DEC office products. What is a PDP-8/F? Date of introduction: 1972. Date of withdrawal: 1978. Technology: an OMNIBUS machine, as with the PDP-8/E. First use of a switching power supply in the PDP-8 family. Reason for introduction: The PDP-8/E had a large enough box and a large enough power supply to accomodate a large configuration. By shortening the box and putting in a small switching power supply, a lower cost OMNIBUS machine was possible. Reason for withdrawal: The PDP-8/A 800 displaced this machine, providing similar expansion capability at a lower cost. Compatability: The PDP-8/F used the PDP-8/E CPU and peripherals. Standard configuration: Identical to the PDP-8/E, except that the KC8E front panel was replaced with a KC8M front panel that had LEDs instead of incandescent lights; this front panel could also be installed on PDP-8/E systems, but the PDP-8/E front panel could not be used on a PDP-8/F because of the lack of a +8 supply for the lights. The original PDP-8/F box had a defective power supply, but a revised (slightly larger) box corrected this problem. Expandability: This machine could be expanded using all PDP-8/E OMNIBUS peripherals, including the external expansion chassis. The relatively small internal power supply and the lack of room for a 20 slot bus expander inside the first box were the only limitations. There were minor compatability problems with some options, for example, the power-fail auto-restart card, as originally sold, was incompatable with the PDP-8/F power supply. What is a PDP-8/M? Date of introduction: 1972. Date of withdrawal: 1978. Technology: This machine was a PDP-8/F (with a PDP-8/E CPU) Reason for introduction: DEC knew that OEM customers were an important market, so they packaged the PDP-8/F for this market, with no hardware changes behind the front panel. Reason for withdrawal: Same as the PDP-8/F Compatability: The PDP-8/M used the PDP-8/E CPU and peripherals. Standard configuration: Identical to the PDP-8/F, except that the KC8M front panel was replaced with a minimal function panel and the color scheme was different. Because of this, one of the following options were required: -- M848 -- KP8E Power fail and auto-restart. -- M847 -- MI8E Hardware Bootstrap Loader. Expandability: All options applying to the PDP-8/F applied. In addition, the KC8M front panel (standard with the PDP-8/F) was available as an option. What is a PDP-8/A? Date of introduction: 1975 Date of withdrawal: 1984 Technology: This machine used the OMNIBUS with a new single-board CPU, made possible by the use of TTL MSI and LSI components on an extra-wide board (formally, hex high, double high) with 6 connector fingers instead of the usual 4. Reason for introduction: Using TTL MSI and LSI components, DEC was able to reduce the PDP-8 CPU to a single hex wide double high card. Similarly, they were able to make an 4K core memory card, and later, an 8K board in this format, and they were able to introduce a static RAM card using semiconductor memory. The net effect was to reduce the minimum system to 3 boards. In addition, the market for the PDP-8 was dominated by small systems, with fewer and fewer customers needing large-scale expandability. Thus, the 20 slot backplane of the early Omnibus machines was too big; with the new single board CPU and memory, a 12 slot backplane was enough. Reason for withdrawal: The market for the PDP-8 family was shrinking in the face of pressure from larger minicomputers and the new monolithic microcomputers. After 1975, many PDP-8 sales were to captive customers who had sufficient software investments that they could not afford to move. Only the word-processing and small business markets remained strong for first-time PDP-8 sales, and in these, the specialized DEC VT-78 and DECmate machines were more cost effective than the open architecture OMNIBUS machines. Compatability: The new PDP-8/A CPU was largely compatable with the PDP-8/E CPU, except that the combination of RTR and RTL (Group 1 OPR instructions) loaded the next address. The power-fail auto-restart option included the standard skip on power low instruction, but also a new skip on battery empty instruction to test the battery used for back-up power on the new solid state memory. Standard configuration: The PDP-8/A was sold with a new short OMNIBUS backplane, mounted on its side above a power supply and a battery to back up the solid state memory. The minimum configuration included a limited function control panel and the following components on the bus: -- M8315 -- KK8A CPU board -- M???? -- MS8A 1K to 4K solid state memory. -- M8316 -- DKC8AA serial/parallel interface and clock. The M8316 board contained a remarkable but useful hodgepodge of commonly used peripherals, including the console terminal interface, a parallel port, the power/fail auto-restart logic, and a 100 Hz real time clock. The original configuration sold had a 10 slot backplane and a poor power supply. The later base model had a 12 slot backplane, the 8/A 400. Expandability: All PDP-8/E peripherals and options could be used with the PDP-8/A. The KK8A cpu was not as fast as the KK8E used in the PDP-8/E, but the KK8E CPU could be substituted for the KK8A CPU, and many PDP-8/A systems were sold with this substitution. A box with a 20 slot backplane, the 8/A 800, was available for large configurations. A pair of PDP-8/A backplanes could be connected using BC08H cables, and there was a special cable, the BC80C, for connecting a hex wide 8A backplane to a PDP-8/E, -8/F or -8/M backplane. By late 1975, the PDP-8/A was being sold in a workstation configuration, with the CPU and dual 8" diskette drives in a desk with a video terminal (VT57?) on top. This followed the pattern set by the Class-ic packaging of the PDP-8/E, but it was aimed at the word-processing market. The following additional PDP-8/A (hex) boards were offered: -- G649 \_ MM8AA 8K Core stack (too slow for 8/E CPU!). -- H219A / MM8AA 8K Core memory control. -- G650 \_ MM8AB 16K Core stack (ok for 8/E CPU!). -- H219B / MM8AB 16K Core memory control. -- M???? -- MR8F 1K ROM (overlayable with RAM). -- M8317 -- KM8A memory extender (with variations). -- M8319 -- KL8A 4 channel RS232 or current loop serial I/O. -- M???? -- RL8A controller for 1 to 4 RL01/RL02 disk drives. -- M8416 -- KT8AA Memory management unit. -- KC8AA Programmer's Console (requires M8316) -- M8417 -- MSC8DJ 128K DRAM MOS Memory. Note that memory extension to 128K was a new PDP-8/A feature that was necessarily incompatable with the older PDP-8 memory expansion options, although the conventional PDP-8 memory expansion instructions still operate correctly on the first 32K. Access to additional fields involved borrowing IOT instructions that were previously dedicated to other devices. The MM8A options require the use of a box with a -20V power supply. Also, the use of the MSC8 DRAM memory cards requires a CPU that supports the memory stall signal, early PDP-8/E CPUs did not. What is a VT78? Date of introduction: 1978 Date of withdrawal: 1980 (Displaced by the DECmate) Also known as: DECstation 78 Technology: Intersil 6100 microprocessor, packaged in a VT52 case. The 6100 processor was able to run at 4 MHz, but in the VT78, it was only clocked at 2.2 MHz because of the speed of the DRAM used and the deliberate use of graded out chips. Reason for introduction: Using TTL MSI and LSI components, DEC could pack their CPU into vacant space in a standard terminal case, allowing PDP-8 systems to compete with personal computers in the small business and office automation market. This was a natural follow-on to the workstation configurations in which the PDP-8/A was already being sold. Compatability: The Group I OPR combinations RAL RAR and RTL RTR are no-ops. Unlike all earlier PDP-8 models, autoindex locations 10 to 17 (octal) only work in page zero mode; these operate like all other memory location when addressed in current page mode from code running on page zero. Other than this, it is fully PDP-8/E compatable, even at the level of I/O instructions for the standard periperals; this was the last PDP-8 to offer this level of compatability. It was not possible to continue from a halt without restarting the machine. In addition, none of the peripherals available on this machine needed DMA (data break) transfers. Standard configuration: The VT78 was sold with 16k words of DRAM with the keyboard and display of the VT52 terminal. An RX01 dual 8" diskette drive was standard, packaged in the pedestal under the terminal. The console (device 03/04), the printer (output only) port (device 66), and the serial ports (devices 30/31 and 32/33) are compatable with the M8650 KL8E, with the latter extended to allow software controlled baud rates selection. The parallel port (device 47) and 100Hz clock are compatable with the comparable PDP-8/A options on the M8316 DKC8AA. The standard ROM boots the system from the RX01 after setting the baud rates to match that selected by the switches on the bottom of the VT52 case. Expandability: This was a closed system, with few options. The base configuration was able to support two RX01 drives (later RX02), for a total of 4 transports. Various boot ROM's were available, including a paper-tape RIM loader ROM for loading diagnostics from tape. Another ROM boots the system from a PDP-11 server in the client/server configuration used by WPS-11. What is a DECmate I? Date of introduction: 1980 Date of withdrawal: 1984 (Phased out in favor of the DECmate II) Also known as: DECmate (prior to the DECmate II, no suffix was used) VT278 Technology: Based on the Intersil/Harris 6120 microprocessor, packaged in a VT-100 box with keyboard and display. Reason for introduction: This machine was aimed primarily at the market originally opened by the VT78, using the IM6120 as a substitute for the older 6100 chip and optimizing for minimum cost and mass production efficiency. Compatability: A new feature was introduced in the 6120 microprocessor: The Group I OPR combination RAL RAR was defined as R3L, or rotate accumulator 3 places left, so that byte swap (BSW) is equivalent to R3L;R3L. RTR RTL remained a no-op, as in the 6100. Also, the EAE operations not implemented in the basic CPU cause the CPU to hang awaiting completion of the operation by a coprocessor. Unfortunately, no EAE coprocessor was ever offered. The printer port offered software baud-rate selection compatable with the VT78 baud-rate selection scheme. The data communications option was completely incompatable with all previous PDP-8 serial ports. The console and printer ports are not fully compatable with the earlier PDP-8 serial ports. Specifically, on earlier serial interfaces, it was possible to test flags without resetting them, but on the DECmate machines, testing the keyboard input flag always resets the flag as a side effect. In addition, on the console port, every successful test of the flag must be followed by reading a character or the flag will never be set again. It was not possible to continue from a halt without restarting the machine. The large amount of device emulation performed by the CPU in supporting screen updates severely limits the ability of the system to run in real time. Standard configuration: The DECmate I was sold with 32k words of memory, with a small additional control memory added to handle control/status and boot options. The console terminal keyboard and display functions are largely supported by control memory routines (as opposed to having separate hardware for terminal support, as in the VT78). DECmate I came with an integral printer port, compatable with the VT78 (device 32/33), and it had an RX02 dual 8 inch diskette drive, mounted in the short cabinet under the terminal/CPU box. A 100Hz clock was included, as in the VT78 and PDP-8/A. Expandability: This was a closed system, with limited options. Specifically, a second RX02 could be connected (or an RX01, because that had a compatable connector), the DP278A and DP278B communications boards (really the same board, but the DP278B had 2 extra chips), and the RL-278 disk controller, able to accomodate from 1 to 4 RL02 rack mount disk drives. When the DP278A option is added, additional control memory is included containing a ROM-based terminal emulator allowing diskless operation. The emulator is an extended VT100 subset that is essentially compatable in 80 column mode. The DP278A option could support both asynchronous and synchronous protocols, and the DP278B could handle SDLC and other nasty bit-stuffing protocols. Various pedestal and desk configurations were sold for housing the RX01 and RX02 drives, most being teacart style designs, but there was also a pedestal version that was essentially a repackaging of the RX02 with either 2 or 4 new 8 inch disk transports (physically incompatable with tearlier DEC transports). What is a DECmate II? Date of introduction: 1982 Date of withdrawal: 1986 Price: $1,435 Technology: Based on the 6120 microprocessor, this shared the same packaging as DEC's other competitors in the PC market, the Rainbow (80x86 based) and the PRO-325 (PDP-11 based). Reason for introduction: This machine was introduced in order to allow more flexibility than the DECmate I and to allow more sharing of parts with the VT220 and DEC's other personal computers. Compatability: Same as the DECmate I, except it could continue from a halt. There was better hardware for device emulation support, allowing for somewhat better real-time performance, and the data communications port was an incompatable improvement on the incompatable DECmate I communications port. The improved data communications port make it essentially as powerful as the DP-278B on the DECmate I, with a more efficient but bizarre software interface. Standard Configuration: The DECmate II was sold with 32K of program memory, plus a second full bank for dedicated control panel functions, an integral RX50 dual 5 1/4 inch diskette drive with an 8051 controller chip, a printer port, a 100Hz real-time clock, single data communications port, and interfaces to the monitor and keyboard. The diskette drive can read single-sided 48 track-per-inch diskettes, so it might be possible to read (but not write) IBM PC diskettes. Expandability: This was the most open of the DECmate systems, with a number of disk options: An additional pair of RX50 drives could be added, and with the RX78 board, it could support a pair of dual 8 inch drives, either RX01 or RX02. As an alternative to the RX78, there was a controller for an MFM hard drive. The interface to the RX78 board wasn't fully compatable with earlier interfaces to RX01 and RX02, and there was no way to have both an RX78 and an MFM drive. The MFM drive could be up to 64 MB, with 16 sectors per track, 512 bytes each and at most 8 heads and 1024 (or possibly 4096) cylinders. A power supply upgrade was needed to support the MFM drive. DEC sold this machine with 5, 10 and 20 meg hard drives, Seagate ST-506, 412, and 225 respectively. A graphics board supporting a color monitor could be added in addition to the monochrome console display. A coprocessor board could be added, with communication to and from the coprocessor through device 14. DEC sold three boards, an APU board (Z80 and 64K), and two XPU boards (Z80, 8086 and either 256K or 512K). If these added processors are used, the 6120 processor is usually used as an I/O server for whatever ran on the coprocessor. The XPU boards used a Z80 for I/O support, so 8086 I/O was very indirect, particularly if it involved I/O to a PDP-8 device that was emulated from control memory! Despite this, I/O through the DECmate version of MS/DOS is generally faster than MS/DOS on more recent 80286 and 80386 based IBM PCs because of effective use of the coprocessors (but they couldn't run MS/DOS code that bypasses MS/DOS for I/O). What is a DECmate III? Date of introduction: 1984 Date of withdrawal: 1990 Price: $2,695 Technology: Same as the DECmate II. Reason for introduction: Again, DEC discovered that the market for large systems was dominated by other products, and that the PDP-8 based products were rarely expanded to their full potential. Thus, there was no point in paying the price of expandability. Compatability: Same as the DECmate II, except that the printer port is fixed at 4800 baud. Standard Configuration: The DECmate III was sold with 32K of program memory, plus a second full bank for dedicated control panel functions, an integral RX50 dual 5 1/4 inch diskette drive with an 8051 controller chip, a printer port, a 100Hz real-time-clock, a data communications port, and interfaces for the VR-201 monitor and keyboard. Expandability: A revised version of the Z80 based coprocessor for the DECmate II was available, and a graphics board compatable with the later DECmate II graphics board could be added allowing the standard monochrome monitor to be replaced with a VR-241 color monitor. Two monitor configurations were not supported. An obscure variant of the DEC scholar modem was also supported as an option. What is a DECmate III+? Date of introduction: 1985 Date of withdrawal: 1990 Technology: Same as the DECmate II. Reason for introduction: This machine apparently represents the last gasp of the PDP-8, hunting for the remains of the ever-shrinking market niche that the earlier DECmates had carved out. The market niche was not there, and the production runs for this machine were short enough that UV erasable EPROM technology was used where earlier DECmates had used mask programmed chips. Compatability: Same as the DECmate II, but the machine was unable to read 48 track per inch IBM formatted diskettes. Again the printer port was fixed at 4800 baud. Standard Configuration: The DECmate III+ was sold with 32K of program memory, plus a second bank for dedicated control panel functions, an integral RX33 single 5 1/4 inch diskette drive with an 8751 controller chip, a printer port, a data communications port and interfaces to the monitor and keyboard. A hard disk controller compatable with the optional one on the DECmate II was included, supporting an integral ST-225 20 MB disk; it is likely that it can only handle up to 1024 cylinders, but it is otherwise compatable with the DECmate II. Expandability: The same coprocessor option sold with the DECmate III was available, but because of the lack of a second floppy drive, this was rarely used (the Z80 was most likely to be used to run CP/M, but that system requires two drives to handle the installation procedure; an appropriately configured bootable image created on a DECmate II or III could run on a DECmate III+). The same graphics board as used on the DECmate III was also available. The circuit traces and connectors for the Scholar modem are present, but this option was never sold on the DECmate III+. From jones@cs.uiowa.edu Tue Feb 8 13:24:13 EST 1994 Article: 638 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!overload.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Newsgroups: alt.sys.pdp8,alt.answers,news.answers Subject: PDP-8 Frequently Asked Questions (posted every other month) Followup-To: alt.sys.pdp8 Date: Fri, 8 Feb 94 08:08:08 GMT Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Lines: 987 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 8 Apr 1994 08:08:08 GMT Message-ID: <2j8837$hpq@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Summary: Answers to common questions about antique DEC PDP-8 computers. Those posting to alt.sys.pdp8 should read this. Keywords: FAQ DEC PDP 8 Xref: bigblue.oit.unc.edu alt.sys.pdp8:638 alt.answers:1716 news.answers:16985 Archive-name: dec-faq/pdp8 Last-modified: Jan 18, 1994 Frequently Asked Questions about the DEC PDP-8 computer. By Douglas Jones, jones@cs.uiowa.edu (with help from many folks) The most recent version of this file is available by anonymous FTP from: rtfm.mit.edu:/pub/usenet/alt.sys.pdp8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc 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 character sets does the PDP-8 support? 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? In 1957, Ken Olson and Harlan Anderson founded Digital Equipment Corporation (DEC), capitalized at $100,000, and 70% owned by American Research and Development Corporation. The founders wanted to call the company Digital Computer Corporation, but the venture capitalists insisted that they avoid the term Computer and hold off on building computers. With facilities in an old woolen mill in Maynard Massachusetts, DEC's first product was a line of transistorized digital "systems modules", plug-in circuit boards with a few logic gates per board. Starting in 1960, DEC finally began to sell computers (the formal acceptance of the first PDP-1 by BBN is reported in Computers and Automation, April 1961, page 8B). Soon after this, there were enough users that DECUS, the Digital Equipment Computer User's Society was founded. DEC's first computer, the PDP-1, sold for only $120,000 at a time when other computers sold for over $1,000,000. (A good photo of a PDP-1 is printed in Computers and Automation, Dec. 1961, page 27). DEC quoted prices as low as $85,000 for minimal models. The venture capitalist's insistance on avoiding the term computer was based on the steriotype that computers were big and expensive, needing a computer center and a large staff; by using the term Programmable Data Processor, or PDP, DEC avoided this stereotype. For over a decade, all digital computers sold by DEC were called PDPs. (In early DEC documentation, plural form "PDPs" is used as a generic term for all DEC computers.) In the early 1960's, DEC was the only manufacturer of large computers without a leasing plan. IBM, Burroughs, CDC and other computer manufacturers leased most of their machines, and many machines were never offered for outright sale. DEC's cash sales approach led to the growth of third party computer leasing companies such as DELOS, a spinoff of BB&N. 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 NA 36 One was built by a customer, not by DEC. PDP-4 1962 $60,000 18 Predecessor of the PDP-7. PDP-5 1963 $27,000 12 The ancestor of the PDP-8. PDP-6 1964 $300,000 36 A big computer; 23 built, most for MIT. PDP-7 1965 $72,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 $110,000 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 are for minimal systems in the year the machine was first introduced. The bits column indicates the word size. Note that the DEC PDP-10 became the DECSYSTEM-20 as a result of marketing considerations, and DEC's VAX series of began as the Virtual Address eXtension of the never-produced PDP-11/78. It is worth mentioning that it is generally accepted that the Data General Nova (see photo, Computers and Automation, Nov. 1968, page 48) 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 perhaps Gordon Bell, who was at C-MU at the time) evaluated the competing designs and rejected both in favor of what we know as the PDP-11. (A less common version of this story is that the reason that DEC never produced a PDP-13 was because the number 13 was assigned to what became the Nova; this is unlikely because the PDP-X prototype came before the PDP-11.) Both DEC and Data General are quiet about these stories. Today, all of the PDP machines are in DEC's corporate past, with the exception of the PDP-11 family of mini and microcomputers. 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, although it is worth noting that the term minicomputer first came into prominence in early 1968. (See Interdata ad, Computers and Automation, May 1968, page 10). The PDP-8 was largely upward compatable with the PDP-5, a machine that was unveiled on August 11, 1963 at WESCON, and the inspiration for that machine came from two earlier machines, the LINC and the CDC 160. All of these machines were characterized by a 12 bit word with no hardware byte structure, a 4K minimum memory configuration, and simple but powerful instruction sets. Although some people consider the CDC 160 the first minicomputer, the PDP-8 was the definitive minicomputer. By late 1973, the PDP-8 family was the best selling computer in the world, and it is likely that it was only displaced from this honor by the Apple II and later, the IBM PC. Most models of the PDP-8 set new records as the least expensive computer on the market at the time of their introduction. 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 has said 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 (see CACM, march 1961, photo on page 244, text on page 246) was such a machine, and in addition to the hundreds of CDC 160 systems sold as stand-alone machines, a derivative 12 bit architecture was used for the I/O processors on Cray's first great supercomputer, the CDC 6600. Note that Cray's 12 bit machines 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 generally as tight as the code on Cray's machines. 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 as indirect addresses. These locations are called auto-index registers (despite the fact that they are in memory); 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 JMS instruction stores the return address in relative word zero of the subroutine, with execution starting with relative word one. Subroutine return is done with an indirect JMP through the return address. Subroutines commonly increment their return addresses to index through inline parameter lists or to perform conditional skips over instructions following the call. The IOT instruction has the following form: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| | | | | | | 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, and these can be microcoded in left to right order. Prior to the PDP-8/E, there were severe restrictions on the interpretation of the op field. As an example of the use of IOT instructions, consider the console terminal interface. On early PDP-8 systems, this was always assumed to be an ASR 33 teletype, complete with low-speed paper tape reader and punch. It was addressed as devices 03 (the keyboard/reader) and 04 (the teleprinter/punch): _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 1 1|0 0 1 - KSF - keyboard skip if flag |0 0 0 0 1 1|0 1 0 - KCC - keyboard clear flag |0 0 0 0 1 1|1 0 0 - KRS - keyboard read static The keyboard flag is set by the arrival of a character. The KCC instruction clears both the flag and the accumulator. KRS ors the 8 bit input data with the low order 8 bits of AC. The commonly used KRB instruction is the or of KCC and KRS. To await one byte of input, use KSF to poll the flag, then read it with KRB. _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 1 0 0|0 0 1 - TSF - teleprinter skip if flag |0 0 0 1 0 0|0 1 0 - TCF - teleprinter clear flag |0 0 0 1 0 0|1 0 0 - TPC - teleprinter print static The teleprinter flag is set by the completion of the TPC operation (as a result, on startup, many applications use TPC to print a null in order to get things going). TCF clears the flag, and TPC outputs the low order 8 bits of the accumulator. The commonly used TLS instruction is the or of TCF and TPC. To output a character, first use TSF to poll the flag, then write the character with TLS. 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: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 0 0|0 0 1 - ION - interrupts turn on |0 0 0 0 0 0|0 1 0 - IOF - interrupts turn off An interrupt was requested when any device raised its flag. The console master clear switch would reset all flags and disable interrupts. Effectively, an interrupt is a JMS instruction to location zero, with the side effect of disabling interrupts. The interrupt service routine would test flags and perform the operations needed to reset them, and then return using ION immediately before the indirect return JMP. The effect of ION is delayed so that interrupts are not enabled until after the JMP. The instructions controlling the optional memory management unit are also IOT instructions. This unit allows the program to address up to 23K of main memory by adding a 3 bit extension to the memory address. Two extensions are available, one for instruction fetch and direct addressing, the other for indirect addressing. 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? There are many different assemblers for the PDP-8, but most use a compatable basic syntax; 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. 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 most assemblers provide a notation 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. Note that the variants "(3" and "[5" (with no closing parentheses) are usually allowed but the use of this sloppy form is discouraged. Furthermore, the widely used PAL8 assembler interprets "(3)+1" as being the same as "(3+1)". Arithmetic is allowed in operand fields and constant definitions, with expressions evaluated in strict left-to-right order, as: 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, PAL8, has trouble when unary operators are mixed with multiplication or division. Generally, only the first 6 characters of identifiers are significant and numeric constants are evaluated in octal. 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. The $, * and = syntax used by most PDP-8 assemblers replace functions performed by pseudo-operations on many other assemblers. In addition, PAL8, the most widely used PDP-8 assembler supports the following pseudo-operations: DECIMAL / Interpret numeric constants in base 10 OCTAL / Interpret numeric constants in base 8 EJECT / Force a page eject in the listing XLIST / toggle listing PAGE / Advance location counter to next page FIELD N / Assemble into extended memory field N TEXT STRING / Pack STRING into consecutive 6 bit bytes ZBLOCK N / Allocate N words, initialized to zero IFDEF S / Assemble C if symbol S is defined IFNDEF S / Assemble C if symbol S is not defined IFZERO E / Assemble C if expression E is zero IFNZRO E / Assemble C if expression E is not zero Conditonally assembled code must be enclosed in angle brackets. The conditionally assembled code may extend over multiple lines. What character sets does the PDP-8 support? With its 12 bit word, the PDP-8 is somewhat awkward in its support for modern 7 and 8 bit character sets. Nonetheless, from the beginning, PDP-8 software has generally assumed that text I/O would be in 7 bit ASCII. Most early PDP-8 systems used teletypes as console terminals; as sold by DEC, these were configured for mark parity, so most older software assumes 7 bit ASCII, upper case only, with the 8th bit set to 1. On output, lines are generally terminated with both CR and LF; on input, CR is typically (but not always) the line terminator and LF is typically ignored. In addition, the tab character (HT) is generally interpreted in terms of a tab-stop every 8 spaces. Most of the better engineered PDP-8 software tends to fold upper and lower case on input, and it ignores the setting of the 8th bit. Internally, PDP-8 programmers are free to use other character sets, but the TEXT pseudo-operation strongly encourages the 6 bit character set called "stripped ASCII". To map from upper-case-only ASCII to stripped ASCII, each 8 bit character is anded with octal 77 and then packed 2 characters per word, left to right. Many programs use a semi-standardized scheme for packing mixed upper and lower case into 6 bit TEXT form; this uses ^ to flip from upper to lower case or lower to upper case, % to encode CR-LF pairs, and @ (octal 00) to mark end of string. Note that this scheme makes no provision for encoding the %, ^ and @ characters, nor does it allow control characters other than the CR-LF pair. Files under the widely used OS/8 system consist of sequences of 256 word blocks. When used for text, each block holds 384 bytes, packed 3 bytes per pair of words as follows: aaaaaaaa ccccaaaaaaaa bbbbbbbb CCCCbbbbbbbb ccccCCCC Control Z is used as an end of file marker. Because most of the PDP-8 system software was originally developed for paper tape, binary object code is typically stored in paper-tape image form using the above packing scheme. What different PDP-8 models were made? The total sales figure for the PDP-8 family is estimated at over 300,000 machines. Over 7000 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-67 116 Transistor PDP-8 65-69 1450 $18,500 Transistor LINC-8 66-69 142 $38,500 Transistor PDP-8/S 66-70 1024 $10,000 Transistor PDP-8/I 68-71 3698 $12,800 TTL PDP-8/L 68-71 3902 $8,500 TTL Scaled down 8/I PDP-12 69-73? 3500? $27,900 TTL Followup to LINC-8 PDP-8/E 70-78 >10K? $7,390 TTL MSI Omnibus 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 78-80 <$10K Intersil IM6100 Dm I 80-84 Harris 6120 Dm II 82-86 $1,435 Harris 6120 Dm III 84-90 $2,695 Harris 6120 Dm III+ 85-90 Harris 6120 Additional information is available in part two of this FAQ, where all known models of the PDP-8, along with variants, alternate marketing names, and other peculiarities are given. The last years of the PDP-8 family were dominated by the PDP-8 compatable microprocessor based VT78 and DECmate (Dm in the above table) machines. DEC also used the Intersil IM6100 and Harris 6120 microprocessors in many peripheral controllers for the PDP-11 and PDP-15. While all of the earlier PDP-8 systems were open architecture systems, the DECmates had closed architectures with an integrated console terminals and limited peripheral options. 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 (a surviving example runs FOCAL). TPA 68? Hungarian, a PDP-8/L clone, ran FOKAL Electrotechnica-100I ? Russian, a PDP-8/I? clone. Saratov-2 ? Russian, a slow clone, perhaps PDP-8/S Voronezh ? Russian, another PDP-8/? clone SPEAR u-LINC ? SPEAR, Inc, Waltham Mass. DCC-112 70-71 Digital Computer Controls DCC-112H 71 Digital Computer Controls 6100 Sampler 7? Intersil, their IM6100 promotional kit Intercept I 7? Intersil, based on IM6100 Intercept Jr 7? Intersil, based on IM6100 PCM-12 7? Pacific CyberMetrix, based on Intercept bus PCM-12A 7? Pacific CyberMetrix, fixed to clock at 4MHz 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. Over 24 LINC systems were built by customers before late 1964 when DEC began selling a commercial version (see Computers and Automation, Nov. 1964, page 43). By the time DEC introduced the LINC-8, 43 LINC systems had been installed (see Computers and Automation, Mar. 1966, page 34). 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 the first 12 bit minicomputer built using DEC hardware. Like the PDP-5 and other early DEC computers, it was built with system modules, DEC's first family of logic modules. 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. The motives behind the development of LINCtape were the same motivives that led IBM to develop the floppy disk almost a decade later, and in fact, DECtape survived as a widely used medium until DEC introduced the RX01 8 inch floppy disk drive around 1975. 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. The 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 to be called the LINC-8/I, but it was sold as the PDP-12. Both the LINC-8 and the PDP-12 had impressive consoles, with separate sets of lights and switches for the LINC and PDP-8 halves. The success of the LINC-8 also led to the development of a clone, the SPEAR micro-LINC. This machine used Motorola MECL integrated circuits and was available for delivery in (June 1965? this date must be wrong!). The LINC-8 and PDP-12 could run essentially any PDP-8 or LINC program, but because they had instructions for switching between modes, a body of software was developed that required both modes. 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. LAP6-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. After about 1976, Reuters bought as many as 10,000 OMNIBUS based machines per year, with perhaps 2000 per year going to other customers. 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. 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? Part II of this FAQ cites the key documents published by DEC describing each model of the PDP-8. These are all 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 out. Douglas Jones has made a small number of bound photocopies of DEC's 1973 introduction to programming, perhaps the definitive introduction to the PDP-8, and the other early DEC handbooks need similar treatment before they all crumble. Maintenance manuals are harder to find, but more valuable. If you need one, you usually need to find someone willing to photocopy one of the few surviving copies. 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, was 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 was a BASIC only system submitted to DECUS and later sold by DEC as part of its EduSystem marketing program. P?S/8 was developed starting in 1971 from an MS/8 foundation. It runs on minimal PDP-8 configurations, supports somewhat device independant I/O and requires a random-access device for the file system (DECtape is random-access!). 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 typically supported 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 supported addressing of more than 4K for data, but limited code to 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. RTS/8 was a real-time system developed by DEC and shipped around 1978. Curiously, for a system developed so late, paper-tape and DECtape were still supported by this system. WPS was DEC's word processing system, developed on the 8/E and widely used on the 1980's vintage machines with a special WPS keycaps replacing the standard keycaps on the keyboard. It was heavily promoted on the VT-78, and when the DECmates came out, DEC began to suppress knowledge that DECmates could run anything else. WPS-11 was a curious distributed system using a PDP-11 as a file server for a cluster of VT-78 WPS 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 almost the same as OS/8, but dates are recorded differently, and a few applications can even run under both COS and OS/8. COS was the last operating system other than WPS promoted by DEC for the DECmates. What programming languages are supported on the PDP-8 The PAL family of assembly languages, particularly PAL III and PAL8 are as close to a standard assembly language as can be found for the PDP-8. These produce absolute object code and there are versions of PAL for minimally configured machines, although these have sever symbol table limitations. MACRO-8 was DEC's first macro assembly language for the PDP-8, but it was rarely used outside the paper-tape environment. 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. Many versions of BASIC were also available, from DEC and other sources. DEC BASIC was widely used on PDP-8 systems sold under the EduSystem marketing program. A paper-tape version was available that ran in 4K, versions for OS/8 and TSS/8, an 8K stand-alone time-sharing version, and 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. POLY SNOBOL was a version of SNOBOL that was somewhere between Griswald's definitions of SNOBOL 3 and SNOBOL 4. 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 PAL8 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. The following anonymous FTP sites contain publically accessable archives of PDP-8 software and other information: ftp.telebit.com:/pub/pdp8 ftp.update.uu.se:/pub/pdp8 nickel.ucs.indiana.edu:/pub/DEC/PDP8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8. The latter archive also maintains an archive of traffic in alt.sys.pdp8 in the directory ...pdp8/usenet. The archive at Indiana contains source code for many PDP-8 compilers and interpreters, as well as common utilities and games. 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 telebit.com archive cited above. This file gives details of every PDP-8 model 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 needs to be gatewayed to this mailing list. 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 accurate and complete (but difficult to read). 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 make much practical use of it. 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, have built 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 was 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 guru, hacked up the PAL III assembler for the -8, based on PAL II. Richard Merrill invented FOCAL and wrote the original (1968) and classic FOCAL-69 interpreters for the PDP-8. Charles Lasner developed P?S/8, and he is widely known as the grand old man of the movement to preserve these historic machines. Wesley Clark developed the LINC while working at Lincoln Labs; this was the first 12 bit minicomputer built with DEC parts. Mary Allen Wilkes Clark developed the early LAP programs for the LINC. Douglas W. Jones wrote this FAQ, but prior to the summer of 1992, he'd never used a PDP-8. He has also written a report on how to photocopy and archivally bind ailing paperback books such as DEC's handouts, a PAL-like cross assembler in C, and a UNIX-based PDP-8 emulator. From chris@envex.demon.co.uk Sat Feb 12 11:06:14 EST 1994 Article: 639 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,comp.os.cpm,alt.sys.pdp8,comp.sys.northstar From: chris@envex.demon.co.uk ("Chris P. Burton") Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!pipex!demon!dis.demon.co.uk!envex.demon.co.uk!chris Subject: Computer Conservation Society (LONG ARTICLE) References: <760740223snz@envex.demon.co.uk> Organization: Envex Services Reply-To: chris@envex.demon.co.uk X-Newsreader: Demon Internet Simple News v1.27 Lines: 177 Date: Thu, 10 Feb 1994 23:41:14 +0000 Message-ID: <760923674snz@envex.demon.co.uk> Sender: usenet@demon.co.uk Xref: bigblue.oit.unc.edu alt.folklore.computers:58114 comp.os.cpm:5794 alt.sys.pdp8:639 comp.sys.northstar:134 I posted the following article to alt.sys.perq and several people have kindly suggested it might be of interest further afield, so here goes. >snip----- Since the PERQ is what we might call a vintage machine, I assume readers are interested in such machines and might not have heard of, or would like to know more about, the Computer Conservation Society (the CCS). The CCS is a Specialist Group of the British Computer Society and was started about four years ago after an approach from the Curator of Computing at the National Science Museum in London. He is responsible for the care, for ever, of machines in the collection, but with little in- house expertise available as to how to care for them; and he was often approached by old-timers offering their skills. The original idea of the CCS was to try to bring these together in an organised way. For the first three years, the Science Museum took on a BCS officer to manage the "Information Age" project, and he was allowed time and facilities to also act as Secretary to the CCS, thus ensuring it got off to a stable and solid start. Although he no longer works for the Museum, he is still the Secretary, working from home. Broadly the objectives are: Promote the conservation of historic computers Develop awareness of the importance of historic computers Encourage research on seminal historic computers. Hardware, software and user applications are all included in the remit. So far as I know, there is no equivalent in the UK to the Charles Babbage Institute in the USA, though there are academic departments, e.g. at the University of Warwick, with an interest in the history. The CCS thus provides a focus for these activities. What counts as historic? As a rule of thumb we would say it should be at least twenty years old, but that shouldn't rule out important younger things which might need rescuing. So early IBM 360s and ICL 1900s count. Commodore Pets count (yes, there are dozens about). PERQs count, just. I saw two in the Science Museum archive store about a couple of weeks ago. Visicalc counts (pun not intended). I think it will be some time before 486 PC clones count. BESM counts (we are very interested in Soviet cold-war-vintage machinery). There are roughly 300 members of whom about 10% are actively involved in some way. Membership is open to anyone interested in computer conservation and the history of computing, and is currently free. Members give their time voluntarilly. There are half a dozen Corporate Members including ICL, Unisys, Digital, Bull HN Information Systems and Vaughan Systems, who donate a large amount of money annually to pay for running the CCS. In order to meet the objectives, the CCS does the following things. WORKING PARTIES There are a number of working parties, each led by a chairman, and containing typically a dozen members who are prepared to give some time and effort, typically a half day every six weeks. Working parties are formed as required and the current ones are: _Elliott 401 WP_. Very active, currently conserving and restoring to working order this very important, unique, valve machine built in 1952 and in the care of the Museum. _Pegasus WP_. Not quite so active, but has maintained in working order the also very important valve machine Pegasus, made by Ferranti Ltd from 1956 on. Not yet on display in the Museum _Manchester Group Pegasus WP_. Newly formed working party operating at the Manchester Museum of Science and Industry to conserve, but perhaps not restore to working order, their early Pegasus, recently "discovered". _Elliott 803 WP_. Small but active, have restored and maintain the Museum's Elliott 803 which was an early transistor machine. _DEC WP_. Active, maintains the Museum's several sorts of PDP8 and a PDP12. _S100 Bus WP_. Active, masses of Altairs, North Star Horizons etc. _Totalisator WP_. Suspended, awaiting space and expertise. Yes, it is considered that the electro-mechanical dog track totalisators from the late 1920's are large-scale, multi-terminal, real-time computers. The Museum has three, I believe, in storage at the moment. _Software and Emulation WP_. Not active, but a lot of work on emulation, see below. Working parties work on Museum objects under very strict curatorial rules and procedures. Because they can only meet infrequently, progress is at a much slower pace than in say industry or academia. ARCHIVING The CCS has a good relationship with the National Archive for the History of Computing based in Manchester, with loosely separate spheres of interest. There is a large and growing collection of manuals, manuscripts, sales literature and so on from the early days. It is catalogued but not easily accessible yet. SIMULATION AND EMULATION Hard to draw the line between them. Quite a lot of interest has been shown in the museum world by some of the simulators written by members to model the behaviour of early, and in some cases extinct, machines. The techniques are applicable to any large, functionally opaque object. At the moment simulators for EDSAC, Pegasus, Elliott 803 and Ferranti Mercury exist, and the Elliott 401 is under development. An emulator for the original Manchester Prototype has been obtained by a devious route from the net, but I have yet to work out it's provenance. SEMINARS At least one all-day seminar is held at the Science Museum annually, where usually pioneers of some system give talks and discussions. This year's will be on the IBM 360, coinciding with the 30th anniversary of the launch. LECTURE PROGRAMME A programme of evening lectures is given during the year on relevant topics. PUBLICATIONS All members receive the quarterly bulletin called "Resurrection", currently free of charge. This has short articles, transcripts of lectures and reports on work in progress. INFORMATION CAPTURE The CCS recognises that not only are early machines dying off, but so are many of the pioneers. An urgent programme of interviewing and video- and audio-recording pioneers has been started, but is not progressing well due to lack of suitable interviewers. The above paragraphs describe most of the CCS activities. However, ambitions are wider. Some members are also active in getting Bletchley Park, where cryptanalysis was done in the last World War, together with some of the remaining Huts, saved for the nation. It looks as though they will succeed. The very large site and buildings will, among other things, house a Museum of Cryptography, and possibly a Museum of Computing. It will provide a permanent and spacious base for the CCS, which will be able to work on old systems of its own as well as of the Science Museum. It is expected that there will be adequate storage space, so that early artefacts and documents can be properly stored and worked-on. In the meantime, the CCS is grateful to accept objects, particularly if the owner can hold on to them for a few more months. Finally, although this posting has been intended to expose the activities of the CCS and not as a recruiting drive, if you feel you would like to join then send an application to the Secretary of the CCS, 15 Northampton Road, Bromham, Bedfordshire MK43 8QB, UK. You will be put on a "steam" mail list on a database. He would like to know: Your name and address, post code and phone number Your BCS membership number if any. (membership of BCS is NOT a requirement) Your personal experience of which early computers as what (designer, builder, maintainer, user or whatever). Younger people not experienced on early machines are particularly welcome if they are willing to learn from us old-timers while we are still lucid. Your experience with hardware technologies (delay lines, drums, tapes, valves, early transistors, card and tape readers and punches etc) Do you have early programs, either tape, cards or coding sheets which you are willing to share by copying. Your willingness to help with recording the history of computing. Your willingness to help with restoration of computers. Ask him if he has a recent issue of "Resurrection" for you to sample. Sorry, very few of us have email access, so we have to work via postal service. {I have not seen any other newsgroups to cross-post this to - .folklore is not quite the right one. If anyone has any other ideas I'd be glad to cross-post.} >snip------ But as you see, I have been persuaded to cross post! -- Chris P. Burton, not far from Oswestry, Shropshire, UK. From supnik@human.enet.dec.com Sat Feb 12 14:31:43 EST 1994 Article: 640 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!agate!ames!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: How does a PDP8 boot? Date: 11 FEB 94 18:46:19 Organization: Digital Equipment Corporation Lines: 38 Message-ID: <2jh5mv$6fq@sousa.ako.dec.com> NNTP-Posting-Host: human.enet.dec.com Summary: How does a PDP8 boot? Keywords: PDP8, bootstrap I'm hunting up information on how the PDP8 boots. 1. Off RK8E. The bootstrap reads cylinder 0, surface 0, sector 0 into locations 0-377(8). The bootstrap is located so that it sits in a loop 31/ DSKP 32/ JMP .-1 even as the boot block is read over it. When the read completes, the code at location 33 is the start of the actual boot routine. (From Bill Haygood's simulator and OS/8 simulated disk.) 2. Off RX8. The bootstrap reads track 1, sector 1 into the buffer, and then empties the buffer into memory starting at location 2 (not 0). The empty buffer loop is locationed at 47/ JMS 53 50/ DCA 2 /modified by next instruction 51/ ISZ 50 52/ JMP 47 53/ 0 54/ STR 55/ JMP 33 /tests for done, if not, jmps to 54 56/ XDR 57/ JMP I 53 Since the buffer is 64(10) words long, this loop will overwrite itself as it empties the buffer; I presume the boot block is set up to allow this. (From the RX01/RX02 Pocket Service Guide; I don't have an RX01 disk image to look at.) Can anyone confirm, deny, or add detail to the above? Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From lasner@sunSITE.unc.edu Sat Feb 12 14:35:53 EST 1994 Article: 641 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: How does a PDP8 boot? Date: 12 Feb 1994 19:31:32 GMT Organization: University of North Carolina, Chapel Hill Lines: 388 Sender: Charles Lasner Message-ID: <2jjaqk$e1l@bigblue.oit.unc.edu> References: <2jh5mv$6fq@sousa.ako.dec.com> NNTP-Posting-Host: calypso.oit.unc.edu Summary: All you ever wanted to know about PDP-8 boot, but were afraid to ask Keywords: PDP8, bootstrap > >I'm hunting up information on how the PDP8 boots. > >1. Off RK8E. The bootstrap reads cylinder 0, surface 0, sector 0 into > locations 0-377(8). The bootstrap is located so that it sits in > a loop > > 31/ DSKP > 32/ JMP .-1 > > even as the boot block is read over it. When the read completes, > the code at location 33 is the start of the actual boot routine. > (From Bill Haygood's simulator and OS/8 simulated disk.) > Since you want *accurate* info, I will take you task on the description above. There are basically three ways a prevailing PDP-8 operating system boots: 1) DMA-style 2) Program-transfer style 3) Exceptions to 1) and 2) The only standard exception to 1) and 2) is the RX which will be handled below. DMA style is the simplest to explain. Basically, an operation is initiated by the code placed in memory by the primary boot process. This initial code may come from a ROM or manual toggle-in, but the point is that this code does not come from the disk device itself. Generally, the primary boot code has some form of wait loop. In some cases, that looks sort of like: DSKP JMP .-1 In this form, the done flag is being waited for, and eventually it skips. Assuming this code *doesn't change* then eventually the flag skips causing the next instruction after the JMP .-1 to come into play, etc. However, there are two variants to what happens here depending on the type of boot. The first type of boot is the one usually documented for TC01/08 DECtape (and notably it's far longer than necessary!). The boot code that checks for the done flag skip is *not* overlayed. Thus, the code that follows the JMP .-1 is provided as part of the primary bootstrap code itself. In general, it's likely little more than a JMP to the code just read in, etc. This implies that the code read in is ready to go, and just merely needs to be started at the correct location. In this instance, the primary boot is a simple image loader for the secondary boot code brought in from the disk device. In the case of the TC01/08 boot, this is *not* the only way to achieve a correct boot! The alternative is that the waiting loop is itself placed in the midst of the DMA buffer! In this case, the device-read code overlays the waiting loop as the DMA occurs. The device-read code may even modify the wait loop as it waits! Generally the second method achieves the shortest primary code for the benefit of manual toggle-in. In the case of the RK8E, it's the standard method: *30 /THE STANDARD SHORT BOOT STARTS HERE 6743 /DLAG, WHICH READS IN SECTOR 0 JMP . /WAIT FOR OVERLAY The program is waiting at 0031 for something to happen. As the DMA starts, it first loads 00000, then 00001, etc. Eventually, it loads 00031 with a JMP to a lesser location such as 00004. (This is the secondary code in the O/S on the disk. Each system can do it a little differently. Constrained by this boot method, the RK8E requires each O/S to make the data overlaying 0031 to be a JMP to a lesser location between 00000 and 00030.) Thus, the just-read code is now waiting for a done flag, but this execution between DMA cycles is occurring at 00004-00005 or somesuch. Eventually the rest of the record is read into all locations through 00377, the done flag raises, and the waiting code skips to now execute additional secondary code to do whatever is required, generally to cause additional records to be brought into memory, and likely to move the code in 00000-00377 elsewhere, such as into 07600-07777 and/or 17600-17777 as required by the system. Often advantage is taken by the fact that some of the locations are the auto-index registers, now preloaded to useful values towards this endeavor of moving blocks of data, etc. Note that the TC01/08 DECtape can use either method. When the overlaying method is chosen, there is a standard among DECtape systems that a wait loop generally exists at 07616-07617. Each DECtape O/S places DTSF;JMP .-1 over these locations as the DMA occurs to ensure the overlay boot can succeed, etc. Note that in the non-overlaying case, the DECtape routine just read in is completely ready to continue the secondary boot process if you start it at 07600. Thus, most non-overlaying (and longer) boot routines wait for the done flag and JMP (indirectly) to 07600. The RK8E *only* supports the overlay form of boot! Not only is it shorter, but due to limitations of the RK hardware, it's the only way to accomplish it due to space limitations. The RK boot convention is to include in the AC the unit number, because the hardware cannot self-interrogate to find this info out at the point of booting. The longer form of the primary boot code does a few extra instructions to load an additional register for the unit number, and it also places that info in the AC. As the DMA occurs and overlays the JMP ., the first thing that must be done is to save the AC passed in from the primary boot, as it contains the unit number needed later. Were a non-overlaying boot allowed, there would have to be an alternate convention of where to JMP to for the purpose of saving the passed unit number, etc. While I haven't investigated what was implied above, it appears that the boot procedure in the emulator may be defective, and may only coincidentally work for OS/8 packs! In order to qualify correctly, the boot has to work as I have described it. The more general form of the boot is as follows: *25 /WHERE LONGER BOOT LOADS LAS /GET UNIT NUMBER INTO THE SWITCHS DLDC /LOAD UNIT NUMBER; AC GETS CLEARED! DLAG /START THE DISK UP (AC CLEAR) LAS /RE-ESTABLISH UNIT NUMBER IN AC JMP . /WAIT FOR OVERLAY The first switch-register read sets up the unit number. The DLAG is issued with a clear AC to read in sector 0, etc. The second switch-register read will inform the secondary code that it's coming in on the selected pack. (The shorter boot can only boot unit 0.) Note that devices such as the DF32, RF08, and TC01/08 also have to setup the 3-cycle data break locations in 7750-51 or 7754-55. As the image of block 0000 is read in, each location overlays the word count location or current address locations as required, to either maintain, modify, or even extend the transfer as required. In the case of TC01/08 DECtape, the external boot allows these locations to just count normally, then a JMP to 7600 starts up a secondary operation in the just-read-in handler that sets up for further O/S-specific transfers. The overlay boot will place the same values over these locations as they already are at the precise point of progressive DMA operations, etc. This is the method OS/8 uses in the case of overlay boot. In the P?S/8 case, the process is taken one step further: As the DMA progresses, the word count and current address locations are modified to continue the transfer, as the memory layout of P?S/8 is such that if the next 17 octal blocks are read in order into 00000 onward, the system is just about up. Thus, when P?S/8 is booted, the tape does *not* rock forward and back, but rather just comes up in one smooth motion (and of course faster!). (Of course if the external method is used, P?S/8 has to search backwards, turn around, come forward and accomplish that transfer, the same way OS/8 always does it, etc.) Both OS/8 and P?S/8 can take advantage of the overlay form of boot on DECtape, thus it is possible to create bootstraps that end with waiting code of *7616 DTSF JMP .-1 or even *7617 JMP . depending on the rest of the primary code. An additional note about the data break type of boot: Generally, because of where the data break locations are, the boot process is constrained to operate within 07600-07777 so that an on-page reference to the locations can be made, etc. Thus, there is an additional convention possible not shared by such as the RK8E (which loads into 00000 because the simplest boot is defined to do that; it takes too much manual effort to do otherwise, etc.) in that the overlaying code knows more intimately the environment it is bringing in with correct absolute addresses. Thus, one of the conventions of the TC01/08 is that a waiting subroutine defined at 7616-7617 and also adjacent locations will be completely read in by the boot process (should it be of the overlay type!). Thus, a typical boot practice is to preload the subroutine at about 7614 with a return address into once-only code within the handler. Thus, any original "call" is obliterated in favor of a transfer that furthers the boot process instead, etc. In the case of P?S/8, this allows the curious warm boot code located at 07600: Jumping to 07600 in P?S/8 TC01/08 starts up a conventional subroutine call to the handler to ask for block zero to be read into 07600-07777 directly! This would seem to ask the image of the handler to self-destruct! However, as the process starts, the waiting subroutine's return address is changed to a just-read-in address of a new routine that causes the additional transfers to occur precisely as if the overlay form of boot had occurred (waiting at 07616-07617), thus the boot process not only succeeds, but it's the single smooth motion kind as well! Thus, every time a program exits on this system, tape motion is minimized. A similar effect occurs in the DF32 and RF08 boot for OS/8 and P?S/8 in that the word count location need not be precisely set, just to avoid an amount that would transfer too few words to get the word count location overlayed. Most documented boot programs dictate that it be set to the same value as the current address (which must be set as stated!). In actuality, that value is just one of thousands of acceptable values, but it's also the one next required for the next toggled-in location (for the current address setting) so it's convenient to minimize switch register changes, etc. As the O/S secondary code is read in, the word count as overlayed with an O/S-dependent value that causes the proper amount of data to be read. The current address is always overlayed with itself, i.e., it points to the word after it as the next word to be transferred. Thus, the location is unchanged from its immediate pre-DMA value. Program Transfer Devices (other than the RX). Program transfer devices such as the TD8E actually work similar to DMA devices in terms of the overlay process. Most program-transfer devices require the overlay type of boot. As the waiting and storing loop gets device data, it blindly overlays the waiting loop itself. Thus, the data that overlays the waiting loop must be identical to the loop code itself. Generally, program transfer devices have precisely defined boot locations to ensure the ability of this one-at-a-time overlay to succeed. The trick of overlaying a return address can apply as well, but this constrains the device of supporting a precise form of waiting subroutine. (This is one of the major limitations of the RX!) It is possible for a program transfer device to support an external boot process as well, as long as the just-read-in code can have an alternate starting address aware of that method. The TD8E supports this convention so that the MR8E-C field 7 ROM can also boot the device. (Note: the MR8E-C is not required to run the non-ROM systems such as the 12K TD8E OS/8 system and 8K P?S/8 systems, but both of these systems can be booted by the ROM!) In that particular case, the ROM is started at 77470. (This value was chosen for minimal switch manipulation. You set the switches to 7470. This allows an extended address load to IF 70 and DF 00 and an address load to 7470 within the ROM.) Of course if the ROM versions of these systems are booted, their secondary code will presume the ROM is present and make direct calls to ROM code as required, etc. When a DMA overlay boot modifies a wait loop routine, it must overlay it with either the same code, or a JMP back to an earlier location already read in. When a program-transfer overlay boot modifies a wait loop routine, the same sort of thing applies. In some cases, the form of the wait loop is drastically changed at some point to serve the rest of the boot process. In any case, such an operation requires an overlay type boot, thus limiting the device to that form of boot operation unless there is also room in the disk data to handle the external boot case. (In the case of the RX, this isn't the case; see below.) >2. Off RX8. The bootstrap reads track 1, sector 1 into the buffer, > and then empties the buffer into memory starting at location 2 > (not 0). The empty buffer loop is locationed at > > 47/ JMS 53 > 50/ DCA 2 /modified by next instruction > 51/ ISZ 50 > 52/ JMP 47 > 53/ 0 > 54/ STR > 55/ JMP 33 /tests for done, if not, jmps to 54 > 56/ XDR > 57/ JMP I 53 > > Since the buffer is 64(10) words long, this loop will overwrite > itself as it empties the buffer; I presume the boot block is set > up to allow this. (From the RX01/RX02 Pocket Service Guide; I > don't have an RX01 disk image to look at.) This doesn't show the entire operation! Note that at 00055 there is a JMP 33. At 00033 there is a SDN followed by a JMP 54. This is known as a "figure-8" loop. The idea is that eventually the transfer flag will not come up anymore, and instead the done flag raises. At that point, the code *then* in memory decides what to do next in an O/S-dependent manner. What is typically done is that 00052 is eventually overlayed with something else, perhaps a JMP to an earlier location where a different transfer is initiated. A likely choice is to continue the transfer, but store into 00060 and following. The reason for all of this is that there is a design weakness in the RX preventing any future optimization not shared by any prior device! Unlike other devices, the RX has the dubious distinction of being the only device where some of the boot code cannot get overlayed. Not only must the boot code not overlay 00033 and 00034 with anything different from what's already presumed there, but also the code at 00047-00051. (00050 has to be overlayed with a DCA 50, which is what it is at the point of overlay.) The part *never* overlayed is the code at 00054-00057, thus all RX boots must assume the permanent presence of these locations. (00053 is a subroutine header which will also have to contain an appropriate value, but as 00052 is overlayed with something (typically a JMP to a lesser just-read-in location lower than 00033), the overlay code is aware of the appropriate address which is likely 00050 caused by the JMS 53 at 00047, etc.) Were 00054-00057 not "unreachable" by the secondary boot code, perhaps a more efficient bootstrap could be constructed. This will never happen as the locations are totally fixed at 00054-00057. Depending on which RX it is (RX01, 02, 50), transfers are made to various locations within the rest of 00000-00377, or are redirected into 17600-17777 or 27600-27777. Generally, the code is loaded into 00002 and following through the overlay of 00052 which then JMP's to a just-read-in routine to continue loading in 00060 and following until the done flag raises. At that point, the SDN in 00033 skips thus the just-read-in code at 00035 is in control, generally initiating another transfer, etc. Note that by fixing this bizarre form of boot method where the data neither loads into neat page boundary locations (perhaps on the "wrong" page needing to be moved to the "right" page ala the RK8E) nor does contiguous loading (the RK08 (NOT RK8E!) boot loads two contiguous pages one-off of a page boundary requiring an after-the-fact simple move of the pages-long data), forever makes the notion of an external boot process impossible. Each O/S has to "fend for itself" in terms of having a boot process that is initiated in a time-sequence-dependent way. Merely doing a contiguous load of record 0000 into an arbitrary location cannot get such a system up! This forever means that the boot process is inherently unreliable. You cannot write a general boot procedure for the device where a "smarter" boot program reads the data in after checking for errors, then transfers control to the just-read-in data. To do so would require a different program for each O/S's individual handlers, literally dozens of cases considering how many O/S's for the various RX systems there are (even though one master boot suffices for them all! That code is "cross-your-fingers-that-it-works only!) Additionally, in the case of all RX02 and most RX01, it's not possible to write-protect the device during the boot process, thus the system is vulnerable to corruption at this critical juncture. (RK8E can be write-protected; my 4-function 8/a boot code does a software-initiated write protect and boot on the selected drive, etc.) (Also note that most boot code looks very much like write code, since it's only a few bits different from read code!) (Of course, an emulator generally won't have problems like this, but there exists at least one emulator where the device is emulated on real hardware, i.e., diskettes. The possibility of an emulator foolishly carrying out the dictates of mis-read code does apply! Some pragmatic kludges can be applied as a partial safety net, such as disallowing device writes until there have at least some requisite number of reads, etc. However, there are perfectly normal boot circumstances in OS/8 where the boot process includes JMP'ing to 07600 which causes a write to occur!) As a consequence of the feebleness of the RX design, extra pains had to be taken to boot P?S/8 on it. In fact, the overall design of the system was changed primarily to accommodate the RX! Before considering the RX, P?S/8 had only seen devices that required one or two page handlers. The RK increased that requirement to 4-page handlers (P?S/8 addresses the RK disk to the nearest one-half physical sector, a technique used later in some CP/M and early MS-DOS systems such as a logically subdivided diskette with 1K physical sectors, etc. In all of these systems, a buffer is required to hold the image of the physical sector. The code to manage this in P?S/8 fits in two pages; the buffer is an additional two pages within the handler space, etc.). The RX has caused the latest P?S/8 definition to be a total of 9 pages. Thus, a P?S/8 system handler either totally resides in 07600-07777 and the system can be configured to run in 4K minimum, or it is presumed to also need x6000-x7777 where x is field 1-7 as available. Thus, the minimum configuration is 8K in these cases. (Note: most of these cases cause OS/8 to require 12K!) However, by allowing that much space for the handler, excellent error recovery and performance are possible. *EVERY* OS/8 RX handler is compromised! > >Can anyone confirm, deny, or add detail to the above? > >Bob Supnik >Supnik@human.enet.dec.com > >All opinions expressed are those of a hardline microcoder > >and do not reflect those of Digital Equipment Corporation cjl From lasner@sunSITE.unc.edu Sat Feb 12 14:46:37 EST 1994 Article: 642 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Pdp8-lover's list archives, etc. Date: 12 Feb 1994 19:45:44 GMT Organization: University of North Carolina, Chapel Hill Lines: 33 Sender: Charles Lasner Message-ID: <2jjbl8$a5d@bigblue.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu Excerpted from a recent post of mine to pdp8-lovers: Recently I have been organizing the older archives of this list. Files from several sources have contributed to a hopefully complete collection. In the interests of "better late than never" I will attempt to respond to some issues raised over the years. The original posting date will be included in the (somewhat trimmed) original articles, etc. Archives will be available on sunsite.unc.edu in the directory /pub/academic/computer-science/history/pdp8/pdp8-lovers Files are organized by months starting from the list's inception in February, 1989. Files are named similarly to the alt.sys.pdp8 archives held in the adjacent directory ../usenet/alt.sys.pdp8. 8902.lov for February, 1989 8903.lov for March, 1989 8904.lov for April, 1989 etc. Anyone who believes they can contribute to the accuracy of the archive should first retrieve the corresponding month's file to see how well we have done, etc. Note: some months may be entirely missing due to circumstances (either the list was temporarily defunct or no activity or just no known record for that period, etc.). Anyone who can fill in any "gaps" is requested to do so, etc. cjl From lasner@sunSITE.unc.edu Sat Feb 12 14:55:30 EST 1994 Article: 643 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Anyone know where this is? Date: 12 Feb 1994 19:54:25 GMT Organization: University of North Carolina, Chapel Hill Lines: 17 Message-ID: <2jjc5h$efa@bigblue.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu The following is taken from a post to pdp8-lovers in May, 1989. To: Johnny Billquist Cc: "Christopher R. Zach" , wally@aerospace.aero.org, PDP8-LOVERS@mc.lcs.mit.edu, wally@lcs.mit.edu Date: Wed, 17 May 89 15:59:45 -0700 From: wally@aerospace.aero.org [...] I have a program CCF (copy coded file) that will compress text. Anyone have a copy of this program, preferably in source form? It could be useful to further the present-day archiving, etc. cjl From lasner@sunSITE.unc.edu Sat Feb 12 21:35:38 EST 1994 Article: 644 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Anyone know about PDP-8/e with cache? Date: 13 Feb 1994 02:34:26 GMT Organization: University of North Carolina, Chapel Hill Lines: 15 Message-ID: <2jk3ji$ccc@bigblue.oit.unc.edu> References: <2jjc5h$efa@bigblue.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu The following is taken from a post to pdp8-lovers in May, 1989. To: pdp8-lovers@mc.lcs.mit.edu Subject: PDP8/E with CACHE Date: Fri, 19 May 89 05:04:17 PST From: fucich@venera.isi.edu A PDP-8 with cache was designed and constructed by Professor David Casasent at Carnegie-Mellon University. This has a performance factor of 5 in comparison to the PDP8/E without cache. There is an article in Computer Design, pp. 83-89 Nov. 1971. Anyone have more info? cjl From lasner@sunSITE.unc.edu Sun Feb 13 12:38:38 EST 1994 Article: 645 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Belated response to an old issue Date: 13 Feb 1994 17:37:42 GMT Organization: University of North Carolina, Chapel Hill Lines: 175 Sender: Charles Lasner Message-ID: <2jloh6$1l6@bigblue.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu The following is an excerpt from an original post to pdp8-lovers in May, 1989. Date: 31-May-89 22:48:46 +0200 From: Johnny Billquist To: pdp8-lovers@mc.lcs.mit.edu Subject: Expansion and memory... I have a question for all you initiated omnibus eighters out there. First of all. I have an 8/e, with an 8/a used as an expansion box. I also have a paper, from dec, which tells a little about expansions for the 8/e. The funny thing is, that this paper, specifies that the backplane having the memory (the box with that backplane I mean) ALWAYS should be on top. They make this extremely clear. However, when I put together my current configuration, I hadn't read this paper, and naturally (according to Murphy) I put the 8/e, with all controllers on top, and the 8/a box, with memory below. Now, this works just fins, never had any problems at all, so why does (did) DEC think that one NEVER should do this? Just curious... Johnny I don't have a definitive answer, but I can explain why JB's stated configuration goes against the configuration guide. The designated way to connect the system he describes (incidentally, my current main system *is* as DEC describes) is to place the 8/e on the bottom and thus the 8/a on top. The key mechanical reasons are that the following key cards are placed thus: 1) KK8E cpu cards in front buss of 8/e box. 2) Terminator in top slot of 8/a box. This placement is considered mandatory; there's an ECO to the M8320 also mandatory which consists of *removing* a half-watt resistor. The reason is that it's extraneous but harmless on the 8/e box but can be detrimental to the 8/a box. It tends to "leak" DC between the full-power and standby-power legs for the purposes of preserving memory contents during short power outages (MOS memory in boxes with batteries) and will confuse the power-low/power-empty sequences, etc. 3) The interconnect cable is always taken from the back of the 8/e box and is also always taken from the bottom of the 8/a box. Note that there are several constraints within the 8/a box: 1) All memory-related cards must be in the top slots because of KT8A considerations (fifth-foot). 2) The option boards have to be in slots 2 and 3 (because of the power-low/power-empty wiring. 3) The KK8F (8/e) CPU *must* be used. With the terminators on the wrong end of the buss, the KK8A card cannot span more than one short-buss box, etc. If the KK8E is in the 8/a box, it has to be at the bottom end because that's the only place to arrange the CPU with EAE. Since there is an interconnect, the cable goes there instead with the CPU in the other box. While not recommended in the guide as far as I can tell, I have seen in-house installations at DEC where they do it all "backwards", i.e., the CPU is in the bottom slots of the 8/a box, and then the interconnect cable runs from the top slot to the back of the 8/e box. The terminator is in the next-to-front slot, just behind the 8/e front panel. I have also seen in-house dual 8/e box systems done this same way. I suspect it's all part of some "conventional wisdom" the field circus guys invented back when the KK8F was in need of lotsa long-buss oriented ECO's that came later. (It's conceivable that when an early CPU was too flakey to run a particular system in two boxes, reversing the order this way changed buss reflections enough that the system did work a bit more reliably. The guide was written long after these ECO's became standard.) In any case, the original issue had to do with which box raises over which box. Part of the answer lies with the interconnect cables: When either 2 8/e boxes or 2 8/a boxes are inter-connected, the designated cabling is 2 pieces of BC08H cable, usually 4.5 feet long (-4f). When the specific configuration is used, an obscure variation is used, the BC-80C cable. This is a number that "fell through the cracks" and has always been extremely difficult to obtain, even when it was relatively new. Part of the problem is that it made it's first appearance as part of the "FPP-8/e" which is the FPP-8/a cards packaged in a 12-slot box to be added onto the back of an 8/e box. The BC-80C cable is a hex board with plated-through holes that "criss-cross" the buss connections. Attached to the card are two white Omnibus cables that terminate the same way as a BC08H, etc. Thus, the cable is designed to come out of the bottom of the 8/a box and have the white cables run underneath it in the crack between the bottom of the 8/a box and a *covered* 8/e box. (Leaving off the 8/e box cover will destroy the cable; many of us are "guilty" of leaving the cover off on an 8/e-only system!) Thus, it's impossible to put the 8/a box beneath the 8/e box. I suspect that the configuration guide assumes the use of 8/a memory, thus the guidance is misguided :-). I also suspect that JB didn't use the BC-80C cable, and instead attempted some "applied origamy" using a pair of BC08H cables to create a non-standard connection. (Note: this is ugly, but functional! Picture the problem of connecting an 8/a box to an 8/e box where the cards run the "wrong" way. Folding the cables is unavoidable!) While I do use a 20-slot box, my BC-80C cable was taken from an FPP-8/e. I was never able to acquire it as a part, nor even find it in any DEC parts guide (known to be notoriously inaccurate on all counts: part numbers, availability, and price). (A digression to a "war story" on the DEC parts front: DEC parts catalogs were merely printouts of LPT output reduced a little and printed on the cheap paper typically used for handbooks, etc. Clearly a computer-based database. Certain parts were priced on a quantity 10 basis, but sometimes stated as a unit price which you then had to multiply by 10 to get your cost, since 1 could not be purchased, etc. When inconsistent methods are used to state cost, mistakes are bound to be made. In the course of this, the blunder was made that made it appear that the DECtape drive guides were of grossly unequal price, i.e., the left guide cost about ten times the right guide! I had to purchase replacement guides, and had to argue with a parts salesman over why it was a typo because in the previous catalog, each part was the same price, albeit both about 15% cheaper. The guy was quite "inventive" and concocted an explanation: He *knew* that DEC had switched vendors for left-hand guides, but not right-hand guides! Many phone calls later, I eventually found someone who would listen to me about the concept of a mistake in the database. I was able to order them at equal price, but he refused to have the database corrected. (I suspect they were under some form of "computers can do no wrong" policy.) As the years went by, there were various managerial manipulations of parts price. essentially, the older the part was, the more they jacked up the price to discourage you from maintaining the equipment. I'll leave it to some business major to discuss justifying 100's of percent increase in general; DEC's business practices have gotten them to where they are today, etc. In any case, because the two parts were never re-synced, they developed independent price-growth changes, apparently placed into separate price increase tiers, etc. Curiously, this is partially self-correcting! At some point, the right guide was "only" six times as expensive as in the last catalog before the incessant price rises while the left guide, elevated by a factor of ten already, had only doubled in cost! Thus, instead of staying at a ratio of 10:1, the prices "converged" on being only 3.3:1.) None of the parts people were ever able to identify the BC-80C. Some of our readers have seen my machine; the part is quite real! A question to a.s.p readers who are also on the pdp8-lovers list: Is there a need to repeat items such as this, generated by past posts to pdp8-lovers, on the pdp8-lovers list, or is the propagation today sufficient via a.s.p? I suspect that many of the original pdp8-lover's list people are a.s.p people today. Please e-mail me if you have any ideas along these lines, etc. In any case, I will continue to make "belated responses" where the topic warrants, etc. cjl ps: Does anyone have any expertise in setting up a listserver so that pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically mailed to the requestor? From bqt@Update.UU.SE Tue Feb 15 17:47:31 EST 1994 Article: 646 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!columba.udac.uu.se!bqt From: bqt@Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: Belated response to an old issue Date: 15 Feb 1994 12:54:06 GMT Organization: Uppsala University Lines: 160 Message-ID: <2jqgle$knd@columba.udac.uu.se> References: <2jloh6$1l6@bigblue.oit.unc.edu> NNTP-Posting-Host: krille.update.uu.se In <2jloh6$1l6@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >The following is an excerpt from an original post to pdp8-lovers in May, >1989. Wow. Long time ago. And I even remember it. (Yikes. :-) >Date: 31-May-89 22:48:46 +0200 >From: Johnny Billquist >To: pdp8-lovers@mc.lcs.mit.edu >Subject: Expansion and memory... >I have a question for all you initiated omnibus eighters out there. >First of all. I have an 8/e, with an 8/a used as an expansion box. >I also have a paper, from dec, which tells a little about expansions >for the 8/e. The funny thing is, that this paper, specifies that >the backplane having the memory (the box with that backplane I mean) >ALWAYS should be on top. They make this extremely clear. >However, when I put together my current configuration, I hadn't read >this paper, and naturally (according to Murphy) I put the 8/e, with >all controllers on top, and the 8/a box, with memory below. >Now, this works just fins, never had any problems at all, so >why does (did) DEC think that one NEVER should do this? > Just curious... > Johnny >I don't have a definitive answer, but I can explain why JB's stated >configuration goes against the configuration guide. >The designated way to connect the system he describes (incidentally, my >current main system *is* as DEC describes) is to place the 8/e on the >bottom and thus the 8/a on top. >The key mechanical reasons are that the following key cards are placed thus: >1) KK8E cpu cards in front buss of 8/e box. >2) Terminator in top slot of 8/a box. This placement is considered >mandatory; there's an ECO to the M8320 also mandatory which consists of >*removing* a half-watt resistor. The reason is that it's extraneous but >harmless on the 8/e box but can be detrimental to the 8/a box. It tends >to "leak" DC between the full-power and standby-power legs for the >purposes of preserving memory contents during short power outages (MOS >memory in boxes with batteries) and will confuse the power-low/power-empty >sequences, etc. >3) The interconnect cable is always taken from the back of the 8/e >box and is also always taken from the bottom of the 8/a box. >Note that there are several constraints within the 8/a box: >1) All memory-related cards must be in the top slots because of KT8A >considerations (fifth-foot). >2) The option boards have to be in slots 2 and 3 (because of the >power-low/power-empty wiring. >3) The KK8F (8/e) CPU *must* be used. With the terminators on the >wrong end of the buss, the KK8A card cannot span more than one short-buss >box, etc. If the KK8E is in the 8/a box, it has to be at the bottom end >because that's the only place to arrange the CPU with EAE. Since there >is an interconnect, the cable goes there instead with the CPU in the other >box. >While not recommended in the guide as far as I can tell, I have seen >in-house installations at DEC where they do it all "backwards", i.e., the >CPU is in the bottom slots of the 8/a box, and then the interconnect >cable runs from the top slot to the back of the 8/e box. The terminator >is in the next-to-front slot, just behind the 8/e front panel. I have >also seen in-house dual 8/e box systems done this same way. I suspect >it's all part of some "conventional wisdom" the field circus guys >invented back when the KK8F was in need of lotsa long-buss oriented ECO's >that came later. (It's conceivable that when an early CPU was too flakey >to run a particular system in two boxes, reversing the order this way >changed buss reflections enough that the system did work a bit more >reliably. The guide was written long after these ECO's became standard.) >In any case, the original issue had to do with which box raises over >which box. Part of the answer lies with the interconnect cables: >When either 2 8/e boxes or 2 8/a boxes are inter-connected, the >designated cabling is 2 pieces of BC08H cable, usually 4.5 feet long (-4f). >When the specific configuration is used, an obscure variation is used, >the BC-80C cable. This is a number that "fell through the cracks" and >has always been extremely difficult to obtain, even when it was >relatively new. Part of the problem is that it made it's first >appearance as part of the "FPP-8/e" which is the FPP-8/a cards packaged >in a 12-slot box to be added onto the back of an 8/e box. >The BC-80C cable is a hex board with plated-through holes that >"criss-cross" the buss connections. Attached to the card are two white >Omnibus cables that terminate the same way as a BC08H, etc. Thus, the >cable is designed to come out of the bottom of the 8/a box and have the >white cables run underneath it in the crack between the bottom of the 8/a >box and a *covered* 8/e box. (Leaving off the 8/e box cover will destroy >the cable; many of us are "guilty" of leaving the cover off on an >8/e-only system!) Thus, it's impossible to put the 8/a box beneath the >8/e box. >I suspect that the configuration guide assumes the use of 8/a memory, >thus the guidance is misguided :-). >I also suspect that JB didn't use the BC-80C cable, and instead attempted >some "applied origamy" using a pair of BC08H cables to create a >non-standard connection. (Note: this is ugly, but functional! Picture >the problem of connecting an 8/a box to an 8/e box where the cards run >the "wrong" way. Folding the cables is unavoidable!) (Sorry about including all the message, but I didn't see any good places for cutting, and not any good places before here to insert my comments.) Well, the system in question is in storage right now, so I can't open it up. But I'll go on my memory for this one. The CPU is right behind the 8/e panel. The cables are unibus-cables, and connect at the back end of the 8/e, and the top of the 8/a. I have two 16K core memories in the 8/a box. The terminator (M8320) is in the bottom of the 8/a. So, no twisted cables, no funny stuff at all, just things placed very backwards to what DEC said. >A question to a.s.p readers who are also on the pdp8-lovers list: >Is there a need to repeat items such as this, generated by past posts to >pdp8-lovers, on the pdp8-lovers list, or is the propagation today >sufficient via a.s.p? I suspect that many of the original pdp8-lover's >list people are a.s.p people today. Please e-mail me if you have any >ideas along these lines, etc. In any case, I will continue to make >"belated responses" where the topic warrants, etc. There are probably some people who might find it interesting. I do at times. (But I have yet to see you make a short answer to anything, cjl. :-) >cjl >ps: Does anyone have any expertise in setting up a listserver so that >pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically >mailed to the requestor? Nope. But if someone have the software, I might be able to set it up on a machine. But why not just making it available for anonymous ftp. There are ftpmail servers on many machines on the net, which can then help those who only have mail access. 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 lasner@sunSITE.unc.edu Tue Feb 15 18:13:05 EST 1994 Article: 647 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Belated response to an old issue Date: 15 Feb 1994 23:10:38 GMT Organization: University of North Carolina, Chapel Hill Lines: 81 Message-ID: <2jrkpe$o2h@bigblue.oit.unc.edu> References: <2jloh6$1l6@bigblue.oit.unc.edu> <2jqgle$knd@columba.udac.uu.se> NNTP-Posting-Host: calypso.oit.unc.edu In article <2jqgle$knd@columba.udac.uu.se>, Johnny Billquist wrote: >In <2jloh6$1l6@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: > >The CPU is right behind the 8/e panel. That's the recommended configuration. >The cables are unibus-cables, and connect at the back end of the >8/e, and the top of the 8/a. Nope. Those are BC08H cables. They superficially look like Unibus cables. They are wired differently. Actually, Unibus cables are weird; these BC08H cables are essentially straight-through wiring. >I have two 16K core memories in the 8/a box. Two MM8AB, same as me. >The terminator (M8320) is in the bottom of the 8/a. Consistent with this non-standard method. >So, no twisted cables, no funny stuff at all, just things >placed very backwards to what DEC said. No, wrong. Neglecting the fact that the 8/a has cards vertically stacked over each other and the 8/e has them stacked horizontally (the chassis essentially are 90 degreees out-of-phase with each other :-)) the cards in the 8/a box face backwards. Berg connectors exit on the right in the 8/a; the left in the 8/e. In order to make that work (i have done it) you have to twist the two cables over each other, as I indicated. The BC-80C does the "twisting" for you in its etch so the cables come out the way you would expect. In any case, I agree with the electrical routine being "backwards" doesn't matter. I explained my ideas that the configuration guide is mis-using its own reasoning to merely arbitrate what is actually just statistically likely. But clearly, DEC's guidance rules are based on using the correct cabling. Only the BC-80C applies here. The BC08H pair is for use with a pair of like boxes only. > >>A question to a.s.p readers who are also on the pdp8-lovers list: > >>Is there a need to repeat items such as this, generated by past posts to >>pdp8-lovers, on the pdp8-lovers list, or is the propagation today >>sufficient via a.s.p? I suspect that many of the original pdp8-lover's >>list people are a.s.p people today. Please e-mail me if you have any >>ideas along these lines, etc. In any case, I will continue to make >>"belated responses" where the topic warrants, etc. > >There are probably some people who might find it >interesting. I do at times. (But I have yet to see >you make a short answer to anything, cjl. :-) That isn't the question! I just want to know if the pdp8-lovers list has to be "cross-posted" in this regard. Since the questions of this form are from that far back, is there a need to also post to the list, or is everyone from back then now reading alt.sys.pdp8? In fact, can anyone provide some kind of net.statistics about who is on the mailing list *not* also on a.s.p? > >>cjl > >>ps: Does anyone have any expertise in setting up a listserver so that >>pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically >>mailed to the requestor? > >Nope. But if someone have the software, I might be able to >set it up on a machine. >But why not just making it available for anonymous ftp. >There are ftpmail servers on many machines on the net, which >can then help those who only have mail access. Anyone know what/how to do this? cjl From steveq@swifty.dap.CSIRO.AU Wed Feb 16 20:16:11 EST 1994 Article: 648 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!agate!msuinfo!harbinger.cc.monash.edu.au!bruce.cs.monash.edu.au!merlin!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!steveq From: steveq@swifty.dap.CSIRO.AU (Stephen Quigg) Subject: Re: Belated response to an old issue Message-ID: Sender: news@syd.dms.CSIRO.AU Nntp-Posting-Host: swifty.dap.csiro.au Organization: CSIRO, Division of Applied Physics, Sydney References: <2jloh6$1l6@bigblue.oit.unc.edu> Date: Sun, 13 Feb 1994 21:50:34 GMT Lines: 29 In article <2jloh6$1l6@bigblue.oit.unc.edu>, Charles Lasner wrote: >The following is an excerpt from an original post to pdp8-lovers in May, >1989. > >Date: 31-May-89 22:48:46 +0200 >From: Johnny Billquist >To: pdp8-lovers@mc.lcs.mit.edu >Subject: Expansion and memory... > >Note that there are several constraints within the 8/a box: > >1) All memory-related cards must be in the top slots because of KT8A >considerations (fifth-foot). > >2) The option boards have to be in slots 2 and 3 (because of the >power-low/power-empty wiring. > >1) All memory-related cards must be in the top slots because of KT8A >considerations (fifth-foot). > >2) The option boards have to be in slots 2 and 3 (because of the >power-low/power-empty wiring. > Also, the boot switch (switches if you have both panels), need the option boards in slots 2, 3 to work. From steveq@swifty.dap.CSIRO.AU Wed Feb 16 21:01:32 EST 1994 Article: 649 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!agate!msuinfo!harbinger.cc.monash.edu.au!bruce.cs.monash.edu.au!merlin!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!steveq From: steveq@swifty.dap.CSIRO.AU (Stephen Quigg) Subject: Front Panel Variations on PDP8's Message-ID: Sender: Stephen Quigg Nntp-Posting-Host: swifty.dap.csiro.au Organization: CSIRO, Division of Applied Physics, Sydney Date: Sun, 13 Feb 1994 21:56:27 GMT Lines: 13 I'd like to start another thread, FRONT PANEL VARIATIONS ON PDP8's. For instance, the 8e has at least 2 (not counting the MARS panel), depending on whether it has an 11 or 12 position switch. I never even noticed this until I tried swapping escutcheons and found that the switch didn't match the markings on the panel. I prefer the 11 position panel (I think it's the older of the two) because it has vertical lines grouping the lamps into groups of 3 to make life easier. I notice on the cover of one of the pdp8a small computer handbooks (1975?) a picture of an 8a programmers console. This is the only picture I've seen where the keypad has round buttons (instead of oval); also the layout of the lamps is a little different. Has anyone seen this panel? From jones@pyrite.cs.uiowa.edu Wed Feb 16 21:02:49 EST 1994 Article: 650 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Front Panel Variations on PDP8's Date: 16 Feb 1994 17:25:32 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 22 Distribution: inet Message-ID: <2jtkuc$hpt@nexus.uiowa.edu> References: NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article , by steveq@swifty.dap.CSIRO.AU (Stephen Quigg): > > I'd like to start another thread, FRONT PANEL VARIATIONS ON PDP8's. For > instance, the 8e has at least 2 (not counting the MARS panel), depending > on whether it has an 11 or 12 position switch. I assume you're referring to the rotary switch. The distinction shows up on page 4-2 of DEC's 1973 Introduction to Programming, where the artwork shows the version without the vertical lines, while the photo shows the vertical lines. You can also (just barely) tell that the switch in the photo has a slightly wider angular separation between the lines pointing to switch positions than the drawing. There's also the completely different front panel artwork for the Industrial -8. This is a PDP-8/E with a red and blue color scheme instead of the usual mustard and terracotta. My only PDP-8/E is this kind, and in addition to additional variations in the line work on the front, they painted the back of the plexiglass with a transparent red wash in order to make the incandescent lamps look like LEDs. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Wed Feb 16 21:03:09 EST 1994 Article: 651 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Belated response to an old issue Date: 17 Feb 1994 01:15:56 GMT Organization: University of North Carolina, Chapel Hill Lines: 17 Message-ID: <2juggc$9s7@bigblue.oit.unc.edu> References: <2jloh6$1l6@bigblue.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Stephen Quigg wrote: >In article <2jloh6$1l6@bigblue.oit.unc.edu>, >Charles Lasner wrote: >>2) The option boards have to be in slots 2 and 3 (because of the >>power-low/power-empty wiring. > > Also, the boot switch (switches if you have both panels), need the option >boards in slots 2, 3 to work. Yes. The SW function of the boot switch is available on any buss slot, but the card has to initiate a power-ok-not sequence, etc. To my knowledge, slots 2 and 3 are interchangeable? cjl From jones@pyrite.cs.uiowa.edu Wed Feb 16 21:17:09 EST 1994 Article: 652 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Some focal code Date: 16 Feb 1994 21:08:02 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 36 Distribution: inet Message-ID: <2ju1vi$mem@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu I was debugging the X-windows interface to my emulator, and I needed to make the thing burn cpu cycles while I tested the front panel behavior, so I wrote a little FOCAL program. It's a nice demo because it plots a curve on the output, using the classic TTY approach to curve plotting, and because anything that plots a curve that looks almost sinusoidal looks very technical, even if it isn't. Here's the code: *WRITE ALL C-FOCAL,1969 01.01 SET I=0 01.02 SET J=0.1 01.03 SET K=J-(I/10) 01.04 DO 2 01.05 SET I=I+J 01.06 SET J=K 01.07 GOTO 01.03 02.01 TYPE I,J," " 02.02 SET X=25+(10*I) 02.03 IF (-X) 02.04; SET X=0 02.04 IF (X-50) 02.05; SET X=50 02.05 IF (X) 02.09 02.06 TYPE " " 02.07 SET X=X-1 02.08 GOTO 02.05 02.09 TYPE "X",! Block 1 is the main program. Block 2 is the subroutine to do the output and curve plotting. It's not fast, but that just makes it look like it's really computing something interesting. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Wed Feb 16 21:17:45 EST 1994 Article: 653 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Front Panel Variations on PDP8's Date: 17 Feb 1994 02:01:16 GMT Organization: University of North Carolina, Chapel Hill Lines: 97 Message-ID: <2juj5c$ira@bigblue.oit.unc.edu> References: NNTP-Posting-Host: calypso.oit.unc.edu In article , Stephen Quigg wrote: > > I'd like to start another thread, FRONT PANEL VARIATIONS ON PDP8's. For >instance, the 8e has at least 2 (not counting the MARS panel), depending >on whether it has an 11 or 12 position switch. I never even noticed this until >I tried swapping escutcheons and found that the switch didn't match the >markings on the panel. I prefer the 11 position panel (I think it's the older >of the two) because it has vertical lines grouping the lamps into groups of >3 to make life easier. Not to complicate things, let's right now stick to consoles of the Omnibus machines, as opposed to other -8's and -12's, and also colors of switches and silkscreens! The standard 8/e panel comes in two variations. The original indeed detents at nice intervals so that STATE and BUS are 180 degrees apart. The switch is actually a multiple magnetic reed assembly and the knob turns a small magnet on a plastic shaft. The shaft is easily broken! Also, it can be turned indefinitely without stops. Sometimes it's useful to set it to a non-position which is easily done. Newer panels, or panels forced to be upgraded after the switch broke have a chincier rotary switch of conventional design with stops at the ends. The silk-screen lines have to be redrawn because the detents are a different number of degrees. Early variant 8/f-m panels exist that were ECO'd from 8/e panels. Some may even have the reed switch. Most have the wafer rotary switch. Production panels all have the wafer. The LED panel can be used in the 8/e; there's even a lug to hang the unused 8V supply lead to! The 8/e panel cannot be used in the 8/f-m because the switching power supply doesn't have that voltage tap available. If you remove the 330 ohm pre-heat resistors, you can use LED's on the 8/e panel. Data Display Products makes an excellent replacement similar to the LED replacement DEC used in late-production RK05 drives. The lamp has a built-in limiting resistor and uses the slide-in package. (The pre-heat resistor must be removed else the brightness for 1 vs. 0 is indistinguishable.) If you are fortunate to have one of the TC08 status panels with sockets, the DDP LED is a direct replacement. Color and intensity coming through the silkscreen dot are remarkably close to an incandescent bulb! There is a double-height card for the Omnibus that functions as an SW switch for limited configurations, similar to that for the 8/m or an 8/a sans the octal readout panel ("linited function panel"). I've seen the card, but there's supposed to be a little panelette for it to be mounted near a power switch on a desk, etc. Years ago, some company made a hand-held calculator-type front panel for the Omnibus. A short-lived company designed a front panel that was meant to be between the console teletype and the Omnibus. The card doubled as device 03/04 until the break key was hit. At that point further keystrokes were directed at the front panel, not the -8. Single-letter commands can access all registers and restart the -8, etc. CESI got the rights to this card and expanded on it to produce the AFP8 or "ASCII Front Panel 8". This card does the same as the earlier prototype, but also includes a real-time clock that is quite incompatible with all others but also does a lot more. It includes a battery-driven clock/calendar chip to keep track of date/time as well as a tick interrupt, etc. Also, the front panel function can address the extended memory functionality of the KT8A and the MEC8 (128K or 512K). DEC produced low-volume ("Computer Special Systems") products that were a hardware breakpoint box (fetch/exec stop) and the "MARS" panel. I have both panels, but alas, neither module to run them :-(. The breakpoint module can stop the machine on any combination of FETCH to a 15-bit address or EXEC to a 15-bit address. DECUS once published the prints of a dual-device of this type; that way you could have both types of trap simultaneously, etc. There was a third-party company that produced a successful module called Computer Interface Systems, Inc. It can trap on one match only similar to the DEC version. The address is dialed up with 5 digit wheels. The controls are available in a hand-held or panel-mounted variation that plugs into the breakpoint module itself. If more than one panel (8/e and 8/a for instance, as on my own machine!) is present, be wary of the OR-ing of the switch register, and also of the indicators bits on the Omnibus. Four of the available displays can only be generated by a unique combination of these bits, thus an incompatible display setting makes (at least one!) of the displays read the wrong register. >I notice on the cover of one of the pdp8a small >computer handbooks (1975?) a picture of an 8a programmers console. This is >the only picture I've seen where the keypad has round buttons (instead of >oval); also the layout of the lamps is a little different. Has anyone seen >this panel? > Any of these variations apply to the 11/34 family? cjl From lasner@sunSITE.unc.edu Wed Feb 16 21:18:05 EST 1994 Article: 654 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Some focal code Date: 17 Feb 1994 02:16:56 GMT Organization: University of North Carolina, Chapel Hill Lines: 35 Message-ID: <2juk2o$hn1@bigblue.oit.unc.edu> References: <2ju1vi$mem@nexus.uiowa.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article <2ju1vi$mem@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: < <*WRITE ALL References: <2jloh6$1l6@bigblue.oit.unc.edu> <2jqgle$knd@columba.udac.uu.se> <2jrkpe$o2h@bigblue.oit.unc.edu> NNTP-Posting-Host: krille.update.uu.se In <2jrkpe$o2h@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article <2jqgle$knd@columba.udac.uu.se>, >Johnny Billquist wrote: >>In <2jloh6$1l6@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >> >>The CPU is right behind the 8/e panel. >That's the recommended configuration. >>The cables are unibus-cables, and connect at the back end of the >>8/e, and the top of the 8/a. >Nope. Those are BC08H cables. They superficially look like Unibus >cables. They are wired differently. Actually, Unibus cables are weird; >these BC08H cables are essentially straight-through wiring. Sorry, but when I say they are Unibus-cables, they are Unibus-cables. I grabbed them right out of a pdp-11. >>I have two 16K core memories in the 8/a box. >Two MM8AB, same as me. >>The terminator (M8320) is in the bottom of the 8/a. >Consistent with this non-standard method. >>So, no twisted cables, no funny stuff at all, just things >>placed very backwards to what DEC said. >No, wrong. Neglecting the fact that the 8/a has cards vertically stacked >over each other and the 8/e has them stacked horizontally (the chassis >essentially are 90 degreees out-of-phase with each other :-)) the cards >in the 8/a box face backwards. Berg connectors exit on the right in the >8/a; the left in the 8/e. In order to make that work (i have done it) >you have to twist the two cables over each other, as I indicated. Hmmm, thinking of it, you're right, I must have them crossed at least. But I don't remember twisting them. >The BC-80C does the "twisting" for you in its etch so the cables come out >the way you would expect. >In any case, I agree with the electrical routine being "backwards" >doesn't matter. I explained my ideas that the configuration guide is >mis-using its own reasoning to merely arbitrate what is actually just >statistically likely. But clearly, DEC's guidance rules are based on >using the correct cabling. Only the BC-80C applies here. The BC08H pair >is for use with a pair of like boxes only. >>>A question to a.s.p readers who are also on the pdp8-lovers list: >> >>>Is there a need to repeat items such as this, generated by past posts to >>>pdp8-lovers, on the pdp8-lovers list, or is the propagation today >>>sufficient via a.s.p? I suspect that many of the original pdp8-lover's >>>list people are a.s.p people today. Please e-mail me if you have any >>>ideas along these lines, etc. In any case, I will continue to make >>>"belated responses" where the topic warrants, etc. >> >>There are probably some people who might find it >>interesting. I do at times. (But I have yet to see >>you make a short answer to anything, cjl. :-) >That isn't the question! I just want to know if the pdp8-lovers list has >to be "cross-posted" in this regard. Since the questions of this form >are from that far back, is there a need to also post to the list, or is >everyone from back then now reading alt.sys.pdp8? The question wether people from back then are reading here and now is hardly the most important question in this case. I think it's more significant to ask; are the people here today interested in those questions? And my answer is; Yes, probably. There are people today who also can benifit from getting more information, who wasn't around at that time. So, from this point of view, I think there is a good reason for reposting those old questions. Especially when they haven't been answered before. If the subject had come to a good finish, you might let it lie, and let people read the digests, though. >In fact, can anyone provide some kind of net.statistics about who is on >the mailing list *not* also on a.s.p? There is no way to find out who is reading news, so unfortunately it's impossible to get such statistics. Who's on the mailinglist can be found out, however. >> >>>cjl >> >>>ps: Does anyone have any expertise in setting up a listserver so that >>>pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically >>>mailed to the requestor? >> >>Nope. But if someone have the software, I might be able to >>set it up on a machine. >>But why not just making it available for anonymous ftp. >>There are ftpmail servers on many machines on the net, which >>can then help those who only have mail access. >Anyone know what/how to do this? Hmmm. Give me a day or so, and I'll look up where mailservers are running. (If I don't forget this.) 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 lasner@sunSITE.unc.edu Sat Feb 19 12:14:38 EST 1994 Article: 656 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Belated response to an old issue Date: 19 Feb 1994 17:13:45 GMT Organization: University of North Carolina, Chapel Hill Lines: 132 Message-ID: <2k5hc9$fho@bigblue.oit.unc.edu> References: <2jloh6$1l6@bigblue.oit.unc.edu> <2jqgle$knd@columba.udac.uu.se> <2jrkpe$o2h@bigblue.oit.unc.edu> <2k2pn3$6rf@columba.udac.uu.se> NNTP-Posting-Host: calypso.oit.unc.edu In article <2k2pn3$6rf@columba.udac.uu.se>, Johnny Billquist wrote: >In <2jrkpe$o2h@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >Sorry, but when I say they are Unibus-cables, they are Unibus-cables. >I grabbed them right out of a pdp-11. Go look at a unibus cable. It shorts together several pins in the etch. The Omnibus doesn't have unused pins, especially on both halves. Please explain how a shorted cable makes a passable Omnibus cable. The BC08H cable is what the unibus cable should have been. All pins are straight-through one-for-one. Had DEC figured out how to do the jumpers for the Unibus granting, etc. on some separate jumper set on the end of the cable, we all would have used only one type of cable! In essence, the BC08H is the "big brother" of the Omnibus jumper M935. The only difference is the handles, the lack of mechanically joining the ends, and of course the length. Note that the unibus has an analogy, the M920. A curious aside: The M920 originally had a tape drawn around the base of it that often was imprinted "unibus" throughout. (Some were plain like the bulk of the M935's.) But I acquired a few M935's with the unibus tape on them :-). Sometimes even DEC people can't tell the difference! >>>So, no twisted cables, no funny stuff at all, just things >>>placed very backwards to what DEC said. > >>No, wrong. Neglecting the fact that the 8/a has cards vertically stacked >>over each other and the 8/e has them stacked horizontally (the chassis >>essentially are 90 degreees out-of-phase with each other :-)) the cards >>in the 8/a box face backwards. Berg connectors exit on the right in the >>8/a; the left in the 8/e. In order to make that work (i have done it) >>you have to twist the two cables over each other, as I indicated. > >Hmmm, thinking of it, you're right, I must have them crossed >at least. But I don't remember twisting them. Crossing *is* twisting. The left-most 8/e-box one comes out, does a 180 degree twist and is placed into the 8/a box on the right, and vice-versa for the other cable. Can't be helped due to the connectors facing the opposite way, etc. (8/e component side towards front; 8/a components skyward.) The BC-80C cable avoids this entirely because the cable joins onto the hex board without twists or crosses. The lands on the card do a criss-cross on the module so that it all goes to the proper place anyway. Thus, the cables come out and lie flat where you would want them to. While I'm not too happy about running the cables under the 8/a box and above a covered 8/e box, I would be less happy attempting to run it above an 8/a box and under an 8/e box! Thus, the 8/a box belongs *over* the 8/e box, which is where we came into this. Electrically, I have no problem with it going in the top or bottom of the 8/a box though. And of course if the boxes are separated in the rack it woudln't matter! >>>>A question to a.s.p readers who are also on the pdp8-lovers list: >>> >>>>Is there a need to repeat items such as this, generated by past posts to >>>>pdp8-lovers, on the pdp8-lovers list, or is the propagation today >>>>sufficient via a.s.p? I suspect that many of the original pdp8-lover's >>>>list people are a.s.p people today. Please e-mail me if you have any >>>>ideas along these lines, etc. In any case, I will continue to make >>>>"belated responses" where the topic warrants, etc. >>> >>>There are probably some people who might find it >>>interesting. I do at times. (But I have yet to see >>>you make a short answer to anything, cjl. :-) > >>That isn't the question! I just want to know if the pdp8-lovers list has >>to be "cross-posted" in this regard. Since the questions of this form >>are from that far back, is there a need to also post to the list, or is >>everyone from back then now reading alt.sys.pdp8? > >The question wether people from back then are reading here >and now is hardly the most important question in this case. >I think it's more significant to ask; are the people here >today interested in those questions? >And my answer is; Yes, probably. There are people today who >also can benifit from getting more information, who wasn't >around at that time. >So, from this point of view, I think there is a good reason >for reposting those old questions. >Especially when they haven't been answered before. >If the subject had come to a good finish, you might let it >lie, and let people read the digests, though. If the issue is at rest, I have been skipping over them and merely archiving them. If the issue is open, then I would think of posting to the list as well as a.s.p. But I suspect that there may be a third kind only relevant to the "old gang" whom I suspect are largely now on a.s.p if not on both! In any case, can anyone help us to "merge" the two things? The ideal situation would be a universal cross-posting regardless of source, etc. > >>In fact, can anyone provide some kind of net.statistics about who is on >>the mailing list *not* also on a.s.p? > >There is no way to find out who is reading news, so unfortunately >it's impossible to get such statistics. Someone estimated that Alt.folklore.urban has 60,000 readers. How does anyone create these statistics (other than out of thin air :-))? >Who's on the mailinglist can be found out, however. Can we get a posting to a.s.p of that list? Then maybe we can get some responses from those who saw their names posted in a.s.p, etc. > >>> >>>>cjl >>> >>>>ps: Does anyone have any expertise in setting up a listserver so that >>>>pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically >>>>mailed to the requestor? >>> >>>Nope. But if someone have the software, I might be able to >>>set it up on a machine. >>>But why not just making it available for anonymous ftp. >>>There are ftpmail servers on many machines on the net, which >>>can then help those who only have mail access. > >>Anyone know what/how to do this? > >Hmmm. Give me a day or so, and I'll look up where mailservers >are running. (If I don't forget this.) Hopefully, they can be made to carry a.s.p. cjl From bqt@Update.UU.SE Sun Feb 20 18:50:43 EST 1994 Article: 657 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!usenet.ins.cwru.edu!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!columba.udac.uu.se!bqt From: bqt@Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: Belated response to an old issue Date: 20 Feb 1994 11:49:18 GMT Organization: Uppsala University Lines: 143 Message-ID: <2k7inu$ehi@columba.udac.uu.se> References: <2jloh6$1l6@bigblue.oit.unc.edu> <2jqgle$knd@columba.udac.uu.se> <2jrkpe$o2h@bigblue.oit.unc.edu> <2k2pn3$6rf@columba.udac.uu.se> <2k5hc9$fho@bigblue.oit.unc.edu> NNTP-Posting-Host: krille.update.uu.se In <2k5hc9$fho@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article <2k2pn3$6rf@columba.udac.uu.se>, >Johnny Billquist wrote: >>In <2jrkpe$o2h@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes: >>Sorry, but when I say they are Unibus-cables, they are Unibus-cables. >>I grabbed them right out of a pdp-11. >Go look at a unibus cable. It shorts together several pins in the etch. >The Omnibus doesn't have unused pins, especially on both halves. Please >explain how a shorted cable makes a passable Omnibus cable. Beats me why it works, but it does. I haven't checked which lines are shorted, and if they matter. However, I certainly never even have had a reason to come close to an Omnibus cable. All my pdp-8 systems have been in a single box. The expansion was made from taking two systems and merging them into one. And the cables definitely are Unibus cables. Since this is getting to be a heated topic, I'll open up my system next time I pass my parents, and make a through check on it. >>>>So, no twisted cables, no funny stuff at all, just things >>>>placed very backwards to what DEC said. >> >>>No, wrong. Neglecting the fact that the 8/a has cards vertically stacked >>>over each other and the 8/e has them stacked horizontally (the chassis >>>essentially are 90 degreees out-of-phase with each other :-)) the cards >>>in the 8/a box face backwards. Berg connectors exit on the right in the >>>8/a; the left in the 8/e. In order to make that work (i have done it) >>>you have to twist the two cables over each other, as I indicated. >> >>Hmmm, thinking of it, you're right, I must have them crossed >>at least. But I don't remember twisting them. >Crossing *is* twisting. The left-most 8/e-box one comes out, does a 180 >degree twist and is placed into the 8/a box on the right, and vice-versa >for the other cable. Can't be helped due to the connectors facing the >opposite way, etc. (8/e component side towards front; 8/a components >skyward.) I'll leave this until I've checked it again. >>>>>A question to a.s.p readers who are also on the pdp8-lovers list: >>>> >>>>>Is there a need to repeat items such as this, generated by past posts to >>>>>pdp8-lovers, on the pdp8-lovers list, or is the propagation today >>>>>sufficient via a.s.p? I suspect that many of the original pdp8-lover's >>>>>list people are a.s.p people today. Please e-mail me if you have any >>>>>ideas along these lines, etc. In any case, I will continue to make >>>>>"belated responses" where the topic warrants, etc. >>>> >>>>There are probably some people who might find it >>>>interesting. I do at times. (But I have yet to see >>>>you make a short answer to anything, cjl. :-) >> >>>That isn't the question! I just want to know if the pdp8-lovers list has >>>to be "cross-posted" in this regard. Since the questions of this form >>>are from that far back, is there a need to also post to the list, or is >>>everyone from back then now reading alt.sys.pdp8? >> >>The question wether people from back then are reading here >>and now is hardly the most important question in this case. >>I think it's more significant to ask; are the people here >>today interested in those questions? >>And my answer is; Yes, probably. There are people today who >>also can benifit from getting more information, who wasn't >>around at that time. >>So, from this point of view, I think there is a good reason >>for reposting those old questions. >>Especially when they haven't been answered before. >>If the subject had come to a good finish, you might let it >>lie, and let people read the digests, though. >If the issue is at rest, I have been skipping over them and merely >archiving them. If the issue is open, then I would think of posting to >the list as well as a.s.p. But I suspect that there may be a third kind >only relevant to the "old gang" whom I suspect are largely now on a.s.p >if not on both! >In any case, can anyone help us to "merge" the two things? The ideal >situation would be a universal cross-posting regardless of source, etc. Hmmm. Someone who could set up a crossposting service between pdp8-lovers and alt.sys.pdp8 then? I might do that once I have a news-service running. The thing has been done for info-pdp11 to vmsnet.pdp11, so I guess I could get the help from those people there. >>>In fact, can anyone provide some kind of net.statistics about who is on >>>the mailing list *not* also on a.s.p? >> >>There is no way to find out who is reading news, so unfortunately >>it's impossible to get such statistics. >Someone estimated that Alt.folklore.urban has 60,000 readers. How does >anyone create these statistics (other than out of thin air :-))? Make guesses from a small sample, tries to approximate the reach of the newsgroup, and extrapolate a number. In short: Just a little denser air. >>Who's on the mailinglist can be found out, however. >Can we get a posting to a.s.p of that list? Then maybe we can get some >responses from those who saw their names posted in a.s.p, etc. Just mail to pdp8-lovers-request@ai.mit.edu, asking for the list should do it. If I remember right, Jan Brittenson is the one who handles it. His email is bson@mit.ai.edu. I don't think he has passed it on, but primarily mail to the -request address. Maybe they can set up a news-gate too. >>>>>ps: Does anyone have any expertise in setting up a listserver so that >>>>>pdp-8 archive files at sunsite.unc.edu or elsewhere can be automatically >>>>>mailed to the requestor? >>>> >>>>Nope. But if someone have the software, I might be able to >>>>set it up on a machine. >>>>But why not just making it available for anonymous ftp. >>>>There are ftpmail servers on many machines on the net, which >>>>can then help those who only have mail access. >> >>>Anyone know what/how to do this? >> >>Hmmm. Give me a day or so, and I'll look up where mailservers >>are running. (If I don't forget this.) >Hopefully, they can be made to carry a.s.p. No, a mailserver can just access anonymous ftp-areas by mail. However, it don't have to be their own ftp-area. That server can access other ftp-areas as well. (At least one ftpmail have been accessing our ftp-area, that much I know...) 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 guenther@bcm.tmc.edu Fri Feb 25 18:54:26 EST 1994 Article: 658 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!bcm!bcm.tmc.edu!guenther From: guenther@bcm.tmc.edu (Margaretha M. Guenther) Newsgroups: alt.sys.pdp8 Subject: PDP-8 Manual Date: 25 Feb 1994 19:02:02 GMT Organization: Baylor College of Medicine, Houston, Tx Lines: 30 Message-ID: <2klhva$av@gazette.bcm.tmc.edu> NNTP-Posting-Host: bcm.tmc.edu Keywords: MANUAL BOOK PDP8 Hello all, BCM had this newsgroup (alt.sys/pdp8), then it didn't. Now we have it back. My husband cleaned out his bookshelves and found a PDP8 manual in excellent shape though slightly yellowed. See description below. I regret to inform you that his supply of spare PCB's for the PDP-8 went to a scrap dealer about 1987. He did not know that there were hobbyists around. To those who have already responded to my message in other newsgroups, thank you, You will be first in line for best offer, but please understand that I will offer the book here, in the proper forum, before I accept any offer. The paperback book has about 540 pages divided as follows: Small computer Primer 1 - 44 PDP-8/S Users Handbook 45 - 170 PDP-8 Users Handbook 171 - 446 LINC-8 Users Handbook 447 - 498 Appendix (Instructions) 499 - 520 The Products (Pictures) 521 - 540 Postage Paid Reply forms 541 - 544 (hehe- you can try to order more info about the PDP-8 family of computers from DIGITAL in Maynard, MA) Is there a wealthy afficionado out there? :-) Please reply to guenther@bcm.tmc.edu in case we lose the newsgroup again. Meg. From billh@comtch.iea.com Sun Feb 27 14:35:23 EST 1994 Article: 659 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!news.intercon.com!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: EAE SAM instruction Date: 26 Feb 1994 01:26:15 GMT Organization: CompuTech Computer Technology / Digital Video Applications Lines: 27 Message-ID: <2km8fn$53a@krel.iea.com> NNTP-Posting-Host: comtch.iea.com X-Newsreader: TIN [version 1.2 PL1] The description of the SAM instruction (on page 5-9 of the 1973 Small Computer Handbook) seems to say that the LINK and GTF (in mode B) will end up with the same value. I quote: "Subtract AC from MQ. The content of the AC is subtracted from the content of the MQ in two's complement arithmetic. The result is loaded into the AC. The MQ remains unchanged. If a borrow is propagated from the most significant bit, the link is set. Otherwise, the link is cleared. Hence, the link is set if and only if the original content of the AC was less than or equal to the content of the MQ. The GTF is helpful when comparing signed numbers. It is set if the signed number in the MQ is greater than or equal to the original signed number in the AC, and cleared otherwise." The GTF should receive its value based on the SIGN EXTENDED contents of the AC and MQ (at least I read the description that way). The description does not make it clear to me whether the LINK receives its value based on the SIGN EXTENDED contents of the AC and MQ or just from the 12-bit 2s complement values. For the moment, I set the LINK equal to the GTF in my emulator until I can get more definitive information. Comments gratefully received. _ |_) |_| |_)ill | |aygood From gint@interaccess.com Sun Feb 27 14:49:44 EST 1994 Article: 660 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!news.ans.net!mailhost.interaccess.com!dyna2-23.interaccess.com!gint From: gint@interaccess.com (Gint Burokas) Newsgroups: alt.sys.pdp8 Subject: There is actually PDP8 users out there * STILL * Date: Sat, 26 Feb 1994 12:34:53 Organization: InterAccess,Chicagoland's Full Service Internet Provider Lines: 14 Message-ID: NNTP-Posting-Host: dyna2-23.interaccess.com X-Newsreader: Trumpet for Windows [Version 1.0 Rev A] I can't believe there is actually a news group for PDP8's on Internet, let alone people discussing EAE SAM stuff. I thought I was the last remaining WIZARD of PDP8's , tho I have long forgotted about EAE. I have several working ones in my little museum : PDP 8i, PDP 8E and a lot of peripherals, disks , tapes and diagnostics. ===================================================================== Gint Burokas gint@interaccess.com Wizdom Systems Inc., Naperville, IL, USA (708) 357-3000 The opinions expressed above do not necessarily etc etc... From guenther@bcm.tmc.edu Sun Feb 27 14:50:20 EST 1994 Article: 661 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!bcm!bcm.tmc.edu!guenther From: guenther@bcm.tmc.edu (Margaretha M. Guenther) Newsgroups: alt.sys.pdp8 Subject: What's a PDP-8? Date: 27 Feb 1994 04:35:05 GMT Organization: Baylor College of Medicine, Houston, Tx Lines: 13 Message-ID: <2kp7tp$2cb@gazette.bcm.tmc.edu> NNTP-Posting-Host: bcm.tmc.edu Keywords: PDP-8 PDP8 How did the PDP-8 compare to later Micros? Does a 12 bit 32 K computer equate to an 8 bit 48 K? Give me something to discuss with my husband. I want to put a PDP-8 morsel into his cocktail at the next party. Keep it down to earth please. Thanks, Meg. From lasner@sunSITE.unc.edu Sun Feb 27 14:50:51 EST 1994 Article: 662 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 27 Feb 1994 19:35:11 GMT Organization: University of North Carolina, Chapel Hill Lines: 23 Message-ID: <2kqslf$tsp@bigblue.oit.unc.edu> References: <2km8fn$53a@krel.iea.com> NNTP-Posting-Host: calypso.oit.unc.edu In article <2km8fn$53a@krel.iea.com>, Bill Haygood wrote: >The GTF should receive its value based on the SIGN EXTENDED contents of the >AC and MQ (at least I read the description that way). The description does >not make it clear to me whether the LINK receives its value based on the >SIGN EXTENDED contents of the AC and MQ or just from the 12-bit 2s >complement values. For the moment, I set the LINK equal to the GTF in my >emulator until I can get more definitive information. Whose sign are you extending? The 12-bit AC is compared to the 12-bit MQ. If the MQ is greater than the AC, set the L and GT. If not, clear them both. AC gets set to the difference between AC and MQ as you quoted. All of this gets checked for in the diagnostics. You can't pass them unless you do it right! Also, this is technically not part of the EAE option. cjl From lasner@sunSITE.unc.edu Sun Feb 27 14:51:03 EST 1994 Article: 663 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: There is actually PDP8 users out there * STILL * Date: 27 Feb 1994 19:49:11 GMT Organization: University of North Carolina, Chapel Hill Lines: 49 Message-ID: <2kqtfn$bv8@bigblue.oit.unc.edu> References: NNTP-Posting-Host: calypso.oit.unc.edu In article , Gint Burokas wrote: >I can't believe there is actually a news group for PDP8's on Internet, let >alone people discussing EAE SAM stuff. Go get via anonymous ftp the archives of alt.sys.pdp8 which started in late 1992. I have it all there up to the end of January '94. The address is sunsite.unc.edu in the directory: /pub/academic/computer-science/history/pdp-8/usenet/alt.sys.pdp8 organized by months. The latest is 9401.asp for Jan '94, etc. > >I thought I was the last remaining WIZARD of PDP8's , tho I have long >forgotted about EAE. Poof! You are nothing but a charlatan! *Real* PDP-8 wizards never forget about EAE. Also, since I am one of them, and I don't know you, you aren't one! > >I have several working ones in my little museum : PDP 8i, PDP 8E and a lot of >peripherals, disks , tapes and diagnostics. We would be curious about your little collection. Please elaborate on it. Perhaps some of us are interested in some of it. However, your collection of newer PDP-8's is not worthy of wizardry. True PDP-8 wizardry requires one to have a working PDP-8, LINC-8, or PDP-5. The true wizard is not dependent on modern technology such as any form of integrated circuits. A goodly collection of 2N3639B transistors, a few diodes and a good soldering iron are true wizard's tools. However, even pretender wizards are welcome to a.s.p. >===================================================================== >Gint Burokas >gint@interaccess.com >Wizdom Systems Inc., Naperville, IL, USA (708) 357-3000 >The opinions expressed above do not necessarily etc etc... > cjl (Grand Imperial PDP-8 Wizard) Bonus question of the day: Can anyone explain the reasoning behind the LINC/LINC-8 instruction ZZZ (which was renamed QLZ in the PDP-12)? (On a scale of 1-10, this question is worth 8 frames of paper-tape leader/trailer.) From bqt@Krille.Update.UU.SE Mon Feb 28 12:29:24 EST 1994 Article: 664 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 28 Feb 1994 05:23:02 +0100 Organization: Update Computer Club Lines: 59 Message-ID: <2krrjk$ifa@Krille.Update.UU.SE> References: <2km8fn$53a@krel.iea.com> NNTP-Posting-Host: krille.update.uu.se In <2km8fn$53a@krel.iea.com> billh@comtch.iea.com (Bill Haygood) writes: >The description of the SAM instruction (on page 5-9 of the 1973 Small >Computer Handbook) seems to say that the LINK and GTF (in mode B) will end >up with the same value. I quote: > "Subtract AC from MQ. The content of the AC is subtracted from > the content of the MQ in two's complement arithmetic. The > result is loaded into the AC. The MQ remains unchanged. If a > borrow is propagated from the most significant bit, the link is > set. Otherwise, the link is cleared. Hence, the link is set > if and only if the original content of the AC was less than or > equal to the content of the MQ. The GTF is helpful when > comparing signed numbers. It is set if the signed number in the > MQ is greater than or equal to the original signed number in the > AC, and cleared otherwise." >The GTF should receive its value based on the SIGN EXTENDED contents of the >AC and MQ (at least I read the description that way). The description does >not make it clear to me whether the LINK receives its value based on the >SIGN EXTENDED contents of the AC and MQ or just from the 12-bit 2s >complement values. For the moment, I set the LINK equal to the GTF in my >emulator until I can get more definitive information. >Comments gratefully received. This seems weird, and unfortunately I can't test it on my 8/a. However, I'll indulge in a little speculation here... SAM substracts AC from MQ. So far, so good. Now, assume that MQ is 1, and AC is 2. The result should then be that AC is -1 (7777). This clearly means a borrow from the MSB was required. That means the LINK should have been set, but the documentation says the LINK gets set if AC is *less* than MQ. Weird. Also, the GTF flag is set if MQ is larger than AC when SAM is executed. This is a signed comparision we are talking about. If we assume MQ is 2, and AC is 1, MQ is larger than AC, so GTF should be set. But a borrow as not needed for this operation, so I think LINK should be clear. If we assume MQ is 1, and AC is 2, MQ is smaller than AC, so GTF should be clear. But a borrow is, as previously noted, needed, so LINK should be set I think. If we say that MQ is 1, and AC is 1, MQ is not smaller than AC, so GTF should once more be clear. But no borrow is needed to execute this substraction, so LINK should also be clear. Anyone who has an KE8-E unit on line, who can check this? 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@Krille.Update.UU.SE Mon Feb 28 12:30:54 EST 1994 Article: 665 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: EAE SAM instruction Date: 28 Feb 1994 17:19:59 +0100 Organization: Update Computer Club Lines: 51 Message-ID: <2kt5jt$g8f@Krille.Update.UU.SE> References: <2km8fn$53a@krel.iea.com> NNTP-Posting-Host: krille.update.uu.se In <2km8fn$53a@krel.iea.com> billh@comtch.iea.com (Bill Haygood) writes: >The description of the SAM instruction (on page 5-9 of the 1973 Small >Computer Handbook) seems to say that the LINK and GTF (in mode B) will end >up with the same value. I quote: > "Subtract AC from MQ. The content of the AC is subtracted from > the content of the MQ in two's complement arithmetic. The > result is loaded into the AC. The MQ remains unchanged. If a > borrow is propagated from the most significant bit, the link is > set. Otherwise, the link is cleared. Hence, the link is set > if and only if the original content of the AC was less than or > equal to the content of the MQ. The GTF is helpful when > comparing signed numbers. It is set if the signed number in the > MQ is greater than or equal to the original signed number in the > AC, and cleared otherwise." >The GTF should receive its value based on the SIGN EXTENDED contents of the >AC and MQ (at least I read the description that way). The description does >not make it clear to me whether the LINK receives its value based on the >SIGN EXTENDED contents of the AC and MQ or just from the 12-bit 2s >complement values. For the moment, I set the LINK equal to the GTF in my >emulator until I can get more definitive information. >Comments gratefully received. Here is another comment. I assume I don't have to explain two-complement stuff for you guys. The GTF gets the result from the 2-compl. comparision between AC and MQ, while the Link gets the result from the unsigned comparision. This is clearly not the same thing. Compare it with the overflow and negative flag of more modern processors if you don't catch on. (Or correct me if I confused myself somewhere.) Unless I'm totally confused, Link is set if unsigned AC is bigger than unsigned MQ, and GTF is set if signed MQ is bigger than signed AC. (The explanation of the action of the link seems incorrect one way or the other in the manual, but if Link is set if AC is less then MQ, it just changes the sign of the Link, not the interpretation. It's still the result from the unsigned comparision.) 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 david.turner@asacomp.com Wed Mar 2 02:15:02 EST 1994 Article: 666 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: DEC PDP-8 Books for sale From: david.turner@asacomp.com (David Turner) Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!usenet.ins.cwru.edu!nigel.msen.com!well!barrnet.net!infoserv!asacomp!david.turner Distribution: world Message-ID: <35.348.2946.0NCE14DF@asacomp.com> Date: Mon, 28 Feb 94 14:54:00 -0500 Organization: ASA CompuHelp, Inc. Lines: 48 FOR SALE: Seven DEC handbooks, most specifically relating to the PDP-8. All book are in good condition, of course with the exception of the yellowed pages and the worn look of the covers associated with DEC handbooks. Pages are not brittle and all are very readable. Exceptions will be noted below. 1. Programming Languages, Vol. 2, 1970 : Cover was ripped halfway up the spine, but has been repaired with clear tape. It was a good repair and in very readable condition. 2. Logic Handbook, 1966-67 : Excellent condition. 3. Communications equipment handbook, 1970 : Also excellent condition. 4. PDP8/E & PDP8/M Small Computer Handbook, 1972 : Cover starting to come off spine, but good readable condition otherwise. Will leave repairs to buyer. 5. Small Computer Handbook, 1968, (featuring the "new" PDP8/I) : Cover is about 40% worn, but book/cover is intact and in good readable condition. 6. OS/8 Handbook, 1974 : Cover starting to come off spine and there is a label marring the cover in the upper left corner. Otherwise, the book is in very good, readable shape. Cover picture in very good shape. I will leave repairs to buyer. 7. PDP8/E, PDP8/M & PDP8/F Small Computer Handbook, 1973 : Cover has a few "bend" marks, but it is otherwise in great shape. Cover picture is very good. These books will be sold to the highest acceptable offer. I just don't have a PDP-8 anymore and hate to see these book rot in the basement. I would really like to sell them as a group, but will consider selling individually. Due to the fact I got ripped of on an online deal before, payment will have to be made in advance. Books are guaranteed, so if you don't like them, send them back in the same condition and I will refund your money (minus shipping). If you would like more information, please do not hesitate to E-mail. +--------------------------------------+------------------------+ | David E. Turner PH: (614) 759-6793 | to a lack of ideas | | | Internet: David.Turner@asacomp.com | this space is open to | | fidonet : (1:226/600) | suggestions. | | RIME: ->ASACOMP | | +--------------------------------------+------------------------+