From ard@siva.bris.ac.uk Wed Jun 1 15:42:09 EDT 1994 Article: 887 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: simple pdp 'type' computer Message-ID: <1JUN199411002486@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2sfufe$grn@nexus.uiowa.edu> Date: Wed, 1 Jun 1994 10:00:00 GMT Lines: 18 In article , oddjob@cix.compulink.co.uk ("Stephen Walters") writes... >Would it make it simpler if the machine was a serial bit processor? In terms of transistor count, probably. In terms of chip count and designing the thing, probably not. You can get 4-bit adders and ALUs in TTL, so going to a bit-serial machine complicates the registers and the timing logic, and simplifies the ALU, which can be built from a couple of chips anyway. If on the other hand you want to build the ALU from simple gates, then it may be a good idea to go bit-serial. > >oddjob@cix.compulink.co.uk -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From coon@socref.corp.sgi.com Wed Jun 1 15:43:59 EDT 1994 Article: 888 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!swrinde!sgiblab!sgigate.sgi.com!odin!socref.corp.sgi.com!coon From: coon@socref.corp.sgi.com (Rich Coon) Subject: Kermit Executable Message-ID: Keywords: OS/278,Kermit Sender: news@odin.corp.sgi.com (Net News) Nntp-Posting-Host: socref.corp.sgi.com Organization: Silicon Graphics, Inc. Date: Wed, 1 Jun 1994 16:04:10 GMT Lines: 20 Help, I've got a DECMATE I up and running with the DECUS supplied OS/278. It's great! I'm trying to get a hold of an executable version of Kermit-8 or Kermit-12 on floppy. I tried to swap Charles L. copies of my WPS disks (and sent them to him last November!!) for a copy, but Charles has been extremely busy, so I am asking the group for help. I'll gladly pay shipping,etc. I also have COS-310, but no Dibol :-( Anyone out there have DIBOL? Thanks in Advance, Rich Coon From jones@pyrite.cs.uiowa.edu Wed Jun 1 21:25:54 EDT 1994 Article: 889 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Nova 2 core memory Date: 1 Jun 1994 21:36:58 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 18 Distribution: world Message-ID: <2siv1q$ogb@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu I just acquired 2 core memory boards that once lived in a long departed Data General Nova 2 computer. One board is a 16K board, copyright 1973 by Data General, with a broken Litton Data Products warantee seal in the center. The date code on the chips is also 1973. The other board is a Standard Memories Inc 16K board, with the cover over the core plane missing (and of course, the warantee seals broken!). It's not obviously ripped anywhere (I did a spot inspection of all places I saw where the wires looked like they'd been touched, and a magnifying glass didn't reveal any wire breaks). No date code on board, but the chips date from 1977. Does anyone have a DG Nova 2 that needs memory that may or may not be any good? Doug Jones jones@cs.uiowa.edu From david.razler@compudata.com Wed Jun 1 21:27:33 EDT 1994 Article: 890 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip From: david.razler@compudata.com (David Razler) Path: bigblue.oit.unc.edu!concert!news.duke.edu!godot.cc.duq.edu!newsfeed.pitt.edu!uunet!cmpudata!david.razler Distribution: world Message-ID: <12a.143.2370.0N3E200C@compudata.com> Date: Wed, 1 Jun 94 04:41:00 -0500 Organization: -=- Compu-Data * Turnersville, NJ -=- Lines: 27 MM>Trivia: (Mention of the fingers reminded me) MM> What letters are missing in the DEC Alphabet? And where is that MM> alphabet used? And why are those letters missing? There are two alphabets: Used letters in 1st:A,B,G,K,M,R,S,W colors of flipchip handles Amber Blue Green blacK Magenta, Red, Strong red (driving power, not color) and White or do you mean Used Letters: S,L,I,M,E,A, the PDP-8 family Or KA KI KL designators of the DecSystem 10? or could you mean ABCDEF, not used in Octal Trivia Questions in return: What do the following series of numbers mean: 2,3,13,17,18,19,21,22,23,24,25,26,27,28,29 and what do the numbers 14 and 16 have in common? [david.razler@compudata.com] [david.razler@compudata.com] --- * WaveRdr 1.0 [NR] * UNREGISTERED EVALUATION COP From david.razler@compudata.com Wed Jun 1 21:28:13 EDT 1994 Article: 891 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip From: david.razler@compudata.com (David Razler) Path: bigblue.oit.unc.edu!concert!news.duke.edu!godot.cc.duq.edu!newsfeed.pitt.edu!uunet!cmpudata!david.razler Distribution: world Message-ID: <12a.144.2370.0N3E200D@compudata.com> Date: Wed, 1 Jun 94 04:41:00 -0500 Organization: -=- Compu-Data * Turnersville, NJ -=- Lines: 15 MM>Trivia: (Mention of the fingers reminded me) MM> What letters are missing in the DEC Alphabet? And where is that MM> alphabet used? And why are those letters missing? OOOHHH, ignore my previous reply: the missing letters are: G,I,O,Q,W,X,Y,Z and they are not used in lettering the pins on a flipchip to avoid confusing potentials GOQ/I for L or 1, WXYZ because there are not enough fingers to need them! [david.razler@compudata.com] [david.razler@compudata.com] --- * WaveRdr 1.0 [NR] * UNREGISTERED EVALUATION COP From steveq@swifty.dap.CSIRO.AU Sat Jun 4 10:23:21 EDT 1994 Article: 892 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!uunet!munnari.oz.au!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!steveq From: steveq@swifty.dap.CSIRO.AU (Stephen Quigg) Subject: Re: simple pdp 'type' computer Message-ID: Sender: news@syd.dms.CSIRO.AU Nntp-Posting-Host: swifty.dap.csiro.au Organization: CSIRO, Division of Applied Physics, Sydney References: Date: Thu, 2 Jun 1994 22:49:28 GMT Lines: 50 In article , Stephen Walters wrote: >Does anybody have any article, books, FAQ's, plans for a serial bit >computer or similar 'simple' machines that can be construted with only >transistors, ttl 74ls chips or 4000 series CMOS? > >This machine would be made of ??? 100+ gates ??? use cassette or acoustic >delay line for storage. > >And....absolutly NO microprocessors >Any suggestions > > >oddjob@cix.compulink.co.uk Here in OZ we have a magazine called "Electronics Australia", and it featured a simple 8-bit machine based on the PDP-8 architecture; it was called "EDUC-8" (obviously derived from "educate", which shows the intention of the machine). The series was as follows; Aug 74 EDUC-8 digital microcomputer - 1: Introduction Sep 74 EDUC-8 microcomputer - 2: How it works Oct 74 EDUC-8 microcomputer - 3: Starting construction Nov 74 EDUC-8 microcomputer - 4: 3 more sections Dec 74 EDUC-8 microcomputer - 5: Getting it going Jan 75 EDUC-8 microcomputer - 6: Input/output interface Feb 75 EDUC-8 microcomputer - 7: Programming Mar 75 EDUC-8 microcomputer - 8: Interfacing with tape Apr 75 Interfacing EDUC-8 with a Philips 60SR printer unit May 75 A full ASCII-type keyboard for the EDUC-8 Jun 75 Teaching your EDUC-8 to play a melody Jul 75 Interfacing EDUC-8 to teleprinters and magnetic tape Aug 75 Interfacing a Burroughs Self-Scan display panel to your EDUC-8 I can't remember the details of this machine except that it was based on TTL logic and had (very small) sollid-state memory. At the time it was a very interesting project, and was almost the first computer construction article anywhere. But today, 32 or 256 bytes of memory is considered a little on the small side. The theory of operation is probably still a good read, and finding one (or buiding one if there are still any kits lying around somewhere) would be interesting from a historical point of view. The cover of one magazine showed the author demonstrating the EDUC-8, and in the background were a couple of "straight-8" systems that were used by the publishing company at the time. Apparently some "lunch time" hours on these machines were the stimulus for the EDUC-8 project. (And I have some DECtapes that came from that company, and may have even been used on the same machines, but that's another story). Cheers, Steve Quigg. From insinga@mv.mv.com Mon Jun 6 09:19:46 EDT 1994 Article: 893 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!blanket.mitre.org!world!mv!mv.mv.com!insinga From: insinga@mv.mv.com (Aron Insinga) Subject: Re: Canonical Flip-Chip Terminology Keywords: Flip Chip, DEC Alphabet Message-ID: Nntp-Posting-Host: mv.mv.com Sender: insinga@mv.mv.com Organization: TBD Date: Mon, 6 Jun 1994 04:25:06 GMT References: <2rg3q4$fsv@nexus.uiowa.edu> Lines: 11 The DEC Alphabet? ABCDEFHJKLMNPRSTUV Used to number pins on Flip Chip Modules. Missing some letters to prevent confusion (especially when there is solder stuck on them?) More trivia: What color(s) were the handles on M-series modules? - Aron Insinga (employed by DEC 1978-1994) (experienced C++ programmer for hire!) From lasner@sunSITE.unc.edu Mon Jun 6 09:20:13 EDT 1994 Article: 894 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 6 Jun 1994 13:18:33 GMT Organization: University of North Carolina, Chapel Hill Lines: 27 Message-ID: <2sv7n9$vsp@bigblue.oit.unc.edu> References: <2rg3q4$fsv@nexus.uiowa.edu> NNTP-Posting-Host: calzone.oit.unc.edu Keywords: Flip Chip, DEC Alphabet In article , Aron Insinga wrote: >The DEC Alphabet? ABCDEFHJKLMNPRSTUV >Used to number pins on Flip Chip Modules. >Missing some letters to prevent confusion >(especially when there is solder stuck on them?) WXYZ *are* part of the "DEC Alphabet" but aren't required for Flip Chip Modules. As proof, look at the pin numbering scheme for more complex cables such as -8/e connectors. After the alphabet is exhausted, you continue with double-letters taken from the same set. >More trivia: What color(s) were the handles on M-series modules? Later: Magenta (obvious) Early: Red (obscure) Also most of the early cards have unreliable chips that are usually blue. Some people summarily replace all of the Sprague chips on sight. (Both handle colors.) Additional trivia: What color(s) (besides red!) were used in more than one module handle series? cjl From oddjob@cix.compulink.co.uk Tue Jun 7 09:16:01 EDT 1994 Article: 895 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uknet!cix.compulink.co.uk!oddjob From: oddjob@cix.compulink.co.uk ("Stephen Walters") Subject: Re: simple pdp 'type' computer Message-ID: Organization: Skills Unlimited References: Date: Tue, 7 Jun 1994 00:06:07 GMT X-News-Software: Ameol Lines: 4 Do you know where any copies of this magazine could be acquired? or copies of the articles oddjob@cix.compulink.co.uk From jones@cs.uiowa.edu Wed Jun 8 11:12:26 EDT 1994 Article: 896 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@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: 8 Jun 94 08:08:08 GMT Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Lines: 1058 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 8 Aug 1994 08:08:08 GMT Message-ID: <2t4fq2$lh4@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:896 alt.answers:3003 news.answers:22338 Archive-name: dec-faq/pdp8 Last-modified: June 7, 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: ftp://rtfm.mit.edu/pub/usenet/alt.sys.pdp8 ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/doc An obsolete version of this file is available on the Walnut Creek CDrom. This posting conforms to RFC1153 USENET digest format (with exceptions due to the fact that it is not really a digest). 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? ---------------------------------------------------------------------- Subject: 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 stereotype 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, the 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. Some 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 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 followup, 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 machines 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. One speculative explanation for Bell's rejection of the design that became the Nova is that the competing proposal was submitted using register-transfer notation, a notation he had introduced in "Bell and Newell, Computer Structures -- Readings and Examples". An alternate version of the 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, which survives as a line of 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. ------------------------------ Subject: 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 the Interdata ad in Computers and Automation, May 1968, page 10), and the term was not immediately generalized to apply to all small computers. 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 (which was displaced by 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 and perhaps tighter than CDC 160 code. ------------------------------ Subject: 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 that resulted from the fact that the operation was delivered as a sequence of IOP pulses, each on a separate line of the I/O bus. Each line was typically used to evoke a different device function, so essentially, the operation 000 was always a no-op because it evoked no functions, and the code 111 evoked all three functions in series. 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 group 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 group 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 (logical or), 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. ------------------------------ Subject: 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) LETA= "A / Define LETA as 000011000001 (ASCII A) 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 replaces 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 FIXMRI OP= VAL / Define OP as memory reference instruction Conditonally assembled code must be enclosed in angle brackets. The enclosed code may extend over multiple lines. ------------------------------ Subject: 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. One difficulty with much PDP-8 software is that it bypasses the device handlers provided by the operating system and goes directly to the device. This results in very irregular device support, so that, for example, control-S and control-Q work to start and stop output under OS8, but the OS8 PAL assembler ignores them when reporting errors. 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. Older PDP-8 software will generally fail when presented with lower case textual input (this includes essentially all OS/8 products prior to OS/278 V1). Internally, PDP-8 programmers are free to use other character sets, but the "X notation provided by the assembler encourages use of 7 bit ASCII with the 8th bit set to 1, and the TEXT pseudo-operation 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-standard 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. The P?S/8 operating system supports a similar 6 bit text file format, where upper and lower case are folded together, tabs are stored as _ (underline), end-of-line is represented by 00, padded with any nonzero filler to a word boundary, and end of file is 0000. 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. ------------------------------ Subject: 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 Very slow 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 Workstation DECmate I 80-84 Harris 6120 Workstation DECmate II 82-86 $1,435 Harris 6120 Workstation DECmate III 84-90 $2,695 Harris 6120 Workstation DECmate III+85-90 Harris 6120 Workstation 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 compatible microprocessor based VT78 and DECmate workstations. DEC also used the Intersil IM6100 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 100? SPEAR, Inc, Waltham Mass (a LINC clone!) SPEAR u-LINC 300? SPEAR, Inc, Waltham Mass (a LINC clone!) 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 ------------------------------ Subject: 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 motives 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, and even after this, DECtape was only slowly phased out. 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, with the exception of the few programs that relied on the primitive interrupt structure of the original LINC architecture; on the LINC-8, all interrupts were handled by the PDP-8 side of the hardware. Because the LINC-8 and PDP-12 had instructions for switching between modes, a new 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. Various versions of LAP, the Linc Assembly Program, were the dominant assemblers 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. ------------------------------ Subject: 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. ------------------------------ Subject: 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. The most difficult to copy material is the large prints, many of which would be quite useful if photoreduced, but this is expensive. ------------------------------ Subject: 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. This included a paper-tape based text editor, the PAL III and MACRO-8 assembler, and a FORTRAN compiler, as well as a library of support routines. 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. Note that much of this paper-tape-based software is based on memory-use and I/O conventions that are incompatable with later disk-based systems. The DECtape Library System was a DECtape oriented save and restore system that was available from the start. The resident portion of this system occupies only 17 words of memory (7600-7625 octal), and it allowed saving and restoring absolute core images as named files on a reel of DECtape. Initially, program development was still done with paper tape, and only executable memory images were stored on DECtape, but eventually, a limited DECtape-based text editor for on-line program development was introduced. 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). It was quite slow, but it also used very little of the available memory. 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 compatibly 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 compatible 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. This was developed from an earlier system, SRT8, dating back to around 1974. 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. ------------------------------ Subject: 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 severe 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 (developed by ICS), 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. Versions of FOCAL run under OS/8, P?S/8 and other systems, and there were many special purpose overlays for FOCAL developed by DEC and by various users. 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 and was compatable with disk based systems, versions were developed for OS/8 and TSS/8, an 8K stand-alone time-sharing version was available, and there were 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. A LISP interpreters was written for the PDP-8; the original version ran in 4K (originally written in Germany?); a disassembled version of this object code was the basis of expanded versions that eventually could utilize up to 16K. POLY SNOBOL was a version of SNOBOL that was somewhere between Griswold'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 this work is the version distributed by DECUS. RT-11 TECO for the PDP-11 is a port of this code. ------------------------------ Subject: 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: ftp://acfcluster.nyu.edu/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://ftp.telebit.com/pub/pdp8 ftp://ftp.update.uu.se/pub/pdp8 ftp://nickel.ucs.indiana.edu/pub/DEC/PDP8 ftp://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 and an archive of traffic in the pdp8-lovers mailing list in .../pdp8/pdp8-lovers. The archive at Indiana contains source code for many PDP-8 compilers and interpreters, as well as common utilities and games. ------------------------------ Subject: Where can I get additional information? The file WHAT-IS-A-PDP8, by Charles Lasner contains considerable additional information; this file is available by ftp from: ftp://ftp.telebit.com/pub/pdp8/WHAT-IS-A-PDP8 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). ------------------------------ Subject: 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. Preservation of the PDP-8 has proven to be of immense practical value in defending against the rising tide of patents in the area of interactive graphics. For example, when Magnavox sued Nintendo for half a billion dollars, a documented copy of a ping pong game, written on a LINC back in the early 1960's, was crucial to the proof that computer games predated the Magnavox patent by over 5 years. The fact that this can be run today on a surviving LINC-8 makes demonstrating this proof far easier than if the only surviving relic was a dusty listing. 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. ------------------------------ Subject: 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, helped hack up the PAL III assembler for the -8 from PAL II. Richard Merrill invented FOCAL and wrote the original (1968) and classic FOCAL-69 interpreters for the PDP-8. He also did early translations of the interpreter to PDP-9/PDP-15 code and perhaps the earliest PDP-11 version. In addition, he wrote the EDIT-8 paper-tape based text editor. 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. ------------------------------ End of PDP-8 Frequently Asked Questions (posted every other month) ****************************************************************** From jones@cs.uiowa.edu Wed Jun 8 11:17:27 EDT 1994 Article: 897 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!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 Jun 94 08:08:08 GMT Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Lines: 1307 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 8 Aug 1994 08:08:08 GMT Message-ID: <2t4ftc$lh6@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:897 alt.answers:3004 news.answers:22339 Archive-name: dec-faq/pdp8-models Last-modified: May 18, 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: ftp://rtfm.mit.edu/pub/usenet/alt.sys.pdp8 ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/docs this posting conforms to RFC1153 USENET digest format (with exceptions due to the fact that it is not really a digest). 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 such systems. Contents: 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+? ---------------------------------------------------------------------- Subject: What is a PDP-5? Date of introduction: Aug 11, 1963, unveiled at WESCON. Date of withdrawal: early 1967. Total production run: 116. Price: $27,000 Technology: The PDP-5 was built with DEC System Modules, the original line of transistorized logic modules sold by DEC. The supply voltages were +10 and -15 volts, with logic levels of -3 (logic 1) and 0 (logic 0). Logic was packaged on boards that were about 4.75 inches high 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 does not support 3 cycle data-break (DMA transfers using memory to hold buffer address and word-count information), so many later PDP-8 peripherals can 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 dual DECtape transports were originally developed for the PDP-5 and contemporaneous DEC systems such as the PDP-6. After the PDP-8 was introduced, DEC offered a bus converter that allowed the PDP-5 to support standard PDP-8 negibus ueripherals, 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. Survival: Do any PDP-5 systems survive? ------------------------------ Subject: What is a PDP-8? Date of introduction: 1965 (Unveiled March 22, in New York). Date of withdrawal: 1968. Total production run: 1450. 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 by Foxboro Corporation. Price: $18500 Technology: Mostly standard 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 some of the discrete components on some logic modules, and DEC soon began to refer to all R-series modules as flip-chip modules; 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. Some special dual height R-series modules were designed specifically for the PDP-8. S and B-series logic modules were also used; these are similar to their R-series cousins, but with different speed/fanout tradeoffs in their design. Some logic modules have trimmers that must be tuned to the context, making replacement of such modules more complex than simply swapping boards. 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 long. The card edge connector had 18 contacts on 1/8 inch centers. Some double height cards were used; these had two card edge connectors and were 5 1/8 inches high. 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. 5 (later 4) more bundles were required to support data-break (DMA) transfers. The total bus length was limited to 50 feet, and bus termination was generally kluged in with 100 ohm resistors clipped or wrapped into the backplane, although a bus terminator card was sometimes used. Some time after the first year of production, flat ribbon cable made of multiple coaxial cables was used, and later still, shielded flat stripline cable was used (but this cut the allowed bus length by a factor of two). Core memory was used, originally made by FERROXCUBE, 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 and for support, as well as an array of boards from the core vendor. 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: This machine defines the core of the PDP-8 instruction set, but with restrictions that were lifted on later machines. 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. The SWP instruction (exchange AC and MQ) never works, even if the extended arithmetic element is present. 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, the basic machine occupies a volume 33 inches high by 19 inches wide by 22 inches deep. The two halves of the backplane are 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 to access the wires-wrap. 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. -- Type 139E analog multiplexor. -- Type 34D oscilloscope display control (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 1966, the following peripherals had been added to the line: -- Type AA01A three-channel digital to analog converter. -- Type CR01C card reader control. -- Type TC01 DECtape control for up to 8 TU55 transports. -- Type 251 drum (8-256 tracks, 8 sectors/track, 128 words/sector). -- Type 645 line printer control. -- Type 680 data communications system (allows 64 teletypes). By 1967, the following peripherals had been added to the line: -- Type AF01 analog to digital converter and multiplexor. -- 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 (32K 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, and the DW08A posibus to negibus converter to allow use of old peripherals on new machines. Survival: Many classic PDP-8 systems survive to this day ------------------------------ Subject: What is a LINC-8? Date of introduction: 1966 (during or before March). Date of withdrawal: 1969 Total production run: 142. 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: The PDP-8 part of the machine was identical to the PDP-8. Reason for withdrawal: The PDP-12 accomplished the same goals at a lower cost. 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. The design of the type 555 dual DECtape transport was based on that of the LINCtape drive. Up to 2 additional ranks of 8 ADC channels could be added. Remote oscilliscope could be added. Survival: One LINC-8 is known to be in operable condition today. ------------------------------ Subject: What is a PDP-8/S? Date of introduction: 1966 (Unveiled, Aug 23, WESCON, Los Angeles). Date of withdrawal: 1970. Total production run: 1024. 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 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 and table-top versions were sold (both 9" high by 19" wide by 20"? deep). The rack mount version included slides so it could be pulled out 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. Survival: Because they were so slow, PDP-8/S systems were quickly discarded as newer machines became available for comparable prices; thus, they are less common today than the Classic PDP-8, even though comparable numbers were made. A few survive in working condition. ------------------------------ Subject: What is a PDP-8/I? Date of introduction: 1968 (announced before December '67) Date of withdrawal: 1971. Total production run: 3698. 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 volt supply, packaged on the same board format 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 the memory configuration and the field that was addressed. A front panel bug prevented continue after load-address without first clearing the machine. Standard configuration: CPU with 4K of memory, plus 110 baud current loop teletype interface. Pedestal, table-top and rack-mount versions were made. The pedestal mounted version was futuristic looking; the table-top version split the pedistal, with the CPU on the table and the power supply (the base of the pedistal) on the floor beside the table. The standard rack-mounted version had the power supply bolted to the right side of the rack while the CPU, mounted on slides, slid out of the left side of the rack. 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. There may be other built-in options. 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 many older machines were converted 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 CPUs and peripherals 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. Y-shaped cables for converting from one physical bus layout to the other were available. To add to this confusion, some negibus PDP-8/I systems were rewired to use 18 conductor posibus cables with 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 and PDP-12. Survival: Many PDP-8/I systems are in operating condition. ------------------------------ Subject: What is a PDP-8/L? Date of introduction: 1968 (announced before August '68) Date of withdrawal: 1971. Total production run: 3902. 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 with a memory cycle cycle of 1.6 microseconds to avoid the speed problems that plagued early -8/I systems. 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 double-sided shielded mylar ribbon cable in most cases. Electrically, coaxial cable could be used, but the slots in the CPU box were too small for this. 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 a Calcomp plotter interface, a card-reader interface, a 4 line asynch terminal interface, a real-time clock, and more. DEC eventually offered the BM12L, an 8K expansion box that is essentially the same as the MM8I, but using positive logic and thus incompatable with the -8/I and -12. This allowed a total memory of 12K on a PDP-8/L. 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 TC08 DECtape controller (for 8 TU55 or 4 TU56). -- The DF32D 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. Survival: Many PDP-8/L systems are in operating condition. ------------------------------ Subject: What is a PDP-12? Date of introduction: 1969 (February or earlier). Date of withdrawal: 1973. Total production run: 3500? 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 the LINC instruction set. 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. The PDP-12 supported trapping of those LINC functions that were emulated by software on the LINC-8. This allowed it to run many LINC-8 bootable systems (but not all, due mostly incompatabilities in LINKtape support), and it allowed such things as emulation of LINKtape instructions for reading and writing disk. The TC12F Linktape controller could, with appropriate software, read or write DECtape. This support is unreliable, and is not software compatable with the TC01 or TC08 DECtape controller. 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 addition, 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 BA12 expander box -- the PC05 paper tape reader punch (needs the BA12). Fabritek made a 24K memory box that could be added to a PDP-8/I or PDP-12. Survival: A few PDP-12 systems are in operating condition. ------------------------------ Subject: 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: SSI and MSI TTL logic were used on these boards, and the entire CPU fit on 3 boards. Nominally, these were DEC M-series flip Chip modules, but in a new large format, quad-high (10.5 inch), extended-length (9 inch, including card-edge connector, excluding handles). The terms used for board height and length are based on the original working assumption that all flip-chips were plugged horizontally into a vertially mounted card-edge connector. On the PDP-8/E, the cards were plugged vertically down into a horizontally mounted connector, so many users incorrectly refer to these boards as quad-wide double-high. 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 jumper would slow all cycles to 1.4 microseconds). 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 high as 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 instruction itself! 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. Survival: It is still fairly common to find PDP-8/E systems on the surplus market, recently removed from service and in working condition or very close to it. A modest number are no-doubt still in service, and there is still a limited amount of commercial support from both DEC and third-party vendors. ------------------------------ Subject: 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. Survival: As with the PDP-8/E, these machines are moderately common on the surplus market, and frequently in working condition. ------------------------------ Subject: 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. Survival: As with the PDP-8/F. ------------------------------ Subject: 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. The backplane was reoriented so that boards plugged into it from the front, with the board held horizontally. Reason for introduction: Using TTL MSI and LSI components, DEC was able to reduce the PDP-8 CPU to a single oversize board (formally, hex height, double width). Similarly, they were able to make an 4K core memory board, and later, an 8K board in this format, and they were able to introduce a static RAM card using semiconductor memory. The minimum system was reduced to 3 boards. 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, allowing further cost reductions. 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. The standard parallel port on the M8316 port was not software compatable with the earlier line-printer interfaces used with device code 66. 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. -- M???? -- MR8A ROM companion for the MS8A. -- 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 600, 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 (VT52) and letter quality printer 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 core). -- M8317 -- KM8A memory extender (with variations). -- M8319 -- KL8A 4 channel RS232 or current loop serial I/O. -- M8433 -- RL8A controller for 1 to 4 RL01/RL02 disk drives. -- M???? -- FPP8A floating point processor. The PDP-8/A model 800 was the same as the model 600, but with the FPP8A floating point processor included as part of the package. -- M8416 -- KT8AA Memory management unit for up to 128K. -- -- 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. Survival: As with the PDP-8/E, these machines are moderately common on the surplus market and a modest number are still in use. Because the original machines were less expensive than and slower than 8/E, they are more likely to be simply discarded instead of sold as surplus. ------------------------------ Subject: 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 desk-mounted 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 locations 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) and the serial ports (devices 30/31 and 32/33) are compatible with the M8650 KL8E, with the latter extended to allow software controlled baud rate selection. There are two parallel ports; device 66 (compatible with the M8365 printer controller) and device 47, compatible with the nonstandard port on the M8316 DKC8AA. There is also a 100Hz clock compatible with the clock 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. Survival: There are probably many VT78 systems still in use. ------------------------------ Subject: 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 dual-port data communications option was flexible but 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 control memory added to handle control/status, console device emulation and boot options. The console terminal keyboard and display functions are largely supported by code running in control memory (a less expensive alternative to dedicating hardware for this, as was done in the VT78). The 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 pedistal 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 routines in control memory come alive to handle terminal emulaton and allow diskless operation. The terminal 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 earlier DEC transports). Survival: Many DECmates are still in use, and they are fairly common on the surplus market. They are found in small numbers just about anywhere large numbers of early PC vintage machines are found. ------------------------------ Subject: 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 (8088 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. The data communications port was an incompatable improvement on the incompatable DECmate I communications port. No built-in terminal emulation was provided, and the data communications port supported only one line, but aside from this, the data communications port is essentially as powerful as the DP-278B on the DECmate I. Standard Configuration: The DECmate II was sold with 32K of program memory, plus a second full bank for dedicated control panel function emulation. Code running in the second bank is sometimes referred to as slushware; it looks like hardware to the PDP-8 user, but it is actually device emulation software that is loaded from the boot diskette. An integral RX50 dual 5 1/4 inch diskette drive with an 8051 controller chip was included, along with 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 on it. 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; two variants of this board were produced during the production run, all slightly incompatable. 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, 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). Survival: As with the DECmate I. ------------------------------ Subject: 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 for 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 largely 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. Survival: As with the DECmate I. ------------------------------ Subject: 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 difficulty of adding 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+. Survival: As with the other DECmates. ------------------------------ End of PDP-8 Summary of Models and Options (posted every other month) ********************************************************************* From McCrohan@iol.ie Thu Jun 9 02:43:49 EDT 1994 Article: 898 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 8 Jun 1994 21:46:51 +0100 Organization: Ireland On-Line Lines: 66 Sender: mccrohan@iol.ie Message-ID: <24VwjGakfC4V064yn@iol.ie> References: <2rg3q4$fsv@nexus.uiowa.edu> <26MAY199421022033@siva.bris.ac.uk> NNTP-Posting-Host: ulysses.iol.ie In article <26MAY199421022033@siva.bris.ac.uk>, PDP11 Hacker ..... wrote: > In article , McCrohan@iol.ie (Mike McCrohan) writes... > >handles, and the Width was measured along the fingers. The thickness of > >the board was always referred to a so many layers. > > To me, the number of layers of a circuit board refers to the number of copper > layers in the PCB - for example, most of the boards in my 11/45 are 4-layer as > they have circuit traces on both surfaces, and internal power and ground > planes. Are you saying that DEC used the term layers to refer to the number of > slots across a backplane that a module would cover? No disagreement. Maybe I worded my original badly, but Layers did/does indeed refer to the number of copper layers as you state. > > >The 11/20 was constructed from single, double and quad height boards - > >all double width. The 8/e is all dual height quads. > > That's inconsistent, surely. As I understand the terms, the 11/20 was made from > single, dual and quad height boards, and the 8/e was all quad _height_ dual > length. That's the way the terms are used in my DEC logic handbook. > Anyway, if you are having quad height boards in an 11/20, you'd better have > them in the 8/e as well... > We are not in disagreement. The terms "width" and "length" have been used interchangebly wrt the DEC modules. As a technician, I and my peers used the word Width to describe the dimension of the board as measured along the handles. Yes, the 8/e was built completely with quad height dual length/width boards - i.e. 4 sets of gold fingers and about 8.5" from handles to fingers. The 11/20 was built of boards that were 8.5" finger to handles, and included 1,2 and 4 sets of Fingers. The issue of terminology is further clouded in Computer Engineering where, on page 118 Best, Douane and McNamara refer to "extended quad", "Hex" and "Super Hex" modules. > > > >Trivia: (Mention of the fingers reminded me) > > What letters are missing in the DEC Alphabet? And where is that > > alphabet used? And why are those letters missing? > > A,B,C,D,E,F,H,J,K,L,M,N,P,R,S,T,U,V - the letters of the pins on a standard > (flip-chip) board slot. > Missing are > G (looks like C??) > I (confusion with 1) > O (confusion with 0) > Q (ditto) > W,X,Y,Z (too few pins :-)) > Yep. Full marks. Regards, Mike . . . . . . . From ard@siva.bris.ac.uk Thu Jun 9 02:59:35 EDT 1994 Article: 899 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: I've been given a few more PDP-8 bits.... Message-ID: <8JUN199421264230@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department Date: Wed, 8 Jun 1994 20:26:00 GMT Lines: 45 Greetings... I've just been given a few more odd bits for my PDP8 system, and I have a few questions about them. Hopefully someone can help a) A EAE board set for the 8/e (M8340 and M8341). I assume I just have to move the 2 CPU cards in my CPU back 2 slots, stick these cards between the CPU and the timing generator, and stick the connector blocks on top. I have the 8/e maintenance manual and schematics, and that's what they seem to imply. I don't need to do any mods to the CPU boards, do I? b) A quad card, labeled M1705 on the handle, and DUAL 12 BIT OMNIBUS OUTPUT INTERFACE on the solder side. Is this a 'User' Output port for e.g. lab control - I can find nothing about it. c) A 8K core board kit, tagged 'G111 faulty, fields 4,5'. Is there a common fault that causes this? d) 2 3rd-party boards. Green handles, quad cards, Labelled 'VG DS' and M246 or V246. Contain DACs (including a Analog Devices DAC1136 :-)), and beleived to come from a mass spectrometer. Any ideas? (VG DS _may_ be Vacuum Generators Data System, or similar). e) The real prize. Lots and lots of documentation. Introduction to programming PDP8 pocket reference RX01/RX02 reference card RL01/RL02 Technical manual PDP8/e maintenance manual (my second copy, but as I know someone who's rescuing a PDP8/e, he'll get this) Microfiche - PDP8/a and 8/e technical stuff (schematics, etc) VT50,52,55 manuals (lots of fun things...) LA180 and LA36 technical manuals Lots of diagnotics etc... Quite a haul :-). I should be getting a PDP8/a with RL8 and drive(s) from there soon... -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From McCrohan@iol.ie Thu Jun 9 03:00:30 EDT 1994 Article: 900 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!convex!news.duke.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Date: 8 Jun 1994 21:46:54 +0100 Organization: Ireland On-Line Lines: 27 Sender: mccrohan@iol.ie Distribution: world Message-ID: References: <12a.143.2370.0N3E200C@compudata.com> NNTP-Posting-Host: ulysses.iol.ie In article <12a.143.2370.0N3E200C@compudata.com>, David Razler wrote: > > Trivia Questions in return: What do the following series of numbers mean: > 2,3,13,17,18,19,21,22,23,24,25,26,27,28,29 and what do the > numbers 14 and 16 have in common? > They look like the numbers NOT used to designate computer families. 2,3, 13, 17,18,19, 21,22,23,24,25,26,27,28,29 PDP1--^ PDP4-------^ PDP5--------^ PDP6---------^ PDP7----------^ PDP8-----------^ PDP9------------^ PDP10------------^ PDP11-------------^ PDP12--------------^ PDP14------------------^ PDP15-------------------^ PDP16--------------------^ PDP20--or DECsystem20---------------^ -Mike From McCrohan@iol.ie Thu Jun 9 03:01:01 EDT 1994 Article: 901 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!convex!news.duke.edu!news-feed-1.peachnet.edu!panther.Gsu.EDU!gatech!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 8 Jun 1994 21:46:57 +0100 Organization: Ireland On-Line Lines: 11 Sender: mccrohan@iol.ie Message-ID: References: <2rg3q4$fsv@nexus.uiowa.edu> NNTP-Posting-Host: ulysses.iol.ie In article , Aron Insinga wrote: > More trivia: What color(s) were the handles on M-series modules? > > - Aron Insinga > (employed by DEC 1978-1994) > (experienced C++ programmer for hire!) Magenta (some claimed Maroon. The M fits either way) -Mike: DEC 1971-1992 From dwalker@trans Thu Jun 9 03:01:30 EDT 1994 Article: 902 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!howland.reston.ans.net!usenet.ins.cwru.edu!news.csuohio.edu!trans!dwalker From: dwalker@trans (Derrik Walker) Subject: emulators? Message-ID: <1994Jun9.002317.20309@news.csuohio.edu> Sender: news@news.csuohio.edu (USENET News System) Organization: Cleveland State University X-Newsreader: TIN [version 1.2 PL2] Date: Thu, 9 Jun 1994 00:23:17 GMT Lines: 13 Does AnyBody know of any PDP - 8 or 11 emulators of the Macintosh? Also what would be a real good scouce of information ano the PDP-8 for writing such an emulator (or maybe even some place I can get the src for a PC version and just port it over)? Reply here or Email Thanx -Derrik dwalker@omega.csuohio.edu From ard@siva.bris.ac.uk Thu Jun 9 03:02:26 EDT 1994 Article: 903 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Wanted: Paper tape reader interface Message-ID: <8JUN199423125344@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department Date: Wed, 8 Jun 1994 22:12:00 GMT Lines: 17 This is a long shot, but anyway.... I've been looking over my PDP8 stuff, and come to the conclusion that the thing I am missing is paper tape. All my other old machines (PDP11's, Intellecs, P850's ,etc) have a paper tape reader, and I find it to be a useful way of loading short diagnostic and demo programs. Now, I have Trend paper tape readers everywhere - these well-made English machines can be obtained over here for under 5 pounds if you are lucky, and the interface on them is somewhat similar to that on other optical readers. Now, does anyone have a spare interface card from a Trend Reader to the Omnibus (PDP8/e). If so, I'd be interested in obtaining it for a mutually agreeable price/barter.... -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From lasner@sunSITE.unc.edu Thu Jun 9 03:03:01 EDT 1994 Article: 904 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: I've been given a few more PDP-8 bits.... Date: 9 Jun 1994 06:57:37 GMT Organization: University of North Carolina, Chapel Hill Lines: 84 Message-ID: <2t6eh1$bmn@bigblue.oit.unc.edu> References: <8JUN199421264230@siva.bris.ac.uk> NNTP-Posting-Host: calzone.oit.unc.edu In article <8JUN199421264230@siva.bris.ac.uk>, PDP11 Hacker ..... wrote: > >Greetings... >I've just been given a few more odd bits for my PDP8 system, and I have a few >questions about them. Hopefully someone can help > >a) A EAE board set for the 8/e (M8340 and M8341). I assume I just have to move >the 2 CPU cards in my CPU back 2 slots, stick these cards between the CPU and >the timing generator, and stick the connector blocks on top. I have the 8/e >maintenance manual and schematics, and that's what they seem to imply. I don't >need to do any mods to the CPU boards, do I? Not exactly, but there are known restrictions about ECO levels of all of these cards together. For example, I think the final rev EAE cards can't reliably work with the 8300 and 8310 cards unless they are also (near) final. > >b) A quad card, labeled M1705 on the handle, and DUAL 12 BIT OMNIBUS OUTPUT >INTERFACE on the solder side. Is this a 'User' Output port for e.g. lab control >- I can find nothing about it. Some of the dismal older interfaces. Some were output-only, some were input-only. All shared the same brain-dead concept: That the user circuitry would be wrapped on green blocks externally to the Omnibus, and these cards woujld plug into the Omnibus and buffer the signals to the user stuff using the same cables as the KA8E and KD8E (flip-chip on one end, Berg on the other.) OF course, we eventually learned to put the interface and the user part on the same card! > >c) A 8K core board kit, tagged 'G111 faulty, fields 4,5'. Is there a common >fault that causes this? Merely indicates the writer believes the G111 card is defective, and that it's for the 8K stack serving as fields 4 and 5 at the time. Field select is determined by three jumpers in the lower right corner. The low-order bit is ignored in 8K stacks, but is looked at on the 4K version (G104). (which is the same etch card). The presence of a jumper=0, cut=1. Factory and user jumpers are the same here (but not in all modules!) (Look at the M8650 for a good example!) It could be thousands of things. > >d) 2 3rd-party boards. Green handles, quad cards, Labelled 'VG DS' and M246 or >V246. Contain DACs (including a Analog Devices DAC1136 :-)), and beleived to >come from a mass spectrometer. Any ideas? >(VG DS _may_ be Vacuum Generators Data System, or similar). Could be anything. > >e) The real prize. Lots and lots of documentation. > Introduction to programming > PDP8 pocket reference > RX01/RX02 reference card > RL01/RL02 Technical manual > PDP8/e maintenance manual (my second copy, but as I know someone > who's rescuing a PDP8/e, he'll get this) > Microfiche - PDP8/a and 8/e technical stuff (schematics, etc) > VT50,52,55 manuals (lots of fun things...) > LA180 and LA36 technical manuals > Lots of diagnotics > etc... > >Quite a haul :-). I should be getting a PDP8/a with RL8 and drive(s) from there >soon... Lotsa good stuff in that list :-). > > >-tony > >Bristol University takes no responsibility for the views expressed in this >posting. They are the personal views of the user concerned. > cjl From ard@siva.bris.ac.uk Thu Jun 9 17:21:04 EDT 1994 Article: 905 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!news.kei.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: I've been given a few more PDP-8 bits.... Message-ID: <9JUN199411565923@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <8JUN199421264230@siva.bris.ac.uk> <2t6eh1$bmn@bigblue.oit.unc.edu> Date: Thu, 9 Jun 1994 10:56:00 GMT Lines: 60 In article <2t6eh1$bmn@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes... [EAE revision levels] >Not exactly, but there are known restrictions about ECO levels of all of >these cards together. For example, I think the final rev EAE cards can't >reliably work with the 8300 and 8310 cards unless they are also (near) final. The cards are dated OCT 1974, and have the labels M8340E on the solder side. I can find no other revision letters on them. Are those cards likely to work with my 8/e, and if not, what should I check first? I have the schematics to everything (including one rev. of the EAE), and a logic analyser. [Output card] >Some of the dismal older interfaces. Some were output-only, some were >input-only. All shared the same brain-dead concept: That the user >circuitry would be wrapped on green blocks externally to the Omnibus, and Is that the only thing that's brain-dead about them? If so, and assuming it's a latched 12-bit TTL output, it seems quite sensible. I can use berg-berg cables to hook it up to my own device. >these cards woujld plug into the Omnibus and buffer the signals to the >user stuff using the same cables as the KA8E and KD8E (flip-chip on one >end, Berg on the other.) OF course, we eventually learned to put the >interface and the user part on the same card! I got 3 of those cable thrown in with the stuff.... [Faulty G111] >Merely indicates the writer believes the G111 card is defective, and that >it's for the 8K stack serving as fields 4 and 5 at the time. Field Aha... I'd got confused as to the size of a field, and though it might mean that an address driver to the XY plane had failed. Still, I'll have a go at sorting it out. >select is determined by three jumpers in the lower right corner. The >low-order bit is ignored in 8K stacks, but is looked at on the 4K version >(G104). (which is the same etch card). The presence of a jumper=0, >cut=1. Factory and user jumpers are the same here (but not in all >modules!) (Look at the M8650 for a good example!) It could be thousands >of things. OK. I have schematics and the maintenance book. Can't be that bad. I fixed the Core Memory in my P850 with no schematics at all... >Lotsa good stuff in that list :-). True... I should have a PDP8 with some periphrals soon... so then I can run some real software... >cjl > -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From jones@pyrite.cs.uiowa.edu Thu Jun 9 17:22:28 EDT 1994 Article: 906 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: emulators? Date: 9 Jun 1994 15:33:11 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 23 Distribution: world Message-ID: <2t7cnn$n77@nexus.uiowa.edu> References: <1994Jun9.002317.20309@news.csuohio.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <1994Jun9.002317.20309@news.csuohio.edu>, by dwalker@trans (Derrik Walker): > Does AnyBody know of any PDP - 8 or 11 emulators of the Macintosh? Dunno. I have one that works under X11, and the bulk of the emulator is independent of the windowing interface. Even the windowing interface code is mostly written without reference to X11, so it might be a good starting point. The code is written in C, and it supports emulated high speed paper tape, and just this week, emulated RX01 diskettes, barely. I'll have the RX01 version ready for release in a week or two. The emulator is for a PDP8/E, by the way. > Also what would be a real good scouce of information ano the PDP-8 for > writing such an emulator (or maybe even some place I can get the src for > a PC version and just port it over)? I work from the following sources: Introduction to Programming, the Small Computer Handbook, the PDP-8/E Maintenance Manual, the RX01 Maintenance Manual, and very occasionally, the CPU schematics. There are machine features that are undocumented where those do help! Doug Jones jones@cs.uiowa.edu From david.razler@compudata.com Sat Jun 11 14:35:03 EDT 1994 Article: 907 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip From: david.razler@compudata.com (David Razler) Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!news2.near.net!yale!yale!yale.edu!xlink.net!nntp.gmd.de!Germany.EU.net!EU.net!uunet!cmpudata!david.razler Distribution: world Message-ID: <12a.162.2370.0N3E2120@compudata.com> Date: Fri, 10 Jun 94 00:37:00 -0500 Organization: -=- Compu-Data * Turnersville, NJ -=- Lines: 30 >More trivia: What color(s) were the handles on M-series modules? CL>Later: Magenta (obvious) CL>Early: Red (obscure) CL>Also most of the early cards have unreliable chips that are usually CL>blue. Some people summarily replace all of the Sprague chips on sight. CL>(Both handle colors.) CL>Additional trivia: What color(s) (besides red!) were used in more than CL>one module handle series? CL>cjl S for Strong Red (capable of driving more input lines ps. In my long history of a DEC collecter/trader (anybody want a TCO1 DecTape controller, some Magenta backplain?) I have never seen TTL with R&B handles. Grey handles are used on experimental modules and home-brew models. I'll take a guess and say magenta was probably used on the KL-10 GaAs modules. [david.razler@compudata.com] [david.razler@compudata.com] --- * WaveRdr 1.0 [NR] * UNREGISTERED EVALUATION COP From McCrohan@iol.ie Sat Jun 11 14:35:43 EDT 1994 Article: 908 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!pipex!sunic!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 Frequently Asked Questions (posted every other month) Date: 10 Jun 1994 10:41:46 +0100 Organization: Ireland On-Line Lines: 25 Sender: mccrohan@iol.ie Distribution: world Message-ID: <0FnzjGakfiH4064yn@iol.ie> References: <2t4fq2$lh4@nexus.uiowa.edu> NNTP-Posting-Host: ulysses.iol.ie In article <2t4fq2$lh4@nexus.uiowa.edu>, Douglas W. Jones wrote: > Archive-name: dec-faq/pdp8 > Last-modified: June 7, 1994 > > Frequently Asked Questions about the DEC PDP-8 computer. > [Snip, Snip] > 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 > > Electrotechnica-100I ? Russian, a PDP-8/I? clone. Electrotechnica was/is a Jugoslavian company based in Ljubjana(sp?). I visited them there back in 1980 when they were one of DEC's largest European OEM's. At that time They were importing dismantled 11/70's and 11/44's and rebuilding them for sale within Jugoslavia and the eastern bloc. Do the Heathkits qualify as clones? Did Heath not offer PDP8 kits, or was that only the -11 kits? From wilsonj@alum01.its.rpi.edu Sat Jun 11 14:36:04 EDT 1994 Article: 909 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!noc.near.net!usenet.elf.com!rpi!wilsonj From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 Frequently Asked Questions (posted every other month) Date: 10 Jun 1994 15:28:47 GMT Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 13 Message-ID: <2ta0rf$9bt@usenet.rpi.edu> References: <2t4fq2$lh4@nexus.uiowa.edu> <0FnzjGakfiH4064yn@iol.ie> NNTP-Posting-Host: alum01.its.rpi.edu In article <0FnzjGakfiH4064yn@iol.ie>, Mike McCrohan wrote: >Do the Heathkits qualify as clones? Did Heath not offer PDP8 kits, or >was that only the -11 kits? The Heathkits weren't so much clones as the real thing, repackaged. That is, the CPU board was a real LSI-11 (or 11/2?), but the rest of the system was made by Heath. HT-11 was just mangled RT-11 (you had to fill out a license form for DEC when you ordered it). The H-8 wasn't a PDP-8, it was an 8080A. John Wilson From lasner@sunSITE.unc.edu Sat Jun 11 14:50:11 EDT 1994 Article: 910 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Date: 11 Jun 1994 18:33:52 GMT Organization: University of North Carolina, Chapel Hill Lines: 44 Message-ID: <2td02g$hg4@bigblue.oit.unc.edu> References: <12a.162.2370.0N3E2120@compudata.com> NNTP-Posting-Host: calzone.oit.unc.edu In article <12a.162.2370.0N3E2120@compudata.com>, David Razler wrote: >>More trivia: What color(s) were the handles on M-series modules? >CL>Later: Magenta (obvious) >CL>Early: Red (obscure) >CL>Also most of the early cards have unreliable chips that are usually >CL>blue. Some people summarily replace all of the Sprague chips on sight. >CL>(Both handle colors.) >CL>Additional trivia: What color(s) (besides red!) were used in more than >CL>one module handle series? > >CL>cjl > S for Strong Red (capable of driving more input lines We mentioned red. The question was what *besides* red (S series was mentioned already as well as being red). There is an alternate answer. > ps. In my long history of a DEC collecter/trader (anybody want a TCO1 >DecTape controller, some Magenta backplain?) I have never seen TTL with R&B >handles. Grey handles are used on experimental modules and home-brew models. >I'll take a guess and say magenta was probably used on the KL-10 GaAs >modules. Am I reading you to say you have a TC01 where the backplane isn't black? I have heard of blocks from Sylvania being a dirty yellow color, but not used by DEC, but compatible. And then of course there are all of the Omnibus blocks that aren't greent, but are more like black, and some have gold contacts, some have curved faces to prevent breakoff when inserting modules. (Also, some green Omnibus blocks are gold pins, and some are curved-cut face grooving to prevent break-off.) (A related issue: some Omnibus cards have rounded holes between feet presumable to fit over the block ridge better to further prevent break-off, etc.) ps: to david: I attempted to e-mail you; Did you get it? cjl From lasner@sunSITE.unc.edu Sat Jun 11 14:50:34 EDT 1994 Article: 911 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Date: 11 Jun 1994 18:49:02 GMT Organization: University of North Carolina, Chapel Hill Lines: 39 Message-ID: <2td0uu$q37@bigblue.oit.unc.edu> References: <12a.162.2370.0N3E2120@compudata.com> <2td02g$hg4@bigblue.oit.unc.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <2td02g$hg4@bigblue.oit.unc.edu>, Charles Lasner wrote: >In article <12a.162.2370.0N3E2120@compudata.com>, >David Razler wrote: > >> ps. In my long history of a DEC collecter/trader (anybody want a TCO1 >>DecTape controller, some Magenta backplain?) I have never seen TTL with R&B >>handles. Grey handles are used on experimental modules and home-brew models. Extremely early M-series as used in early flakey -8/i's use sprague chips. The earliest of these with spargue chips also have red handles stamped with the M number. Perhaps there wasn't any purple plastic out yet? (Or the Barney people were getting ready a few decades early?) Another related obscurity: Early R-series modules have a different plastic than later ones. The early ones couldn't pass a UL fire test, i.e., the handles burned too easily, so they changed over to a different plastic. The older handles have a dull powdery appearance, but the powder could be from decomposition due to age and exposure, etc. Yet another plastic topic: Anyone got any theories as to why the Noryl goes yellow on recent systems? VT-220 and VR-201 and LK-201 cases go yellow in weird ways, often being zone-dependent. Various theories include batch variations, mold age (contamination from an earlier casting later in the production run because they don't clean the mold between units), and in any case exposure to light, heat, chemicals. Any ideas, and anything to do with them? Sometimes rubbing down with foamy Scotch-brite pads and detergent and water lessens it, but they often have a blotchy appearance. What to do? (Bleachable?). Another one: What causes urethane death as in various filter parts in RK05, covers of CPU boxes, Acoustic-suspension speaker cone rims, etc. that just spontaneously turn into gooey piles of crud? cjl From cohj@world.std.com Sun Jun 12 22:07:58 EDT 1994 Article: 912 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!pipex!bt!uknet!EU.net!uunet!world!cohj From: cohj@world.std.com (Jonathan A Cohen) Subject: pdp8 resource Message-ID: Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: TIN [version 1.2 PL2] Date: Sat, 11 Jun 1994 22:59:58 GMT Lines: 13 I'd like to pipe in and offer help to anyone in the Boston area who is seriously interested in establishing and/or maintaining a pdp8 installation. I have substantial resources in 8E, 8M and 8A components (not enough to be a dealer). I have rx01's, rx02's, TD8E dectapes, high-speed reader/punches, rk05's galore, rl01, and rl02's. I am unfortunately too rusty to offer heavy technical assistance, but have a lot of old software on various media. I am interested in getting a TM8E(?) reel-to-reel setup; I have a pertec drive but it seems to be incompatible with OS/8. I am also interested in that operating system with the "?" in the name; never heard of it before... From avk@hafnium.cchem.berkeley.edu Sun Jun 12 22:08:18 EDT 1994 Article: 913 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!agate!hafnium.cchem.berkeley.edu!avk From: avk@hafnium.cchem.berkeley.edu (Tony Konashenok) Newsgroups: alt.sys.pdp8 Subject: HD controller for DMII sought Date: 11 Jun 1994 23:46:08 GMT Organization: University of California, Berkeley Lines: 13 Message-ID: <2tdic0$ajl@agate.berkeley.edu> NNTP-Posting-Host: hafnium.cchem.berkeley.edu Hello folks: I'm in search of a hard disk controller for my DECmate II. If anybody is willing to part with one for a not very substantial amount of money, or trade for PDP-11/microVAX parts, please let me know! Thanks, -- Tony Konashenok avk@hafnium.cchem.berkeley.edu (510)843-5632 (home) University of California, Berkeley (510)642-5831 (office) Strauss research group, Latimer Hall, UC Berkeley, Berkeley CA 94720, U.S.A. ################ Assembler programmers drive stick shifts ################ From avk@hafnium.cchem.berkeley.edu Sun Jun 12 22:08:32 EDT 1994 Article: 914 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!agate!hafnium.cchem.berkeley.edu!avk From: avk@hafnium.cchem.berkeley.edu (Tony Konashenok) Newsgroups: alt.sys.pdp8 Subject: Is it possible to outfit a DECmate II with an RX33? Date: 12 Jun 1994 06:01:39 GMT Organization: University of California, Berkeley Lines: 9 Message-ID: <2te8c3$d7g@agate.berkeley.edu> NNTP-Posting-Host: hafnium.cchem.berkeley.edu Well, the subject line says it all. Can I just replace the FDC chip and use a high-density drive? -- Tony Konashenok avk@hafnium.cchem.berkeley.edu (510)843-5632 (home) University of California, Berkeley (510)642-5831 (office) Strauss research group, Latimer Hall, UC Berkeley, Berkeley CA 94720, U.S.A. ################ Assembler programmers drive stick shifts ################ From :cohj@world.std.com Mon Jun 13 08:20:17 EDT 1994 Article: 915 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: pdp8 resource From: :cohj@world.std.com Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!uknet!EU.net!uunet!cmpudata! :cohj Distribution: world Message-ID: <12a.174.2370@compudata.com> Date: Mon, 13 Jun 94 01:52:00 -0500 Organization: -=- Compu-Data * Turnersville, NJ -=- Lines: 31 JA>Message-ID: JA>Newsgroups: alt.sys.pdp8 JA>Organization: The World Public Access UNIX, Brookline, MA JA>I'd like to pipe in and offer help to anyone in the Boston area who is JA>seriously interested in establishing and/or maintaining a pdp8 JA>installation. I have substantial resources in 8E, 8M and 8A components JA>(not enough to be a dealer). I have rx01's, rx02's, TD8E dectapes, JA>high-speed reader/punches, rk05's galore, rl01, and rl02's. I am JA>unfortunately too rusty to offer heavy technical assistance, but have a JA>lot of old software on various media. I am interested in getting a JA>TM8E(?) reel-to-reel setup; I have a pertec drive but it seems to be JA>incompatible with OS/8. I am also interested in that operating system JA>with the "?" in the name; never heard of it before... I am very interested in a reader-punch and a lot of software for my straight-8. Am extremely interested in getting prints for building my own desktop frame for this formerly-rack-mounted machine, and the dECOlog for it, other basic stufflike that. Will gladly trade old PDP-15 memory (mostly of use for the backplanes) and 18-bit doc, both copies and originals if I have duplicates (mainly PDP-9 stuff in that category) dmr [david.razler@compudata.com] [david.razler@compudata.com] --- * WaveRdr 1.0 [NR] * UNREGISTERED EVALUATION COP From emorgan@eccdb1.pms.ford.com Tue Jun 14 01:38:57 EDT 1994 Article: 916 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!jobone!slee01.srl.ford.com!eccdb1.pms.ford.com!eccdb1.pms.ford.com!not-for-mail From: emorgan@eccdb1.pms.ford.com (Edmund P. Morgan) Newsgroups: alt.sys.pdp8 Subject: Wanted C Compiler for the Pro-350; P/OS v1.7 Date: 13 Jun 1994 11:08:08 -0400 Organization: Ford Motor Co. Lines: 8 Message-ID: <2thsooINNk98@eccdb1.pms.ford.com> NNTP-Posting-Host: eccdb1.pms.ford.com X-Newsreader: TIN [version 1.1 PL6] Does anyone have a copy of a "C" compiler for the Dec Pro-350 running P/OS v1.7? Thanks, From insinga@mv.mv.com Tue Jun 14 01:39:55 EDT 1994 Article: 917 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!uhog.mit.edu!news.mtholyoke.edu!world!mv!mv.mv.com!insinga From: insinga@mv.mv.com (Aron Insinga) Subject: Re: Canonical Flip-Chip Terminology Message-ID: Nntp-Posting-Host: mv.mv.com Sender: usenet@mv.mv.com (System Administrator) Organization: MV Communications, Inc. Date: Mon, 13 Jun 1994 17:10:08 GMT References: <2rg3q4$fsv@nexus.uiowa.edu> Lines: 25 In article , Mike McCrohan wrote: >In article , Aron Insinga wrote: >> More trivia: What color(s) were the handles on M-series modules? >> >> - Aron Insinga >> (employed by DEC 1978-1994) >> (experienced C++ programmer for hire!) > >Magenta (some claimed Maroon. The M fits either way) > >-Mike: DEC 1971-1992 > Also Metal-colored (trick question?) although perhaps the metal-handled modules were considered to be in the Magenta module series too. I don't think any hex module had colored plastic handles. The metal-handled modules had toggles on the top 2 corners that could lock the module in place to keep it from wobbling around. I think that included most of the 11/45 cpu and the 2020 cpu and many later machines. Hmm, how about the modules without handles, e.g. PDT-11/150? Are't they M also series? If so, there's a third color: invisible! - Aron Insinga From ard@siva.bris.ac.uk Tue Jun 14 01:41:06 EDT 1994 Article: 918 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!sundance.llnl.gov!fastrac.llnl.gov!s1.gov!overload.lbl.gov!agate!howland.reston.ans.net!swrinde!pipex!lyra.csx.cam.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: Canonical Flip-Chip Terminology Message-ID: <13JUN199420312757@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2rg3q4$fsv@nexus.uiowa.edu> Date: Mon, 13 Jun 1994 19:31:00 GMT Lines: 41 In article , insinga@mv.mv.com (Aron Insinga) writes... [M series module handles] >Also Metal-colored (trick question?) although perhaps the >metal-handled modules were considered to be in the Magenta module The M-series modules with metal handles had the type number written in Magenta paint. I have a few G-series hex modules (16K word core planes for a PDP11), and those have green paint for the type number. >series too. I don't think any hex module had colored plastic handles. On the other hand, Some Q-Bus quad modules (RLV11 for example) had metal handles... >The metal-handled modules had toggles on the top 2 corners that could >lock the module in place to keep it from wobbling around. I think >that included most of the 11/45 cpu and the 2020 cpu and many later The entire 11/45 CPU including floating point and memory management was on hex-height modules, except for the M8109 timing board which was a quad. >machines. > >Hmm, how about the modules without handles, e.g. PDT-11/150? Are't >they M also series? If so, there's a third color: invisible! Were there ever H-series modules (I am wondering if the braided ROM subboard on the MR8-E for example. The manual describes it as a M880 quad module with an H241 braid board mounted on it)?. If so, did it have handles (the picture shoes it as a shorter-length quad board, _with_ handles), and what colour. My guess is green, which would mean that green was used for both G and H modules. > >- Aron Insinga -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From djk@egret.gsfc.nasa.gov Wed Jun 15 22:30:17 EDT 1994 Article: 919 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!egret!djk From: djk@egret.gsfc.nasa.gov (David Kendig) Newsgroups: vmsnet.pdp-11,alt.sys.pdp8 Subject: PDP-11/44 Problem. HELP!!! Date: 15 Jun 1994 14:18:16 GMT Organization: NASA/Goddard Space Flight Center Lines: 40 Message-ID: <2tn2j8$ecc@paperboy.gsfc.nasa.gov> NNTP-Posting-Host: egret.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Newsreader: NN version 6.5.0 #7 (NOV) Xref: bigblue.oit.unc.edu vmsnet.pdp-11:1216 alt.sys.pdp8:919 Hi, I am looking for some help on a rather peculiar problem that has been driving me and my repairman nuts. I am running a PDP-11/44 with RSX11M. Last week it crashed and I rebooted it fine except for one thing. When I issue a 'dir' or 'pip' command, I get a stack dump on the terminal with the message 'Memory protect violation'. If I explicitly run [1,54]pip.tsk, it says 'INS - File not task image'. This has happened in the past and I recovered by restoring the system directory and running VMR to create a new system. I also previously ran BAD on the disk, but it found nothing unusual so I do not believe I have a flaky disk. One other strange symptom is the following: As I said, if I run PIP, I get an error, but if I explicitly run a copy of PIP from another disk and then run the installed version it works fine UNTIL I do a ^C abort on the PIP process. Afterwards, the installed PIP command fails with the memory protect error. The computer behaves fine if booted from a second disk which is a copy of the primary disk except for some data files. MY QUESTION IS, DOES ANYONE HAVE ANY SUGGESTIONS or some tests to try? We have not even been able decide for sure if it is a software or hardware error. We have swapped out the controller, some processor and some memory boards and we are out of ideas. Thanks a bunch. -- ( . (. ) ) ) ( ( David Kendig (Hughes STX) .________. Operations Manager EGRET/Gamma Ray Observatory | | __| Code 664, GSFC/NASA | )) Greenbelt, MD 20771 | | //| (301) 286-7242 `---`-`------'---' Coffee coffee ... djk@egretop.gsfc.nasa.gov From McCrohan@iol.ie Fri Jun 17 12:34:24 EDT 1994 Article: 920 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 17 Jun 1994 01:06:48 +0100 Organization: Ireland On-Line Lines: 26 Sender: mccrohan@iol.ie Message-ID: References: <2rg3q4$fsv@nexus.uiowa.edu> <13JUN199420312757@siva.bris.ac.uk> NNTP-Posting-Host: ulysses.iol.ie In article <13JUN199420312757@siva.bris.ac.uk>, PDP11 Hacker ..... wrote: > > Were there ever H-series modules (I am wondering if the braided ROM subboard on > the MR8-E for example. The manual describes it as a M880 quad module with an > H241 braid board mounted on it)?. If so, did it have handles (the picture shoes > it as a shorter-length quad board, _with_ handles), and what colour. My guess > is green, which would mean that green was used for both G and H modules. > The H- designation was generally for Cabinets, power supplies, regulators and related equipment. H960 cab, H722 ps, etc come to mind. Certain power cables/connectors also, I think had the H- designation. Also, the core memory stacks were Hxxx, were they not? The M- and G-series carried on from the plastic handled boards as in the 8/e and 11/20 to the metal handled equivalents in the 11/40, 11/05 and later 11s. As has been stated the number stamped on the handles was in green or magenta to match its g-series or m-series family. The VAX finally departed from M series CPU modiles with the introduction of the extended hex boards. Are these not H-series too? (Major brain rot in the memory are here). On reflection, H was used all over the shop! From david.razler@compudata.com Fri Jun 17 12:34:45 EDT 1994 Article: 921 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: PDP-11/44 Problem. HELP! From: david.razler@compudata.com (David Razler) Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!swrinde!pipex!sunic!EU.net!uunet!cmpudata!david.razler Distribution: world Message-ID: <12a.177.2370@compudata.com> Date: Fri, 17 Jun 94 00:45:00 -0500 Organization: -=- Compu-Data * Turnersville, NJ -=- Lines: 16 DK>MY QUESTION IS, DOES ANYONE HAVE ANY SUGGESTIONS or some tests DK>to try? DK>We have not even been able decide for sure if it is a software or DK>hardware error. We have swapped out the controller, some processor DK>and some memory boards and we are out of ideas. Thanks a bunch. 1) blow out the dust 2) I hate to say it, but if you've tried everything else, I would blame the pack and replace. [david.razler@compudata.com] [david.razler@compudata.com] --- * WaveRdr 1.0 [NR] * UNREGISTERED EVALUATION COP From copley1@muvms6.wvnet.edu Sun Jun 19 12:49:06 EDT 1994 Article: 922 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!wvnvms!marshall.wvnet.edu!copley1 Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Message-ID: <1994Jun17.102656.6787@muvms6> From: copley1@muvms6.wvnet.edu (Ronald Copley) Date: 17 Jun 94 10:26:56 EDT References: <2rg3q4$fsv@nexus.uiowa.edu> <13JUN199420312757@siva.bris.ac.uk> Organization: Marshall University Lines: 23 In article <13JUN199420312757@siva.bris.ac.uk>, ard@siva.bris.ac.uk (PDP11 Hacker .....) writes: > On the other hand, > Some Q-Bus quad modules (RLV11 for example) had metal handles... > LSI-11 CPU board (quad) had metal handles... >> >>Hmm, how about the modules without handles, e.g. PDT-11/150? Are't >>they M also series? If so, there's a third color: invisible! > Well, since the 150 had an /03 (or /23, if you had the EIS/FIS chipset and dual microm) CPU, I guess it could be construed to be indirectly M-series... -- Ronald Copley, owner | As always, I'm interested in your old Informatiks | computer equipment. Particularly DEC, Scottown OH | Pyramid, and DG. 1.614.643.1340 | If you have Pink Fairies bootlegs, etc. | *please* contact me! -- From wilsonj@alum01.its.rpi.edu Mon Jun 20 04:51:57 EDT 1994 Article: 923 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!eff!news.kei.com!MathWorks.Com!news2.near.net!noc.near.net!usenet.elf.com!rpi!wilsonj From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 19 Jun 1994 18:47:28 GMT Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 14 Message-ID: <2u23s0$okq@usenet.rpi.edu> References: <2rg3q4$fsv@nexus.uiowa.edu> <13JUN199420312757@siva.bris.ac.uk> <1994Jun17.102656.6787@muvms6> NNTP-Posting-Host: alum01.its.rpi.edu In article <1994Jun17.102656.6787@muvms6>, Ronald Copley wrote: >>>Hmm, how about the modules without handles, e.g. PDT-11/150? Are't >>>they M also series? If so, there's a third color: invisible! >Well, since the 150 had an /03 (or /23, if you had the EIS/FIS chipset and >dual microm) CPU, I guess it could be construed to be indirectly M-series... Um no, the 2-in-1 microm and EIS/FIS microm just made it an /03 with EIS/FIS. F-11 is an entirely different chipset. Anyway this sounds familiar, I'm 99% sure that the 11/150 boards really had "Mxxxx" designations, and I think the handle-less board in an LA120 does too (both are in storage or I'd look). John Wilson From ard@siva.bris.ac.uk Mon Jun 20 04:53:29 EDT 1994 Article: 924 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!pipex!uknet!gdt!bsmail!siva.bris.ac.uk!ard From: ard@siva.bris.ac.uk (PDP11 Hacker .....) Subject: Re: Canonical Flip-Chip Terminology Message-ID: <19JUN199420164223@siva.bris.ac.uk> News-Software: VAX/VMS VNEWS 1.41 Sender: usenet@info.bris.ac.uk (Usenet news owner) Nntp-Posting-Host: siva.bris.ac.uk Organization: University of Bristol Physics Department References: <2rg3q4$fsv@nexus.uiowa.edu> <13JUN199420312757@siva.bris.ac.uk> <1994Jun17.102656.6787@muvms6> <2u23s0$okq@usenet.rpi.edu> Date: Sun, 19 Jun 1994 19:16:00 GMT Lines: 31 In article <2u23s0$okq@usenet.rpi.edu>, wilsonj@alum01.its.rpi.edu (John Wilson) writes... >sure that the 11/150 boards really had "Mxxxx" designations, and I think the >handle-less board in an LA120 does too (both are in storage or I'd look). Acording to the printset, the RX02 board had M-series numbers - M7744 for the controller M7745 for the Read/Write board Both are handle-less, and not plugged into edge connectors > >John Wilson While we're talking about obscure DEC boards, a) What is the official name for a quad-sized board is _one_ double-sided 18-pin connector. The only one that I know of is the VT105 'waveform generator' - the board you stick in a VT100 to make it a graphics terminal b) In the VT55, there's an extra board, over and above what you find in a VT52, to give it the graphics feautres. This board is hex-height, but it's not plugged into anything - the connections are made by flying leads with sockets that fit onto pins on the standard PCBs. However, the edge connectors on the hex height board seem to be connected to somewhere - basically, why. Was it for testing, or was there ever a device that accepted a VT55 graphics board plugged in on the edge connectors? -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned. From pi92ts@pt.hk-r.se Mon Jun 20 12:33:44 EDT 1994 Article: 925 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Help with a M8655 Message-ID: <1994Jun20.154652.13232@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: tornet.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden Date: Mon, 20 Jun 1994 15:46:52 GMT Lines: 6 Can some one tell me what all jumpers and dipswitches are for and how to set them, please. Tommy From jones@pyrite.cs.uiowa.edu Mon Jun 20 19:05:53 EDT 1994 Article: 926 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Help with a M8655 Date: 20 Jun 1994 18:08:56 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 7 Distribution: world Message-ID: <2u4lvo$lb9@nexus.uiowa.edu> References: <1994Jun20.154652.13232@nomina.lu.se> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <1994Jun20.154652.13232@nomina.lu.se>, by pi92ts@pt.hk-r.se (Tommy Stendahl): > Can some one tell me what all jumpers and dipswitches are for > and how to set them, please. done, by E-mail Doug Jones jones@cs.uiowa.edu From jones@pyrite.cs.uiowa.edu Mon Jun 20 19:06:20 EDT 1994 Article: 927 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!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: Original PDP-8 pocket reference card Date: 20 Jun 1994 18:22:36 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 301 Distribution: world Message-ID: <2u4mpc$lst@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu C. D Lowenstein of UCSD has just sent me a vintage PDP-8 Pocket Reference Card. The original was 5 1/2 inches tall by 3 1/2 inches wide on stiff white cardstock printed in light green ink. I have taken liberties in my attempt to approximate the typography of the original. Most of it is set in a small sans-serif font (Helvetica?) with bold titles for each instruction group in the same font, and bigger fonts used only for the title on the front page and the corporate logo on the back page. The PDP-8 "Trademark" used here had PDP written in an extended bold typewriter like font over a very extended large numeral 8; this same form was used in a corner of every page of every software listing published by DEC in 1965, but it wasn't used on any of the original hardware manuals that I've got. The card is appended to this message (after a formfeed); I proofred what I transcribed, and I was careful to include all typos DEC included in the original. The worst are in the COMBINED OPERATE MICROINSTRUCTIONS section for SMA SZA, SPA SZL and SPA CLA; in all these, it skips if AC=0, but the comments don't say so! He also sent the 4/67 edition of the card. This fixes the typos, includes the new higher performance figures for the upgraded EAE, and includes the PC02, PC03, and TU55/TC01 instead of the Type 750C, 75E and 555/552 listed in the earlier documentation. In addition, it includes another 2-sided page showing the bit assignments for the different instruction formats. Under the conditions of DEC's letter of permission to reproduce documentation, I should say that this is reproduced with permission in 1994 and that DEC holds whatever copyright applies to this material. Doug Jones jones@cs.uiowa.edu F-86 5/65 P D P 88888 8 8 88888 I N S T R U C T I O N L I S T 8 8 88888 Mnemonic Code Operation Cycles BASIC INSTRUCTIONS AND 0000 logical AND 2 TAD 1000 2's complement add 2 ISZ 2000 increment and skip if zero 2 DCA 3000 deposic and clear AC 2 JMS 4000 jump to subroutine 2 JMP 5000 jump 1 IOT 6000 in-out transfer 2 1/2 OPR 7000 operate 1 GROUP 1 OPERATE MICROINSTRUCTIONS (1 CYCLE) Event Time NOP 7000 no operation 1 CLA 7200 clear AC 1 CLL 7100 clear link 1 CMA 7040 complement AC 1 CML 7020 complement link 1 RAR 7010 rotate AC and link right one 2 RAL 7004 rotate AC and link left one 2 RTR 7012 rotate AC and link right two 2 RTL 7006 rotate AC and link left two 2 IAC 7001 increment AC 2 GROUP 2 OPERATE MICROINSTRUCTIONS (1 CYCLE) Event Time SMA 7500 skip on minus AC 1 SZA 7440 skip on zero AC 1 SPA 7510 skip on plus AC 1 SNA 7450 skip on non zero AC 1 SNL 7420 skip on non-zero link 1 SZL 7430 skip on zero link 1 SKP 7410 skip unconditionally 1 OSR 7404 inclusive OR, switch register with AC 2 HLT 7402 halts the program 1 CLA 7600 clear AC 1 Mnemonic Code Operation Cycles COMBINED OPERATE MICROINSTRUCTIONS CIA 7041 complement and increment AC 1 LAS 7604 load AC with switch register 1 STL 7120 set link (to 1) 1 GLK 7204 get link (and put int AC bit 11) 1 CLA CLL 7300 clear AC and link 1 CLA IAC 7201 set AC = 1 1 CLA CMA 7240 set AC = -1 1 CLL RAR 7110 shift positive number one right 1 CLL RAL 7104 shift positive number one left 1 CLL RTL 7106 clear link, rotate 2 left 1 CLL RTR 7112 clear link, rotate 2 right 1 SZA CLA 7640 skip if AC = 0, then clear AC 1 SZA SNL 7460 skip if AC = 0, or link is 1, or both 1 SNA CLA 7650 skip if AC /= 0, then clear AC 1 SMA CLA 7700 skip if AC < 0, then clear AC 1 SMA SZA 7540 skip if AC <= 0 1 SMA SNL 7520 skip if AC < 0 or line is 1 or both 1 SPA SNA 7550 skip if AC > 0 1 SPA SZL 7530 skip if AC > 0 and if the link is 0 1 SPA CLA 7710 skip of AC > 0, then clear AC 1 SNA SZL 7470 skip if AC /= 0 and link = 0 1 Mnemonic Code Operation Time ( usec.) EAE MICROINSTRUCTION TYPE 182 DVI 7407 divide <36.7 NMI 7411 normalize 3.0+0.5n SHL 7413 shift left 3.0+0.5n ASR 7415 arithmetic shift right 3.0+0.5n LSR 7417 logical shift right 3.0+0.5n MQL 7421 load AC into MQ, clear AC 1.5 MUY 7405 multiply 15.0-21.2 MQA 7501 inclusive OR, MA with AC 1.5 CAM 7621 clear AC and MQ 1.5 SCA 7441 read SC into AC 1.5 MQA 7501 read MQ into AC 1.5 Mnemonic Code Operation Cycles IOT MICROINSTRUCTIONS PROGRAM INTERRUPT ION 6001 turn interrupt on 1 IOF 6002 turn interrupt off 1 ANALOG TO DIGITAL CONVERTER TYPE 189 ADC 6004 convert A to D TELETYPE KEYBOARD/READER KSF 6031 skip if keyboard/reader flag=1 2 1/2 KCC 6032 clear AC and keyboard/reader 2 1/2 flag KRS 6034 read keyboard/reader buffer, 2 1/2 static KRB 6036 clear AC, read keyboard buffer 2 1/2 clear keyboard flag Mnemonic Code Operation Cycles TELETYPE TELEPRINTER/PUNCH TSF 6041 skip if teleprinter/punch 2 1/2 flag = 1 TCF 6042 clear teleprinter/punch flag 2 1/2 TPC 6044 load teleprinter/punch 2 1/2 buffer, select and print TLS 6046 load teleprinter/punch buffer, 2 1/2 select and print, and clear teleprinter/punch flag HIGH SPEED PERFORATED TAPE READER TYPE 750C RSF 6011 skip if reader flag = 1 2 1/2 RRB 6012 read reader buffer, 2 1/2 and clear flag RFC 6014 clear flag and buffer and 2 1/2 fetch character HIGH SPEED PERFORATED TAPE PUNCH TYPE 75E PSF 6021 skip if punch flag = 1 2 1/2 PCF 6022 clear flag and buffer 2 1/2 PPC 6024 load buffer and punch 2 1/2 character PLS 6026 clear flag and buffer; 2 1/2 load and punch OSCILLOSCOPE DISPLAY TYPE 34B DXL 6053 clear and load x buffer 2 1/2 DYL 6063 clear and load y buffer 2 1/2 DXS 6057 combined dxl and dix 2 1/2 DYS 6067 combined dyl and diy 2 1/2 DIY 6064 intensify point 2 1/2 DIX 6054 intensify point 2 1/2 DCY 6061 clear y buffer 2 1/2 DCX 6051 clear x buffer 2 1/2 DECTAPE AND CONTROL TYPE 555/552 MMLS 6751 load unit select register 2 1/2 and clear DECtape flag MMLM 6752 load motion register and 2 1/2 clear DECtape flag MMLF 6754 load function register 2 1/2 MMMF 6756 load motion and function 2 1/2 registers and clear DECtape flag MMMM 6757 load unit select motion and 2 1/2 function registers and clear DECtape flag MMSF 6761 skip if DECtape flag = 1 2 1/2 MMML 6766 clear and load memory 2 1/2 address register MMSC 6771 skip if error flag = 1 2 1/2 MMCF 6772 clear error flag and 2 1/2 DECtape flag MMRS 6774 read status bits into AC bits 0-7 2 1/2 EXTENDED MEMORY TYPE 183 CDF 62n1 change to data field n 1 CIF 62n2 change to instruction field n 1 RDF 6214 read data field into AC 6-8 1 RIF 6224 read instruction field into AC 6-8 1 RMF 6244 restore memory field 1 RIB 6234 read interrupt buffer 1 ASCII CODE Character Code Character Code --------- ---- --------- --- A 301 ! 241 B 302 " 242 C 303 # 243 D 304 $ 244 E 305 % 245 F 306 & 246 G 307 ' 247 H 310 ( 250 I 311 ) 251 J 312 * 252 K 313 + 253 L 314 , 254 M 315 - 255 N 316 . 256 O 317 / 257 P 320 : 272 Q 321 ; 273 R 322 < 274 S 323 = 275 T 324 > 276 U 325 ? 277 V 326 @ 300 W 327 [ 333 X 330 \ 334 Y 331 ] 335 Z 332 ^ 336 0 260 <- 337 1 261 EOT 204 2 262 W RU 205 3 263 RU 206 4 264 BELL 207 5 265 Line Feed 212 6 266 Return 215 7 267 Space 240 8 270 ALT MODE 375 9 271 Rub Out 377 ___ ___ ___ ___ ___ ___ ___ | | | | | | | | | | | | | | | | | d | i | g | i | t | a | l | | | | | | | | | |___|___|___|___|___|___|___| E Q U I P M E N T C O R P O R A T I O N MAYNARD, MASSACHUSETTS 5732 PRINTED IN U.S.A. 25-5/65 From ivie@cc.usu.edu Mon Jun 20 19:07:00 EDT 1994 Article: 928 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.concert.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!fastrac.llnl.gov!s1.gov!overload.lbl.gov!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Message-ID: <1994Jun20.094700.21769@cc.usu.edu> Date: 20 Jun 94 09:47:00 MDT References: <2rg3q4$fsv@nexus.uiowa.edu> Organization: Utah State University Lines: 15 In article , McCrohan@iol.ie (Mike McCrohan) writes: > The VAX finally departed from M series CPU modiles with the introduction > of the extended hex boards. Are these not H-series too? (Major brain rot > in the memory are here). While it's been an awfully long time since I looked in a /780, I know that a lot of the strange stuff used in VAXes was labelled L-series. I know the VAXstation 3520/3540 used L-series and I'm fairly certain that the /750 used L-series, also. VAXBI, on the other hand, are T-series... -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready' From insinga@mv.mv.com Tue Jun 21 04:17:40 EDT 1994 Article: 929 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!eff!news.kei.com!world!mv!mv.mv.com!insinga From: insinga@mv.mv.com (Aron Insinga) Subject: Re: Canonical Flip-Chip Terminology Message-ID: Nntp-Posting-Host: mv.mv.com Sender: usenet@mv.mv.com (System Administrator) Organization: MV Communications, Inc. Date: Tue, 21 Jun 1994 04:31:01 GMT References: <2rg3q4$fsv@nexus.uiowa.edu> <1994Jun20.094700.21769@cc.usu.edu> Lines: 19 There was also a list (perhaps only written in someone's gray matter) of wha the colors meant, and some of them were mnemonic. This actually is usefull to get a vague idea of what some module designation is for. What I recollect (just a few bits) is: K series - blacK - industrial Kontrol W series - White - Wire your own (is that the right wording?) [blank] S series - red(!) - for pdp-8/S A series - Amber - Analog I'm sure this isn't true of all colors/series, but does anyone know more? (If this was earlier in the thread, I apologize.) These are discussed to some extent in _Computer Engineering_ circa pages 112-118 (where 'hex' etc. are mentioned). - Aron Insinga (who likes to watch lights flash more than he likes to flip switches :-) From pi92ts@pt.hk-r.se Tue Jun 21 12:40:32 EDT 1994 Article: 930 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Bootstrap OS-8 Message-ID: <1994Jun21.125837.21303@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: tornet.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden Date: Tue, 21 Jun 1994 12:58:37 GMT Lines: 5 How long time should it take to bootstrap OS-8 from an RK05? Tommy From billh@comtch.iea.com Tue Jun 21 20:40:23 EDT 1994 Article: 931 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!swrinde!news.dell.com!tadpole.com!uunet!nwnexus!krel.iea.com!comtch!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 21 Jun 1994 17:22:18 GMT Organization: home Lines: 12 Message-ID: <2u77ka$fnm@krel.iea.com> References: <1994Jun21.125837.21303@nomina.lu.se> NNTP-Posting-Host: comtch.iea.com X-Newsreader: TIN [version 1.2 PL1] Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: : How long time should it take to bootstrap OS-8 from an RK05? : Tommy If I understand your question correctly, i.e. after toggling in the RK8E bootstrap (3 locs) and depressing the CLEAR and CONT keys, how much time elapses before the OS/8 prompt appears? From my 1970's experience: virtually instantaneously. _ |_) |_)ill From pi92ts@pt.hk-r.se Wed Jun 22 09:24:59 EDT 1994 Article: 932 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!pipex!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun22.113957.2731@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: tornet.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2u77ka$fnm@krel.iea.com> Date: Wed, 22 Jun 1994 11:39:57 GMT Lines: 30 In article fnm@krel.iea.com, billh@comtch.iea.com (Bill Haygood) writes: >Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: >: How long time should it take to bootstrap OS-8 from an RK05? > >: Tommy > >If I understand your question correctly, i.e. after toggling in the >RK8E bootstrap (3 locs) and depressing the CLEAR and CONT keys, how >much time elapses before the OS/8 prompt appears? From my 1970's >experience: virtually instantaneously. > _ >|_) >|_)ill Then something is wrong. After I have toggled in the bootstrap and depress the CLEAR and CONT nothing happens. This is the bootstrap I use: 0030 6743 DMNT 0031 5031 JMP 31 Its from the OS/8 handbook so I guess that its correct but it looks strange. The problem could also be that I dont have a disk with OS/8 on, is there any way to check this other then just try the bootstrap and see if it works? Tommy From McCrohan@iol.ie Thu Jun 23 02:56:20 EDT 1994 Article: 933 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!zombie.ncsc.mil!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!ieunet!iol!iol!not-for-mail From: McCrohan@iol.ie (Mike McCrohan) Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Date: 22 Jun 1994 18:03:56 +0100 Organization: Ireland On-Line Lines: 22 Sender: mccrohan@iol.ie Message-ID: References: <2rg3q4$fsv@nexus.uiowa.edu> <1994Jun20.094700.21769@cc.usu.edu> NNTP-Posting-Host: ulysses.iol.ie In article <1994Jun20.094700.21769@cc.usu.edu>, ivie@cc.usu.edu wrote: > In article , McCrohan@iol.ie (Mike McCrohan) writes: > > The VAX finally departed from M series CPU modiles with the introduction > > of the extended hex boards. Are these not H-series too? (Major brain rot > > in the memory are here). > > While it's been an awfully long time since I looked in a /780, I know that a > lot of the strange stuff used in VAXes was labelled L-series. I know the > VAXstation 3520/3540 used L-series and I'm fairly certain that the /750 used > L-series, also. Yes, of course, it was/is L-series. The brain rot is getting worse! -mike From lasner@sunSITE.unc.edu Thu Jun 23 03:33:40 EDT 1994 Article: 934 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 23 Jun 1994 07:34:00 GMT Organization: University of North Carolina, Chapel Hill Lines: 114 Message-ID: <2ubdt8$mgv@bigblue.oit.unc.edu> References: <2u77ka$fnm@krel.iea.com> <1994Jun22.113957.2731@nomina.lu.se> NNTP-Posting-Host: calzone.oit.unc.edu In article <1994Jun22.113957.2731@nomina.lu.se>, Tommy Stendahl wrote: >In article fnm@krel.iea.com, billh@comtch.iea.com (Bill Haygood) writes: >>Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: >>: How long time should it take to bootstrap OS-8 from an RK05? >> >>: Tommy >> >>If I understand your question correctly, i.e. after toggling in the >>RK8E bootstrap (3 locs) and depressing the CLEAR and CONT keys, how >>much time elapses before the OS/8 prompt appears? From my 1970's >>experience: virtually instantaneously. OS/8 has one of the shortest (not *the* shortest!) boot sequences even when coming up cold. Using the RK8E as an example, the boot reads in physical record 0000 (track 0, head 0, sector 0) into 00000-00377. In the process, the JMP . at 0031 is overlayed with other code just read in (somewhere between 0000 and 0031) even before the rest of the DMA is complete. (The whole process depends on there not being any I/O errors, for which no check is made.) Once the just-read-in code is in control, it generally waits for the done flag and could check for errors. Assuming no errors, the contents of 00000-00377 are now completely loaded. The rest of the boot process is performed by the now-resident code. In OS/8, the job is to move the contents of 00200-00377 to 07600-07777 because that's the image of the handler and where it must be to execute. (The DMA was convenient, but read the right stuff into the wrong place!) This is generally done by auto-indexed move loops becuase the relevant registers are pre-loaded by the DMA also (00010-00017). OS/8 also wants the stuff now in 00000-00177 to be moved to 17600-17777 (although some of these moves are extraneous; the loops structure makes it easier to move the pages simultaneously, etc.). At this point, if the boot continues in 7600 (RK8E doesn't) it causes a part of memory (0000-1777) to be written to designated scratch blocks reserved for the purpose. This operation could fail perhaps if the disk is write-protected, etc. The result is the error return taken from the call to the handler that is in 07600 and the HLT at 07604 results from this. (Note: different versions of OS/8 family members might put different exact instructions in 07604; all of them are a micro-coded instruction involving the basic HLT and perhaps CLA, etc.) In the case of the RK8E, the code proceeds directly to 07605, thus avoiding the write operation at 07600. (Not always the case with other devices!) The code there is a JMP after a CIF 10 to continue the boot process which is to read in the keyboard monitor into 0000-1777 (perhaps over the swapped-out image). It is this code that prints the "." prompt. Note that all of these operations involve disk sectors near the physical beginning of the disk; the disk has already been seeked to track 0 by virtue of the DLAG instruction, so this is all quite fast. Some OS/8 devices can't fit the handler into 4K. In this case, they require the machine to have 12K minimum. The two pages of the system handler now involve logical record 66 as well. (Anyone remember which half of record 66 is anomalous to which half of record 0 in an 8K system? I consider this a design weakness in that 4 pages are being used to express what's in 3 pages of memory.) Often the device boot code has to physically address the sector where the rest of the handler is, since the handler itself isn't up yet to accomplish the mapping! In any case, when all loaded, the handler is now resident in 07600-07777 and 27600-27777 (Note: a small handful of the field 2 locations are reserved for BATCH, which also requires 12K.) Pretty much the same code is found in 17600-17777 in either case. The rest of the boot process is handled as in the 8K system case, etc. Even this longer process is quite fast for most devices. At some other point, I'll describe the even shorter/faster P?S/8 boot process for a 4K system. But for systems such as the RK8E, all reasonable systems should boot up in less than a second; if you are waiting around, something is very wrong. >> _ >>|_) >>|_)ill > >Then something is wrong. After I have toggled in the bootstrap and depress the >CLEAR and CONT nothing happens. This is the bootstrap I use: > >0030 6743 DMNT >0031 5031 JMP 31 I would like to know where this incorrect info is coming from exactly. The RK8E instruction is known as DLAG although the octal value is correct. >Its from the OS/8 handbook so I guess that its correct but it looks strange. Strange is in the eye of the beholder. Part of the design process was to get the hand boot small as possible. As we discussed a few months ago, this is one of the top 5 boot devices in terms of short user toggle-in to get it up, etc. (Yet, there are still smaller, including one device that needs no words loaded!) > >The problem could also be that I dont have a disk with OS/8 on, is there any way to >check this other then just try the bootstrap and see if it works? Yes, try toggling in a slightly smarter program that checks for errors. Someone can post the correct octal contents of memory that ought to occur. IF you get errors, then you know where to begin. If you get totally alien memory read-in, then likely the disk ain't OS/8-bootable. Another possibility is that you get "shredded" data where some of the bits are fine, indicating a disk controller and/or memory/DMA problem, etc. Running the RK diagnostics (if you hanve a way of loading them without an OS) could help here, etc. > >Tommy cjl From pi92ts@pt.hk-r.se Thu Jun 23 16:11:08 EDT 1994 Article: 935 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun23.181149.24635@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: tornet.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2ubdt8$mgv@bigblue.oit.unc.edu> Date: Thu, 23 Jun 1994 18:11:49 GMT Lines: 56 In article mgv@bigblue.oit.unc.edu, lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article <1994Jun22.113957.2731@nomina.lu.se>, >Tommy Stendahl wrote: > [Very interesting part removed] >>Then something is wrong. After I have toggled in the bootstrap and depress the >>CLEAR and CONT nothing happens. This is the bootstrap I use: >> >>0030 6743 DMNT >>0031 5031 JMP 31 > >I would like to know where this incorrect info is coming from exactly. >The RK8E instruction is known as DLAG although the octal value is correct. > Sorry, that was my misstake. > >>Its from the OS/8 handbook so I guess that its correct but it looks strange. > >Strange is in the eye of the beholder. Part of the design process was to >get the hand boot small as possible. As we discussed a few months ago, >this is one of the top 5 boot devices in terms of short user toggle-in to >get it up, etc. (Yet, there are still smaller, including one device that >needs no words loaded!) > Well, now that you have explained how it works it doesent look strange anymore. >> >>The problem could also be that I dont have a disk with OS/8 on, is there any way to >>check this other then just try the bootstrap and see if it works? > >Yes, try toggling in a slightly smarter program that checks for errors. >Someone can post the correct octal contents of memory that ought to I would really appreciate if someome could do that. >occur. IF you get errors, then you know where to begin. If you get >totally alien memory read-in, then likely the disk ain't OS/8-bootable. >Another possibility is that you get "shredded" data where some of the >bits are fine, indicating a disk controller and/or memory/DMA problem, >etc. Running the RK diagnostics (if you hanve a way of loading them >without an OS) could help here, etc. > Can I download it from my terminal? If so can you send it to me? >> >>Tommy > >cjl > Tommy From pi92ts@pt.hk-r.se Thu Jun 23 16:11:58 EDT 1994 Article: 936 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun23.175518.23979@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: tornet.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2ubdt8$mgv@bigblue.oit.unc.edu> Date: Thu, 23 Jun 1994 17:55:18 GMT Lines: 57 In article mgv@bigblue.oit.unc.edu, lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article <1994Jun22.113957.2731@nomina.lu.se>, >Tommy Stendahl wrote: [Very interesting part removed] >>Then something is wrong. After I have toggled in the bootstrap and depress the >>CLEAR and CONT nothing happens. This is the bootstrap I use: >> >>0030 6743 DMNT >>0031 5031 JMP 31 > >I would like to know where this incorrect info is coming from exactly. >The RK8E instruction is known as DLAG although the octal value is correct. > Sorry, that was a misstake by me. > >>Its from the OS/8 handbook so I guess that its correct but it looks strange. > >Strange is in the eye of the beholder. Part of the design process was to >get the hand boot small as possible. As we discussed a few months ago, >this is one of the top 5 boot devices in terms of short user toggle-in to >get it up, etc. (Yet, there are still smaller, including one device that >needs no words loaded!) > Well, now that you have explained how it works it dosent look strange anymore. >> >>The problem could also be that I dont have a disk with OS/8 on, is there any way to >>check this other then just try the bootstrap and see if it works? > >Yes, try toggling in a slightly smarter program that checks for errors. >Someone can post the correct octal contents of memory that ought to >occur. IF you get errors, then you know where to begin. If you get I would realy appreciate if someone could do that. >totally alien memory read-in, then likely the disk ain't OS/8-bootable. >Another possibility is that you get "shredded" data where some of the >bits are fine, indicating a disk controller and/or memory/DMA problem, >etc. Running the RK diagnostics (if you hanve a way of loading them >without an OS) could help here, etc. > Can I download it from the computer I use as terminal? If so can you send it to me? >> >>Tommy > >cjl > Tommy From jones@pyrite.cs.uiowa.edu Thu Jun 23 18:45:52 EDT 1994 Article: 937 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!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: Asides in PAL code Date: 23 Jun 1994 20:15:22 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 54 Distribution: world Message-ID: <2ucqgq$ljl@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Before I write code that depends on it, I want to check to see if one of my favorite assembly language coding tricks is generally effective under most PAL implementations for the PDP-8. Here's an assembly listing that illustrates the trick and shows a correct assembly of it: 1 PAGE 2 THUMB=.;*POOL / begin aside 3 00600 0001 A, 1 / eg, text that goes with 4 00601 0002 B, 2 / stuff on this page 5 POOL=.;*THUMB / end aside 6 00200 0600 A / this is assembled normally 7 00201 0601 B / and references the aside 8 PAGE 9 THUMB=.;*POOL / begin aside 10 00602 0003 C, 3 / stuff referenced by 11 00603 0004 D, 4 / a different page 12 POOL=.;*THUMB / end aside 13 00400 0602 C / this is assembled normally 14 00401 0603 D / and references its stuff 15 PAGE 16 POOL= . / asides assemble after here 17 $ If you've used an assembler with different csects (in the MACRO-11 sense of the word), the uses of this should be apparent. I think the first place I saw it done this was was under the assembler on the DDP-516, which was paged in the same way as the PDP-8. The idea is that you want things that are related to each other to be nearby in the source listing, but if something is never directly referenced as an operand (that is, full-word pointers are always used), it has no business on the same page as the code that references it. So, put the stuff that belongs elsewhere in the aside for the page holding the code that references it. TEXT directives are obvious material for such asides. So are most arrays. The problem is, some assemblers die when they hit an undefined assembly origin, even if, as in the above example, everything works out perfectly by the time it matters (during the second pass). At least one assembler I used this trick with assembled the code correctly, but it did so with a huge belch of error messages, a "fatal" pass one error for each undefined origin, plus a "multiply defined label" error for each label defined in an aside. Programming with this approach does introduce one little stumbling block, you can't make a forward reference to code in an aside because those symbols are still undefined at the end of pass 1 (well, they might be defined, but they got their values from an undefined location counter). So, does the above assembler as above under OS/8 PAL, how about P?S/8. Doug Jones jones@cs.uiowa.edu From billh@comtch.iea.com Fri Jun 24 13:48:51 EDT 1994 Article: 938 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!sundog.tiac.net!news.sprintlink.net!nwnexus!krel.iea.com!comtch!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 23 Jun 1994 22:49:32 GMT Organization: home Lines: 53 Message-ID: <2ud3hs$gos@krel.iea.com> References: <2u77ka$fnm@krel.iea.com> <1994Jun22.113957.2731@nomina.lu.se> NNTP-Posting-Host: comtch.iea.com X-Newsreader: TIN [version 1.2 PL1] Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: : In article fnm@krel.iea.com, billh@comtch.iea.com (Bill Haygood) writes: : >Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: : >: How long time should it take to bootstrap OS-8 from an RK05? : > : >: Tommy : > : >If I understand your question correctly, i.e. after toggling in the : >RK8E bootstrap (3 locs) and depressing the CLEAR and CONT keys, how : >much time elapses before the OS/8 prompt appears? From my 1970's : >experience: virtually instantaneously. : > _ : >|_) : >|_)ill : Then something is wrong. After I have toggled in the bootstrap and : depress the CLEAR and CONT nothing happens. This is the bootstrap I use: : 0030 6743 DMNT The `6743' actually means DLAG for `Disk Load And Go' (this instruction loads the C(AC) into the disk address register and loads that block [block zero, in this case] into pdp8 memory address 0). So, the block on the disk should copy into pdp8 locations 0-377. Locations 0030-0031 get overlaid in the process. The DLAG instruction gets replaced with something like `DSKP, JMP .-1' and waits until the transfer completes. : 0031 5031 JMP 31 : Its from the OS/8 handbook so I guess that its correct but it looks strange. : The problem could also be that I dont have a disk with OS/8 on, is there any way to check this other then just try the bootstrap and see if it works? To check this out quickly, I would try to locate a known good OS/8 RK05 boot pack and boot that. Others on the group could likely answer these questions much more definitively than I. : Tommy We did, perhaps leave out two steps, namely: after toggling in the bootstrap (yours above appears correct), reset the SR switches to 0030, then press LOAD ADDR, reset SR switches to 0000, press EXT LOAD ADDR, *then* press CLEAR and CONT. It you have already done these steps and OS/8 still does not boot, then something else likely has failed (hardware perhaps or RK05 pack does not have a `normal' RK05 OS/8 boot on it). _ |_) |_)ill From pi92ts@pt.hk-r.se Fri Jun 24 13:49:54 EDT 1994 Article: 939 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!EU.net!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun24.105944.28313@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: lalle.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2ud3hs$gos@krel.iea.com> Date: Fri, 24 Jun 1994 10:59:44 GMT Lines: 88 In article gos@krel.iea.com, billh@comtch.iea.com (Bill Haygood) writes: >Tommy Stendahl (pi92ts@pt.hk-r.se) wrote: >: Then something is wrong. After I have toggled in the bootstrap and >: depress the CLEAR and CONT nothing happens. This is the bootstrap I use: > >: 0030 6743 DMNT > >The `6743' actually means DLAG for `Disk Load And Go' (this instruction >loads the C(AC) into the disk address register and loads that block [block >zero, in this case] into pdp8 memory address 0). So, the block on the >disk should copy into pdp8 locations 0-377. Locations 0030-0031 get >overlaid in the process. The DLAG instruction gets replaced with >something like `DSKP, JMP .-1' and waits until the transfer completes. > >: 0031 5031 JMP 31 > >: Its from the OS/8 handbook so I guess that its correct but it looks strange. > >: The problem could also be that I dont have a disk with OS/8 on, is there >any way to check this other then just try the bootstrap and see if it works? > >To check this out quickly, I would try to locate a known good OS/8 RK05 >boot pack and boot that. > >Others on the group could likely answer these questions much more >definitively than I. > >: Tommy > >We did, perhaps leave out two steps, namely: after toggling in the >bootstrap (yours above appears correct), reset the SR switches to 0030, >then press LOAD ADDR, reset SR switches to 0000, press EXT LOAD ADDR, >*then* press CLEAR and CONT. > I did this steps to so thats not the problem. >It you have already done these steps and OS/8 still does not boot, then >something else likely has failed (hardware perhaps or RK05 pack does >not have a `normal' RK05 OS/8 boot on it). > _ >|_) >|_)ill I did a litle test today. I tryed the bootstrap on all (7) disks I have and then I checked loc 0030-0032 after each one and wrote down the value in them. This is the results: disk 1: 0030 0671 0031 5503 0032 6006 disk 2: 0030 6203 0031 0321 0032 1630 disk 3: 0030 6203 0031 0321 0032 1630 disk 4: 0030 6203 0031 0321 0032 1630 disk 5: 0030 6203 0031 0307 0032 1630 disk 6: 0030 6203 0031 0321 0032 1630 disk 7: 0030 1570 0031 5507 0032 7003 Can someone check that value this locs should have? Tommy From lasner@sunSITE.unc.edu Fri Jun 24 14:10:01 EDT 1994 Article: 940 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 24 Jun 1994 18:06:58 GMT Organization: University of North Carolina, Chapel Hill Lines: 33 Message-ID: <2uf7c2$f1u@bigblue.oit.unc.edu> References: <2ud3hs$gos@krel.iea.com> <1994Jun24.105944.28313@nomina.lu.se> NNTP-Posting-Host: calzone.oit.unc.edu In article <1994Jun24.105944.28313@nomina.lu.se>, Tommy Stendahl wrote: > >I did a litle test today. I tryed the bootstrap on all (7) disks I have and This doesn't accomplish much. Now we know your machine is capable of DMA because the locations got to be different (assuming that 6743; 5031 executes as normal -8 instructions in the first place!). The problem with further testing of this nature is that the locations are quickly modified when it works, so you are setting off a large cataclysm of memory contents change that can give no useful results, etc. Here's a better method: into 00377 put 6743 followed by 5200. Start it as the original but instead of 0030 start at 0377. The machine should loop indefinitely in 0400 with that JMP . instruction. Location 00377 should be different from 6743 (an unlikely contents of that word for a bootable disk). You might also want to pre-load 0000-0376 with 7777 once to prove that these locations all get changed. (Again, using 7777 is because this is an unlikely value to be found in a valid bootblock image.) Assuming the contents of 0000-0377 changed (and also 0400 did not!) you can then rattle off for us the first few dozen locations from 0000 onward to see if it's something familiar, etc. The most important stuff is what comes into 0000-0031. If that works, we'll see about some secondary help,e tc. cjl From lasner@sunSITE.unc.edu Fri Jun 24 14:26:50 EDT 1994 Article: 941 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Asides in PAL code Date: 24 Jun 1994 18:27:16 GMT Organization: University of North Carolina, Chapel Hill Lines: 72 Message-ID: <2uf8i4$rnk@bigblue.oit.unc.edu> References: <2ucqgq$ljl@nexus.uiowa.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <2ucqgq$ljl@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: [wants to use pet tricks] Your assembly is not "correct" by PDP-8 standards. Both PAL8 and P?S/8 will not tolerate symbols defined by comma being redefined unless the redefinition is to precisely the same value as a special case. During pass one, "POOL" is undefined the first time, thus giving an undefined expression to lead to the argument to the "*". P?S/8 and PAL8 differ on this one slightly. PAL8 will make the entire expression 0000 since it's undefined. P?S/8 PAL will attempt to continue the expression scan with just the local symbol value being 0000. (Your example is too trivial to see a difference; try something like POOL+1.) If you can change the program so that POOL starts out at its final value after pass one ends, but at the start of pass 1, then it will assemble without errors. Note also that equated symbols can be redefined without error. BTW, a quirk of P?S/8 PAL is that since there is a pass-1-end summary of undefined symbols whose values are listed as the first occurrence's address, you may have code that yields an error-free two-pass assembly even though there is a one-pass error. (Since PAL8 can do neither a one-pass assembly nor a pass-1-end status report, you don't see the problem, etc.) IF PAL8 were upgraded to include a between-passes summary, the error would pop up, etc. since the table shows undefined symbols. > > 1 PAGE > 2 THUMB=.;*POOL / begin aside > 3 00600 0001 A, 1 / eg, text that goes with > 4 00601 0002 B, 2 / stuff on this page > 5 POOL=.;*THUMB / end aside > 6 00200 0600 A / this is assembled normally > 7 00201 0601 B / and references the aside > 8 PAGE > 9 THUMB=.;*POOL / begin aside > 10 00602 0003 C, 3 / stuff referenced by > 11 00603 0004 D, 4 / a different page > 12 POOL=.;*THUMB / end aside > 13 00400 0602 C / this is assembled normally > 14 00401 0603 D / and references its stuff > 15 PAGE > 16 POOL= . / asides assemble after here > 17 $ > > >Programming with this approach does introduce one little stumbling >block, you can't make a forward reference to code in an aside because >those symbols are still undefined at the end of pass 1 (well, they might >be defined, but they got their values from an undefined location >counter). Generally not true. It can be done, as long as the second pass starts with the finally correct value. The exception case is when literals are being referenced, since the address of a literal is dependent on all references to all symbols that contribute to prior entries in the literal tables. (At higher addresses since literals start at the end of the page and work back towards the beginning.) > >So, does the above assembler as above under OS/8 PAL, how about P?S/8. > > Doug Jones > jones@cs.uiowa.edu Your assembler needs to be made meaner, so that you get ID or DT errors attempting to redefine code labels. You can always use = to get what you want though. cjl From copley1@muvms6.wvnet.edu Sat Jun 25 14:00:24 EDT 1994 Article: 942 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!solaris.cc.vt.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!darwin.sura.net!wvnvms!marshall.wvnet.edu!copley1 Newsgroups: alt.sys.pdp8 Subject: Re: Canonical Flip-Chip Terminology Message-ID: <1994Jun24.085812.6976@muvms6> From: copley1@muvms6.wvnet.edu (Ronald Copley) Date: 24 Jun 94 08:58:12 EDT References: <2rg3q4$fsv@nexus.uiowa.edu> <13JUN199420312757@siva.bris.ac.uk> <1994Jun17.102656.6787@muvms6> <2u23s0$okq@usenet.rpi.edu> Organization: Marshall University Lines: 29 In article <2u23s0$okq@usenet.rpi.edu>, wilsonj@alum01.its.rpi.edu (John Wilson) writes: > In article <1994Jun17.102656.6787@muvms6>, > Ronald Copley wrote: >>>>Hmm, how about the modules without handles, e.g. PDT-11/150? Are't >>>>they M also series? If so, there's a third color: invisible! > >>Well, since the 150 had an /03 (or /23, if you had the EIS/FIS chipset and >>dual microm) CPU, I guess it could be construed to be indirectly M-series... > > Um no, the 2-in-1 microm and EIS/FIS microm just made it an /03 with EIS/FIS. > F-11 is an entirely different chipset. Anyway this sounds familiar, I'm 99% > sure that the 11/150 boards really had "Mxxxx" designations, and I think the > handle-less board in an LA120 does too (both are in storage or I'd look). > > John Wilson Just checked this and you're right. I must have been high. I need to clear my head of all the extraneous info floating about in it. At any rate, when someone gets the Mxxxx designations for the PDT-11, please post them. -- Ronald Copley, owner | As always, I'm interested in your old Informatiks | computer equipment. Particularly DEC, 1010 Township RD 78W | Pyramid, Sun and DG. Scottown OH 45678-9051 | +1.614.643.1340 | If you have Pink Fairies bootlegs, etc. | *please* contact me! -- From jones@pyrite.cs.uiowa.edu Sat Jun 25 15:13:29 EDT 1994 Article: 943 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Asides in PAL code Date: 24 Jun 1994 20:36:26 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 65 Distribution: world Message-ID: <2ufg4a$sfh@nexus.uiowa.edu> References: <2uf8i4$rnk@bigblue.oit.unc.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <2uf8i4$rnk@bigblue.oit.unc.edu>, by lasner@sunSITE.unc.edu (Charles Lasner): > If you can change the program so that POOL starts out at its final value > after pass one ends, but at the start of pass 1, then it will assemble > without errors. That's no fun, because you have to know what page your pool starts on before you can assemble things correctly. Of course, you can assemble it, with errors, check the outcome, define POOL to match it's eventual value, then assemble it again without errors, but that's no fun. > Note also that equated symbols can be redefined without > error. That means that the following is safe code, merely by substituting, for example, "A=.; 1" for "A, 1". It's ugly, but sometimes, ugly is OK. 1 PAGE 2 THUMB=.;*POOL / begin aside 3 00600 0001 A=.; 1 / eg, text that goes with 4 00601 0002 B=.; 2 / stuff on this page 5 POOL=.;*THUMB / end aside 6 00200 0600 A / this is assembled normally 7 00201 0601 B / and references the aside 8 PAGE 9 THUMB=.;*POOL / begin aside 10 00602 0003 C=.; 3 / stuff referenced by 11 00603 0004 D=.; 4 / a different page 12 POOL=.;*THUMB / end aside 13 00400 0602 C / this is assembled normally 14 00401 0603 D / and references its stuff 15 PAGE 16 POOL= . / asides assemble after here 17 $ > BTW, a quirk of P?S/8 PAL is that since there is a pass-1-end > summary of undefined symbols whose values are listed as the first > occurrence's address, you may have code that yields an error-free > two-pass assembly even though there is a one-pass error. That's what happened with MODCOMP's assembler all the time. It assembled correctly, but it only did it while kicking and screaming. I ended up living with the error messages, much to the disgust of the people in MODCOMP's software support department. I was using essentially the above trick to generate the jump table for a Pascal case statement. The compiler worked like a charm, but programmers had to learn to ignore all the pass one errors out of the assembler (you'd get one such error for every case label). > > Your assembler needs to be made meaner, so that you get ID or DT errors > attempting to redefine code labels. You're right about that, but I've always used the following algorithm to generate such error messages: When assigning a value to a label (as defined with a comma in PAL, or with a colon in MACRO-11), require either that the previous value of the label be undefined or that the previous value be the same as the new one. During pass 1, A, B, C and D in the above example get undefined values because the location counter was undefined. Of course, I had the luxury of room for code to distinguish undefined from other values, and shoehorning an assembler into 4K doesn't guarantee room for this. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Sat Jun 25 15:17:54 EDT 1994 Article: 944 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Asides in PAL code Date: 25 Jun 1994 19:14:03 GMT Organization: University of North Carolina, Chapel Hill Lines: 181 Message-ID: <2uhvlr$hsv@bigblue.oit.unc.edu> References: <2uf8i4$rnk@bigblue.oit.unc.edu> <2ufg4a$sfh@nexus.uiowa.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <2ufg4a$sfh@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article <2uf8i4$rnk@bigblue.oit.unc.edu>, >by lasner@sunSITE.unc.edu (Charles Lasner): > >> If you can change the program so that POOL starts out at its final value >> after pass one ends, but at the start of pass 1, then it will assemble >> without errors. > >That's no fun, because you have to know what page your pool starts >on before you can assemble things correctly. Of course, you can >assemble it, with errors, check the outcome, define POOL to match >it's eventual value, then assemble it again without errors, but >that's no fun. True, but the alternatives are fun-breakers or error messages. And worse, the errors are real, i.e., the redefinition doesn't take, so it stays being wrong at the initial, albeit useless, values. DT means duplicate tag error, it gets ignored. Sometimes it's known as an illegal definition or ID error, again it gets ignored. > >> Note also that equated symbols can be redefined without >> error. > >That means that the following is safe code, merely by substituting, for >example, "A=.; 1" for "A, 1". It's ugly, but sometimes, ugly is OK. > > 1 PAGE > 2 THUMB=.;*POOL / begin aside > 3 00600 0001 A=.; 1 / eg, text that goes with > 4 00601 0002 B=.; 2 / stuff on this page > 5 POOL=.;*THUMB / end aside > 6 00200 0600 A / this is assembled normally > 7 00201 0601 B / and references the aside > 8 PAGE > 9 THUMB=.;*POOL / begin aside > 10 00602 0003 C=.; 3 / stuff referenced by > 11 00603 0004 D=.; 4 / a different page > 12 POOL=.;*THUMB / end aside > 13 00400 0602 C / this is assembled normally > 14 00401 0603 D / and references its stuff > 15 PAGE > 16 POOL= . / asides assemble after here > 17 $ > Yes, that works fine, because you have relieved the assembler of address label responsibility; equates are always the final authority, as well they should be. (It's saying to the assembler that I know what this should be whether you think you did know or not!) >> BTW, a quirk of P?S/8 PAL is that since there is a pass-1-end >> summary of undefined symbols whose values are listed as the first >> occurrence's address, you may have code that yields an error-free >> two-pass assembly even though there is a one-pass error. This feature emanates from the original paper-tape PAL III and was never added to PAL8. The problems over the years with PAL8 stem from the fact that we bitched about it for years to a deaf-eared Richard Lary who assumed that Mark Bramhall knew how to write non-quirky assemblers. (The earliest PAL8 versions were quite brain-dead. My Kermit-12 distribution includes one file, DECODE.PAL, which is written in a subset of what I'd normally expect from PAL8, so that it can be locally assembled on a user site. The resulting binary can then be used to decode the rest of the Kermit-12 distribution, which includes the PAL8 Version B0 from OS/278, which is a much better assembler than its ancestors, etc.) Eventually, Richie apologized to me when he saw just how piss-poor it was. He did some fast fixes to it to make it passible, but then had no further time to improve it. No significent work has ever been done on it since then, other than Jim Roth's hashing symbol routines. (Jim is the original architect of P?S/8 PAL.) Jim spent a lot of time developing PDP-8 quick-sort and hashing routines using a dummy "null assembler" that basically scanned for symbols and placed them in the table. Real source files were used for timing tests, etc. The results of his tests were the basis for routines added to both P?S/8 PAL and also PAL8 at different times, etc. Jim was quite encouraged by the way the optimized routines ran faster than the older methods both assemblers used (binary searches, etc.), and he proceeded to add live code to PAL8 while we upgraded P?S/8 PAL. (I was adding many features to P?S/8 PAL at the time to support LINC mode, literals, obscure syntax such as "JMP.-1", etc., so it was a good time to upgrade the symbol stuff as well.) However, he was greatly disappointed by the dismal performance of PAL8, in that only insignificent improvement resulted in PAL8 due to its overall crummy design and poor scanning performance; the symbol table probes aren't the largest factor in terms of time spent, so improving those routines doesn't contribute that much! This is part of why P?S/8 PAL today is so much faster an assembler than PAL8, more a matter of how slow PAL8 is, than how fast P?S/8 PAL is, i.e., PAL8 could be rewritten from the ground up and would be much faster, etc. At one point, DEC was negotiating with me for using P?S/8 PAL as the CAPS-8 assembler. I had been disappointed with them too many times by then, and I demanded a credible discussion before proceeding. (Too many free demos to idiot managers who had attitude problems, etc.) When they saw I was serious, they abandoned me. The net result is that CAPS-8 PALC is just a warmed-over variant on PAL8 of that era, etc. This was the infamous "showdown" incident where I ran P?S/8 on two DECtapes versus them running OS/8 on an RK8E. They chose the task, which turned out to be to assemble CCL.PA on both systems. After leveling the playing field on considerations such as line-printing, etc., we ran the "race". OS/8 and PAL8 was indeed twice as fast as P?S/8 PAL! But considering that an RK8E-based system ought to be 10-20 times as fast as a DECtape made them scared! (The coup-de-grace was when I binary loaded the results from the DECtape *faster* than OS/8 could from the RK8E.) > >That's what happened with MODCOMP's assembler all the time. It assembled >correctly, but it only did it while kicking and screaming. I ended up >living with the error messages, much to the disgust of the people in >MODCOMP's software support department. I was using essentially the above >trick to generate the jump table for a Pascal case statement. The compiler >worked like a charm, but programmers had to learn to ignore all the pass >one errors out of the assembler (you'd get one such error for every >case label). Programmers have always attempted to do sane things that were disallowed by stupid assemblers. Try on an x86 machine to generate a short jump instruction at the beginning of your code around all of the data to the real program start address. MASM assumes the need for a long jump so you waste a NOP anyway. (The data comes first because otherwise all of the other references to the data will also become long; it's too stupid to figure it out unless the references come after the definition.) There is an x86 disassembler called Master Key that creates code with comments explaining that the syntax will cause errors in MASM. Apparently the programmers used data bytes to create the values directly! >> >> Your assembler needs to be made meaner, so that you get ID or DT errors >> attempting to redefine code labels. > >You're right about that, but I've always used the following algorithm to >generate such error messages: When assigning a value to a label (as >defined with a comma in PAL, or with a colon in MACRO-11), require either >that the previous value of the label be undefined or that the previous >value be the same as the new one. During pass 1, A, B, C and D in the >above example get undefined values because the location counter was >undefined. Of course, I had the luxury of room for code to distinguish >undefined from other values, and shoehorning an assembler into 4K doesn't >guarantee room for this. No, the symbol does have the ability to be considered undefined. As I said, there is a pass-one-end summary of all symbols still undefined using the first usage occurrence's address as the "value" for the benefit of the printout, etc. However, there is no provision for the concept that the current location counter is itself in an undefined state. Thus each statement is an island unto itself, contrary to your algorithm. Additionally, PAL8 voids the entire statement returning 0000 should any part of it be undefined, while P?S/8 PAL merely voids the undefined item. Thus, code with errors flagged can generate different output: PAL8: 0000 UNDEF+1 1000 TAD UNDEF+1 P?S/8: 0001 UNDEF+1 1001 TAD UNDEF+1 I tend to think the P?S/8 PAL method is more consistent, since PAL8 doesn't void the entire expression should the statement be an MRI, while P?S/8 PAL never voids anything but the undefined element. BTW, P?S/8 PAL has some extensions to the syntax that is reminiscent of the -11: FOO: TAD #3 The : is equivalent to the , and the # is equivalent to the (. > Doug Jones > jones@cs.uiowa.edu cjl From pi92ts@pt.hk-r.se Sun Jun 26 11:55:01 EDT 1994 Article: 945 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!pipex!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun26.153146.20434@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: lelle.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2uf7c2$f1u@bigblue.oit.unc.edu> Date: Sun, 26 Jun 1994 15:31:46 GMT Lines: 73 In article f1u@bigblue.oit.unc.edu, lasner@sunSITE.unc.edu (Charles Lasner) writes: >Here's a better method: > >into 00377 put 6743 followed by 5200. Start it as the original but >instead of 0030 start at 0377. The machine should loop indefinitely in >0400 with that JMP . instruction. Location 00377 should be different >from 6743 (an unlikely contents of that word for a bootable disk). You >might also want to pre-load 0000-0376 with 7777 once to prove that these >locations all get changed. (Again, using 7777 is because this is an >unlikely value to be found in a valid bootblock image.) > >Assuming the contents of 0000-0377 changed (and also 0400 did not!) you >can then rattle off for us the first few dozen locations from 0000 onward >to see if it's something familiar, etc. The most important stuff is what >comes into 0000-0031. > >If that works, we'll see about some secondary help,e tc. > >cjl > Ok, I tryed your method today. I pre-loaded 0000-0376 with 7777 and 0000-0377 were changed and 0400 were not. Then I for each disk I put 6743 in to 0377 and 5200 in to 0400 and started it at 0377 and then I wrote down the value of 0000-0031. Here it is: disk1 0000: 1412 3413 7005 1013 7640 5000 1414 6211 0010: 3415 5016 0177 7577 0047 7727 0406 0230 0020: 1750 1205 2403 2403 3440 6410 7501 1543 0030: 1474 5503 disk2 0000: 1412 3413 7005 1013 7640 5000 1414 6211 0010: 3415 5016 0177 7577 0046 7646 1015 1040 0020: 7640 5024 2014 2015 6201 2041 5006 5437 0030: 6741 5030 disk3 0000: 1412 3413 1414 6211 3415 6201 1013 7640 0010: 5000 5437 0177 7577 0046 7646 0000 0000 0020: 0000 0000 0000 0000 0000 0000 0000 0000 0030: 6741 5030 disk4 0000: 1412 3413 1414 6211 3415 6201 1013 7640 0010: 5000 5437 0177 7577 0046 7646 0000 0000 0020: 0000 0000 0000 0000 0000 0000 0000 0000 0030: 6741 5030 disk5 0000: 1412 3413 1414 6211 3415 6201 1013 7640 0010: 5000 5437 0177 7577 0046 7646 0000 0000 0020: 0000 0000 0000 0000 0000 0000 0000 0000 0030: 6741 5030 disk6 0000: 1412 3413 1414 6211 3415 6201 1013 7640 0010: 5000 5437 0177 7577 0046 7646 0000 0000 0020: 0000 0000 0000 0000 0000 0000 0000 0000 0030: 6741 5030 disk7 0000: 1412 3413 7005 1413 3720 2400 6606 3442 0010: 4703 7203 7437 6757 6004 5764 0101 0104 0020: 4764 4502 5201 1201 1620 6204 7500 1543 0030: 4674 6643 If someone could check this and make any sense out of it I would be very greatfull. Tommy From lasner@sunSITE.unc.edu Sun Jun 26 16:53:25 EDT 1994 Article: 946 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 26 Jun 1994 20:54:06 GMT Organization: University of North Carolina, Chapel Hill Lines: 79 Message-ID: <2ukpte$u50@bigblue.oit.unc.edu> References: <2uf7c2$f1u@bigblue.oit.unc.edu> <1994Jun26.153146.20434@nomina.lu.se> NNTP-Posting-Host: calzone.oit.unc.edu In article <1994Jun26.153146.20434@nomina.lu.se>, Tommy Stendahl wrote: > >disk1 >0000: 1412 3413 7005 1013 7640 5000 1414 6211 >0010: 3415 5016 0177 7577 0047 7727 0406 0230 >0020: 1750 1205 2403 2403 3440 6410 7501 1543 >0030: 1474 5503 Clearly this is a disk bootstrap record, but not the standard OS/8 one. This one bothers to avoid changing 07777, and there is some skewed moving going on in field 1. Perhaps this is a COS boot or some privately written system? > >disk2 >0000: 1412 3413 7005 1013 7640 5000 1414 6211 >0010: 3415 5016 0177 7577 0046 7646 1015 1040 >0020: 7640 5024 2014 2015 6201 2041 5006 5437 >0030: 6741 5030 Strangely, the field 1 stuff in this one is different! > >disk3 >0000: 1412 3413 1414 6211 3415 6201 1013 7640 >0010: 5000 5437 0177 7577 0046 7646 0000 0000 >0020: 0000 0000 0000 0000 0000 0000 0000 0000 >0030: 6741 5030 This looks more like OS/8. > >disk4 >0000: 1412 3413 1414 6211 3415 6201 1013 7640 >0010: 5000 5437 0177 7577 0046 7646 0000 0000 >0020: 0000 0000 0000 0000 0000 0000 0000 0000 >0030: 6741 5030 Ditto. > >disk5 >0000: 1412 3413 1414 6211 3415 6201 1013 7640 >0010: 5000 5437 0177 7577 0046 7646 0000 0000 >0020: 0000 0000 0000 0000 0000 0000 0000 0000 >0030: 6741 5030 Ditto. > >disk6 >0000: 1412 3413 1414 6211 3415 6201 1013 7640 >0010: 5000 5437 0177 7577 0046 7646 0000 0000 >0020: 0000 0000 0000 0000 0000 0000 0000 0000 >0030: 6741 5030 Ditto. > >disk7 >0000: 1412 3413 7005 1413 3720 2400 6606 3442 >0010: 4703 7203 7437 6757 6004 5764 0101 0104 >0020: 4764 4502 5201 1201 1620 6204 7500 1543 >0030: 4674 6643 If this one isn't the results of your not completely erasing memory pre the DMA, then it's a strangely corrupted case that seems to start with that variant as above, but quickly becomes corrupted junk, etc. So, stick with the ones that are at least the beginning of OS/8, although this is no guarantee you'll get the whole thing up. Pick one, and I suggest an octal dump of the whole record. IF we get that far, then we can tackle the rest of the blocks, etc. While tedious, it is possible to patch the disk in memory by a read-patch-write sequence, assuming it isn't too badly messed up,etc. Has the machine in question been determined to be otherwise functional? cjl From pi92ts@pt.hk-r.se Tue Jun 28 11:34:18 EDT 1994 Article: 947 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun26.233604.3344@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: lalle.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2ukpte$u50@bigblue.oit.unc.edu> Date: Sun, 26 Jun 1994 23:36:04 GMT Lines: 27 In article u50@bigblue.oit.unc.edu, lasner@sunSITE.unc.edu (Charles Lasner) writes: >So, stick with the ones that are at least the beginning of OS/8, although >this is no guarantee you'll get the whole thing up. Pick one, and I >suggest an octal dump of the whole record. IF we get that far, then we >can tackle the rest of the blocks, etc. > Thanks for helping me so far. I will pick one of the disks that look like it might be an OS/8 disk and try to dump the whole record. >While tedious, it is possible to patch the disk in memory by a >read-patch-write sequence, assuming it isn't too badly messed up,etc. > >Has the machine in question been determined to be otherwise functional? > I have tryed the small test progs that were posted here a while back. And done someouther small test and everything seams to work. >cjl But I was thinking maybe its my terminal that isn't compatible with OS/8 or something like that. The one I use now is vt100/ANSI with 8bit ASCII, is this ok? Tommy From jones@pyrite.cs.uiowa.edu Tue Jun 28 11:34:56 EDT 1994 Article: 948 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!pipex!uknet!EU.net!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Bootable RX01 diskette image? Date: 27 Jun 1994 14:49:09 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 15 Distribution: world Message-ID: <2umot5$58e@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu My X-windows PDP-8/E emulator now has an almost working RX01 emulation, and I need to test it out. Perhaps the most interesting test would be to get a bootable RX01 diskette image and see if I can run something from the thing. Anyone willing to mail me such a goodie? I'd suggest compressing and uuencoding it for transit, and please tell me what format it's in. The format that would be easiest to digest would be a literal byte stream image of the entire disk, 128 bytes per sector, starting with sector 1 track 0 and going all the way to sector 26 track 76. With that kind of data, I can manufacture an emulated disk image quite quickly (assuming that the application doesn't care about deleted data sectors). Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Tue Jun 28 12:02:34 EDT 1994 Article: 949 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bootable RX01 diskette image? Date: 28 Jun 1994 16:01:53 GMT Organization: University of North Carolina, Chapel Hill Lines: 44 Message-ID: <2uphhh$q16@bigblue.oit.unc.edu> References: <2umot5$58e@nexus.uiowa.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <2umot5$58e@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >My X-windows PDP-8/E emulator now has an almost working RX01 emulation, >and I need to test it out. Perhaps the most interesting test would be >to get a bootable RX01 diskette image and see if I can run something >from the thing. Anyone willing to mail me such a goodie? I'd suggest >compressing and uuencoding it for transit, and please tell me what format >it's in. The easiest way to get a bootable RX01 image is to use PDP-8 ENCODE format. RX01 boot conventions are such that track 0 is ignored, and the rest of the disk is read in 12-bit mode, thus the last 1/4 of each sector is ignored. (I think that when you write in 12-bit mode, the last 8 bits sent are replicated 32 times to flesh out the data.) Assuming that OS/8's standard RX01 handler was used with ENCODE.SV in image mode, the contents of the file are the logical records of the OS/8 layout which in turn implies that the sectors are referenced in 2:1 interleave order, each track identically laid out, etc: 1,3,5,7,9,11,13,15,17,19,21,23,25,2,4,6,8,10,12,14,16,18,20,22,24,26 in terms of sector order of the data. Thus, the binary level of the file is the data for each sector's first 96 bytes in the proscribed sector order for all tracks 1 through 76. (Thus wasting all of track 0 and the last 1/4 of every other sector on the entire diskette.) It would be useful to create a utility that converts the output of ENCODE into a byte stream. The only assumption needed is that the data represents multiples of 192 bytes represented as multiples of 128 12-bit words. Data lost would be device-dependent, such as the mapping described above for RX stuff, or the DECtape phenomena where each 128 12-bit word set excludes the 129th physical word for each block, etc. So, a pair of conversion utilites to/from ENCODE format seems to be a useful thing unto itself, and a solution to your specific, etc. ENCODE format is itself documented as part of the Kermit-12 collection available on watsun.cc.columbia.edu or sunsite.unc.edu, etc. See the file k12mit.dsk for a "roadmap" of the related files, etc. cjl From pi92ts@pt.hk-r.se Wed Jun 29 11:50:13 EDT 1994 Article: 950 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!xanth.cs.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Re: Bootstrap OS-8 Message-ID: <1994Jun28.162443.20764@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: lalle.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: University Karlskrona/Ronneby, Sweden References: <2ukpte$u50@bigblue.oit.unc.edu> Date: Tue, 28 Jun 1994 16:24:43 GMT Lines: 50 In article u50@bigblue.oit.unc.edu, lasner@sunSITE.unc.edu (Charles Lasner) writes: >So, stick with the ones that are at least the beginning of OS/8, although >this is no guarantee you'll get the whole thing up. Pick one, and I >suggest an octal dump of the whole record. IF we get that far, then we >can tackle the rest of the blocks, etc. > Ok, here is a dump of the whole record from one of the disks. 0000: 1412 3413 1414 6211 3415 6201 1013 7640 0010: 5000 5437 0177 7577 0046 7646 0000 0000 0020: 0000 0000 0000 0000 0000 0000 0000 0000 0030: 6741 5030 0035 3436 5000 0006 0342 7605 0040: 7326 6751 6211 4053 3417 5044 5205 7607 0050: 7607 0000 0000 0000 0000 0000 0000 0000 0060: 0000 0000 0000 0000 0000 0000 0000 6202 0070: 4207 1000 0000 0007 7746 6203 5677 1077 0100: 0000 3340 6214 1275 3336 6201 1674 7010 0110: 6211 7630 5321 6202 4207 5010 0000 0027 0120: 7402 6202 4207 0610 0000 0013 7602 5020 0130: 6202 4207 1010 0000 0027 7402 0000 5700 0140: 0000 0000 0000 0000 0000 0000 0000 0000 0150: 0000 0000 0000 0000 0000 0000 0000 0000 0160: 4230 4230 4230 4230 4230 4230 4230 4230 0170: 4250 4250 0000 1040 1020 2010 0000 0000 0200: 4207 5000 0000 0033 7602 6213 5267 0003 0210: 7300 1207 3221 5224 6260 4070 3700 6202 0220: 0037 0003 7200 1214 3207 7346 3351 6214 0230: 1217 3337 1221 3221 1621 0215 1342 3353 0240: 1621 2221 0216 7450 7330 3352 1621 2221 0250: 6744 1621 7100 1207 3350 7430 2353 3354 0260: 1352 0335 7650 1341 1354 7112 1353 6746 0270: 1350 6743 6741 5272 6745 7104 7640 5317 0300: 7410 7401 1352 1335 7550 5334 3352 1350 0310: 7040 0220 7640 7130 2350 5257 5256 6742 0320: 7126 6742 6741 5322 6742 6745 7640 5324 0330: 7344 2351 5232 5336 2221 7600 2221 7401 0340: 5621 0400 0000 5313 6203 0200 0000 0000 0350: 7750 7751 7752 7753 7754 7755 7607 4756 0360: 3700 0000 0365 7402 5372 4207 0300 7000 0370: 0035 7402 6203 6042 5775 0200 0000 0200 What do you make of this? > >cjl Tommy From lasner@sunSITE.unc.edu Wed Jun 29 11:50:55 EDT 1994 Article: 951 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bootstrap OS-8 Date: 29 Jun 1994 15:50:52 GMT Organization: University of North Carolina, Chapel Hill Lines: 10 Message-ID: <2us58s$v3d@bigblue.oit.unc.edu> References: <2ukpte$u50@bigblue.oit.unc.edu> <1994Jun28.162443.20764@nomina.lu.se> NNTP-Posting-Host: calzone.oit.unc.edu OK, the posted copy of record 0 is indeed OS/8 for an RK8E. and should boot. OS/8 comes up by looping somewhere around 1207. The wait loop is the 6031; JMP .-1 if you get that far. But this is the right boot block. Whether the rest of the system it loads is valid remains to be seen! cjl From micah@utxsvs.cc.utexas.edu Thu Jun 30 04:39:26 EDT 1994 Article: 952 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!geraldo.cc.utexas.edu!usenet From: micah@utxsvs.cc.utexas.edu (micah) Newsgroups: alt.sys.pdp8 Subject: I got a pdp-8 Date: 29 Jun 1994 16:20:00 GMT Organization: University of Texas Lines: 5 Message-ID: <2us6vg$ruv@geraldo.cc.utexas.edu> NNTP-Posting-Host: slip-12-7.ots.utexas.edu X-Newsreader: WinVN version 0.82 Ok, I got a pdp-8 from my dads office. What is the thing good for? I'm not even sure if I would now how to fire the thing up. Please E-mail any tips or advice on what to do with it. Thanks From jones@pyrite.cs.uiowa.edu Thu Jun 30 04:40:43 EDT 1994 Article: 953 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!eff!usenet.ins.cwru.edu!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: I got a pdp-8 Date: 29 Jun 1994 22:11:28 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 27 Distribution: world Message-ID: <2usrig$sr9@nexus.uiowa.edu> References: <2us6vg$ruv@geraldo.cc.utexas.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu My X-windows emulator for the PDP-8/E now supports the RX01. I'll E-mail the thing to anyone who wants to try it. It doesn't support maintenance mode. Other than that, it supports everything I tried on it -- my real purpose was to have enough support for the RX01 that I could write a reasonable exerciser program for my real RX01 at home, test it on the emulator, and then launch it on the real thing to see how my real hardware works (currently, ready to test but untested). Spec's: Requires X11R3 or above, with Xt toolkit. There are known bugs that make it bring down the Xterm from which it was launched when it terminates on some systems; X-windows is like that. It's tested on an IBM RT, and before I send it out, I'll do a run on an RS 6000 and a Sun SPARC processor. The only significant peripherals supported are the console TTY, PC01 reader/punch, and RX01. No EAE yet, but it has a memory manager. Until I get a bootable RX01 based system, all you get with the thing is bare hardware, including a simulated RX01 diskette full of gibberish left there by my test program. I'll also let anyone have the test program source itself, if that's of any use. It makes for good blinking lights -- it uses a random number generator to do a seek test on both drives of the disk, so it's pleasantly eratic in operation. From jones@pyrite.cs.uiowa.edu Thu Jun 30 04:41:36 EDT 1994 Article: 954 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: comp.emulators.misc,alt.sys.pdp8 Subject: PDP-8 emulator for X-windows Date: 29 Jun 1994 22:36:31 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 20 Distribution: world Message-ID: <2ust1f$4d@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Xref: bigblue.oit.unc.edu comp.emulators.misc:585 alt.sys.pdp8:954 I am ready to release my X-windows emulator for the PDP-8/E, complete with blinking lights and front panel operation using simulated toggle switches. It uses the Xterminal it was launched from as a teletype, it can read and write stream files (simulated paper tape), and it uses disk files to simulate the RX01 dual diskette drive. The front panel interface has button-click-based help explaining (briefly) what the various knobs and buttons do. The alt.sys.pdp8 faq explains the machine language (you can get it by ftp from rtfm.mit.edu, where all faq's get stored, if they're done right). The emulator comes with a core image of DEC's 4K FOCAL interpreter, a marvelous antique programming language. I have no other software for it, yet, but I hope to get a bootable RX01 image of a real operating system. It runs on my IBM RT under X11R3 with the Xt toolkit. I'll test it with on an IBM RS 6000 and on a Sun SPARC before I mail copies out. Doug Jones jones@cs.uiowa.edu