From greg@huia.canterbury.ac.nz Wed Dec 8 00:24:44 EST 1993 Article: 496 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!waikato!canterbury.ac.nz!huia!greg From: greg@huia.canterbury.ac.nz (Greg Ewing) Subject: Re: PDP 8 emulator standards Message-ID: Nntp-Posting-Host: huia.canterbury.ac.nz Reply-To: greg@huia.canterbury.ac.nz (Greg Ewing) Organization: University of Canterbury, Christchurch, New Zealand References: <1993Nov30.160002.684@news.uiowa.edu> Date: Wed, 1 Dec 1993 01:15:53 GMT Lines: 65 In article <1993Nov30.160002.684@news.uiowa.edu>, jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: |> | | | | | | | | | |> |1|0| 1 | 0 | |> |_|_|_____|_____| |> marks data data Alternatively it could be packed | | | | | | | | | |1| 1 |0| 0 | |_|_____|_|_____| m data m data which could be argued to be a more logical layout, since it keeps each mark bit next to its associated data. On the other hand, it would require more shifting and masking to assemble and disassemble. If you're going to do it that way, then it might be better if it were big-endian: | | | | | | | | | |0| 0 |1| 1 | |_|_____|_|_____| m data m data Then you could read the digits of a hex dump left to right and they would correspond to successive lines. |> Of course, reverse reads and reverse writes are a bit messier, because you |> end up reading the lines in the wrong order, with all the bits inverted, |> but that's a problem any DECtape emulator will have to deal with anyway! A real DECtape must have had an interesting time of it, too! I don't understand what you mean by the bits being inverted, though. Won't it just be a matter of assembling the 3-bit nybbles in the opposite order? |> This won't work very well except for tapes with standard format. A good |> emulator should be able to work with tapes formatted in nonstandard |> block lengths, It depends on what the internal format is like. You should be able to scan the tape, parse it into blocks and build and index of block numbers & lengths with pointers to the data, which would be preconverted to something compatible with your memory so you could just copy straight in and out. |> or if you let users run tape formatting |> software on the emulated machine. Er, yes, well... that could cause a few headaches. You might have to switch into slow mode and then reconvert the tape when it was all over - if you could tell when it was over. Perhaps by sensing the switch that enables writing on the mark track? |> |> To summarize, the first bytes of an emulated DECtape ought to be DECtape, |> and after that, you'd want to start right in with a string of end-zone |> data formatted as above. |> |> Doug Jones |> jones@cs.uiowa.edu From supnik@human.enet.dec.com Wed Dec 8 00:25:32 EST 1993 Article: 497 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!ames!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: Group 3 OPR instructions Date: 30 NOV 93 21:39:03 Organization: Digital Equipment Corporation Lines: 13 Message-ID: <2dh08i$5e5@sousa.ako.dec.com> References: <2dgek0$mpg@sol.ctr.columbia.edu> NNTP-Posting-Host: human.enet.dec.com In article <2dgek0$mpg@sol.ctr.columbia.edu>, johnv@sun.rhbnc.ac.uk (John E. Veness) writes... > [text deleted] >I wish to add the group 3 OPRs, but I don't really have documentation on them. > [text deleted] >Anyway, I don't have any details of the EAE instructions, as the 6100 I have them written, as part of a simulator package. Send email, and I'll send you the CPU source if you want. Note that they are NOT debugged. Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From jones@cs.uiowa.edu Wed Dec 8 00:26:11 EST 1993 Article: 498 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu Subject: DECtape (Was: PDP 8 emulator standards) Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec1.155430.22835@news.uiowa.edu> Date: Wed, 1 Dec 1993 15:54:30 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 29 >From article , by greg@huia.canterbury.ac.nz (Greg Ewing): > > | | | | | | | | | > |0| 0 |1| 1 | > |_|_____|_|_____| > m data m data > > Then you could read the digits of a hex dump left to right and they > would correspond to successive lines. So who wants to use hex dumps of the contents of DECtape for anything? Ugh! > I don't understand what you mean by the bits being inverted, though. > Won't it just be a matter of assembling the 3-bit nybbles in the > opposite order? The encoding used on DECtape is such that if a bit read in one direction is seen as a 1, the hardware will sense a 0 in the other direction! No extra hardware is included in the interface to compensate for this, so you've got to compensate in software. In addition, 3 bit lines are assembled into words in the order received, with no attention to the direction of tape motion. The net result is that if you write the word 000 001 010 011 and then read it in the opposite direction, you get 100 101 110 111. Doug Jones jones@cs.uiowa.edu From jones@pyrite Wed Dec 8 00:27:58 EST 1993 Article: 499 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: PDP-8 emulator performance Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec1.193758.28225@news.uiowa.edu> Date: Wed, 1 Dec 1993 19:37:58 GMT References: <1993Nov29.225539.16188@news.uiowa.edu> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 70 I've just done some benchmarking of my PDP-8 emulator, with some help from Andrew Riebs at DEC (riebs@tanfl.amt.ako.dec.com). The set task (a small FOCAL program) ran in 60 seconds on my IBM RT running AOS (IBM's BSD) with output to an Xterm. On my Tadpole SPARCbook I (a laptop SPARCstation), running Solaris, with output to a remote Xterminal, the same output took about 22 seconds. On a DECstation 3100 (ULTRIX MIPS), it took about 27 seconds, with output to an Xterm window on the same system. On a prototype Alpha AXP system with a CPU that is probably clocked at 160 MHz, with display to a remote Xterm window, it took well under 5 seconds. The benchmark we used was written in FOCAL; here's a transcript of the session (it comes out the same on any machine you use): % pdp8e focal PDP-8 Emulator, type ? for help. 0000 (0000 0200g CONGRATULATIONS!! YOU HAVE SUCCESSFULLY LOADED 'FOCAL,1969' ON A PDP-8 COMPUTER. SHALL I RETAIN LOG, EXP, ATN ?:NO SHALL I RETAIN SINE, COSINE ?:NO PROCEED. *1.1 SET A=1 ......... the FOCAL prompt is a * *1.2 TYPE A,! *1.3 SET A=2*A *1.4 GOTO 1.2 *GO ......... here I typed in a program = 1.0000 = 2.0000 = 4.0000 = 8.0000 ..................... it ran for a while = 0.11529220E+19 = 0.23058430E+19 = 0.46116900E+19 = 0.92233?01.00 @ 01.20 .. here I typed control C * The benchmark is trivial (building the emulator, typing the benchmark and running the test took less time than it's taking to type in this report); the idea is to just time how long it takes to reach an output of 0.46116900E+19, using whatever clock you have handy (I used my wristwatch). It's worth noting that the emulator was built with its default settings in the distributed form (1200 baud, 4K of memory, no KM8E memory manager). An alternate benchmark is to use the fact that the Alpha got up to 0.18768820E+256 in 60 seconds. On my SPARCbook, it took about 8 minutes and 10 seconds to get to that point. The output at the extreme end of the run is clearly CPU bound (something about the way FOCAL handles floating point output makes it take longer and longer as the exponent grows). In any case, it is clear that the Alpha emulation of a PDP-8/E using my emulator is a few times faster than the original hardware! Doug Jones jones@cs.uiowa.edu From mbg@world.std.com Wed Dec 8 00:28:44 EST 1993 Article: 500 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Group 3 OPR instructions Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2dgek0$mpg@sol.ctr.columbia.edu> Date: Wed, 1 Dec 1993 21:11:40 GMT Lines: 52 johnv@sun.rhbnc.ac.uk (John E. Veness) writes: >Anyway, my question this time is a very simple one. I've so far >simulated all the MRI instructions, the group 1 OPR instructions, and >the group 2 OPR instructions. I wish to add the group 3 OPRs, but I >don't really have documentation on them. I have Intro to Programming, >and a Intersil 6100 book, and they don't really help. The 6100 seems >to have three instructions in group 3, CLA, MQL, and MQA (working out >how to do the combination SWP of MQL and MQA was just a bit difficult >- well, a bit more than the two separately). Well, there is bit 06, SCA, which logical ors the step counter (SC) with the AC. Bits <08:10> are a three-bit field which encode the EAE operation to perform. 0 = no operation 1 = SCL (load's step counter from contents of address PC+1 2 = MUY (multiply MQ by contents of address PC+1, results into AC (high-order 12 bits) and MQ (low-order 12 bits) 3 = DVI (divide combined AC/MQ by contents of address PC+1, quotient in AC, remainder in MQ, if I remember correctly) 4 = NMI (normalize, shifts combined AC/MQ left until AC0 and AC1 do not match OR AC/MQ = 06000000, step counter (SC) gets count of shift. AC0 shifts to L, bits shifted out of L are lost) 5 = SHL (Shift left combined AC/MQ by contents of PC+1 incremented by one. AC0 shifts to L, L shifts to bit bucket) 6 = ASR (Arithmetic shift right combined AC/MQ by contents of PC+1 incremented by one. AC0 at start of instruction specifies contents of L at end of instruction as well as bits shifted into AC0, shift out of MQ11 is lost) 7 = LSR (Logical shift right combined AC/MQ by contents of PC+1 incremented by one. Zeros shift into AC0, MQ11 shifts to bit-bucket). This is what I understand so far. It is 'mode A' operation. Apparently mode B operation changes where the shift count for some operations come from. I think it means that the contents of PC+1 is the address of the location from which you get the count. This also means that there are additional instructions (SWAB - switch mode from A to B, and SWBA - switch mode from B to A). There are also some double precision instructions, but I have yet to read up on them (the rest of the above was from memory). Megan Gentry Former RT-11 Developer From kerch@parc.xerox.com Wed Dec 8 00:28:58 EST 1993 Article: 501 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!uunet!decwrl!decwrl!parc!news!kerch From: kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval) Subject: Re: PDP-8 emulator performance In-Reply-To: jones@pyrite's message of Wed, 1 Dec 1993 19:37:58 GMT Message-ID: Sender: news@parc.xerox.com Reply-To: kerch@parc.xerox.com Organization: Xerox Palo Alto Research Center References: <1993Nov29.225539.16188@news.uiowa.edu> <1993Dec1.193758.28225@news.uiowa.edu> Date: 02 Dec 1993 17:45:12 GMT Lines: 15 >>>>> "Douglas" == Douglas W Jones,201H MLH,3193350740,3193382879 writes: In article <1993Dec1.193758.28225@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: Douglas> On a prototype Alpha AXP system with a CPU that is Douglas> probably clocked at 160 MHz, with display to a remote Douglas> Xterm window, it took well under 5 seconds. On a SparcCenter 1000 running Solaris 2.3, I get to the E+19 range in about 5.5 seconds. -- Berry Kercheval :: kerch@parc.xerox.com From jones@pyrite Wed Dec 8 00:29:09 EST 1993 Article: 502 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: KL8E address straps & connections please ? Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec3.151236.4629@news.uiowa.edu> Date: Fri, 3 Dec 1993 15:12:36 GMT References: <1993Dec3.093844.1@scm.dsto.gov.au> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 8 >From article <1993Dec3.093844.1@scm.dsto.gov.au>, by bennett@scm.dsto.gov.au: > > Could some kind soul please EMAIL me the info ... Done Doug Jones jones@cs.uiowa.edu From mbg@world.std.com Wed Dec 8 00:30:21 EST 1993 Article: 503 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!corpgate!news.utdallas.edu!hermes.chpc.utexas.edu!cs.utexas.edu!howland.reston.ans.net!usenet.ins.cwru.edu!eff!news.kei.com!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Question re timesharing option behavior Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2dltud$2bv@sousa.ako.dec.com> <1993Dec3.151104.4550@news.uiowa.edu> Date: Sat, 4 Dec 1993 11:05:48 GMT Lines: 31 jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >When the computer is operated in user mode, operation is normal except >for IOT, HLT, LAS and OSR instructions. When one of these instructions >is encountered, the hardware inhibits the normal instruction sequence >(other than rewriting the instruction in memory), and generates an >interrupt at the end of the current memory cycle by setting the UINT >flip-flop. The time-sharing system's monitor program then analyzes the >source of the interrupt, and takes appropriate action. >This suggests that PC should not be incremented by the fetch of a >prohibited instruction, and that no side effects such as CLA or skips >take place in the case of microcoded combinations with OSR or HLT. >When you think about it, it would be impossible for the interrupt >service routine to respond correctly to the interrupt if the PC were >allowed to change to point to anything other than the instruction that >caused the interrupt, because then any code to analyze the cause of >the interrupt would be hopelessly confused. I've been thinking about such occurrances which cause special code to be processed like this. Since this is an emulator, you can take one of two different courses - 1) Make it as similar to a real machine, including all idiocyncracies or 2) Try to clean up, in emulation, the operation of the machine. I think this is one of those cases where doing some clean-up in design might not be destructive to the emulation. If the emulation processes an instruction completely before responding to an interrupt, you could always pretend that the interrupt didn't happen until the instruction completed anyway... Megan Gentry From bennett@scm.dsto.gov.au Wed Dec 8 00:30:40 EST 1993 Article: 504 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!sgiblab!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!dstos3.dsto.gov.au!bennett From: bennett@scm.dsto.gov.au Newsgroups: alt.sys.pdp8 Subject: Re: KL8E address straps & connections please ? Date: 6 Dec 93 16:12:04 +1030 Organization: Defence Science and Technology Organisation Lines: 14 Message-ID: <1993Dec6.161204.1@scm.dsto.gov.au> References: <1993Dec3.093844.1@scm.dsto.gov.au> NNTP-Posting-Host: dstos3.dsto.gov.au In article <1993Dec3.093844.1@scm.dsto.gov.au>, bennett@scm.dsto.gov.au writes: > Could some kind soul please EMAIL me the info about setting the console A couple of people mailed the M8650 notes - thanks guys. Regards, John Bennett bennett@scm.dsto.gov.au Head, I.T. Services Development Phone : +61 8 259 5292 Corporate Information Systems FAX : +61 8 259 5537 DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal: Bld 73 Labs Area AUSTRALIA PO Box 1500 Salisbury South Australia 5108 AUSTRALIA From mpe@micado.rmi.de Wed Dec 8 00:31:15 EST 1993 Article: 505 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!not-for-mail From: mpe@micado.rmi.de (Manfred Peters) Newsgroups: alt.sys.pdp8 Subject: Searching for a beauty...... Date: 6 Dec 1993 04:16:01 -0600 Organization: UTexas Mail-to-News Gateway Lines: 23 Sender: daemon@cs.utexas.edu Message-ID: <60@micado.rmi.de> Reply-To: mpe@micado.rmi.de NNTP-Posting-Host: cs.utexas.edu Hi, netlanders (in Germany and nearby)! I'm looking for a PDP-8 (such an old beautiful beast) for my private computer museum! It should be at least equipped with a DEC-Tape unit and some memory. If it works: FANTASTIC! A Teletype is okay too. If anyone has such a beast and wants to get rid of it, please send a PM to one of the addresses below or phone me to discuss conditions etc. Thanks a lot. Manfred PS: Some more greetings come from Dancing Danny Dectape (you know?). -- mpeters@infoac.rmi.de snail-mail: Manfred Peters mpe@micado.rmi.de P.O.Box 30 08 64 D-51337 Leverkusen Voice: +49+2171+730730 Fax: +49+2171+730731 (on request) ISDN-XFER: +49+2171+730732 (on request) From krause@azu.informatik.uni-stuttgart.de Wed Dec 8 00:32:09 EST 1993 Article: 506 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news From: krause@azu.informatik.uni-stuttgart.de (krause) Subject: Re: PDP-8 emulator performance Message-ID: <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> Sender: news@informatik.uni-stuttgart.de Organization: Informatik, Uni Stuttgart, Germany References: <1993Nov29.225539.16188@news.uiowa.edu> <1993Dec1.193758.28225@news.uiowa.edu> Date: Mon, 6 Dec 1993 15:52:43 GMT Lines: 49 In article <1993Dec1.193758.28225@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >I've just done some benchmarking of my PDP-8 emulator, with some help >from Andrew Riebs at DEC (riebs@tanfl.amt.ako.dec.com). The set task >(a small FOCAL program) ran in 60 seconds on my IBM RT running AOS >(IBM's BSD) with output to an Xterm. > >On my Tadpole SPARCbook I (a laptop SPARCstation), running Solaris, >with output to a remote Xterminal, the same output took about 22 >seconds. > >On a DECstation 3100 (ULTRIX MIPS), it took about 27 seconds, with >output to an Xterm window on the same system. > >On a prototype Alpha AXP system with a CPU that is probably clocked >at 160 MHz, with display to a remote Xterm window, it took well under >5 seconds. > >The benchmark we used was written in FOCAL; here's a transcript of the >session (it comes out the same on any machine you use): > > .... >*1.1 SET A=1 ......... the FOCAL prompt is a * >*1.2 TYPE A,! >*1.3 SET A=2*A >*1.4 GOTO 1.2 >*GO ......... here I typed in a program Is that serious ? On my original 8/e this focal program runs in aproximately 2 seconds. (I have a hp 2648-terminal with 9600 baud). With the 16K-4Word focal (ten digits accuracy) it took 4.5 seconds. In this context another questions to the gurus: If I would place our emulator in the public domain, which is planned to run OS/8, whats about the copyright from DEC ? Do I have to ask for a licence to use CCL.SV, DIRECT.SV, FOTP.SV and PAL8.SV? I think on my personal -8 this is legal, because I bought hardware and soft- ware from the original owner. But what, if I copy the contents of my SYS: to an emulator? Klemens Krause National Centre for Minimal- and Retrocomputing Stuttgart Germany From ivie@cc.usu.edu Wed Dec 8 00:32:32 EST 1993 Article: 507 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 emulator performance Message-ID: <1993Dec6.133414.5541@cc.usu.edu> Date: 6 Dec 93 13:34:14 MDT References: <1993Nov29.225539.16188@news.uiowa.edu> <1993Dec1.193758.28225@news.uiowa.edu> <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> Organization: Utah State University Lines: 12 In article <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de>, krause@azu.informatik.uni-stuttgart.de (krause) writes: > In this context another questions to the gurus: > If I would place our emulator in the public domain, which is planned to > run OS/8, whats about the copyright from DEC ? Since DEC has released OS/278 (the version of OS/8 for the DECmate) to DECUS, you should be able to use at least those versions without trouble. Of course, cjl will no doubt comment on the quality of the OS/278 code... -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready' From jones@pyrite Wed Dec 8 00:33:23 EST 1993 Article: 508 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: PDP-8 emulator performance Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec6.222226.11158@news.uiowa.edu> Date: Mon, 6 Dec 1993 22:22:26 GMT References: <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 30 >From article <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de>, by krause@azu.informatik.uni-stuttgart.de (krause): > > Is that serious ? > On my original 8/e this focal program runs in aproximately 2 seconds. > (I have a hp 2648-terminal with 9600 baud). The Benchmark is I/O bound, and most of the instructions it is timing are the instructions in the polling loop! You must use the same speed I/O interface to make the benchmark into a fair comparison! > With the 16K-4Word focal (ten digits accuracy) it took 4.5 seconds. Can you possibly make this available over the net? I'd love a copy, and I do have 16K in my PDP-8/F. > > In this context another questions to the gurus: > If I would place our emulator in the public domain, which is planned to > run OS/8, whats about the copyright from DEC ? In the permission letter I have from DEC to photocopy and distribute technical documentation, they didn't cite specific documents, instead, they gave something of a blanket permission to duplicate and distribute old documentation, so long as I gave proper credit to DEC. The letter was as ironclad in its definition of proper credit as it was loose in specifying what I could copy. I hope someone can get similar permission with regard to OS/8, but since my disk is not yet up, I haven't done this. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Wed Dec 8 01:06:34 EST 1993 Article: 509 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 emulator performance Date: 8 Dec 1993 06:02:24 GMT Organization: University of North Carolina, Chapel Hill Lines: 53 Message-ID: <2e3qlg$o5d@samba.oit.unc.edu> References: <1993Nov29.225539.16188@news.uiowa.edu> <1993Dec1.193758.28225@news.uiowa.edu> <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> <1993Dec6.133414.5541@cc.usu.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article <1993Dec6.133414.5541@cc.usu.edu>, wrote: >In article <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de>, krause@azu.informatik.uni-stuttgart.de (krause) writes: >> In this context another questions to the gurus: >> If I would place our emulator in the public domain, which is planned to >> run OS/8, whats about the copyright from DEC ? > >Since DEC has released OS/278 (the version of OS/8 for the DECmate) to DECUS, >you should be able to use at least those versions without trouble. Of course, >cjl will no doubt comment on the quality of the OS/278 code... Unlike Kibo (and his/her/its minions), I don't grep the newsgroup for my name or initials, but I just returned from pressing matters, and noticed this one: a) OS/278 V2 will run on an 8/e or 8/a or DECmate. b) It is PD by virtue of its DECUS distribution. c) It has lame restrictions due to emasculation of the code primarily as a bandaid against perceived and occasionally actual restrictions of the Decmate hardware environment, part of which is simulated in ways that can be improved upon, and part of which is hopelessly incompatible with the standard PDP-8 environment all prior models have. (Note: even the PDP-5 and PDP-8/s, while lacking in other ways that prevent virtually all software other than Focal from running on them, don't have the DECmates' problems!) d) The sources are incomplete and don't match the binaries. So far as I have checked, the binaries are more trustworthy than the sources. However, there are numerous introduced bugs that just didn't exist in older OS/8 versions, and they seem to be related only to non-hardware issues. For example, there are bugs in the SAVE command that are influenced by how ABSLDR was invoked, etc. In all probability this is related to what some people call creeping featurism, etc., so the sources *and* binaries need to be checked against older versions, etc. e) In the process of merging in fixes derived from the original thoughts in the old code, as long as the newer sources are used as the basis for improvements, instead of the old sources, the DECUS distribution nullifies any claim DEC has/had on the system. Thus, I would project that as OS/8 source files get modified to become input into the OS/8 V5 project (whereby old bugs and old model-dependancies are removed, etc. in preparation for changes to accomodate the *real* DECmate incompatibilities, etc.) the resultant sources are derivative of OS/278 V2, and as such are not DEC's concern as such, etc. And since I intend to distribute OS/8 V5 through DECUS et al., no one should have a claim at that point, etc. So, if you don't mind running a PDP-8/e according to the limitations of DECmate-derived dementia, OS/278 V2 is the system for you (masochists!). cjl ps: the first "feature" that goes is the prompt goes back to "." (not "}" ugh!) From lasner@sunSITE.unc.edu Wed Dec 8 01:16:10 EST 1993 Article: 510 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Question re timesharing option behavior Date: 8 Dec 1993 06:15:21 GMT Organization: University of North Carolina, Chapel Hill Lines: 43 Message-ID: <2e3rdp$oe2@samba.oit.unc.edu> References: <2dltud$2bv@sousa.ako.dec.com> <1993Dec3.151104.4550@news.uiowa.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Megan wrote: >jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > >>When the computer is operated in user mode, operation is normal except >>for IOT, HLT, LAS and OSR instructions. When one of these instructions >>is encountered, the hardware inhibits the normal instruction sequence >>(other than rewriting the instruction in memory), and generates an >>interrupt at the end of the current memory cycle by setting the UINT >>flip-flop. The time-sharing system's monitor program then analyzes the >>source of the interrupt, and takes appropriate action. > >>This suggests that PC should not be incremented by the fetch of a >>prohibited instruction, and that no side effects such as CLA or skips >>take place in the case of microcoded combinations with OSR or HLT. >>When you think about it, it would be impossible for the interrupt >>service routine to respond correctly to the interrupt if the PC were >>allowed to change to point to anything other than the instruction that >>caused the interrupt, because then any code to analyze the cause of >>the interrupt would be hopelessly confused. > >I've been thinking about such occurrances which cause special code to >be processed like this. Since this is an emulator, you can take one >of two different courses - 1) Make it as similar to a real machine, >including all idiocyncracies or 2) Try to clean up, in emulation, the >operation of the machine. I think this is one of those cases where >doing some clean-up in design might not be destructive to the >emulation. If the emulation processes an instruction completely >before responding to an interrupt, you could always pretend that the >interrupt didn't happen until the instruction completed anyway... > > Megan Gentry > A simple form of the answer: if you change the hardware (whether emulated or not!) you break the software. Lotsa stuff written to handle this problem already works fine, being only slightly fooled by trick sequences such as SKP HLT;HLT where the SKP part may be a conditional, and it's hard to trace back the exact PC value, etc. (Note: this only affects status reports of the halt, thus the exact PC value is subject to a +/-1 error worst case; when execution continues, all runs properly, etc.) cj (if it ain't broke, don't fix it) l From mbg@world.std.com Sat Dec 11 01:11:09 EST 1993 Article: 511 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!decwrl!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Question re timesharing option behavior Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2dltud$2bv@sousa.ako.dec.com> <1993Dec3.151104.4550@news.uiowa.edu> <2e3rdp$oe2@samba.oit.unc.edu> Date: Thu, 9 Dec 1993 00:08:17 GMT Lines: 53 lasner@sunSITE.unc.edu (Charles Lasner) writes: >In article , Megan wrote: >>jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >> >>>When the computer is operated in user mode, operation is normal except >>>for IOT, HLT, LAS and OSR instructions. When one of these instructions >>>is encountered, the hardware inhibits the normal instruction sequence >>>(other than rewriting the instruction in memory), and generates an >>>interrupt at the end of the current memory cycle by setting the UINT >>>flip-flop. The time-sharing system's monitor program then analyzes the >>>source of the interrupt, and takes appropriate action. >> >>>This suggests that PC should not be incremented by the fetch of a >>>prohibited instruction, and that no side effects such as CLA or skips >>>take place in the case of microcoded combinations with OSR or HLT. >>>When you think about it, it would be impossible for the interrupt >>>service routine to respond correctly to the interrupt if the PC were >>>allowed to change to point to anything other than the instruction that >>>caused the interrupt, because then any code to analyze the cause of >>>the interrupt would be hopelessly confused. >> >>I've been thinking about such occurrances which cause special code to >>be processed like this. Since this is an emulator, you can take one >>of two different courses - 1) Make it as similar to a real machine, >>including all idiocyncracies or 2) Try to clean up, in emulation, the >>operation of the machine. I think this is one of those cases where >>doing some clean-up in design might not be destructive to the >>emulation. If the emulation processes an instruction completely >>before responding to an interrupt, you could always pretend that the >>interrupt didn't happen until the instruction completed anyway... >A simple form of the answer: if you change the hardware (whether emulated or >not!) you break the software. Lotsa stuff written to handle this problem >already works fine, being only slightly fooled by trick sequences such >as SKP HLT;HLT where the SKP part may be a conditional, and it's hard to trace >back the exact PC value, etc. (Note: this only affects status reports of the >halt, thus the exact PC value is subject to a +/-1 error worst case; when >execution continues, all runs properly, etc.) But keep in mind, the probability of executing an instruction without an interrupt is hopefully much higher than executing one that is interrupted. Therefore, if you process the instruction as if no interruupt had occurred, that operation will be correct. If you then process the interrupt (as if the interrupt HAD happened between instructions), THAT operation should work correctly as well. As for the example (SKP HLT;HLT) which you posit, I was under the impression (probably faulty) that the PC is incremented at the end of an instruction. Megan Gentry From jones@cs.uiowa.edu Sat Dec 11 01:49:22 EST 1993 Article: 512 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.answers,news.answers Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!europa.eng.gtefsd.com!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: PDP-8 Frequently Asked Questions (posted every other month) Summary: Answers to common questions about antique DEC PDP-8 computers. Those posting to alt.sys.pdp8 should read this. Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec8.221620.28091@news.uiowa.edu> Approved: news-answers-request@MIT.Edu Date: Wed, 8 Dec 1993 08:08:08 GMT Expires: Tue, 8 Feb 1994 08:08:08 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Keywords: FAQ DEC PDP 8 Followup-To: alt.sys.pdp8 Lines: 985 Xref: samba.oit.unc.edu alt.sys.pdp8:512 alt.answers:1325 news.answers:14868 Archive-name: dec-faq/pdp8 Last-modified: Dec 8, 1993 Frequently Asked Questions about the DEC PDP-8 computer. By Douglas Jones, jones@cs.uiowa.edu (with help from many folks) The most recent version of this file is available by anonymous FTP from: rtfm.mit.edu:/pub/usenet/alt.sys.pdp8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc Contents: What is a PDP? What is a PDP-8? What is the PDP-8 instruction set? What does PDP-8 assembly language look like? What character sets does the PDP-8 support? What different PDP-8 models were made? What about the LINC-8 and PDP-12? Where can I get a PDP-8 today? Where can I get PDP-8 documentation? What operating systems were written for the PDP-8? What programming languages were supported on the PDP-8? Where can I get PDP-8 software? Where can I get additional information? What use is a PDP-8 today? Who's Who? What is a PDP? In 1957, Ken Olson and Harlan Anderson founded Digital Equipment Corporation (DEC), capitalized at $100,000, and 70% owned by American Research and Development Corporation. Olson and Anderson 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 transistorized 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 of this machine. The venture capitalist's insistance on avoiding the term computer was based on the steriotype that computers were big and expensive and needed a computer center and a large staff; by using the term Programmable Data Processor, or PDP, DEC avoided these stereotypes by entirely avoiding the term "computer"; thus, for over a decade, all digital computers sold by DEC were called PDPs. (In early DEC documentation, plural form "PDPs" is used as a generic term for all DEC computers.) In the early 1960's, DEC was the only manufacturer of large computers without a computer leasing plan. IBM and all the other larger manufacturers leased most of their machines, and many machines were never offered for outright sale. DEC's cash sales approach led to the growth of third party computer leasing companies such as DELOS, a spinoff of BB&N. DEC built a number of different computers under the PDP label, with a huge range of price and performance. The largest of these are fully worthy of large computer centers with big support staffs. Many early DEC computers were not really built by DEC. With the PDP-3 and LINC, for example, customers built the machines using DEC parts and facilities. Here is the list of PDP computers: MODEL DATE PRICE BITS COMMENTS ===== ==== ======== ==== ===== PDP-1 1960 $120,000 18 DEC's first computer PDP-2 NA 24 Never built? PDP-3 NA 36 One was built by a customer, not by DEC. PDP-4 1962 $60,000 18 Predecessor of the PDP-7. PDP-5 1963 $27,000 12 The ancestor of the PDP-8. PDP-6 1964 $300,000 36 A big computer; 23 built, most for MIT. PDP-7 1965 $72,000 18 Widely used for real-time control. PDP-8 1965 $18,500 12 The smallest and least expensive PDP. PDP-9 1966 $35,000 18 An upgrade of the PDP-7. PDP-10 1967 $110,000 36 A PDP-6 successor, great for timesharing. PDP-11 1970 $10,800 16 DEC's first and only 16 bit computer. PDP-12 1969 $27,900 12 A PDP-8 relative. PDP-13 NA Bad luck, there was no such machine. PDP-14 A ROM-based programmable controller. PDP-15 1970 $16,500 18 A TTL upgrade of the PDP-9. PDP-16 1972 NA 8/16 A register-transfer module system. Corrections and additions to this list are welcome! The prices given are for minimal systems in the year the machine was first introduced. The bits column indicates the word size. Note that the DEC PDP-10 became the DECSYSTEM-20 as a result of marketing considerations, and DEC's VAX series of began as the Virtual Address eXtension of the never-produced PDP-11/78. It is worth mentioning that it is generally accepted that the Data General Nova (see photo, Computers and Automation, Nov. 1968, page 48) was originally developed as the PDP-X, a 16-bit multi-register version of the PDP-8. A prototype PDP-X was built at DEC before the design was rejected. This and a competing 16-bit design were apparently submitted to Harold McFarland at Carnegie-Mellon University for evaluation; McFarland (and perhaps Gordon Bell, who was at C-MU at the time) evaluated the competing designs and rejected both in favor of what we know as the PDP-11. (A less common version of this story is that the reason that DEC never produced a PDP-13 was because the number 13 was assigned to what became the Nova; this is unlikely because the PDP-X prototype came before the PDP-11.) Both DEC and Data General are quiet about these stories. Today, all of the PDP machines are in DEC's corporate past, with the exception of the PDP-11 family of minicomputers and microprocessors. Of course, occasionally, some lab builds a machine out of DEC hardware and calls it a PDP with a new number. For example, the Australian Atomic Energy Commission once upgraded a PDP-7 by adding a PDP-15 on the side; they called the result a PDP-22. What is a PDP-8? The PDP-8 family of minicomputers were built by Digital Equipment corporation between 1965 and 1990, although it is worth noting that the term minicomputer first came into prominence in early 1968. (See Interdata ad, Computers and Automation, May 1968, page 10). The PDP-8 was largely upward compatable with the PDP-5, a machine that was unveiled on August 11, 1963 at WESCON, and the inspiration for that machine came from two earlier machines, the LINC and the CDC 160. All of these machines were characterized by a 12 bit word with no hardware byte structure, a 4K minimum memory configuration, and simple but powerful instruction sets. Although some people consider the CDC 160 the first minicomputer, the PDP-8 was the definitive minicomputer. By late 1973, the PDP-8 family was the best selling computer in the world, and it is likely that it was only displaced from this honor by the Apple II and later, the IBM PC. Most models of the PDP-8 set new records as the least expensive computer on the market at the time of their introduction. The PDP-8 has been described as the model-T of the computer industry because it was the first computer to be mass produced at a cost that just about anyone could afford. C. Gordon Bell has said that the basic idea of the PDP-8 was not really original with him. He gives credit to Seymour Cray (of CDC and later Cray) for the idea of a single-accumulator 12 bit minicomputer. Cray's CDC 160 family (see CACM, march 1961, photo on page 244, text on page 246) was such a machine, and in addition to the hundreds of CDC 160 systems sold as stand-alone machines, a derivative 12 bit architecture was used for the I/O processors on Cray's first great supercomputer, the CDC 6600. Note that Cray's 12 bit machines had 6 basic addressing modes with variable length instruction words and other features that were far from the simple elegance of the PDP-8. Despite its many modes, the CDC architecture lacked the notion of current page addressing, and the result is that, for examples that don't involve indexing, PDP-8 code is generally as tight as the code on Cray's machines. What is the PDP-8 instruction set? The PDP-8 word size is 12 bits, and the basic memory is 4K words. The minimal CPU contained the following registers: PC - the program counter, 12 bits. AC - the accumulator, 12 bits. L - the link, 1 bit, commonly prefixed to AC as . It is worth noting that many operations such as procedure linkage and indexing, which are usually thought of as involving registers, are done with memory on the PDP-8 family. Instruction words are organized as follows: _ _ _ _ _ _ _ _ _ _ _ _ |_|_|_|_|_|_|_|_|_|_|_|_| | | | | | | op |i|z| addr | op - the opcode. i - the indirect bit (0 = direct, 1 = indirect). z - the page bit (0 = page zero, 1 = current page). addr - the word in page. The top 5 bits of the 12 bit program counter give the current page, and memory addressing is also complicated by the fact that absolute memory locations 8 through 15 are incremented prior to use when used as indirect addresses. These locations are called auto-index registers (despite the fact that they are in memory); they allow the formulation of very tightly coded array operations. The basic instructions are: 000 - AND - and operand with AC. 001 - TAD - add operand to (a 13 bit value). 010 - ISZ - increment operand and skip if result is zero. 011 - DCA - deposit AC in memory and clear AC. 100 - JMS - jump to subroutine. 101 - JMP - jump. 110 - IOT - input/output transfer. 111 - OPR - microcoded operations. The ISZ and other skip instructions conditionally skip the next instruction in sequence. The ISZ is commonly used to increment a loop counter and skip if done, and it is also used as an general increment instruction, either followed by a no-op or in contexts where it is known that the result will never be zero. The JMS instruction stores the return address in relative word zero of the subroutine, with execution starting with relative word one. Subroutine return is done with an indirect JMP through the return address. Subroutines commonly increment their return addresses to index through inline parameter lists or to perform conditional skips over instructions following the call. The IOT instruction has the following form: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| | | | | | | device | op | The IOT instruction specifies one of up to 8 operations on one of 64 devices. Typically (but not universally), each bit of the op field evokes an operation, and these can be microcoded in left to right order. Prior to the PDP-8/E, there were severe restrictions on the interpretation of the op field. As an example of the use of IOT instructions, consider the console terminal interface. On early PDP-8 systems, this was always assumed to be an ASR 33 teletype, complete with low-speed paper tape reader and punch. It was addressed as devices 03 (the keyboard/reader) and 04 (the teleprinter/punch): _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 1 1|0 0 1 - KSF - keyboard skip if flag |0 0 0 0 1 1|0 1 0 - KCC - keyboard clear flag |0 0 0 0 1 1|1 0 0 - KRS - keyboard read static The keyboard flag is set by the arrival of a character. The KCC instruction clears both the flag and the accumulator. KRS ors the 8 bit input data with the low order 8 bits of AC. The commonly used KRB instruction is the or of KCC and KRS. To await one byte of input, use KSF to poll the flag, then read it with KRB. _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 1 0 0|0 0 1 - TSF - teleprinter skip if flag |0 0 0 1 0 0|0 1 0 - TCF - teleprinter clear flag |0 0 0 1 0 0|1 0 0 - TPC - teleprinter print static The teleprinter flag is set by the completion of the TPC operation (as a result, on startup, many applications use TPC to print a null in order to get things going). TCF clears the flag, and TPC outputs the low order 8 bits of the accumulator. The commonly used TLS instruction is the or of TCF and TPC. To output a character, first use TSF to poll the flag, then write the character with TLS. IOT instructions may be used to initiate data break transfers from block devices such as disk or tape. The term "data break" was, for years, DEC's preferred term for cycle-stealing direct-memory- access data transfers. Some CPU functions are accessed only by IOT instructions. For example, interrupt enable and disable are IOT instructions: _ _ _ _ _ _ _ _ _ _ _ _ |1|1|0|_|_|_|_|_|_|_|_|_| |0 0 0 0 0 0|0 0 1 - ION - interrupts turn on |0 0 0 0 0 0|0 1 0 - IOF - interrupts turn off An interrupt was requested when any device raised its flag. The console master clear switch would reset all flags and disable interrupts. Effectively, an interrupt is a JMS instruction to location zero, with the side effect of disabling interrupts. The interrupt service routine would test flags and perform the operations needed to reset them, and then return using ION immediately before the indirect return JMP. The effect of ION is delayed so that interrupts are not enabled until after the JMP. The instructions controlling the optional memory management unit are also IOT instructions. This unit allows the program to address up to 23K of main memory by adding a 3 bit extension to the memory address. Two extensions are available, one for instruction fetch and direct addressing, the other for indirect addressing. A wide variety of operations are available through the OPR microcoded instructions: _ _ _ _ _ _ _ _ _ _ _ _ Group 1 |1|1|1|0|_|_|_|_|_|_|_|_| 1 - CLA - clear AC 1 - CLL - clear the L bit 1 - CMA - ones complement AC 1 - CML - complement L bit 1 - IAC - increment 1 0 0 - RAR - rotate right 0 1 0 - RAL - rotate left 1 0 1 - RTR - rotate right twice 0 1 1 - RTL - rotate left twice In general, the above operations can be combined by oring the bit patterns for the desired operations into a single instruction. If none of the bits are set, the result is the NOP instruction. When these operations are combined, they operate top to bottom in the order shown above. The exception to this is that IAC cannot be combined with the rotate operations on some models, and attempts to combine rotate operations have different effects from one model to another (for example, on the PDP-8/E, the rotate code 001 means swap 6 bit bytes in the accumulator, while previous models took this to mean something like "shift neither left nor right 2 bits"). _ _ _ _ _ _ _ _ _ _ _ _ Group 2 |1|1|1|1|_|_|_|_|_|_|_|0| 1 0 - SMA - skip on AC < 0 \ 1 0 - SZA - skip on AC = 0 > or 1 0 - SNL - skip on L /= 0 / 0 0 0 1 - SKP - skip unconditionally 1 1 - SPA - skip on AC >= 0 \ 1 1 - SNA - skip on AC /= 0 > and 1 1 - SZL - skip on L = 0 / 1 - CLA - clear AC 1 - OSR - or switches with AC 1 - HLT - halt The above operations may be combined by oring them together, except that there are two distinct incompatible groups of skip instructions. When combined, SMA, SZA and SNL, skip if one or the other of the indicated conditions are true, while SPA, SNA and SZL skip if all of the indicated conditions are true (logical and). When combined, these operate top to bottom in the order shown; thus, the accumulator may be tested and then cleared. Setting the halt bit in a skip instruction is a crude but useful way to set a breakpoint for front-panel debugging. If none of the bits are set, the result is an alternative form of no-op. A third group of operate microinstructions (with a 1 in the least significant bit) deals with the optional extended arithmetic element to allow such things as hardware multiply and divide, 24 bit shift operations, and normalize. These operations involve an additional data register, MQ or multiplier quotient, and a small step count register. On the PDP-8/E and successors, MQ and the instructions for loading and storing it were always present, even when the EAE was absent, and the EAE was extended to provide a useful variety of 24 bit arithmetic operations. What does PDP-8 assembly language look like? There are many different assemblers for the PDP-8, but most use a compatable basic syntax; here is an example: START, CLA CLL / Clear everything TAD X / Load X AND I Y / And with the value pointed to by Y DCA X / Store in X HLT / Halt X, 1 / A variable Y, 7 / A pointer Note that labels are terminated by a comma, and comments are separated from the code by a slash. There are no fixed fields or column restrictions. The "CLA CLL" instruction on the first line is an example of the microcoding of two of the Group 1 operate instructions. CLA alone has the code 7200 (octal), while CLL has the code 7100; combining these as "CLA CLL" produces 7300, the instruction to clear both AC and the link bit. As a general rule, except when memory reference instructions are involved, the assembler simply ors together the values of all blank separated fields between the label and comment. Indirection is indicated by the special symbol I in the operand field, as in the third line of the example. The typical PDP-8 assembler has no explicit notation to distinguish between page zero and current page addresses. Instead, the assembler is expected to note the page holding the operand and automatically generate the appropriate mode. If the operand is neither in the current page nor page zero, some assemblers will raise an error, others will automatically generate an indirect pointer to the off-page operand (This feature should be avoided!). Note, in the final two lines of the example, that there is no "define constant" pseudo-operation. Instead, where a constant is to be assembled into memory, the constant takes the place of the op-code field. The PDP-8 has no immediate addressing mode, but most assemblers provide an optional mechanism to allow the programmer to ignore this lack: TAD (3) / add 3, from memory on the current page. TAD [5] / add 5, from memory on page zero. JMP I (LAB) / jump indirect through the address of LAB. Assemblers that support this automatically fill the end of each page with constants defined in this way that have been accumulated during the assembly of that page. Note that the variants "(3" and "[5" (with no closing parentheses) are usually allowed but the use of this sloppy form is generally 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, but expressions are evaluated in strict left-to-right order, as shown below: TAD X+1 / add the contents of the location after X. TAD (X-1) / add the address of the location before X. Other operators allowed included and (&), or (!), multiply (^) and divide (%), as well as a unary sign (+ or -). Unfortunately, one of the most widely used assemblers, PAL8, has trouble when unary operators are mixed with multiplication or division. Generally, only the first 6 characters of identifiers are significant and numeric constants are evaluated in octal. Other assembly language features are illustrated below: / Comments may stand on lines by themselves / Blank lines are allowed *200 / Set the assembly origin to 200 (octal) NL0002= CLA CLL CML RTL / Define new opcode NL0002. NL0002 / Use new opcode (load 0002 in AC) JMP .-1 / Jump to the previous instruction X1= 10 / Define X1 (an auto-index register address) TAD I X1 / Use autoindex register 1 IAC; RAL / Multiple instructions on one line $ / End of assembly The assembly file ends with a line containing a $ (dollar sign) not in a comment field. The $, * and = syntax used by most PDP-8 assemblers replace functions performed by pseudo-operations on many other assemblers. In addition, PAL8, the most widely used PDP-8 assembler supports the following pseudo-operations: DECIMAL / Interpret numeric constants in base 10 OCTAL / Interpret numeric constants in base 8 EJECT / Force a page eject in the listing XLIST / toggle listing PAGE / Advance location counter to next page FIELD N / Assemble into extended memory field N TEXT STRING / Pack STRING into consecutive 6 bit bytes ZBLOCK N / Allocate N words, initialized to zero IFDEF S / Assemble C if symbol S is defined IFNDEF S / Assemble C if symbol S is not defined IFZERO E / Assemble C if expression E is zero IFNZRO E / Assemble C if expression E is not zero Conditonally assembled code must be enclosed in angle brackets. The conditionally assembled code may extend over multiple lines. What character sets does the PDP-8 support? With its 12 bit word, the PDP-8 is somewhat awkward in its support for modern 7 and 8 bit character sets. Nonetheless, from the beginning, PDP-8 software has generally assumed that text I/O would be in 7 bit ASCII. Most early PDP-8 systems used teletypes as console terminals; as sold by DEC, these were configured for mark parity, so most older software assumes 7 bit ASCII, upper case only, with the 8th bit set to 1. On output, lines are generally terminated with both CR and LF; on input, CR is typically (but not always) the line terminator and LF is typically ignored. In addition, the tab character (HT) is generally interpreted in terms of a tab-stop every 8 spaces. Most of the better engineered PDP-8 software tends to fold upper and lower case on input, and it ignores the setting of the 8th bit. Internally, PDP-8 programmers are free to use other character sets, but the TEXT pseudo-operation strongly encourages the 6 bit character set called "stripped ASCII". To map from upper-case-only ASCII to stripped ASCII, each 8 bit character is anded with octal 77 and then packed 2 characters per word, left to right. Many programs use a semi-standardized scheme for packing mixed upper and lower case into 6 bit TEXT form; this uses ^ to flip from upper to lower case or lower to upper case, % to encode CR-LF pairs, and @ (octal 00) to mark end of string. Note that this scheme makes no provision for encoding the %, ^ and @ characters, nor does it allow control characters other than the CR-LF pair. Files under the widely used OS/8 system consist of sequences of 256 word blocks. When used for text, each block holds 384 bytes, packed 3 bytes per pair of words as follows: aaaaaaaa ccccaaaaaaaa bbbbbbbb CCCCbbbbbbbb ccccCCCC Control Z is used as an end of file marker. Because most of the PDP-8 system software was originally developed for paper tape, binary object code is typically stored in paper-tape image form using the above packing scheme. What different PDP-8 models were made? The total sales figure for the PDP-8 family is estimated at over 300,000 machines. Over 7000 of these were sold prior to 1970. During the PDP-8 production run, a number of models were made, as listed in the following table. Of these, the PDP-8/E is generally considered to be the definitive machine. If the PDP-8 is considered to be the Model T of the computer industry, perhaps the PDP-8/E should be considered to be the industry's Model A. MODEL DATES SALES COST TECHNOLOGY REMARKS PDP-5 63-67 116 Transistor PDP-8 65-69 1450 $18,500 Transistor LINC-8 66-69 142 $38,500 Transistor PDP-8/S 66-70 1024 $10,000 Transistor PDP-8/I 68-71 3698 $12,800 TTL PDP-8/L 68-71 3902 $8,500 TTL Scaled down 8/I PDP-12 69-73? 3500? $27,900 TTL Followup to LINC-8 PDP-8/E 70-78 >10K? $7,390 TTL MSI Omnibus PDP-8/F 72-78? >10K? <$7K TTL MSI Omnibus Based on 8/E CPU PDP-8/M 72-78? >10K? <$7K TTL MSI Omnibus OEM version of 8/F PDP-8/A 75-84? >10K? $1,317 TTL LSI Omnibus New CPU or 8/E CPU VT78 78-80 <$10K Intersil IM6100 Dm I 80-84 Harris 6120 Dm II 82-86 $1,435 Harris 6120 Dm III 84-90 $2,695 Harris 6120 Dm III+ 85-90 Harris 6120 Additional information is available in part two of this FAQ, where all known models of the PDP-8, along with variants, alternate marketing names, and other peculiarities are given. The last years of the PDP-8 family were dominated by the PDP-8 compatable microprocessor based VT78 and DECmate (Dm in the above table) machines. DEC also used the Intersil IM6100 and Harris 6120 microprocessors in many peripheral controllers for the PDP-11 and PDP-15. While all of the earlier PDP-8 systems were open architecture systems, the DECmates had closed architectures with an integrated console terminals and limited peripheral options. The following PDP-8 compatible or semi-compatible machines were made and sold by others; very little is known about many of these: MODEL DATE MAKER, NOTES MP-12 6? Fabritek (a surviving example runs FOCAL). TPA 68? Hungarian, a PDP-8/L clone, ran FOKAL Electrotechnica-100I ? Russian, a PDP-8/I? clone. Saratov-2 ? Russian, a slow clone, perhaps PDP-8/S Voronezh ? Russian, another PDP-8/? clone SPEAR u-LINC ? SPEAR, Inc, Waltham Mass. DCC-112 70-71 Digital Computer Controls DCC-112H 71 Digital Computer Controls 6100 Sampler 7? Intersil, their IM6100 promotional kit Intercept I 7? Intersil, based on IM6100 Intercept Jr 7? Intersil, based on IM6100 PCM-12 7? Pacific CyberMetrix, based on Intercept bus PCM-12A 7? Pacific CyberMetrix, fixed to clock at 4MHz SBC-8 84-88 CESI, Based on IM6120, SCSI bus What about the LINC/8 and PDP-12? Wesley Clark, then at Lincoln Labs, developed the LINC, or Laboratory INstrumentation Computer, as a personal laboratory computer in the early 1960's. He developed it in response to the needs of Mary Brazier, a neurophysiologist at MIT who needed better laboratory tools. Over 24 LINC systems were built by customers before late 1964 when DEC began selling a commercial version (see Computers and Automation, Nov. 1964, page 43). By the time DEC introduced the LINC-8, 43 LINC systems had been installed (see Computers and Automation, Mar. 1966, page 34). When Lincoln Labs decided that the LINC did not fit their mission, a group at the the National Institute of Health funded an experiment to see if the LINC would be a productive tool in the life sciences. As a result of this project, 12 LINCs were built and debugged, each by its eventual user. The LINC was the first 12 bit minicomputer built using DEC hardware. Like the PDP-5 and other early DEC computers, it was built with system modules, DEC's first family of logic modules. Along with the CDC 160, it paved the way for the PDP-5 and PDP-8. When compared with the PDP-8, the LINC instruction set was not as well suited for general purpose computation, but the common peripherals needed for lab work such as analog to digital and digital to analog converters were all bundled into the LINC system. Users judged it to be a superb laboratory instrument. One of the major innovations introduced with the LINC was the LINCtape. These tapes could be carelessly pocketed or dropped on the floor without fear of data loss, and they allowed random access to data blocks. DEC improved on this idea slightly to make their DECtape format, and DECtape was widely used with all DEC computers made in the late 1960's and early 1970's. The motives behind the development of LINCtape were the same motivives that led IBM to develop the floppy disk almost a decade later, and in fact, DECtape survived as a widely used medium until DEC introduced the RX01 8 inch floppy disk drive around 1975. Within a year of the introduction of the PDP-8, DEC released the LINC-8, a machine that combined a PDP-8 with a LINC in one package. The success of the LINC-8 led DEC to re-engineer the machine using TTL logic in the late 1960's; the new version was originally to be called the LINC-8/I, but it was sold as the PDP-12. Both the LINC-8 and the PDP-12 had impressive consoles, with separate sets of lights and switches for the LINC and PDP-8 halves. The success of the LINC-8 also led to the development of a clone, the SPEAR micro-LINC. This machine used Motorola MECL integrated circuits and was available for delivery in (June 1965? this date must be wrong!). The LINC-8 and PDP-12 could run essentially any PDP-8 or LINC software, but because they included instructions for switching between modes, a third body of software was developed that required both modes. One feature of LINC and LINC-8 software is the common use of the graphic display for input-output. These machines were some of the first to include such a display as a standard component, and many programs used the knobs on the analog to digital converter to move a cursor on the display in the way we now use a mouse. LAP, the Linc Assembly Program, was the dominant assembler used on the LINC. WISAL (WISconson Assembly Language) or LAP6-W was the version of this assembler that survived to run on the PDP-12. Curiously, this includes a PDP-8 assembler written in LINC code. LAP6-DIAL (Display Interactive Assembly Language) evolved from this on the PDP-12 to became the dominant operating system for the PDP-12. The 8K version of this is DIAL MS (Mass Storage), even if it has only two LINCtape drives. These were eventually displaced by the OS/8 variant known as OS/12. Where can I get a PDP-8 today? The CESI machine may still be on the market, for a high price, but generally, you can't buy a new PDP-8 anymore. There are quite a few PDP-8 machines to be found in odd places on the used equipment market. They were widely incorporated into products such as computer controlled machine tools, X-ray diffraction machines, and other industrial and lab equipment. Many of them were sold under the EduSystem marketing program to public schools and universities, and others were used to control laboratory instrumentation. After about 1976, Reuters bought on the order of 10,000 OMNIBUS based machines per year, with perhaps 2000 per year going to other customers. If you can't get real hardware, you can get emulators. Over the years, many PDP-8 emulators have been written; the best of these are indistinguishable from the real machine from a software prespective, and on a modern high-speed RISC platform, these frequently outperform the hardware they are emulating. Finally, you can always build your own. The textbook "The Art of Digital Design," second edition, by Franklin Prosser and David Winkel (Prentice-Hall, 1987, ISBN 0-13-046780-4) uses the design of a PDP-8 as a running example. Many students who have used this book were required to build working PDP-8 systems as lab projects. Where can I get PDP-8 documentation? Part II of this FAQ cites the key documents published by DEC describing each model of the PDP-8. These are all out of print, and DEC was in the habit of printing much of their documentation on newsprint with paperback bindings, which is to say, surviving copies tend to be yellow and brittle. DEC distributed huge numbers of catalogs and programming handbooks in this inexpensive paperback format, and these circulate widely on the second-hand market. When research laboratories and electronics shops are being cleaned out, it is still common to find a few dusty, yellowed copies of these books being thrown out. Douglas Jones has made a small number of bound photocopies of DEC's 1973 introduction to programming, perhaps the definitive introduction to the PDP-8, and the other early DEC handbooks need similar treatment before they all crumble. Maintenance manuals are harder to find, but more valuable. If you need one, you usually need to find someone willing to photocopy one of the few surviving copies. Fortunately, DEC has been friendly to collectors, granting fairly broad letters of permission to reprint obsolete documentation, and the network makes if fairly easy to find someone who has the documentation you need and can get copies. What operating systems were written for the PDP-8? A punched paper-tape library of stand-alone programs was commonly used with the smallest (diskless and tapeless) configurations from the beginning up through the mid 1970's. Many paper tapes from this library survive to the present at various sites! The minimum configuration expected by these tapes is a CPU with 4K memory, and a teletype ASR 33 with paper tape reader and punch. The DECtape Library System was an early DECtape oriented save and restore system that allowed a reel of tape to hold a directory of named files that could be loaded and run on a 4K system. Eventually, this supported a very limited tape-based text editor for on-line program development. This did not use the DECtape's block addressable character; the software was based on minimal ports of the paper-tape based software described above. The 4K Disk Monitor System provided slightly better facilities. This supported on-line program development and it worked with any device that supported 129 word blocks (DECtape, the DF32 disk, or the RF08 disk). MS/8 or the R-L Monitor System, was developed starting in 1966 and submitted to DECUS in 1970. This was a disk oriented system, faster than the above, with tricks to make it run quickly on DECtape based systems. POLY BASIC was a BASIC only system submitted to DECUS and later sold by DEC as part of its EduSystem marketing program. P?S/8 was developed starting in 1971 from an MS/8 foundation. It runs on minimal PDP-8 configurations, supports somewhat device independant I/O and requires a random-access device for the file system (DECtape is random-access!). P?S/8 runs compatably on most PDP-8 machines including DECmates, excepting only the PDP-8/S and PDP-5. P?S/8 is still being developed! OS/8, developed in parallel with P?S/8, became the main PDP-8 programming environment sold by DEC. The minimum configuration required was 8K words and a random-access device to hold the system. For some devices, OS/8 requires 12K. There are a large number of OS/8 versions that are not quite portable across various subsets of the PDP-8 family. OS/78 was developed from OS/8 to support the DECmate I, and OS/278 was developed for the later DECmate machines. These have unnecessary incompatabilities with earlier versions of OS/8 and with pre-Omnibus machines. There are also stories that DEC included code in either OS/8 or one of its predecessors to make it incompatable with the DCC-112. OS8 (no slash) may still be viable. It requires 8K of main memory, an extended arithmetic unit, and DECtape hardware. Unlike most PDP-8 operating systems, it uses a directory structure on DECtape compatable with that used on the PDP-10. TSS/8 was developed in 1968 as a timesharing system. It required a minimum of 12K words of memory and a swapping device. It was the standard operating system on the EduSystem 50 which was sold to many small colleges and large public school systems. Each user gets a virtual 4K PDP-8; many of the utilities users ran on these virtual machines were only slightly modified versions of utilities from the Disk Monitor System or paper-tape environments. Other timesharing systems developed for the PDP-8 include MULTI-8, ETOS, MULTOS, and OMNI-8; some of these required nonstandard memory management hardware. By the mid 1970's, some of these were true virtual machine operating systems in the same spirit as IBM's VM-370; they typically supported some version of OS/8 running on a 32K virtual PDP-8 assigned to each user. Some could support different user operating systems on each virtual machine, others supported addressing of more than 4K for data, but limited code to field zero of a process's virtual memory. CAPS-8 was a cassette based operating system supporting PAL and BASIC. There are OS/8 utilities to manipulate CAPS-8 cassettes, and the file format on cassette is compatible with a PDP-11 based system called CAPS-11. WPS was DEC's word processing system, developed on the 8/E and widely used on the 1980's vintage machines with a special WPS keycaps replacing the standard keycaps on the keyboard. It was heavily promoted on the VT-78, and when the DECmates came out, DEC began to suppress knowledge that DECmates could run anything else. WPS-11 was a curious distributed system using a PDP-11 as a file server for a cluster of VT-78 WPS systems. COS-310, DEC's commercial operating system for the PDP-8, supported the DIBOL language. COS-310 was a derivative of MS/8 and OS/8, but with a new text file format. The file system is almost the same as OS/8, but dates are recorded differently, and a few applications can even run under both COS and OS/8. COS was the last operating system other than WPS promoted by DEC for the DECmates. What programming languages are supported on the PDP-8 The PAL family of assembly languages, particularly PAL III and PAL8 are as close to a standard assembly language as can be found for the PDP-8. These produce absolute object code and there are versions of PAL for minimally configured machines, although these have sever symbol table limitations. MACRO-8 was DEC's first macro assembly language for the PDP-8, but it was rarely used outside the paper-tape environment. MACREL and SABR are assembly languages that produce relocatable output. SABR is the final pass for the ALICS II FORTRAN compiler, and MACREL was developed in (unfulfilled) anticipation of similar use. MACREL was heavily used by the DECmate group at DEC. There was also RALF, the relocatable assembler supporting RTPS FORTRAN, and FLAP, an absolute assembler derived from RALF. Both SABR and RALF/FALP are assemblers that handle their intended applications but have quirky and incompatible syntax. A subset of FORTRAN was supported on both the PDP-5 and the original PDP-8. Surviving documentation describes a DEC compiler from 1964 and a compiler written by Information Control Systems from 1968. The latter, ALICS II FORTRAN, was originally a paper tape based compiler, but it forms the basis of the OS/8 8K FORTRAN compiler, and was also adapted to the Disk Monitor System. RTPS FORTRAN required 8K and a floating point processor; it had real-time extensions and was a full implementation of FORTRAN IV (also known as ANSI FORTRAN 66). OS/8 F4 is RTPS FORTRAN stripped of the requirement for hardware floating point (if the hardware is missing, it uses software emulation). FOCAL, an interpretive language comparable to BASIC, was available on all models of the family, including the PDP-5 and PDP-8/S. Varsions of FOCAL run under PS/8, P?S/8 and other systems. Many versions of BASIC were also available, from DEC and other sources. DEC BASIC was widely used on PDP-8 systems sold under the EduSystem marketing program. A paper-tape version was available that ran in 4K, versions for OS/8 and TSS/8, an 8K stand-alone time-sharing version, and others. DIBOL was DEC's attempt at competing with COBOL in the commercial arena. It was originally implemented under MS/8 but most versions were sold to run under the COS operating system. Algol was available from a fairly early date. At least two Pascal compilers were developed for the PDP-8. One was a Pascal-S interpreter, written in assembler, the other was a Pascal-P compiler with a P-code interpreter written in assembler. At least two LISP interpreters were written for the PDP-8; one runs in 4K, the other can use up to 16K. POLY SNOBOL was a version of SNOBOL that was somewhere between Griswald's definitions of SNOBOL 3 and SNOBOL 4. TECO, the text editor, is available, and is also a general purpose language, and someone is working on a PDP-8 C. The story of TECO on the PDP-8 is convoluted. Russ Ham implemented TECO under his OS8 (without a slash) system. This version of TECO was pirated by the Oregon Museum of Science and Industry (OMSI), where the system was ported to PS/8. Richard Lary and Stan Rabinowitz made it more compatible with other versions of TECO, and the result of work is the version distributed by DECUS. RT-11 TECO for the PDP-11 is a port of this code. Where can I get PDP-8 software? DECUS, the DEC User Society, is still alive and well, and their submission form still lists PAL8 and FOCAL as languages in which they accept submissions! The DECUS library is available on-line by anonymous FTP at acfcluster.nyu.edu in subdirectory DECUS. To quote the README file from the current on-line catalog, "Items from older DECUS Library catalogs are still also available (provided their media can still be read), but machine readable catalog information is not available for these." Direct questions by E-mail to INFORMATION@DECUS.ORG. The following anonymous FTP sites contain publically accessable archives of PDP-8 software and other information: ftp.telebit.com:/pub/pdp8 ftp.update.uu.se:/pub/pdp8 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. Where can I get additional information? The file WHAT-IS-A-PDP8, by Charles Lasner contains considerable additional information; this file is included in the telebit.com archive cited above. This file gives details of every PDP-8 model including the small quirks and incompatabilities that (to be generous) allow software to determine which model it is running on. These quirks also make it all too easy for careless programmers to write almost portable software with very obscure bugs. The mailing list pdp8-lovers@ai.mit.edu reaches a number of PDP-8 owners and users, not all of whom have USENET feeds. The USENET newsgroup alt.sys.pdp8 needs to be gatewayed to this mailing list. Many "archival" books have included fairly complete descriptions of the PDP-8; among them, "Computer Architecture, Readings and Examples" by Gordon Bell and Allen Newell is among the most accurate and complete (but difficult to read). What use is a PDP-8 today? What use is a Model T today? Collectors of both come in the same basic classes. First, there are antiquarians who keep an old one in the garage, polished and restored to new condition but hardly ever used. Once a year, they warm it up and use it, just to prove that it still works, but they don't make much practical use of it. PDP-8 systems maintained by antiquarians are frequently in beautiful shape. Antiquarians worry about dust, chipped paint, and missing switches, and they establish newsgroups and mailing lists to help them locate parts and the advice needed to fix their machines. In the second class are those who find old machines and soup them up, replacing major parts to make a hotrod that only looks like the original from the outside, or keeping the old mechanism and putting it to uses that were never intended. Some PDP-8 owners, for example, have built PDP-8 systems with modern SCSI disk interfaces! There is serious interest in some quarters in constructing an omnibus board that would support an IDE disk of the variety that was mass-produced for the IBM PC/AT. Last, there are the old folks who still use their old machines for their intended purposes long after any sane economic analysis would recommend such use. If it ain't broke, don't fix it, and if it can be fixed, why bother replacing it? Both Model T Fords and the classic PDP-8 machines are simple enough that end users can maintain and repair them indefinitely. All you need to keep a vintage -8 running are a stock of inexpensive silicon diodes and a stock of 2N3639B or better, 2N3640 transistors. Unlike most modern personal computers, PDP-8 systems were routinely sold with complete maintenance manuals; these included schematic diagrams, explanations of not only how to use the devices, but how they are built, and suggestions to those considering building their own peripherals. Compared with many so-called "open systems" of today, the PDP-8 was far better documented and far more open. Finally, the PDP-8 is such a minimal machine that it is an excellent introduction to how computers really work. Over the years, many students have built complete working PDP-8 systems from scratch as lab projects, and the I/O environment on a PDP-8 is simple enough that it is a very appropriate environment for learning operating system programming techniques. Who's Who? C. Gordon Bell is generally credited with the original design of the PDP-8. He was also involved with recommending what became the PDP-11 when that design was competing with the design that probably became the NOVA, and as vice president of research, he oversaw the development of the DEC VAX family. Alan Kotok worked with Bell in working up the original specifications of the PDP-8. Ben Gurley designed most of the big DEC machines, starting with the PDP-1. The actual design work on the -8, however, was done by Ed deCastro, who later founded Data General to build the Nova. Ken Olson ran DEC from the beginning. Ed Yourdon, who later became well known as a programming methodology guru, hacked up the PAL III assembler for the -8, based on PAL II. 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, and he has written a PAL-like cross assembler in C. From jones@cs.uiowa.edu Sat Dec 11 01:50:08 EST 1993 Article: 513 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.answers,news.answers Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: PDP-8 Summary of Models and Options (posted every other month) Summary: Descriptions of all models of the DEC PDP-8 computer. Those posting to alt.sys.pdp8 should read this. Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec9.141448.3435@news.uiowa.edu> Approved: news-answers-request@MIT.Edu Date: Wed, 8 Dec 1993 08:08:08 GMT Expires: Tue, 8 Feb 1994 08:08:08 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA Keywords: FAQ DEC PDP 8 Followup-To: alt.sys.pdp8 Lines: 1202 Xref: samba.oit.unc.edu alt.sys.pdp8:513 alt.answers:1331 news.answers:14879 Archive-name: dec-faq/pdp8-models Last-modified: Oct 8, 1993 Frequently Asked Questions about DEC PDP-8 models and options. By Douglas Jones, jones@cs.uiowa.edu (with help from many folks) Sites known to carry FTPable copies of this file: rtfm.mit.edu:/pub/usenet/alt.sys.pdp8 sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc Contents What is this FAQ? What is a PDP-5? What is a PDP-8? What is a LINC-8? What is a PDP-8/S? What is a PDP-8/I? What is a PDP-8/L? What is a PDP-12? What is a PDP-8/E? What is a PDP-8/F? What is a PDP-8/M? What is a PDP-8/A? What is a VT78? What is a DECmate I? What is a DECmate II? What is a DECmate III? What is a DECmate III+? What is this FAQ? The purpose of this document is to supplement the material in the primary "Frequently Asked Questions about the PDP-8" file with more detailed information about the hardware and options of the different models of the PDP-8 sold by DEC. Although this document is something of a history of the DEC PDP-8 family, the primary purpose of this document is as a guide and general outline to the PDP-8 models and options likely to be encountered by those involved in collecting and restoring systems. What is a PDP-5? Date of introduction: Aug 11, 1963, unveiled at WESCON. Date of withdrawal: early 1967. Price: $27,000 Technology: Built with DEC System Modules, the original line of transistorized logic modules sold by DEC. Supply voltages of +10 and -15 volts; the logic levels -3 (logic 1) and 0 (logic 0). Logic packaged on boards that were about 4.75 inches wide with each card mounted in a metal frame with a 22 pin edge connector. Input output devices were connected to the daisy-chained I/O bus using military-style armored cables and connectors. Use of toggle switches (as opposed to slide switches) on the front panel was another vestige of military-style design. Reason for introduction: This machine was inspired by the success of the CDC-160, Seymour Cray's 12 bit minicomputer, and by the success of the LINC, a machine that was built by DEC customers out of System modules. These demonstrated that there was a market for a small inexpensive computer, and from the start, DEC's advertisements were aimed at this market. "Now you can own the PDP-5 computer for what a core memory alone used to cost: $27,000", ran one 1964 ad. Reason for withdrawal: The PDP-8 outperformed the PDP-5, and did so for a lower price. Compatability: The core of the PDP-8 instruction set is present, but memory location zero is the program counter, and interrupts are handled differently. The Group 1 OPR rotate instructions cannot be combined with IAC or CMA; this limits the ability of the PDP-5 to support code from later models. The machine did not support 3 cycle data-break (DMA transfers using memory to hold buffer address and word-count information), so many later PDP-8 peripherals could not be used on the PDP-5. In addition, DMA transfers are not allowed outside the program's current 4K data field, severely limiting software compatability on systems with over 4K of memory where either interrupts or software initiated changes to the data field during a transfer would cause chaos. Standard configuration: CPU with 1K or 4K of memory (2K and 3K versions were not available). Peripherals: An extended arithmetic element (EAE) was available; this was an I/O device, using IOT instructions to evoke EAE operations. As a result, it was not compatable with the later PDP-8 EAEs. In addition, machines with the EAE option had a different front panel from those without. The type 552 DECtape control and type 555 DECtape transports were originally developed for the PDP-5. After the PDP-8 was introduced, DEC offered a bus converter that allowed the PDP-5 to support standard PDP-8 negibus peripherals, so long as they avoided using 3-cycle data break transfers. The standard 804 PDP-8 expander box was frequently sold as an upgrade to PDP-5 systems. What is a PDP-8? Date of introduction: 1965 (Unveiled March 22, in New York) Date of withdrawal: 1968. Also known as: Classic PDP-8 (to point out lack of a model suffix) Straight-8 (Again, points out the lack of a model suffix) PCP-88, an OEM label, used Foxboro Corporation. Price: $18500 Technology: Mostly DEC R-series logic modules; these were originally discrete component transistor logic, but around the time the PDP-8 was introduced, DEC introduced the Flip Chip, a hybrid diode/resistor "integrated circuit" on a ceramic substrate. These could directly replace discrete components on the PC boards, and DEC began to refer to their R-series modules as flip-chip modules and they even advertised the PDP-8 as an integrated circuit computer. A typical flip-chip module, the R111, had three 2-input nand gates and cost $14, with no price change from 1965 to 1970. S-series logic modules were also used; these are essentially the same as their R-series cousins, but with different pull-up resistors for higher speed at lower fanout. Many R and S series modules have trimmers that must be tuned to the context, making replacement of such modules more complex than a simple board swap. As with the system modules used in the PDP-5, the supply voltages were +10 and -15 volts and the logic levels were -3 (logic 1) and 0 (logic 0). Logic was packaged on boards that were 2.5 inches wide by 5 inches high. The card edge connector had 18 contacts on 1/8 inch centers. Some double width cards were used; these had two card edge connectors and were 5 1/8 inches wide. Machine wrapped wire-wrap technology was used on the backplane using 24-gauge wire. The "negibus" or negative logic I/O bus used -3 and 0 volt logic levels in 92 ohm coaxial cable, with 9 coaxial cables bundled per connector card and 6 bundles making up the basic bus. 4 (originally 5) more bundles were required to support data-break (DMA) transfers. Bus termination was generally kluged in with 100 ohm resistors clipped or wrapped into the backplane, although a bus terminator card was occasionally used. Some time after the first year of production, flat ribbon cable made of multiple coaxial cables was used, and later still, flat mylar stripline cable was used (but never recommended because it lacked necessary shielding). Core memory was used, with a 1.5 microsecond cycle time, giving the machine an add time of 3 microseconds. 4K of core occupied an aluminum box 6 inches on a side and needed numerous auxiliary flip-chips for support. It is worth noting that the PDP-8 was about as fast as was practical with the logic technology used; only by using tricks like memory interleaving or pipelining could the machine have been made much faster. Reason for introduction: This machine was inspired by the success of the PDP-5 and by the realization that, with their new Flip-Chip technology, DEC could make a table-top computer that could be powered by a single standard wall outlet; of course, adding any peripherals quickly increased the power requirement! Reason for withdrawal: The PDP-8/I was less expensive, and after initial production difficulties, it equalled the performance of the PDP-8. Compatability: The core of the PDP-8 instruction set is present, but the Group 1 OPR instruction IAC cannot be combined with any of the rotate instructions. If RAR and RAL or RTR and RTL are combined, the results are unpredictable (simultaneous set and reset of bits of AC results in metastable behavior). The IOT 0 instruction was used for the internal type 189 ADC, and not for the later CAF (clear all flags) instruction. As a result, if the ADC option was not present, IOT 6004 (or microcoded variants) would hang the machine. If the extended arithmetic element is present, the SWP (exchange AC and MQ) instruction does not work. This works on later models when the EAE is present, although it was only documented with the introduction of the PDP-8/E. Finally, the EAE lacks the SCL (shift count load) instruction that is present on later models. On machines with 8K or more, an attempt to change the data field to a non-existant field caused a bizarre double- indirect and skip instruction execution that must be accounted for in memory diagnostics. Standard configuration: The PDP-8 was sold as a CPU with 4K of memory, a 110 baud current loop teletype interface and an ASR 33 Teletype. In addition, the standard in-cabinet logic includes support for the full negibus interface, including data-break (DMA) transfers. Both a rack-mount model with rosewood trim and an elegant plexiglass enclosed table-top configuration were standard. Under the skin, basic machine occupied a volume 33 inches high by 19 inches wide by 22 inches deep. The two halves of the backplane were mounted vertically, like the covers of a book, with the spine in back and circuit modules inserted from the two sides. Sliding the CPU out of the relay rack or removing the plexiglass covers allows the backplane to swung open for access to the wires. Expandability: In-cabinet options include the type 182 extended arithmetic element (EAE), the type 183 memory extension control subsystem, and the type 189 low performance analog to digital converter (ADC). Prewired backplane slots were reserved for all of these. Expansion beyond 4K of memory requires rack space for the rack-mounted type 184 memory module; each such module adds one 4K field of memory, up to a maximum of 32K. The rack-mount CPU occupied a large part of one rack, allowing room for a single type 184 memory expansion module below the CPU; generally, a second rack was needed for added peripherals or memory. At the end of the production run, some PDP-8 systems were sold with PDP-8/I memory, allowing room for an additional 4K without need for an expansion chassis. These nonstandard machines were very difficult to maintain! Peripherals: At the time of introduction, the following negibus peripherals were offered. -- Type 750C high speed paper tape reader and control. -- Type 75E high speed paper tape punch and control. -- Type 138E analog to digital converter and multiplexor. -- Type 34D oscilloscope display (dual digital to analog). -- Type 350B incremental (CalComp) plotter control. -- Type 451 card reader and control. -- Type 450 card punch control for IBM Type 523 punch. -- Type 64 (later 645) Mohawk line printer and control. -- Type RM08 serial magnetic drum system (up to 256K words). -- Type 552 DECtape control (for type 555 DECtape drives). -- Type 57A magnetic tape control (IBM type 729 drive). -- Type 580 magnetic tape system. By 1967, the following peripherals had been added to the line: -- Type TC01 DECtape control for up to 8 TU55 transports. -- Type AF01 analog to digital converter and multiplexor. -- Type AA01A 3 channel digital to analog (scope display). -- Type AX08 parallel digital input port. -- Type 338 Programmed Buffered Display (vector graphics). By 1968, the following new peripheral had been added: -- Type DF32 fixed head disk system (up to 256K words). -- Type BE01 OEM version of the TC01 (no blinking lights). -- Type BE03 dual TU55 drive for the TC01 or BE01. Finally, as DEC abandoned the negibus, they introduced the DW08B negibus to posibus converter so newer posibus peripherals could be used on older negibus machines. What is a LINC-8? Date of introduction: 1966 (during or before March) Date of withdrawal: 1969 (displaced by PDP-12) Price: $38,500 Technology: DEC Flip Chip modules, as in the PDP-8, with a LINC CPU partially reimplemented in Flip Chips and partially emulated with PDP-8 instructions. (The original LINC was built from the same System Modules used in the PDP-5.) Compatability: Identical to the PDP-8. Standard configuration: The combined PDP-8/LINC CPU, plus 4K of memory was central to the system. The set of peripherals bundled with the machine was impressive: -- An ASR 33 Teletype modified for the LINC character set. -- Two LINCtape drives. -- 8 analog to digital converter channels with knob inputs. -- Another 8 ADC channels with jack inputs. -- 6 programmable relay outputs, good up to 60 Hz. -- 1 Tektronix 560 oscilliscope, somewhat modified. The X and Y axis control for the scope came from DACs attached to the LINC's AC and MB registers, respectively. Expandability: In addition to standard PDP-8 peripherals, up to 3 additional pairs of LINCtape drives could be added, for a total of 8 drives. Each pair of drives cosmetically resembled the type BE03 dual DECtape transport, but single drives were not available. Up to 2 additional ranks of 8 ADC channels could be added. A second oscilliscope could be added. What is a PDP-8/S? Date of introduction: 1966 (Unveiled, Aug 23, WESCON, Los Angeles). Date of withdrawal: 1970. Price: $10,000 Technology: DEC Flip Chip modules and core memory, as in the PDP-8. Unlike the PDP-8, the PDP-8/S memory was mounted on quad-height single-width boards that plugged into the standard flip-chip sockets. Reason for introduction: This machine was developed as a successful exercise in minimizing the cost of the machine. It was the least expensive general purpose computer made with second generation (discrete transistor) technology, and it was one of the smallest such machines to be mass produced (a number of smaller machines were made for aerospace applications). It was also incredibly slow, with a 36 microsecond add time, and some instructions taking as much as 78 microseconds. By 1967, DEC took the then unusual step of offering this machine for off the shelf delivery, with one machine stocked in each field office available for retail sale. Reason for withdrawal: The PDP-8/L vastly outperformed the PDP-8/S, and it did so at a lower price. Compatability: The core of the PDP-8 instruction set is present, but there are a sufficient number of incompatabilities that, as with the PDP-5, many otherwise portable "family of 8" programs will not run on the PDP-8/S. Perhaps the worst incompatability is that the Group 1 OPR instruction CMA cannot be combined with any of the rotate instructions; as with the PDP-8, IAC also cannot be combined with rotate. Standard configuration: CPU with 4K of memory, plus PT08 110 baud current loop teletype interface and teletype. Both a rack-mount table-top versions were sold (both 9" high by 19" wide by 20"? deep). The rack mount could be slid out of the rack on slides for for maintenance. Expandability: The CPU supported the standard PDP-8 negibus, but I/O bandwidth was 1/5 that of the PDP-8. Thus, most, but not all PDP-8 peripherals could be used. A few DEC peripherals such as the DF32 came with special options such as interleaving to slow them down for compatability with the PDP-8/S. The speed problems were such that there was never any way to attach DECtape to this machine. What is a PDP-8/I? Date of introduction: 1968 (announced before December '67) Date of withdrawal: 1971. Technology: DEC M-series logic modules, called M-series flip-chips as the term flip-chip was applied to the module format instead of to DEC's hybrid integrated circuits. M-series modules used TTL chips, with a +5 supply, packaged on the same format board as was used with the original flip-chips, but with double-sided card-edge connectors (36 contacts instead of 18). Modules were limited to typically 4 SSI ICs each. The M113, a typical M-series module, had 10 2-input nand gates and cost $23 in 1967 (the price fell to $18 in 1970). Wire-wrapped backplanes used 30-gauge wire. The PDP-8/I, as originally sold, supported the then-standard PDP-8 negibus. 4K words of core were packaged in a 1 inch thick module made of 5 rigidly connected 5 by 5 inch two-sided printed circuit boards. Connectors and support electronics occupied an additional 32 backplane slots. Nominally, the core memory (which, curiously, used a negative logic interface!) was supposed to run at a 1.5 microsecond cycle time, but many early PDP-8/I systems were delivered running at a slower rate because of memory quality problems. DEC went through many vendors in the search for good memory! The memory interface was asynchronous, allowing the CPU to delay for slow memory. DEC continued to make the classic PDP-8 until the problems with memory speed were solved. Reason for introduction: This machine was developed in response to the introduction of DIP component packaging of TTL integrated circuits. This allowed a machine of about the same performance as the original PDP-8 to fit in about half the volume and sell for a lower price. Reason for withdrawal: The PDP-8/E made slight performance improvements while undercutting the price of the PDP-8/I. Compatability: The core of the PDP-8 instruction set is present, and unlike the original PDP-8, IAC can be combined with rotate in a single microcoded Group 1 OPR instruction. Combined RAR and RAL or RTR and RTL produce the logical and of the expected results from each of the combined shifts. If the extended arithmetic element is present, the SWP (exchange AC and MQ) instruction works, but this was not documented. On large memory configurations, memory fetches from a nonexistant memory field take about 30 microseconds (waiting for a bus timeout) and then they return either 0000 or 7777 depending on whether the fetch was from an even or odd field. Standard configuration: CPU with 4K of memory, plus 110 baud current loop teletype interface. Pedestal, rack-mount and table-top versions were made. In the pedestal version, the logic filled the body of the pedestal, with the console lights and switches on top. In one rack-mount version, the machine was built on a backplane that was bolted to the back of the rack, while the front panel hung from the front (unlike all other rack-mounted PDP-8 models, this version could not be swung out for maintenance on chassis slides). Finally, a boxed version was sold that could be used on table-top or mounted on chassis slides. Expandability: 4K of memory could be added internally, and additional memory could be added externally using a rack-mounted MM8I memory expansion module for each 4K or 8K addition over 8K. The backplane of the PDP-8/I was prewired to hold a Calcomp plotter interface, with the adjacent backplane slot reserved for the cable connection to the plotter. Initially, the CPU was sold with bus drivers for the PDP-8 negibus, allowing this machine to support all older DEC peripherals, but later machines were sold with posibus interfaces, and DEC made an effort to convert earlier machines to the posibus in the field. A posibus to negibus converter, the DW08A, allowed use of all older PDP-8 peripherals, with small modifications. The change from negibus to posibus during the period of PDP-8/I production leads to confusion because surviving systems may have any of three I/O bus configurations: Negibus, early posibus, or final posibus. The early posibus used the same connectors and cables as the negibus, with only 9 conductors per connector, while the final posibus used both sides of the connector paddles, for 18 bus lines per connector. To add to this confusion, some negibus PDP-8/I systems were rewired to use 18 conductor posibus cables while still using negative logic! Eventually, an add-on box was sold that allowed PDP-8/E (OMNIBUS) memory to be added to a PDP-8/I. Additionally, Fabritek sold a 24K memory box for the 8/I. What is a PDP-8/L? Date of introduction: 1968 (announced before August '68) Date of withdrawal: 1971. Price: $8,500 Technology: DEC M-series flip Chip modules, as in the PDP-8/I, with the same core memory as the 8/I, but the memory cycle cycle time was downgraded to 1.6 microseconds to avoid the speed problems of the -8/I. The positive I/O bus, or posibus, was a 100 ohm bus clamped between 0 and 3 volts with TTL drivers and receivers. This was packaged with 18 signal lines per 2-sided interconnect cable, using mylar ribbon cable in most cases. Electrically, coaxial cable could be used, but the slots in the CPU box were too small to allow convenient use of this option. Reason for introduction: This machine was developed as a moderately successful exercise using M-series logic to produce a lower cost but moderately fast machine. The idea was to cut costs by limiting provisions for expansion. Reason for withdrawal: The PDP-8/E made performance improvements while slightly undercutting the price of the PDP-8/L. Compatability: The core of the PDP-8 instruction set is present, but all Group 3 OPR instructions are no-ops, even the Group 3 version of the CLA instruction. This is because there was no provision made for adding an EAE to this machine. Microcoding RAR and RAL together works as in the PDP-8/I. Finally, a new front panel feature was added, the protect switch. When thrown, this makes the last page of the last field of memory read-only (to protect your bootstrap code). The instruction to change the data field on an 8/L becomes a no-op when the destination data field is non-existant; on all other machines, attempts to address non-existant fields are possible. One option for expanding the 8/L was to add a box that allowed 8/E memory modules to be added to the 8/L; when this was done, access to nonexistant data fields becomes possible and always returns 0000 on read. Standard configuration: A CPU with 4K of memory, plus 110 baud current loop teletype interface was standard. Both rack-mount and table-top versions were sold (both 9" high by 19" wide by 21" deep). The backplane was on top, with modules plugged in from the bottom. The rack-mount version could be slid out for maintenance. Expandability: The CPU supported a new bus standard, the PDP-8 posibus. There is little space for in-box peripherals, but an expander box with the same volume as the CPU was available, the BA08A; this was prewired to hold an additional 4K of memory and to support in-box peripheral interfaces for such devices as the PDP-8/I Calcomp plotter interface. DEC eventually offered the BM12L, an 8K expansion box, allowing 12K total memory on a PDP-8/L. Curiously, this contains precisely the modules needed to upgrade a 4K PDP-8/I or PDP-12 to an 8K machine, or to populate an MM8I box to add 8K of additional memory to an 8/I or PDP-12. Finally, DEC eventually offered a box allowing PDP-8/E (OMNIBUS) memory to be used with the PDP-8/L. PDP-8/L configurations with over 8K of memory were awkward because the front panel only showed one bit of the extended memory address. As a result, extra lights and switches for the additional bits of the memory address were mounted on the front of the memory expander boxes for the large configurations. A variety of posibus peripherals were introduced, most of which were built with the option of negibus interface logic (the -P and -N suffixes on these new peripherals indicated which was which). Many early PDP-8/L systems were sold with DW08A bus level converters to run old negibus peripherals. Posibus peripherals introduced after the PDP-8/L (and also used with posibus versions of the PDP-8/I) included: -- The TC08P DECtape controller (for 8 TU55 or 4 TU56). -- The DF32D-P fixed head disk controller (a posibus DF32). -- The FPP-12 floating point processor. -- The TR02 simple magnetic tape control. -- The RK08 disk subsystem, 4 disk packs, 831,488 words each. What is a PDP-12? Date of introduction: 1969 (February or earlier). Date of withdrawal: 1973. Price: $27,900 Technology: DEC M-series flip Chip modules, as in the PDP-8/I. Reason for introduction: This machine was developed as a follow-up to the LINC-8. Originally it was to be called the LINC-8/I, but somehow it got its own number. In effect, it was a PDP-8/I with added logic to allow it to execute most of the LINC instruction set, with trapping and software emulation used more selective than on the LINC-8. Reason for withdrawal: The LAB-8/E and the LAB-11 (a PDP-8/E and a PDP-11/20 with lab peripherals) eventually proved the equal of the PDP-12 in practice, and LINC compatability eventually proved to be of insufficient value to keep the machine alive in the marketplace. Compatability: This machine is fully compatable with the PDP-8/I, with additional instructions to flip from PDP-8 mode to LINC mode and back. IOT 0 could enable the API, causing trouble with later PDP-8 code that assumes IOT 0 is "Clear all flags". Also, the DECtape instruction DTLA (6766) becomes part of a stack-oriented extension to the instruction set, PUSHJ, on late model (or field updated) machines with the KF12-B backplane. Standard configuration: PDP-8/LINC CPU with 4K of memory, plus 110 baud current loop interface, plus output relay registers. In addition, the standard configuration included either two TU55 or one TU56 drive, with a PDP-12 only controller allowing it to handle LINCtape. In additoon, a 12" scope was always included, with a connector that can connect to a second scope. Expandability: An analog to digital converter and multiplexor was needed to fully support knob-oriented LINC software. Other options included: -- the KW12 programmable lab clock. -- additional TU55 or TU56 drives (up to 8 transports). -- the PRTC12F option to allow DECtape as well as LINCtape. -- the PC05 paper tape reader punch. What is a PDP-8/E? Date of introduction: 1970 (during or before August). Date of withdrawal: 1978. Also known as: Industrial-8 (with a red color scheme) LAB-8/E (with a green color scheme) Price: $7,390 Technology: Nominally made from DEC M-series flip Chip modules, but in a new format, quad-wide (10.5 inches wide), double- height (9 inches, including card-edge connector, excluding handles). SSI and MSI TTL logic were used on these boards, and the entire CPU fit on 3 boards. Interconnection between boards was through a new bus, the OMNIBUS. This eliminated the need for a wire-wrapped backplane, since all slots in the bus were wired identically. A new line of peripheral interfaces was produced, most being single cards that could be plugged directly into the inside the main enclosure. These included a set of posibus adapters allowing use of older peripherals on the new machine. Interboard connectors were needed for some multiboard options, including the CPU and memory subsystems. These used standard 36 pin backplane connectors on the opposite side of the board from the backplane. Some boards, notably memory boards, had a total of 8 connector fingers, 4 for the omnibus and 4 for interboard connectors. The core memory cycle time was 1.2 or 1.4 microseconds, depending on whether a read-modify-write cycle was involved. A 4K core plane was packaged on a single quad-wide double- high board, with most of the drive electronics packed onto two adjacent boards. Soon after the machine was introduced, an 8K core plane was released in the same format. Reason for introduction: The cost of the PDP-8/I and PDP-8/L was dominated by the cost of the interconnect wiring, and this cost was a result of the use of small circuit boards. By packing a larger number of chips per board, similar function could be attained in a smaller volume because less interboard communication was required. The PDP-8/E exploited this to achieve a new low in cost while attaining a new high in performance. Reason for withdrawal: This machine was slowly displaced by the PDP-8/A as the market for large PDP-8 configurations declined in the face of pressure from 16 bit mini and microcomputers. Compatability: As with the PDP-8/I and PDP-8/L, there are no limits on the combination of IAC and rotate instructions. Unlike the early machines, basic Group 3 OPR operations for loading and storing the MQ register work even if there is no extended arithmetic element. Finally, a new instruction was added, BSW; this swaps the left and right bytes in AC, and is encoded as a Group 1 OPR instruction using the "double the shift count bit". An odd quirk of this machine is that the RAL RAR combination ands the AC with the op-code, and the RTR RTL combination does an effective address computation loading the high 5 bits of AC with the current page and the lower bits of AC with the address field of the OPR instruction! The EAE has a new mode, mode B. Previous EAE designs were single-mode. Mode B supports a large set of 24 bit operations and a somewhat more rational set of shift operations than the standard EAE. All prior EAE designs would hang on the microcoded CLA NMI (clear/normalize) instruction applied to a nonzero AC. This instruction is redefined to be a mode changing instruction on the 8/E. Standard configuration: A CPU with 4K of memory, plus 110 baud current loop teletype interface. Both a rack-mount table-top versions were sold (both 9" high by 19" wide by 21" deep). The rack mount version was mounted on slides for easy maintenance. The OMNIBUS backplane was on the bottom, with boards inserted from the top. The standard OMNIBUS backplane had 20 slots, with no fixed assignments, but the following conventional uses: -- KC8E programmer's console (lights and switches) -- M8300 \_ KK8E CPU registers -- M8310 / KK8E CPU control -- -- -- M833 - Timing board (system clock) -- M865 - KL8E console terminal interface. -- -- -- -- space for more peripherals -- -- -- M849 - shield to isolate memory from CPU -- G104 \ -- H220 > MM8E 4K memory -- G227 / -- -- -- space for more memory -- -- M8320 - KK8E Bus terminator Most of the early boards with 3 digit numbers were defective in one way or another, and the corrected boards added a trailing zero. Thus, the M833 was generally replaced with an M8330, and the M865 was replaced with the M8650. Expandability: The following are among the OMNIBUS boards that could be added internally: -- M8650 - KL8E RS232 or current loop serial interface. -- M8340 \_ Extended arithmetic element. -- M8341 / (must be attached in two slots adjacent to CPU. -- M8350 - KA8E posibus interface (excluding DMA transfers). -- M8360 - KD8E data break interface (one per DMA device). -- M837 - KM8E memory extension control (needed for over 4K). -- M840 - PC8E high speed paper tape reader-punch interface. -- M842 - XY8E X/Y plotter control. -- M843 - CR8E card reader interface. There were many other internal options. There was room in the basic box for another 20 slot backplane; taking into account the 2 slots occupied by the M935 bridge between the two backplanes, this allowed 38 slots, and a second box could be added to accomodate another 38 slot backplane, bridged to the first box by a pair of BC08H OMNIBUS extension cables. Given a M837 memory extension control, additional memory could be added in increments of 4K by adding G104, H220, G227 triplets. The suggested arrangement of boards on the OMNIBUS always maintained the M849 shield between memory other options. The one exception was that the M8350 KA8E and M8360 KD8E external posibus interfaces were typically placed at the end of the OMNIBUS right before the terminator. The following options were introduced later, and there were many options offered by third party suppliers. -- G111 \ -- H212 > MM8EJ 8K memory -- G233 / -- M8357 -- RX8E interface to RX01/02 8" diskette drives. -- M7104 \ -- M7105 > RK8E RK05 Disk Interface -- M7106 / -- M8321 \ -- M8322 \ TM8E Magtape control for 9 track tape. -- M8323 / -- M8327 / At one point, DEC packaged a PDP-8/E in a desk with no front panel controls other than power and bootstrap switch, along with an RX01 accessable from the front and a VT50 on top. This was sold as the Class-ic system, with an intended market in the classroom (hence the name); it was the forerunner, in terms of packaging, of many later DEC office products. What is a PDP-8/F? Date of introduction: 1972. Date of withdrawal: 1978. Technology: an OMNIBUS machine, as with the PDP-8/E. First use of a switching power supply in the PDP-8 family. Reason for introduction: The PDP-8/E had a large enough box and a large enough power supply to accomodate a large configuration. By shortening the box and putting in a small switching power supply, a lower cost OMNIBUS machine was possible. Reason for withdrawal: The PDP-8/A 800 displaced this machine, providing similar expansion capability at a lower cost. Compatability: The PDP-8/F used the PDP-8/E CPU and peripherals. Standard configuration: Identical to the PDP-8/E, except that the KC8E front panel was replaced with a KC8M front panel that had LEDs instead of incandescent lights; this front panel could also be installed on PDP-8/E systems, but the PDP-8/E front panel could not be used on a PDP-8/F because of the lack of a +8 supply for the lights. The original PDP-8/F box had a defective power supply, but a revised (slightly larger) box corrected this problem. Expandability: This machine could be expanded using all PDP-8/E OMNIBUS peripherals, including the external expansion chassis. The relatively small internal power supply and the lack of room for a 20 slot bus expander inside the first box were the only limitations. There were minor compatability problems with some options, for example, the power-fail auto-restart card, as originally sold, was incompatable with the PDP-8/F power supply. What is a PDP-8/M? Date of introduction: 1972. Date of withdrawal: 1978. Technology: This machine was a PDP-8/F (with a PDP-8/E CPU) Reason for introduction: DEC knew that OEM customers were an important market, so they packaged the PDP-8/F for this market, with no hardware changes behind the front panel. Reason for withdrawal: Same as the PDP-8/F Compatability: The PDP-8/M used the PDP-8/E CPU and peripherals. Standard configuration: Identical to the PDP-8/F, except that the KC8M front panel was replaced with a minimal function panel and the color scheme was different. Because of this, one of the following options were required: -- M848 -- KP8E Power fail and auto-restart. -- M847 -- MI8E Hardware Bootstrap Loader. Expandability: All options applying to the PDP-8/F applied. In addition, the KC8M front panel (standard with the PDP-8/F) was available as an option. What is a PDP-8/A? Date of introduction: 1975 Date of withdrawal: 1984 Technology: This machine used the OMNIBUS with a new single-board CPU, made possible by the use of TTL MSI and LSI components on an extra-wide board (formally, hex high, double high) with 6 connector fingers instead of the usual 4. Reason for introduction: Using TTL MSI and LSI components, DEC was able to reduce the PDP-8 CPU to a single hex wide double high card. Similarly, they were able to make an 4K core memory card, and later, an 8K board in this format, and they were able to introduce a static RAM card using semiconductor memory. The net effect was to reduce the minimum system to 3 boards. In addition, the market for the PDP-8 was dominated by small systems, with fewer and fewer customers needing large-scale expandability. Thus, the 20 slot backplane of the early Omnibus machines was too big; with the new single board CPU and memory, a 12 slot backplane was enough. Reason for withdrawal: The market for the PDP-8 family was shrinking in the face of pressure from larger minicomputers and the new monolithic microcomputers. After 1975, many PDP-8 sales were to captive customers who had sufficient software investments that they could not afford to move. Only the word-processing and small business markets remained strong for first-time PDP-8 sales, and in these, the specialized DEC VT-78 and DECmate machines were more cost effective than the open architecture OMNIBUS machines. Compatability: The new PDP-8/A CPU was largely compatable with the PDP-8/E CPU, except that the combination of RTR and RTL (Group 1 OPR instructions) loaded the next address. The power-fail auto-restart option included the standard skip on power low instruction, but also a new skip on battery empty instruction to test the battery used for back-up power on the new solid state memory. Standard configuration: The PDP-8/A was sold with a new short OMNIBUS backplane, mounted on its side above a power supply and a battery to back up the solid state memory. The minimum configuration included a limited function control panel and the following components on the bus: -- M8315 -- KK8A CPU board -- M???? -- MS8A 1K to 4K solid state memory. -- M8316 -- DKC8AA serial/parallel interface and clock. The M8316 board contained a remarkable but useful hodgepodge of commonly used peripherals, including the console terminal interface, a parallel port, the power/fail auto-restart logic, and a 100 Hz real time clock. The original configuration sold had a 10 slot backplane and a poor power supply. The later base model had a 12 slot backplane, the 8/A 400. Expandability: All PDP-8/E peripherals and options could be used with the PDP-8/A. The KK8A cpu was not as fast as the KK8E used in the PDP-8/E, but the KK8E CPU could be substituted for the KK8A CPU, and many PDP-8/A systems were sold with this substitution. A box with a 20 slot backplane, the 8/A 800, was available for large configurations. A pair of PDP-8/A backplanes could be connected using BC08H cables, and there was a special cable, the BC80C, for connecting a hex wide 8A backplane to a PDP-8/E, -8/F or -8/M backplane. By late 1975, the PDP-8/A was being sold in a workstation configuration, with the CPU and dual 8" diskette drives in a desk with a video terminal (VT57?) on top. This followed the pattern set by the Class-ic packaging of the PDP-8/E, but it was aimed at the word-processing market. The following additional PDP-8/A (hex) boards were offered: -- G649 \_ MM8AA 8K Core stack (too slow for 8/E CPU!). -- H219A / MM8AA 8K Core memory control. -- G650 \_ MM8AB 16K Core stack (ok for 8/E CPU!). -- H219B / MM8AB 16K Core memory control. -- M???? -- MR8F 1K ROM (overlayable with RAM). -- M8317 -- KM8A memory extender (with variations). -- M8319 -- KL8A 4 channel RS232 or current loop serial I/O. -- M???? -- RL8A controller for 1 to 4 RL01/RL02 disk drives. -- M8416 -- KT8AA Memory management unit. -- KC8AA Programmer's Console (requires M8316) -- M8417 -- MSC8DJ 128K DRAM MOS Memory. Note that memory extension to 128K was a new PDP-8/A feature that was necessarily incompatable with the older PDP-8 memory expansion options, although the conventional PDP-8 memory expansion instructions still operate correctly on the first 32K. Access to additional fields involved borrowing IOT instructions that were previously dedicated to other devices. The MM8A options require the use of a box with a -20V power supply. Also, the use of the MSC8 DRAM memory cards requires a CPU that supports the memory stall signal, early PDP-8/E CPUs did not. What is a VT78? Date of introduction: 1978 Date of withdrawal: 1980 (Displaced by the DECmate) Also known as: DECstation 78 Technology: Intersil 6100 microprocessor, packaged in a VT52 case. The 6100 processor was able to run at 4 MHz, but in the VT78, it was only clocked at 2.2 MHz because of the speed of the DRAM used and the deliberate use of graded out chips. Reason for introduction: Using TTL MSI and LSI components, DEC could pack their CPU into vacant space in a standard terminal case, allowing PDP-8 systems to compete with personal computers in the small business and office automation market. This was a natural follow-on to the workstation configurations in which the PDP-8/A was already being sold. Compatability: The Group I OPR combinations RAL RAR and RTL RTR are no-ops. Unlike all earlier PDP-8 models, autoindex locations 10 to 17 (octal) only work in page zero mode; these operate like all other memory location when addressed in current page mode from code running on page zero. Other than this, it is fully PDP-8/E compatable, even at the level of I/O instructions for the standard periperals; this was the last PDP-8 to offer this level of compatability. It was not possible to continue from a halt without restarting the machine. In addition, none of the peripherals available on this machine needed DMA (data break) transfers. Standard configuration: The VT78 was sold with 16k words of DRAM with the keyboard and display of the VT52 terminal. An RX01 dual 8" diskette drive was standard, packaged in the pedestal under the terminal. The console (device 03/04), the printer (output only) port (device 66), and the serial ports (devices 30/31 and 32/33) are compatable with the M8650 KL8E, with the latter extended to allow software controlled baud rates selection. The parallel port (device 47) and 100Hz clock are compatable with the comparable PDP-8/A options on the M8316 DKC8AA. The standard ROM boots the system from the RX01 after setting the baud rates to match that selected by the switches on the bottom of the VT52 case. Expandability: This was a closed system, with few options. The base configuration was able to support two RX01 drives (later RX02), for a total of 4 transports. Various boot ROM's were available, including a paper-tape RIM loader ROM for loading diagnostics from tape. Another ROM boots the system from a PDP-11 server in the client/server configuration used by WPS-11. What is a DECmate I? Date of introduction: 1980 Date of withdrawal: 1984 (Phased out in favor of the DECmate II) Also known as: DECmate (prior to the DECmate II, no suffix was used) Technology: Based on the Intersil/Harris 6120 microprocessor, packaged in a VT-100 box with keyboard and display. Reason for introduction: This machine was aimed primarily at the market originally opened by the VT78, using the IM6120 as a substitute for the older 6100 chip and optimizing for minimum cost and mass production efficiency. Compatability: A new feature was introduced in the 6120 microprocessor: The Group I OPR combination RAL RAR was defined as R3L, or rotate accumulator 3 places left, so that byte swap (BSW) is equivalent to R3L;R3L. RTR RTL remained a no-op, as in the 6100. Also, the EAE operations not implemented in the basic CPU cause the CPU to hang awaiting completion of the operation by a coprocessor. Unfortunately, no EAE coprocessor was ever offered. The printer port offered software baud-rate selection compatable with the VT78 baud-rate selection scheme. The data communications option was completely incompatable with all previous PDP-8 serial ports. The console and printer ports are not fully compatable with the earlier PDP-8 serial ports. Specifically, on earlier serial interfaces, it was possible to test flags without resetting them, but on the DECmate machines, testing the keyboard input flag always resets the flag as a side effect. In addition, on the console port, every successful test of the flag must be followed by reading a character or the flag will never be set again. It was not possible to continue from a halt without restarting the machine. The large amount of device emulation performed by the CPU in supporting screen updates severely limits the ability of the system to run in real time. Standard configuration: The DECmate I was sold with 32k words of memory, with a small additional control memory added to handle control/status and boot options. The console terminal keyboard and display functions are largely supported by control memory routines (as opposed to having separate hardware for terminal support, as in the VT78). DECmate I came with an integral printer port, compatable with the VT78 (device 32/33), and it had an RX02 dual 8 inch diskette drive, mounted in the short cabinet under the terminal/CPU box. A 100Hz clock was included, as in the VT78 and PDP-8/A. Expandability: This was a closed system, with limited options. Specifically, a second RX02 could be connected (or an RX01, because that had a compatable connector), the DP278A and DP278B communications boards (really the same board, but the DP278B had 2 extra chips), and the RL-278 disk controller, able to accomodate from 1 to 4 RL02 rack mount disk drives. When the DP278A option is added, additional control memory is included containing a ROM-based terminal emulator allowing diskless operation. The emulator is an extended VT100 subset that is essentially compatable in 80 column mode. The DP278A option could support both asynchronous and synchronous protocols, and the DP278B could handle SDLC and other nasty bit-stuffing protocols. Various pedestal and desk configurations were sold for housing the RX01 and RX02 drives, most being teacart style designs, but there was also a pedestal version that was essentially a repackaging of the RX02 with either 2 or 4 new 8 inch disk transports (physically incompatable with tearlier DEC transports). What is a DECmate II? Date of introduction: 1982 Date of withdrawal: 1986 Price: $1,435 Technology: Based on the 6120 microprocessor, this shared the same packaging as DEC's other competitors in the PC market, the Rainbow (80x86 based) and the PRO-325 (PDP-11 based). Reason for introduction: This machine was introduced in order to allow more flexibility than the DECmate I and to allow more sharing of parts with the VT220 and DEC's other personal computers. Compatability: Same as the DECmate I, except it could continue from a halt. There was better hardware for device emulation support, allowing for somewhat better real-time performance, and the data communications port was an incompatable improvement on the incompatable DECmate I communications port. The improved data communications port make it essentially as powerful as the DP-278B on the DECmate I, with a more efficient but bizarre software interface. Standard Configuration: The DECmate II was sold with 32K of program memory, plus a second full bank for dedicated control panel functions, an integral RX50 dual 5 1/4 inch diskette drive with an 8051 controller chip, a printer port, a 100Hz real-time clock, single data communications port, and interfaces to the monitor and keyboard. The diskette drive can read single-sided 48 track-per-inch diskettes, so it might be possible to read (but not write) IBM PC diskettes. Expandability: This was the most open of the DECmate systems, with a number of disk options: An additional pair of RX50 drives could be added, and with the RX78 board, it could support a pair of dual 8 inch drives, either RX01 or RX02. As an alternative to the RX78, there was a controller for an MFM hard drive. The interface to the RX78 board wasn't fully compatable with earlier interfaces to RX01 and RX02, and there was no way to have both an RX78 and an MFM drive. The MFM drive could be up to 64 MB, with 16 sectors per track, 512 bytes each and at most 8 heads and 1024 (or possibly 4096) cylinders. A power supply upgrade was needed to support the MFM drive. DEC sold this machine with 5, 10 and 20 meg hard drives, Seagate ST-506, 412, and 225 respectively. A graphics board supporting a color monitor could be added in addition to the monochrome console display. A coprocessor board could be added, with communication to and from the coprocessor through device 14. DEC sold three boards, an APU board (Z80 and 64K), and two XPU boards (Z80, 8086 and either 256K or 512K). If these added processors are used, the 6120 processor is usually used as an I/O server for whatever ran on the coprocessor. The XPU boards used a Z80 for I/O support, so 8086 I/O was very indirect, particularly if it involved I/O to a PDP-8 device that was emulated from control memory! Despite this, I/O through the DECmate version of MS/DOS is generally faster than MS/DOS on more recent 80286 and 80386 based IBM PCs because of effective use of the coprocessors (but they couldn't run MS/DOS code that bypasses MS/DOS for I/O). What is a DECmate III? Date of introduction: 1984 Date of withdrawal: 1990 Price: $2,695 Technology: Same as the DECmate II. Reason for introduction: Again, DEC discovered that the market for large systems was dominated by other products, and that the PDP-8 based products were rarely expanded to their full potential. Thus, there was no point in paying the price of expandability. Compatability: Same as the DECmate II, except that the printer port is fixed at 4800 baud. Standard Configuration: The DECmate III was sold with 32K of program memory, plus a second full bank for dedicated control panel functions, an integral RX50 dual 5 1/4 inch diskette drive with an 8051 controller chip, a printer port, a 100Hz real-time-clock, a data communications port, and interfaces for the VR-201 monitor and keyboard. Expandability: A revised version of the Z80 based coprocessor for the DECmate II was available, and a graphics board compatable with the later DECmate II graphics board could be added allowing the standard monochrome monitor to be replaced with a VR-241 color monitor. Two monitor configurations were not supported. An obscure variant of the DEC scholar modem was also supported as an option. What is a DECmate III+? Date of introduction: 1985 Date of withdrawal: 1990 Technology: Same as the DECmate II. Reason for introduction: This machine apparently represents the last gasp of the PDP-8, hunting for the remains of the ever-shrinking market niche that the earlier DECmates had carved out. The market niche was not there, and the production runs for this machine were short enough that UV erasable EPROM technology was used where earlier DECmates had used mask programmed chips. Compatability: Same as the DECmate II, but the machine was unable to read 48 track per inch IBM formatted diskettes. Again the printer port was fixed at 4800 baud. Standard Configuration: The DECmate III+ was sold with 32K of program memory, plus a second bank for dedicated control panel functions, an integral RX33 single 5 1/4 inch diskette drive with an 8751 controller chip, a printer port, a data communications port and interfaces to the monitor and keyboard. A hard disk controller compatable with the optional one on the DECmate II was included, supporting an integral ST-225 20 MB disk; it is likely that it can only handle up to 1024 cylinders, but it is otherwise compatable with the DECmate II. Expandability: The same coprocessor option sold with the DECmate III was available, but because of the lack of a second floppy drive, this was rarely used (the Z80 was most likely to be used to run CP/M, but that system requires two drives to handle the installation procedure; an appropriately configured bootable image created on a DECmate II or III could run on a DECmate III+). The same graphics board as used on the DECmate III was also available. The circuit traces and connectors for the Scholar modem are present, but this option was never sold on the DECmate III+. From zrepachol@cc.curtin.edu.au Sat Dec 11 01:50:34 EST 1993 Article: 514 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!msuinfo!harbinger.cc.monash.edu.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8 emulator performance Date: 9 Dec 93 23:22:50 +0900 Organization: Curtin University of Technology Lines: 21 Message-ID: <1993Dec9.232250.1@cc.curtin.edu.au> References: <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> <1993Dec6.222226.11158@news.uiowa.edu> NNTP-Posting-Host: cc.curtin.edu.au In article <1993Dec6.222226.11158@news.uiowa.edu>, jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > From article <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de>, > by krause@azu.informatik.uni-stuttgart.de (krause): ... > In the permission letter I have from DEC to photocopy and distribute > technical documentation, they didn't cite specific documents, instead, > they gave something of a blanket permission to duplicate and distribute > old documentation, so long as I gave proper credit to DEC. The letter > was as ironclad in its definition of proper credit as it was loose in > specifying what I could copy. I hope someone can get similar permission > with regard to OS/8, but since my disk is not yet up, I haven't done this. About 1985 in the hardware doc catalogue, dec anounced that you where free to copy ANY hardware docs that where not in the catalogue, or not available. remember when you could get decent catalogues of what was available... ~Paul From meei@babbage.harvard.edu Sat Dec 11 01:52:53 EST 1993 Article: 515 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!bloom-beacon.mit.edu!noc.near.net!das-news.harvard.edu!babbage!meei From: meei@babbage.harvard.edu (David Allan Steffens) Subject: Re: PDP-8 emulator performance Message-ID: <1993Dec10.050222.776@das.harvard.edu> Sender: usenet@das.harvard.edu (Network News) Organization: Eaton-Peabody Laboratory, Mass. Eye&Ear Infirmary, Boston, MA References: <1993Dec1.193758.28225@news.uiowa.edu> <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> <1993Dec6.222226.11158@news.uiowa.edu> Date: Fri, 10 Dec 1993 05:02:22 GMT Lines: 104 In article <1993Dec1.193758.28225@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: 1> I've just done some benchmarking of my PDP-8 emulator... 1> ran in 60 seconds on my IBM RT running AOS... 1> On my Tadpole SPARCbook I..., the same output took about 22 seconds. 1> On a DECstation 3100 (ULTRIX MIPS), it took about 27 seconds... 1> On a prototype Alpha AXP..., it took well under 5 seconds. 1> ... 1> The benchmark we used was written in FOCAL... 1> *1.1 SET A=1 1> *1.2 TYPE A,! 1> *1.3 SET A=2*A 1> *1.4 GOTO 1.2 1> ... In article kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval) writes: 2> On a SparcCenter 1000 running Solaris 2.3,... about 5.5 seconds. In article <1993Dec6.155243.7651@ifi.informatik.uni-stuttgart.de> krause@azu.informatik.uni-stuttgart.de (krause) writes: 3> ... On my original 8/e this focal program runs in aproximately 2 seconds. 3> (I have a hp 2648-terminal with 9600 baud). ... In article <1993Dec6.222226.11158@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: 4> The Benchmark is I/O bound, and most of the instructions it is timing 4> are the instructions in the polling loop! You must use the same speed 4> I/O interface to make the benchmark into a fair comparison! ... Well, you know what they say about lies, d*mn lies, ... and BENCHMARKS! So let's look _carefully_ at this "benchmark" and determine _precisely_ what it is that we are measuring. Doug's analysis that the program is IO-bound is _not_ correct in all of the above cases. The "benchmark" must print about 600 characters. At 1200 baud (about 120 cps) this requires a _minimum_ of about 5 seconds wallclock time. Any processor that takes _more_ time than this to finish is _not_ IO-bound, and any _excess_ time over 5 seconds is directly attributable to computation. For the real PDP8/e with a 9600 baud terminal, the expected time to print 600 chars is about 0.6 second. Thus about 1.4 seconds of the time to run the "benchmark" is directly attributable to PDP8/e computational processing. Now I want to ask _why_ you want to benchmark the IO when you already _know_ how long that should take? Why not try a variation of your "benchmark", e.g. 01.10 set a=1; set n=0 01.20 set a=2*a; set n=n+1 01.30 if (a-5e37) 1.2 01.40 type n,a,! This "benchmark" only prints one line at the end and will be compute-bound on all processors. The number "5e37" was chosen since my version of FOCAL does not support the full exponent range of the original version. You may also need to change case and reformat slightly -- my version of FOCAL is much more forgiving in this regard than the original version. On a DEC uVAX II (Ultrix 1.1) and a Sun 4/260 (SunOS 4.1.3) I get: DAS.epl> time ufoc -x focal.pgm 126.0000 8.507059173e+37 0.150u 0.120s 0:00.72 37.5% 22+43k 1+1io 16pf+0w DAS.epl> sun time ufoc -x focal.pgm 126.0000 8.507059173e+37 0.030u 0.030s 0:00.06 100.0% 0+31k 0+0io 0pf+0w Of course the correct answer is: DAS.epl> bc 2^126 85070591730234615865843651857942052864 BTW, and in case you haven't already figured it out, _my_ sweepstakes entry is a FOCAL interpreter that runs native on UNIX ! I wrote this code back in 1983 as sort of a hack learning exercise under UNIX v7 on a PDP11/34 and later ported it to the DEC and Sun. It has been used for real scientific computation and simulation work in my lab and appears to be relatively "bug-free". The "ufoc" program is written in C and uses lex for token analysis and yacc for the parser. The user's FOCAL program is converted into an internal P-code representation for fast run-time interpretation. "Ufoc" supports full interactive program editing using a line-at-a-time editing style similar to the original FOCAL and the resulting programs can be saved to UNIX files and later retreived. "Ufoc" can also read/write UNIX standard IO and files, so a "ufoc" program can be executed as a component of a UNIX pipeline. A UNIX-style manpage describing "ufoc" is available on request by return email. A formatted version is also available for those without access to nroff. Please send all requests and other correspondence to: das%eplunix.uucp@harvard.harvard.edu The "ufoc" code is somewhat primitive by today's coding standards, and it needs some clean-up before I would feel comfortable releasing it. However, it should be relatively easy to port to Solaris 2.X. And I think that GNU's bison+flex could be substituted for yacc+lex without too much trouble. If there is sufficient interest, I might be persuaded to undertake the effort needed to get "ufoc" into shape for release. I'd probably want to copyleft the source, although I might want to reserve the right to charge a small shareware fee, especially if there appears to be some hot _commercial_ interest out there! :-) -- David Allan Steffens | I believe in learning from past mistakes... Eaton-Peabody Laboratory | but why does a good education require so many? Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114 eplunix!das@harvard.harvard.edu Tel (617) 573-3748 Fax (617) 720-4408 From john@mercury.cs.uregina.ca Sat Dec 11 01:53:04 EST 1993 Article: 516 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!corpgate!news.utdallas.edu!hermes.chpc.utexas.edu!cs.utexas.edu!howland.reston.ans.net!agate!ames!decwrl!decwrl!tribune.usask.ca!sue!mercury.cs.uregina.ca!john From: john@mercury.cs.uregina.ca (John Rosloot) Subject: Re: Need Unix/PDP help Sender: news@sue.cc.uregina.ca Message-ID: <1993Dec10.155558.1159985@sue.cc.uregina.ca> Date: Fri, 10 Dec 1993 15:55:58 GMT Organization: University of Regina Lines: 12 I posted yesterday about how my MicroPDP 11/73 said my 2.10 BSD Unix packs were 'non-bootable media'. I've already received an explanation of where my problem is originating (thanks, Steven :). Thanks to all who replied. Sorry if my original post was innappropriate to this particular newsgroup. ____________________________________________________________________________ | John Rosloot, Technician | BULLWINKLE: "You just leave that to my | | Department of Computer Science | pal. He's the brains of the | | University of Regina | outfit." | | Regina, Saskatchewan, Canada | GENERAL: "What does that make YOU?" | | john@cs.uregina.ca | BULLWINKLE: "What else? An executive..." | ---------------------------------------------------------------------------- From u9119523@sys.uea.ac.uk Sat Dec 11 01:53:26 EST 1993 Article: 517 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!pipex!uknet!doc.ic.ac.uk!news.sys.uea.ac.uk From: u9119523@sys.uea.ac.uk (Graham Cox) Subject: PDP-8 Emulation on Macintosh Message-ID: Followup-To: alt.sys.pdp8 Sender: news@sys.uea.ac.uk Organization: School of Information Systems, UEA, Norwich Date: Fri, 10 Dec 1993 18:04:29 GMT Lines: 13 I don't know if this will be of the slightest interest to anybody, but i have a rather simple-minded PDP-8 emulator (or really a simulator- it's pretty slow) which runs in a window on a Mac. I wrote it as a piece of coursework for my undergrad computer science course- it isn't useful for anything but you can watch it working, so it might be an interesting curiosity for you 8-ers out there. Nice interface and easy to use. Also includes built-in assembler, but no I/O support. Email me if you want it. -------------------------------------------------------------------------- Love & BSWK, Graham -Everyone is entitled to their opinion, no matter how wrong they may be... -------------------------------------------------------------------------- From jones@pyrite Sat Dec 11 01:54:04 EST 1993 Article: 518 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: PDP-8 emulator performance Sender: news@news.uiowa.edu (News) Message-ID: <1993Dec10.162219.4283@news.uiowa.edu> Date: Fri, 10 Dec 1993 16:22:19 GMT References: <1993Dec10.050222.776@das.harvard.edu> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 17 >From article <1993Dec10.050222.776@das.harvard.edu>, by meei@babbage.harvard.edu (David Allan Steffens): > Now I want to ask _why_ you want to benchmark the IO when you already _know_ > how long that should take? Because my emulator emulates I/O timing faithfully. That is, if you "jumper" the console port on the emulator to run at an emulated 1200 baud, then a PDP-8 program with a timing loop to measure how long the terminal is busy between outputs of, for example, null characters, will be unable to tell if it is running on an emulated PDP-8/E or a real one. My emulator faithfully measures all instruction and memory access times, to the clock cycle, and it emulates I/O latency with similar accuracy, but without any of the random clock jitter that might be present in a real system. Thus, the emulator is not as fast as it could be (because of overhead of accurate timing), but it will be difficult to write software which distinguishes between the emulator and the real CPU. From lasner@sunSITE.unc.edu Sat Dec 11 01:54:46 EST 1993 Article: 519 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Question re timesharing option behavior Date: 11 Dec 1993 06:08:58 GMT Organization: University of North Carolina, Chapel Hill Lines: 27 Message-ID: <2ebo5q$oie@samba.oit.unc.edu> References: <2dltud$2bv@sousa.ako.dec.com> <2e3rdp$oe2@samba.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Megan wrote: > >But keep in mind, the probability of executing an instruction without >an interrupt is hopefully much higher than executing one that is >interrupted. Therefore, if you process the instruction as if no >interruupt had occurred, that operation will be correct. If you then >process the interrupt (as if the interrupt HAD happened between >instructions), THAT operation should work correctly as well. > >As for the example (SKP HLT;HLT) which you posit, I was under the >impression (probably faulty) that the PC is incremented at the end of >an instruction. All this is irrelevant. The only uncertainty is reporting exactly *where* in memory a HLT occurred should it want to be reported at all. Assuming the user wants to continue from the halt, just dismiss the interrupt. The machine continues. The interrupt handler for the UINT has to determine why it's been enterred. OSR services will be handled normally according to some convention and the HLT part will either be continued or aborted/restarted from a designated starting address. In any case, the original issue was that the -8 design shouldn't be changed, whether emulated or real. There isn't enough concern for this nebulous point to bother. cjl From xb302@city.ac.uk Sat Dec 11 10:00:48 EST 1993 Article: 520 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!cs.city.ac.uk!city!xb302 From: xb302@city.ac.uk (VENESS J) Subject: PDP-8 CPU simulator Message-ID: <1993Dec11.005838.12083@city.ac.uk> Sender: news@city.ac.uk (Unix Network News) Nntp-Posting-Host: victoria Organization: The City University X-Newsreader: TIN [version 1.2 PL2] Date: Sat, 11 Dec 93 00:58:38 GMT Lines: 22 Somebody out there mailed me their PDP-8 simulator, in reply to one of my postings asking about the group 3 OPR instructions. I tried to get it running but it needs a header file. Unfortunately I deleted the mail headers, and can't remember who sent it! Can whoever it was please send the file pdp8_defs.h! Thanks. The top of the C file is: /* PDP-8 CPU simulator This routine is the main instruction decode routine for the PDP-8. It is called from the simulator control program to execute instructions in simulated memory, starting at the simulated PC. It runs until 'reason' is set non-zero. BTW, I checked the alt.sys.pdp8 archive on sunsite.unc.edu, but this only goes up to August. Pel -- _ John Veness |_)_ | _, _, _ johnv@dcs.rhbnc.ac.uk | (_'|(_|(_|(_) (_) From lasner@sunSITE.unc.edu Sat Dec 11 10:18:47 EST 1993 Article: 521 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Done interrupt on RX01/02/50 Date: 11 Dec 1993 15:18:40 GMT Organization: University of North Carolina, Chapel Hill Lines: 29 Message-ID: <2ecocg$d1l@samba.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu Just a few words on a subject some others touched on: The DONE interrupt on the RX interface means that the current function is complete, regardless of what that function is. Reading or writing are actually two-step processes. The physical I/O phase of course needs an interrupt when it completes. No one need be lectured on the concept of interrupts. But the other half of the process always involves data shoveling based on the non-interrupting transfer flag skip, yet done comes up at the end of the operation anyway. Since the code has to do the shoveling anyway, getting an interrupt at the end of the data is extraneous, although lazy code can use the done interrupt instead of counting the data. On the RX01, there is one possible error, a parity error in the interface, but that raises the ERROR flag, not necessarily the DONE flag, so it's otherwise impossible to find any status to worry over when the DONE flag raises after all the TRANSFER skips have been processed. Note that the transfers wouldn't have even initiated unless grosser problems had already been addressed long before the transfer even started, etc. Thus, a DONE flag interrupt handler just goes through the motions and finds no errors, and is dismissed. You have the nuisance value of stating that you are in a shoveling phase, neither idle nor awaiting I/O completion, when that occurs. Were there no DONE interrupt in shoveling, the interrupt handler could be slightly simplified. Also, note that the speed of shoveling is potentially fast enough to warrant foreground processing, but not so fast that you want it to occur in an interrupt handler while interrupts are off. Alternatively, it's part of background processing and the DONE interrupt then becomes the switch to turn off the shoveling process. Either way, the shoveling process needs to be interruptible to not hog the machine; the physical I/O wait for read or write can be handled by conventional means like any other disk device, etc. cjl From lasner@sunSITE.unc.edu Sun Dec 12 20:05:53 EST 1993 Article: 522 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP 8 emulator standards Date: 12 Dec 1993 23:48:02 GMT Organization: University of North Carolina, Chapel Hill Lines: 78 Message-ID: <2egaji$5ui@samba.oit.unc.edu> References: <1993Nov29.043300.27275@news.uiowa.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article <1993Nov29.043300.27275@news.uiowa.edu>, wrote: >With the number of "full function" emulators being developed, I wonder if >we ought to try to agree on some standards. I'm all for that! > >1) A proposed standard for the core image file, saved on emulator > shutdown and loaded on startup: I am using Lasner's IPL file > format, with the added rule that line 1 of the file may begin > with the characters #!, followed by the absolute path name of > the emulator (thus allowing the system to be named and run by > the name of its core image file under UNIX). Got a problem with that one. The data characters of the .IPL format are 041 through 140 or ! through `. The file format starts with leader outside that range thus lower-case comments are allowed. Codes 000-040 are always ignored so that nul's and space characters can always be added, etc. By starting with #!, you are stating there is no leader, and that these two are the first data word for loading into location 0000. Usually a path name would be lower-case, thus a trailer situation ensues, and the loading is terminated. Remember, the IPL format was designed to allow a minimal loader for the real PDP-8 using printable characters to avoid binary problems. By ignoring spaces, nul's, CR, LF, etc. it allows the files to be "friendly" to virtually any system. Your suggestion undermines this. So, I suggest you use your format as an appendage to be removed from a "real" IPL file. > > Lasner's IPL format allows comments, and a nice standard use > for these comments would be to indicate what devices the core > image expects to be supported by its emulator. The leader must be lower-case. The first character in the character set from ! through ` is the first data character. The next time a lower-case character is seen means that the trailer has occurred. At that point, anything could be added. In Kermit-12 release files, there are lower-case comments at the beginning and mixed-case comments at the end. >3) A proposed standard for representing RX01 diskettes emulated on a > host system. I'm using C streams for this, with random access to > 128 byte blocks of the stream representing sectors of the disk. > Sector zero of the stream is reserved. The first 4 bytes of the > file must be rx01. I haven't started to deal with any uses for > other bytes, but the following suggest themselves: > > 1) an indication of how the disk is formatted -- specifically, how > are the sectors interleaved. The actual address of the sector > in the file is computed by adding the sector number to the track > number times the number of sectors per track, but access latency > depends on the interleave factor. RX01 disks are *never* interleaved. The software requests the sectors in an appropriately interleaved order. Not a concern of an emulator, other than to make good access to the sectors when referenced in a mapped manner that's implicitly mapped 2:1 expressly, possibly augmented by a stagger factor (usually 6). > > 2) a bit table of which sectors are "deleted". This feature of the > RX01 is one I don't intend to support, but I suppose we should > reserve space for the table anyway. Does it even fit in 128 > bytes? Is it worth supporting? In theory, any and all sectors could be marked as deleted. The returned status during a read would show this if appropriate. Thus you need enough bits to represent 77 x 26 sectors' deletion status. There is no reason not to support the feature; you just support the function to write a deleted-data segment so that it reads back correctly with the status set. Only incidentally more complicated than the read/write basic requirement, and needed to pass the diagnostics! cjl From lasner@sunSITE.unc.edu Sun Dec 12 20:06:32 EST 1993 Article: 523 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: RX01 Date: 13 Dec 1993 00:13:12 GMT Organization: University of North Carolina, Chapel Hill Lines: 48 Message-ID: <2egc2o$795@samba.oit.unc.edu> References: <1993Nov29.040954.26934@news.uiowa.edu> <1993Nov28.223758.13904@crash> NNTP-Posting-Host: calypso.oit.unc.edu In article <1993Nov28.223758.13904@crash>, Jeff Makey wrote: >In article <1993Nov29.040954.26934@news.uiowa.edu>, wrote: >>The interrupt at the >>end of the transfer of a sector between the RX01 interface and main memory >>seems to be a really useless feature > >If you are writing to the disk, such an interrupt would tell you when >the memory is available for some other use. If you are in a hurry, >this sure beats waiting until the real I/O is done. If you are >reading from the disk, it just tells you when your data is available. Thank you for your comments on interrupts 101 :-). However, the interrupt Doug is complaining about comes about only at the synchronous point where the last data word or byte is transferred. It is caused by an instruction, not an asynchronous operation that independently completed. There is no overlapped operation whatsoever as in normal interrupts. For example, if you want to read an RX01 sector, you first start a read operation of that sector into the silo buffer. For such an operation, an interrupt at the done point makes good sense since you can go do something else until interrupted. However, at the point of the read-done interrupt, you now have to start a new operation called empty-silo. This is a protocol where the transfer flag will raise exactly 128 times to transfer a byte (or 64 times to transfer a word if a 12-bit variant empty operation) at the somewhat annoying rate of several dozen microseconds per data value, and the transfer flag does *not* cause an interrupt! This operation is essentially a foreground task enterred as either the result after a read or inversely a silo-load preceding a write. It takes too long to be the chore of an interrupt handler, and makes no sense that way if part of a write since it then precedes the interrupt. When the last transfer is performed, the done flag also raises, thus the last IOT to accomplish the last transfer no longer raises any additional transfer flags (remember, they cause a skip only, not an interrupt!) but does cause that done flag raise that will interrupt if so enabled. The time between the last XDR instruction and the done flag raise (meaning that SDN could now skip and a done interrupt if enabled will occur) is just a handful of microseconds. Thus, there is no point to that interrupt, since there's no processing to overlap with. Lazy software could use the done flag event to terminate the data shoveling, but better software should count the data! Note that non-interrupt boot, etc. code uses a so-called "figure-8" loop where the transfer and done flag are both serviced as polled. If transfer comes up then transfer a word with XDR. If done comes up then go on to some new operation, etc. This avoids the need to count, but it's still part of "cross your fingers" boot coding, etc. cj (Maybe I should teach Interrupts 102 :-)) l From lasner@sunSITE.unc.edu Sun Dec 12 20:06:49 EST 1993 Article: 524 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: RX01 Date: 13 Dec 1993 00:21:45 GMT Organization: University of North Carolina, Chapel Hill Lines: 27 Message-ID: <2egcip$7h7@samba.oit.unc.edu> References: <1993Nov29.040954.26934@news.uiowa.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Greg Ewing wrote: >In article <1993Nov29.040954.26934@news.uiowa.edu>, jones@cs.uiowa.edu writes: >|> The interrupt at the >|> end of the transfer of a sector between the RX01 interface and main memory >|> seems to be a really useless feature > >Not if you want to overlap processing with I/O. You start a >transfer, then go away and do something else. The interrupt >lets you know when the transfer is complete. Wrong. The interrupt occurs in less time than the overhead of handling the interrupt takes to accomplish! There is nothing to overlap with since the done interrupt occurs a handful of microseconds after you finish the last data transfer from the operation. Remember, on the RX interface (and even on the RX11) the data is transferred onesies, not DMA. That happens 127 times, then on the 128th one you have been waiting for STR to skip on, you do the last XDR and immediately there is a done interrupt that buys you nothing but overhead. IF DMA had been doing the transfer, then there is something to overlap with, but you are an unwilling participant in each and every data transfer! cjl From lasner@sunSITE.unc.edu Sun Dec 12 20:07:06 EST 1993 Article: 525 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Group 3 OPR instructions Date: 13 Dec 1993 01:04:23 GMT Organization: University of North Carolina, Chapel Hill Lines: 42 Message-ID: <2egf2n$97s@samba.oit.unc.edu> References: <2dgek0$mpg@sol.ctr.columbia.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Megan wrote: > >This is what I understand so far. It is 'mode A' operation. Apparently >mode B operation changes where the shift count for some operations come >from. I think it means that the contents of PC+1 is the address of >the location from which you get the count. Not quite right. In Mode A, the next word is the count-1, thus SHL;0 does one shift. In Mode B, the next word is the exact count, thus SHL;0 is a NOP. All counts are always the same for all count-type iunstructions. In Mode A, the arg for the MUY or DVI follows in-line. In Mode B, a pointer to the arg follows, and the DF thus matters. In fact, if the MUY instruction is placed into location 0007-0016, the Mode B version auto-indexs! > >This also means that there are additional instructions (SWAB - switch >mode from A to B, and SWBA - switch mode from B to A). Yes. SWAB is a hack - it avoids a bug of all prior EAE implementations: If the AC or MQ is non-zero, then CLA [MQL if necessary] NMI hangs the hardware up in an infinite loop. This is because the special-case check for NMI-not-necessary is done before the check for AC,MQ will become 0000,0000. To substantially avoid this, SWAB is actually CLA NMI! > >There are also some double precision instructions, but I have yet >to read up on them (the rest of the above was from memory). Double-add, store, increment, check-if-zero, clear-and-store-zero,complement are all present. The ones that need address operands take the pointer from the next word. There is an instruction (SAM) to subtract the AC from the MQ and store the result's status into the "greater-than" flag. Note that 6006 is skip on the GTF set, and it's part of the get-flags/restore-flags sequence. Also, in Mode B, the low-order bit isn't lost on a right shift; it winds up in the GTF. cjl From mbg@world.std.com Mon Dec 13 17:21:04 EST 1993 Article: 526 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!decwrl!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Question re timesharing option behavior Message-ID: Keywords: timesharing, violation Organization: The World Public Access UNIX, Brookline, MA References: <2dltud$2bv@sousa.ako.dec.com> Date: Sun, 12 Dec 1993 06:18:02 GMT Lines: 49 supnik@human.enet.dec.com (Bob Supnik) writes: >On a PDP-8 with the timesharing option installed, and user flag = 1: >1. When an IOT is decoded, an interrupt occurs. Does the saved PC in > location 0 point at the IOT, or the next instruction? >2. When an OSR or HLT is decoded, an interrupt occurs. > a) Does the saved PC in location 0 point at the operate, or the > next instruction? > b) Are the other parts of the operate (including the skips) executed > or nop'd? I think I found the answer. According to the manual I have, the PC is incremented after an instruction is read from memory. More specifically, it is incremented (on a pdp-8/e) during time state 1 (ts1) of the fetch cycle, apparently before the instruction has actually been fetched because it uses a secondary internal register (cpma) to point to the address to read. Also according to the book I have, the interrupt request line is polled during ts4 of every memory cycle in which execution of an instruction occurred. During ts4 of every machine cycle: (note: yes falls through) 1) about to enter fetch? n) finish current instruction 2) is interrupt system on? n) begin next instruction 3) is interrupt request line asserted? n) begin next instruction 4) set ir = 4 5) set cpma = 0 6) enable execute state 7) processor turns interrupt system off and executes jms 0 instruction Basic instructions have up to three states (fetch, defer and execute, each with 4 time states), IOT and operate instructions have only one state (fetch, also with 4 time states). Since the PC is incremented at the start of fetch, and the interrupt request line is polled at the end of each state (fetch/defer/execute), I would say that the contents of location 0 during an interrupt would point to the instruction following the IOT/OPR. Megan Gentry Former RT-11 Developer From lasner@sunSITE.unc.edu Mon Dec 13 17:39:59 EST 1993 Article: 527 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Question re timesharing option behavior Date: 13 Dec 1993 22:39:28 GMT Organization: University of North Carolina, Chapel Hill Lines: 108 Message-ID: <2eiqv0$qml@samba.oit.unc.edu> References: <2dltud$2bv@sousa.ako.dec.com> NNTP-Posting-Host: calypso.oit.unc.edu Keywords: timesharing, violation In article , Megan wrote: >supnik@human.enet.dec.com (Bob Supnik) writes: > >>On a PDP-8 with the timesharing option installed, and user flag = 1: **** AND interrupts are enabled! **** > >>1. When an IOT is decoded, an interrupt occurs. Does the saved PC in >> location 0 point at the IOT, or the next instruction? The IOT action is inhibited, thus it can't skip, so it points to the next. > >>2. When an OSR or HLT is decoded, an interrupt occurs. >> a) Does the saved PC in location 0 point at the operate, or the >> next instruction? Always the next, unless a skip occurred in which the one following that. >> b) Are the other parts of the operate (including the skips) executed >> or nop'd? All else works regardless, and thus might skip if appropriate. > >I think I found the answer. According to the manual I have, the PC >is incremented after an instruction is read from memory. More >specifically, it is incremented (on a pdp-8/e) during time state 1 >(ts1) of the fetch cycle, apparently before the instruction has >actually been fetched because it uses a secondary internal register >(cpma) to point to the address to read. Correct. The PC is always (at least) incremented to point to the next. If a JMP of SKP happens, then it will change, but not yet at the earlier phase of an instruction, etc. > >Also according to the book I have, the interrupt request line is >polled during ts4 of every memory cycle in which execution of an >instruction occurred. Correct. Keyword here is EXECUTE. > >During ts4 of every machine cycle: >(note: yes falls through) > > 1) about to enter fetch? > n) finish current instruction Correct. Instructions, once started - will finish! > 2) is interrupt system on? > n) begin next instruction Correct. No interrupts unless enabled. (Also not default!) > 3) is interrupt request line asserted? > n) begin next instruction Yes, an interrupt can be acknowledged. > 4) set ir = 4 Yes, fake JMS. > 5) set cpma = 0 Yes, fake JMS 00000. > 6) enable execute state Needed to allow extended memory considerations to finish as well! > 7) processor turns interrupt system off > and executes jms 0 instruction Correct. Interrupt routines start in 00001, and are themselves interrupt- immune! > >Basic instructions have up to three states (fetch, defer and execute, >each with 4 time states), IOT and operate instructions have only one >state (fetch, also with 4 time states). Since the PC is incremented at >the start of fetch, and the interrupt request line is polled at the end >of each state (fetch/defer/execute), I would say that the contents of Wrong, only on EXECUTE. A started instruction always finishs. That's why they talk about interrupt latency for long EAE instructions! >location 0 during an interrupt would point to the instruction following >the IOT/OPR. In the sense you ask, yes, but still not correct. The instruction could be SPA CLA HLT. If HLT follows it, is the PC updated because the SPA made it skip? You can't tell since the AC is now cleared. However, all this means is you have to look at the last two instructions to figure it out. The worst thing is that you could misinform about exactly where the HLT occurred, or in some bizarre case, fail to update the OSR information. But certainly, it never points to the trapped instruction, only to after it. The question is how far. > > Megan Gentry > Former RT-11 Developer cjl (Current P?S/8 Developer) From greg@huia.canterbury.ac.nz Tue Dec 14 12:12:32 EST 1993 Article: 528 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!usc!cs.utexas.edu!uwm.edu!news.doit.wisc.edu!decwrl!waikato!canterbury.ac.nz!huia!greg From: greg@huia.canterbury.ac.nz (Greg Ewing) Subject: Re: Question re timesharing option behavior Message-ID: Nntp-Posting-Host: huia.canterbury.ac.nz Reply-To: greg@huia.canterbury.ac.nz (Greg Ewing) Organization: University of Canterbury, Christchurch, New Zealand References: <2dltud$2bv@sousa.ako.dec.com> <1993Dec3.151104.4550@news.uiowa.edu> <2e3rdp$oe2@samba.oit.unc.edu> Date: Mon, 13 Dec 1993 01:37:48 GMT Lines: 26 In article , mbg@world.std.com (Megan) writes: |> Therefore, if you process the instruction as if no |> interruupt had occurred, that operation will be correct. That's true for externally-generated interrupts, but this discussion is about traps which occur as a result of encountering a "privileged" instruction while in "non-privileged" mode. In that case, the exact behaviour of the hardware must be replicated, because software depends on it. >From what's been said, it seems that the correct behaviour is *not* to execute the trapped instruction (that's the point of trapping it, after all), with the return address equal to the address of the trapped instruction plus one. The latter is important because the trap handler may want to find the instruction that caused the trap, so it can decide what action to take. I've used the word "trap" instead of "interrupt" to make it clearer that we are talking about a synchronous rather than an asynchronous event. |> Megan Gentry - Greg From u9119523@sys.uea.ac.uk Tue Dec 14 12:12:52 EST 1993 Article: 529 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!doc.ic.ac.uk!news.sys.uea.ac.uk From: u9119523@sys.uea.ac.uk (Graham Cox) Subject: Re: PDP-8 Emulation on Macintosh Message-ID: Followup-To: alt.sys.pdp8 Sender: news@sys.uea.ac.uk Organization: School of Information Systems, UEA, Norwich References: Date: Mon, 13 Dec 1993 14:43:53 GMT Lines: 21 In article , u9119523@sys.uea.ac.uk (Graham Cox) wrote: > I don't know if this will be of the slightest interest to anybody, but i > have a rather simple-minded PDP-8 emulator (or really a simulator- it's > pretty slow) which runs in a window on a Mac. I wrote it as a piece of > coursework for my undergrad computer science course- it isn't useful for > anything but you can watch it working, so it might be an interesting > curiosity for you 8-ers out there. Nice interface and easy to use. Also > includes built-in assembler, but no I/O support. Email me if you want it. OK, there does seem to be small demand out there- but too large to email it to everyone concerned individually, so I'll upload the software somewhere so you can FTP it. Does anyone have any suggestions as to where would be a good place? -------------------------------------------------------------------------- Love & BSWK, Graham -Everyone is entitled to their opinion, no matter how wrong they may be... -------------------------------------------------------------------------- From lasner@sunSITE.unc.edu Tue Dec 14 12:16:30 EST 1993 Article: 530 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Question re timesharing option behavior Date: 14 Dec 1993 16:09:00 GMT Organization: University of North Carolina, Chapel Hill Lines: 95 Message-ID: <2ekoes$444@samba.oit.unc.edu> References: <2dltud$2bv@sousa.ako.dec.com> <2e3rdp$oe2@samba.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu In article , Greg Ewing wrote: >In article , mbg@world.std.com (Megan) writes: >|> Therefore, if you process the instruction as if no >|> interruupt had occurred, that operation will be correct. > >That's true for externally-generated interrupts, but this discussion >is about traps which occur as a result of encountering a "privileged" >instruction while in "non-privileged" mode. In that case, the >exact behaviour of the hardware must be replicated, because >software depends on it. Exactly correct. This is not a discussion on the need to maintain "transparency" through the course of normal interrupts. That applies in any and all interrupt-driven code. This is a discussion of the specifics of user mode as implemented with the time-share trap hardware. > >From what's been said, it seems that the correct behaviour is >*not* to execute the trapped instruction (that's the point of trapping >it, after all), with the return address equal to the address of >the trapped instruction plus one. Correct. All the software written expects the interrupted PC to have already been updated. There is no valid discussion regarding "correcting" it since that's an officially recognized and expected behavior. A few rounds ago I first joined in with "if it ain't broke, don't fix it". > >The latter is important because the trap handler may want to find >the instruction that caused the trap, so it can decide what action >to take. Correct. The classic example is where the execution of standard IOT's relative to the normal 03/04 console can be faked out to respond to the actual hardware status of the user's console on a TSS8 system where the user's hardware isn't 03/04 at all, but rather a channel of a DC02 or whatever. This satisfies compatibility with stand-alone software run on the time-sharing system, etc. However, there is an actual problem, although somewhat contrived. The first half of the problem has to do with disposition of a HLT operation. In the case of something like SKP HLT;HLT, it's not precisely possible to indicate the last executed instruction, since a JMP to the HLT could have occurred. A similar situation exists where the first could be something like SPA CLA HLT. This is because the CLA has obliterated the means to be certain of whether the following HLT was/wasn't skipped. In any case, the only consequence of any of this is the imprecise statement of last instruction executed, and a copout is possible: just merely display the restart address. That info is always correct for all scenarios of this type. The second half is more serious. Should OSR be included in what might have executed, you could be misled into improper handling of it. For example, it's not possible to determine whether or not to emulate the switch register if the sequence SPA CLA OSR HLT;HLT is given because the HLT could've been JMP'ed to instead of skipped over by the successful skip operation because the AC was positive before execution. The CLA makes the AC clear so you can't tell if perhaps the AC was actually negative and the HLT wasn't actually skipped. Of course if the AC is non-zero, you do know that the HLT *was* JMP'ed to, etc. IMO, anyone who uses these "trick" sequences gets what they deserve. There really isn't much call for conditionally skipping over an OSR operation, and in an emulator or time-shared version, it isn't necessary to placate such nonsense anyway. So, in summary: Time-share trap systems cannot report the last executed instruction under some circumstances, but can always restart after a HLT correctly. This behavior is incidentally shared by the DECmates other than DM I. Trick sequences involving OSR in combination with conditional skips in combination with CLA in combination with an adjacent trappable instruction should ignore the OSR or complain about it as a "violation" of the time-share environment. The significence of this tempest-in-a-teapot is so slight that no attempt should be made to "correct" it. > >I've used the word "trap" instead of "interrupt" to make it clearer >that we are talking about a synchronous rather than an asynchronous >event. Correct. There is no place in this discussion for anything remotely to do with conventional interrupt handling. The user interrupt is a trap that immediately causes entry into the UINT handler; all other interrupts are only entered when the external devices are acknowledged between instructions. > >|> Megan Gentry > >- Greg cjl From mbg@world.std.com Wed Dec 15 09:58:34 EST 1993 Article: 531 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!corpgate!news.utdallas.edu!hermes.chpc.utexas.edu!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Question re timesharing option behavior Message-ID: Keywords: timesharing, violation Organization: The World Public Access UNIX, Brookline, MA References: <2dltud$2bv@sousa.ako.dec.com> <2eiqv0$qml@samba.oit.unc.edu> Date: Tue, 14 Dec 1993 01:26:58 GMT Lines: 19 lasner@sunSITE.unc.edu (Charles Lasner) writes: >>Basic instructions have up to three states (fetch, defer and execute, >>each with 4 time states), IOT and operate instructions have only one >>state (fetch, also with 4 time states). Since the PC is incremented at >>the start of fetch, and the interrupt request line is polled at the end >>of each state (fetch/defer/execute), I would say that the contents of >Wrong, only on EXECUTE. A started instruction always finishs. That's why >they talk about interrupt latency for long EAE instructions! Right, I had meant to get that across, but failed. I meant to say that if the instruction is an OPR or IOT instruction, the check mentioned in my previous mail occurs at the end of the fetch cycle. If it is a basic instruction, the check would occur at the end of the execute cycle. At least this is how I understand it. The key being "in the cycle in which an instruction is executed". Megan Gentry From krause@azu.informatik.uni-stuttgart.de Wed Dec 15 11:30:23 EST 1993 Article: 532 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.lang.focal Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news From: krause@azu.informatik.uni-stuttgart.de (krause) Subject: Re: PDP-8 emulator performance Message-ID: <1993Dec14.080531.12903@ifi.informatik.uni-stuttgart.de> Sender: news@informatik.uni-stuttgart.de Organization: Informatik, Uni Stuttgart, Germany References: <1993Dec10.050222.776@das.harvard.edu> <1993Dec10.162219.4283@news.uiowa.edu> Date: Tue, 14 Dec 1993 08:05:31 GMT Lines: 191 In article <1993Dec10.162219.4283@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >From article <1993Dec10.050222.776@das.harvard.edu>, >by meei@babbage.harvard.edu (David Allan Steffens): > >> Now I want to ask _why_ you want to benchmark the IO when you already _know_ >> how long that should take? > >Because my emulator emulates I/O timing faithfully. That is, if you "jumper" >the console port on the emulator to run at an emulated 1200 baud, then a >PDP-8 program with a timing loop to measure how long the terminal is busy >between outputs of, for example, null characters, will be unable to tell if >it is running on an emulated PDP-8/E or a real one. My emulator faithfully >measures all instruction and memory access times, to the clock cycle, and it >emulates I/O latency with similar accuracy, but without any of the random >clock jitter that might be present in a real system. Thus, the emulator >is not as fast as it could be (because of overhead of accurate timing), but >it will be difficult to write software which distinguishes between the >emulator and the real CPU. This is another approach to an emulator. My intention was primarily a little bit other: I said to the guys who are writing the emulator: 1. Compatibility: All paper tape software (.BN-files) have to tun without patches, so the M6850 (KL8-8) instructions are to be emulated bit by bit, including inter- rupt behaviour. OS/8 must be bootable from an octal-dump of my SYS: (RK8E + RK05) with the instructions: 0030 6743 0031 5031 I want then to compile a 180K-Fortran IV programm and run the KERMITs from CJL and JBQ. 2. Speed: Make it as fast as ever possible. The result is, that the programm is fully written in assembler. There is a table with 4096 entries and a pdp8 instruction is taken as offset to this table. An instruction fetch takes 3 machine instructions. These three instructions are part of every emulated pdp8 instruction. So a CLA IAC RTL consists of 4 machine instructions (all pdp8 registers are held in 80x86 registers). If required for compatibility reasons, it is naturally possible to slow down the emulated M6850 to 1200 bauds. But what would Doug Jones' compatibility test say on a machine like mine, where the M6850 is strapped to 9600 baud? For measuring execution speed of single machine instructions I wrote a little programm. It consists of two nested loops, with 2500 and 4000 repetitions, so that the inner loop is executed 10 000 000 times. The instructions to be tested are between labels LOOP2 and RETURN. If there is nothing between them, you get the time for the basic looping overhead. I then filled in one or two instruction (i.e. removed one comment / at a time and stopped the time now). The difference between the empty loop and the one - or two instruction loop divided by ten is the time in microseconds for each instruction. For those who are not familiar with PAL8-assembler: If you make an off-page memory reference, then PAL8 makes automatically an indirect access and deposes a litteral with the off-page address at the end of the current page. Also zero-page accesses are made automatically without explicit indication by the programmer. *0017 PAL8-VB0 10-DEC-93 PAGE 1 0017 *0017 000017 0000 AUTOX, 0 0160 *160 000160 0000 ZPAGE, 0 / / / 1000 *1000 / HLT 001000 7200 CLA DECIMAL 001001 1377 TAD (-2500 001002 3220 DCA CNT1 LOOP1, 001003 7200 CLA 001004 1376 TAD (-4000 001005 3221 DCA CNT2 OCTAL LOOP2, 001006 7000 / NOP /EXACTLY ONE OF THESE INSTRUCTIONS / / IS NOT COMMENTED OUT (EXCEPT B0.BN) / / TAD CPAGE /CURRENT PAGE / / TAD ZPAGE /ZERO PAGE / / TAD OPAGE /OTHER PAGE / / TAD I AUTOX /AUTOINDEX / / DCA CPAGE /CURRENT PAGE / / DCA OPAGE /OTHER PAGE / / CLA CMA IAC / / JMS CSRT /SUBROUTINE CURRENT PAGE / / JMS OSRT /SUBROUT. OTHER PAGE / / JMP CDEST /JMP CURRENT PAGE / / JMP ODEST /JMP OTHER PAGE / RETURN, 001007 2221 ISZ CNT2 001010 5206 JMP LOOP2 001011 2220 ISZ CNT1 001012 5203 JMP LOOP1 / HLT 001013 5775' JMP 7600 / 001014 0000 CPAGE, 0 001015 0000 CSRT, 0 001016 5615 JMP I CSRT 001017 5207 CDEST, JMP RETURN 001020 0000 CNT1, 0 001021 0000 CNT2, 0 / 001175 7600 001176 0140 001177 3074 1200 *1200 001200 0000 OPAGE, 0 001201 0000 OSRT, 0 001202 5601 JMP I OSRT 001203 5777' ODEST, JMP RETURN / 001377 1007 $ Here is a table with execution times: 386 386 486 486 pdp8/e 25Mc 40Mc 33Mc 50Mc _____________________________________________________ B0.BN empty 38.4 37.6 24.0 12.8 7.7 B1.BN NOP 50.4 47.3 30.7 16.5 9.7 1.2us .37us .2us B2.BN TAD CP 64.4 56.1 35.7 19.1 11.5 2.6us .63us .38us B3.BN TAD ZP 64.3 53.6 34.35 18.6 - 2.6us .58us B4.BN TAD OP 76.3 63.7 40.3 21.6 12.9 3.8us .88us 0.52us B5.BN TAD AIX 78.4 63.82 40.72 25.5 - 4.0us 1.27us B6.BN DCA CP 64.0 57.1 34.26 18.6 - 2.6us .58us B7.BN DCA OP 76.4 60.9 39.03 20.7 12.8 3.8us .79us .51us B8.BN CLA ... 50.4 50.7 31.79 17.4 9.9 1.2us .46us .22us >From here two Instructions, one JMx and an adequate return: B9.BN JMS CP 88.3 82.7 53.5 27.1 - 5.0us 1.42us B10.BN JMS OP 100.5 90.5 58.6 29.4 - 6.2us 1.66us B11.BN JMP CP 62.5 71.8 47.16 32.19 - 2.4us 1.94us B12.BN JMP OP 86.4 87.1 56.6 28.6 - 4.8us 1.58us Please no discussion about percents and hundreds of micro- seconds. I took the times with my wrist watch, and there may by some translation errors, but the tendency is clear: The emulator on a '386 with 25 Mc has approximately the same speed as a pdp8/e, and the '486 with eiza bus is a little bit more than three times faster as the original. Another item is the speed of the RK05. I couldn't test this till now, but as soon as it is possible I'll post this too. If the emulator runs stable, I'll make it available to the public. Klemens Krause National Centre for Minimal- and Retro- computing Stuttgart / Germany From mbg@world.std.com Wed Dec 15 11:31:18 EST 1993 Article: 533 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!decwrl!world!mbg From: mbg@world.std.com (Megan) Subject: Re: Upgrade a PDP11/03 ? Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2el188INNva2@rs18.hrz.th-darmstadt.de> Date: Wed, 15 Dec 1993 00:50:08 GMT Lines: 24 wosch@rbg.informatik.th-darmstadt.de (Olav Woelfelschneider) writes: >I've a PDP11/03-processor jumpered to use 60kRAM, together with a RLV11, >two RL01 5meg disk-drives and four serial ports (don't now the board name now). >It's a huge refrigerator sized box, and I wonder if I could run something >better on it than RT11? Is there a c-compiler for RT11, or am I doomed to >use FORTRAN, BASIC-11 or even assembly-language? Has anyone a description >of the assembly commands and the processor structure anyhow? You can obtain from DECUS (Digital Equipment Computer User's Society) a copy of DECUS-C, which runs on RT-11/RSX/RSTS. Sources are provided in case you want to fix something. >Thank you....It feels strange switching on such an old >dinosaur....Greetings from Jurassic Park ... (: In a notesfile I read regularly, we refer to them as 'Jurassic Parts' :-) Megan Gentry Former RT-11 Developer p.s. You might want to take further pdp-11 questions to vmsnet.pdp-11, comp.sys.dec or comp.sys.dec.micro From lasner@sunSITE.unc.edu Wed Dec 15 11:32:10 EST 1993 Article: 534 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.lang.focal Subject: Re: PDP-8 emulator performance Date: 15 Dec 1993 16:30:43 GMT Organization: University of North Carolina, Chapel Hill Lines: 113 Message-ID: <2ene3j$mo2@samba.oit.unc.edu> References: <1993Dec10.050222.776@das.harvard.edu> <1993Dec10.162219.4283@news.uiowa.edu> <1993Dec14.080531.12903@ifi.informatik.uni-stuttgart.de> NNTP-Posting-Host: calypso.oit.unc.edu In article <1993Dec14.080531.12903@ifi.informatik.uni-stuttgart.de>, >This is another approach to an emulator. My intention was primarily a little >bit other: >I said to the guys who are writing the emulator: >1. Compatibility: > All paper tape software (.BN-files) have to tun without patches, so the > M6850 (KL8-8) instructions are to be emulated bit by bit, including inter- > rupt behaviour. Yes, this is most necessary. It's all too easy to wind up with an emulator that doesn't emulate the timing of interrupt-driven code. The net result is code that has all the overhead and none of the advantages of using interrupts, a situation largely the case on the DECmates :-(. Also, note that this also means that all of the diagnostic paper tapes have to run as well. (You may copout and not implement the time-share trap :-).) > OS/8 must be bootable from an octal-dump of my SYS: (RK8E + RK05) with > the instructions: > 0030 6743 > 0031 5031 > As you are aware, OS/8 doesn't run materially different from different devices since it runs without interrupts on the disk always, and always on all other devices except when the FORTRAN IV run-time is executing. (Little else about OS/8 cares about interrupts.) So, the only driving parameter here is the fastest emulation. While the RX01/02 is probably the worst standard device to emulate, the RK8E is not the best one. Clearly, the best standard device to emulate is the RF08 since it's able to sustain a DMA transfer of an entire field and has minimal protocol to emulate in terms of emulated handler code to get the handler calls accomplished. You cannot claim the advantage of being dismounted, since the emulated device will not be data-transferable to the real media, rather just the ability to eventually get an image of it there. Incidentally, my PDP-8 ENCODE utilities allow image transfers of devices between systems, assuming Kermit is available to send the data. Thus, you could send a copy of your RK data to the emulated -8 :-). The best overall device to emulate is the MDC8. The SCSI devices can be a mix of emulated devices and also real ones. For example, if the PC has an SCSI port already, such as for a CD-ROM, you could also hang a SyQuest drive on the SCSI buss. That SyQuest drive could be a bootable 45 MByte or larger drive (they come now in three sizes, up to 105 MByte) that contains MENU-8, under which could be running (multiple) copies of P?S/8 and/or OS/8. If you emulate the OMTI 5400 controller (or hang a real one on!) you can also have MFM drives (real or emulated) and also high-density floppies. The most minimal configuration (assuming a PC or Mac as the base of the emulator) would be a pair of high-density floppies. (I have a pair of 1.2 MByte HD drives on my -8/e-a, but could easily change to 1.44 MByte 3.5" drives.) If only floppies are to be emulated, a PC can do 1.2 MB and 1.44 MB, while a Mac must be new enough to support 1.44 MB at all. Note that this level of emulation requires no hardware at all, since all of these machines have what it takes built-in. (I don't want to hear about PDP-8 emulators run from XT's with 360K-only disks :-).) This kind of emulation achieves something you were only hoping for: actual media compatibility between a PDP-8 and the machine it's emulated on! The bootable HD diskettes of P?S/8 and OS/8 for the MDC8 w/5400 and HD diskette drives will boot on the -8, and also on the emulator directly! Further, they can be turned into MS-DOS files using TELEDISK, and shipped around the net in uuencoded files, etc. (The DECmates already have this, as we routinely send RX50 images just about anywhere :-).) Emulation of the MDC8 is superior to all other devices: Consider the RK8E. The RK8E requires PDP-8 code to setup a single sector transfer. Then you have so accomplish the equivalent of the DMA for that sector, then run the emulated code that diddles around setting up the next transfer, etc. The emulated handler calls chew up a lot of emulated PDP-8 cycles. The MDC8 works by issuing two IOT's that point to an SCSI command in memory that the handler sets up. The command is carried out by DMA, and then typically implies a DMA transfer to read or write the block data, etc. But unlike the RK8E, the DMA transfer is done in one operation. Maximum transfer is 256 sectors, but in practice is limited to 32K at a time. OS/8 and P?S/8 handlers will limit this further to 4K at a time, but this is a far cry from the .25K at a time the RK8E transfers! Furthermore, the MDC8 is not size-limited like the RF08, which has a maximum size of just one large OS/8 device. (Note: the RK8E is typically implemented as two logical devices - RKA0: and RKB0: on the first drive. But each is *smaller* than the RF08 or MDC8 logical drives. Due to the size of most MDC8 SCSI devices, OS/8 is mapped into several logical devices, all of which are the size of an RF08.) Since most of the MDC8 operation is done by DMA and another processor, it's the ideal choice for an emulated device. The total number of emulated PDP-8 cycles is minimal, which makes for the fastest possible emulation, etc. Note that even a PDP-8 RAM disk would be slower to emulate, since all transfer operations are carried out by IOT's. > I want then to compile a 180K-Fortran IV programm and run the KERMITs from > CJL and JBQ. Agreed. Also, this brings up a fine point of emulation. Strictly speaking, PDP-8's are ignorant of their baud rate speeds. In theory, the interface could be clocked against something else, such as CPU speed or a DK8E, but in practice the rate is just ignored. However, support for the baud rate selection can be added ala the VT-78 and newer machines. But this would be limited in the standard version to 19200 baud and lower. >2. Speed: > Make it as fast as ever possible. The result is, that the programm is fully > written in assembler. Agreed. Thus don't support mediocre I/O devices like the RK8E. Most of the software is disk-i/o-bound, not CPU bound, so put a lot of effort into improving the performance of the disk emulation. cjl From wosch@rbg.informatik.th-darmstadt.de Thu Dec 16 11:02:12 EST 1993 Article: 535 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!inxs.concert.net!taco!lll-winken.llnl.gov!sundance.llnl.gov!fastrac.llnl.gov!cronkite.nersc.gov!s1.gov!overload.lbl.gov!agate!howland.reston.ans.net!xlink.net!zib-berlin.de!news.th-darmstadt.de!rbg.informatik.th-darmstadt.de!wosch From: wosch@rbg.informatik.th-darmstadt.de (Olav Woelfelschneider) Newsgroups: alt.sys.pdp8 Subject: Upgrade a PDP11/03 ? Date: 14 Dec 1993 18:39:04 GMT Organization: TU Darmstadt Lines: 21 Distribution: world Message-ID: <2el188INNva2@rs18.hrz.th-darmstadt.de> NNTP-Posting-Host: rbhp82.rbg.informatik.th-darmstadt.de I've a PDP11/03-processor jumpered to use 60kRAM, together with a RLV11, two RL01 5meg disk-drives and four serial ports (don't now the board name now). It's a huge refrigerator sized box, and I wonder if I could run something better on it than RT11? Is there a c-compiler for RT11, or am I doomed to use FORTRAN, BASIC-11 or even assembly-language? Has anyone a description of the assembly commands and the processor structure anyhow? Thank you....It feels strange switching on such an old dinosaur....Greetings from Jurassic Park ... (: Olav -- /===================================================\ | Olav Woelfelschneider | | wosch@rbg.informatik.th.darmstadt.de | +---------------------------------------------------+ | Pay no attention to the man behind the curtain. | | Wizard Of Oz | \===================================================/ From lasner@sunSITE.unc.edu Fri Dec 17 03:18:51 EST 1993 Article: 536 of alt.sys.pdp8 Path: samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Requirements for PAL-compatible cross-assemblers Date: 16 Dec 1993 21:22:39 GMT Organization: University of North Carolina, Chapel Hill Lines: 40 Message-ID: <2eqjiv$pvj@samba.oit.unc.edu> NNTP-Posting-Host: calypso.oit.unc.edu I will be putting together a PAL "torture test" file that will include some "sticky" examples of the kind of code a truly compatible assembler needs to support PAL code properly. In passing, it should be noted that currently there are *no* assemblers that will totally pass this torture test fully. The reason is simply that all known viable candidates have some implementation restrictions. Some of the restrictions are cosmetic, while others actually force programming technique limitations on the programmer. Some of the problems revolve around known bugs. For example, PAL8 has always had a problematic bug associated with the syntax of literals. The following code functions as documented in PAL8: TAD (3)-1 /GET WHAT'S IN ADDRESS BEFORE LITERAL The PAL8 documentation says this should generate 1376 and a literal 0003 in 0377. TOPS-10 PAL10 and P?S/8 PAL both do this. However, all known versions of PAL8 instead generate 1377 and 0004 in 0377, i.e., the ")" character is ignored! This leads to the requirement that literal expressions be simplified, etc. The number of passes taken by an assembler can influence the result in some cases. Programmers are warned of using forward references to literal expressions. The values of the expressions can change as a function of the pass number. Since PAL8 does a first pass, then does an optional binary second pass, then an optional listing third pass, a third pass listing may not match the binary output! The proof would be to do two assemblies. If one assembly deletes the binary pass, then the listings won't match in this case. Therefore, for compatibility, it's necessary that any cross-assemblers be written in exactly two passes to avoid this, etc. (Note: PAL8 was done this way due to the generic OS/8 limitation that only one file at a time can be open on a specific device. To avoid the need to specify multiple devices, the third-pass method is a simple copout, not to mention requiring about 50% longer assembly time!) Hopefully, this compilation will guide cross-develops towards a "better" PAL assembler. cjl From george@bio-medical-physics.aberdeen.ac.uk Fri Dec 17 15:01:06 EST 1993 Article: 537 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!math.ohio-state.edu!caen!usenet.coe.montana.edu!decwrl!pa.dec.com!aberdeen.ac.uk:george@bio-medical-physics.aberdeen.ac.uk! From: george@bio-medical-physics.aberdeen.ac.uk (George Cameron) Message-ID: <9312171136.AA03042@biomed.abdn.ac.uk> Subject: 8" RX02 floppies on IBM PC Date: Fri, 17 Dec 1993 11:36:53 +0000 X-Received: by usenet.pa.dec.com; id AA11933; Fri, 17 Dec 93 03:40:50 -0800 X-Received: by inet-gw-1.pa.dec.com; id AA14065; Fri, 17 Dec 93 03:37:09 -0800 X-Via: uk.ac.aberdeen; Fri, 17 Dec 1993 11:36:39 +0000 X-Received: from biomed.abdn.ac.uk (tethys.biomed.abdn.ac.uk) by aberdeen.ac.uk; Fri, 17 Dec 93 11:38:40 GMT X-Received: from hyperion.biomed.abdn.ac.uk.biomed.abdn.ac.uk by biomed.abdn.ac.uk (5.0/SMI-SVR4) id AA03042; Fri, 17 Dec 1993 11:36:53 +0000 X-To: alt.sys.pdp8.usenet X-Content-Length: 2630 Lines: 59 This has already been posted to the other groups mentioned, but Charles Lasner suggested that I try alt.sys.pdp8 as a potential source of experts in this area. Any suggestions very welcome! [Posted to alt.sys.pdp8, comp.sys.ibm.pc.hardware, comp.ibm.pc.hardware, comp.sys.dec, comp.sys.dec.micro] Maybe this is a FAQ, but I've not managed to find it anywhere. Let me know if I've missed it, or if there's a better group I should be posting to. 1/ My questions: (i) Can I interface an 8" floppy drive to a standard PC controller on a PC clone computer? Do I simply need a conversion cable? (ii) Is there any software around (PD/commercial) which would allow me to read the RX02 format (written on an RSX system, so I guess this implies Files-11)? Do some PC BIOSs include 8" floppy support, and would this be any help to me (since it isn't an MSDOS floppy!) (iii) Alternatively, would it be possible for the RX02 controller on the RSX host to control a 3.5" or 5.25" drive, so that only a software driver would be required to read it on the PC? (ie. could the RX02 controller drive, say, a 1.44MB 3.5" drive, using only 77 tracks instead of 80, and using 26 256-byte sectors instead of 18 512-byte ones? (iv) Any other suggestions? 2/ A little background, for anybody interested: We have an old PDP11/60 running RSX (v2.something I think) which is still in use because of the equipment it is attached to. However, it is a little fragile, and I'm told that the Unibus is full and its disks choc-a-bloc, so it would not be easy/desirable to modify the system setup. The primary data output medium for this machine is 8" RX02 floppy (no ethernet, serial line too slow to be convenient), and we keep an old Microvax with RX02 drives in a corner and use TCP/IP to get the data from this machine onto our Suns. However, the RSX machine and the microvax are actually on different sites, about 20mins by car across town. In addition, we are about to set up a PC based system as the main processing computer at the same site as the RSX machine, so it would be a great improvement to the system if we could transfer data via floppy between the PDP and the PC + + + I hope somebody can help - please reply by email, and I'll summarize the replies I receive. Thanks for your time, George --------------------------------------------------------------------------- George Cameron g.cameron@biomed.abdn.ac.uk Dept. BioMedical Physics Aberdeen University Foresterhill Fax: +44 (0)224-685645 Aberdeen AB9 2ZD Telephone: +44 (0)224-681818 ext 53195 From supnik@human.enet.dec.com Sat Dec 18 22:00:43 EST 1993 Article: 538 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!doc.ic.ac.uk!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Timeshare question resolved Date: 18 DEC 93 18:41:58 Organization: Digital Equipment Corporation Lines: 32 Message-ID: <2f04mv$g70@sousa.ako.dec.com> NNTP-Posting-Host: human.enet.dec.com Summary: Works the 'easy' way Keywords: PDP-8, timeshare option Thanks to Max Burnet (curator of the Nostalgic Obsolete Products SIG in Australia), the question of timesharing option behavior is resolved. 1. If in user mode, with interrupts enabled, an IOT or OSR or HLT is executed, the PC points at the following instruction. 2. If the trapped instruction is an operate, then ALL parts of the operate except for OSR or HLT have been executed before the user mode interrupt occurs. This includes SKPs and CLA, if programmed. Examples (in user mode, interrupts enabled) n/ IOT n+1/ ... Location 0 will contain n+1 n/ CLA SKP HLT n+1/ ... n+2/ ... Location 0 will contain n+2, and the AC will be clear. Both cases are explicitly tested in the memory extension and timeshare option diagnostic. On to the EAE... Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From mbg@world.std.com Sun Dec 19 14:03:16 EST 1993 Article: 539 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!world!mbg From: mbg@world.std.com (Megan) Subject: Retro computing to an extreme? Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2f04mv$g70@sousa.ako.dec.com> Date: Sun, 19 Dec 1993 04:23:27 GMT Lines: 15 So far, all the work I've seen relating to emulators of "mature" archiectures (ripe?) consist of seeing what kind of speed increase over the original machine an emulator running on newer techology might attain. It occurred to me the other day that this could be carried to an extreme... Imagine, a pdp-8 emulator (built to run on an -11), running on a pdp-11 emulator (built to run on an alpha), running on an alpha emulator (?!), running on whatever ... Hey, we might even approach the operating speed of the ORIGINAL pdp-8 architecture :-) Megan Gentry From supnik@human.enet.dec.com Sun Dec 19 14:04:33 EST 1993 Article: 540 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!pipex!doc.ic.ac.uk!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: Retro computing to an extreme? Date: 19 DEC 93 00:55:36 Organization: Digital Equipment Corporation Lines: 41 Message-ID: <2f0qmt$qi6@sousa.ako.dec.com> References: <2f04mv$g70@sousa.ako.dec.com> NNTP-Posting-Host: human.enet.dec.com Summary: Fun Keywords: Simulation, ratios In article , mbg@world.std.com (Megan) writes... >So far, all the work I've seen relating to emulators of "mature" >archiectures (ripe?) consist of seeing what kind of speed increase >over the original machine an emulator running on newer techology >might attain. > >It occurred to me the other day that this could be carried to an >extreme... > >Imagine, a pdp-8 emulator (built to run on an -11), running on a >pdp-11 emulator (built to run on an alpha), running on an alpha >emulator (?!), running on whatever ... Hey, we might even approach >the operating speed of the ORIGINAL pdp-8 architecture :-) It's certainly possible to do the nesting, but I have my doubts about the resulting performance. For example, there was a major simulation system on the DEC-10 (MIMIC), which simulated 8's, 11's, Nova's, etc. With Ken Harrenstein's (sp?) DEC-10 simulator, one could resurrect MIMIC, simulating 8's on 10's on the UNIX system of your choice. Carrying that one step further, various people (including me in a previous life) wrote 8 simulators on 11's. So one could simulate 8's on 11's on 10's on the UNIX system of your choice. Standing in the way are a few small practical problems: 1. MIMIC has disappeared, at least in source form (and oh! would I like to find it). 2. Although the 10 simulator, on an Alpha, will run faster than "real time" on a KL, MIMIC delivered simulation ratios of 15:1 (Nova) to 45:1 (PDP11 with memory manglement). So the nested simulators won't run fast enough. Plus, I wonder how all the nested simulators would fight over which level got to handle ^C...:-) Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From jeff@crash.cts.com Sun Dec 19 14:05:08 EST 1993 Article: 541 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!newshub.nosc.mil!crash!jeff From: jeff@crash.cts.com (Jeff Makey) Subject: Re: Retro computing to an extreme? Organization: Future Procrastinators of America Date: 18 Dec 93 23:33:26 PST Message-ID: <1993Dec18.233326.26559@crash> References: <2f04mv$g70@sousa.ako.dec.com> Lines: 27 In article , Megan Gentry wrote: >Imagine, a pdp-8 emulator (built to run on an -11), running on a >pdp-11 emulator (built to run on an alpha), running on an alpha >emulator (?!), running on whatever ... Hey, we might even approach >the operating speed of the ORIGINAL pdp-8 architecture :-) The Alpha had better be pretty fast, because the PDP-8 emulator I wrote in 1978 in BASIC+2 on a RSTS/E PDP-11/70 was considerably slower than the real thing. For instance, with PDP-8 BASIC loaded it took maybe 10 seconds to parse a blank line of input (from a typed carriage return) and print the appropriate line feed. The layering went something like this: PDP-8 BASIC on top of a PDP-8 emulator executing in the BASIC+2 runtime system on top of the RSTS/E (version 6c, I think) operating system running on a PDP-11/70. As I recall, there was a bug in my emulator (that I never tracked down) that kept BASIC's LIST command from working, although everything else seemed fine. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Domain: jeff@crash.cts.com UUCP: nosc!crash!jeff From supnik@human.enet.dec.com Sun Dec 19 14:05:35 EST 1993 Article: 542 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!doc.ic.ac.uk!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Revised EAE code Date: 19 DEC 93 12:51:50 Organization: Digital Equipment Corporation Lines: 11 Message-ID: <2f24bu$hlb@sousa.ako.dec.com> NNTP-Posting-Host: human.enet.dec.com Summary: Revised EAE code available Keywords: PDP8, EAE My apologies for posting this in the conference, but my news feed has deleted most back notes. Would the person who asked for EAE sources please send me Email? I've revised the code from the PDP8-E EAE maintenance manual and it is now considerably more accurate. Still no guarantees of perfection (waiting for diagnostics to run) but much closer than previously. Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From shoppa@almach.caltech.edu Mon Dec 20 00:31:31 EST 1993 Article: 543 of alt.sys.pdp8 Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde!dptspd!news.tamu.edu!bloom-beacon.mit.edu!uhog.mit.edu!nntp.club.cc.cmu.edu!news.mic.ucla.edu!ucla-cs!paris.ics.uci.edu!news.claremont.edu!nntp-server.caltech.edu!almach.caltech.edu!shoppa From: shoppa@almach.caltech.edu (Timothy D. Shoppa x4256) Newsgroups: alt.sys.pdp8 Subject: Re: Retro computing to an extreme? Date: 18 Dec 1993 20:42 PST Organization: California Institute of Technology Lines: 44 Distribution: world Message-ID: <18DEC199320424156@almach.caltech.edu> References: <2f04mv$g70@sousa.ako.dec.com> NNTP-Posting-Host: almach.caltech.edu News-Software: VAX/VMS VNEWS 1.41 In article , mbg@world.std.com (Megan) writes... > >So far, all the work I've seen relating to emulators of "mature" >archiectures (ripe?) consist of seeing what kind of speed increase >over the original machine an emulator running on newer techology >might attain. > >It occurred to me the other day that this could be carried to an >extreme... > >Imagine, a pdp-8 emulator (built to run on an -11), running on a >pdp-11 emulator (built to run on an alpha), running on an alpha >emulator (?!), running on whatever ... Hey, we might even approach >the operating speed of the ORIGINAL pdp-8 architecture :-) > > Megan Gentry This is almost an urban legend (the source is a 'friend of a friend'), but I've heard that WPS for the PDP-8 was developed on a emulator (or simulator, I can never remember which is which) running on a PDP-11/60. The emulator supposedly used the 11/60's Writeable Control Store to implement many of the 8's instructions. At the time (I would guess late 70's, given what I know about the 11/60) it was the fastest way to execute PDP-8 software; I heard it was 2-3 times as fast as any of the real PDP-8 hardware. Anyone know more details of this emulation? Were any of these machines ever used outside DEC? Instead of emulating the machine code of an architecture, why not emulate the microcode? Hell, I've got field maintenance print sets for the 11/60; we could feed the gate interconnections into a logic simulator running on some platform. Then we could load emulating microcode into the WCS. I truly doubt we would approach anywhere near the speed of the ORIGINAL pdp-8 architecture after all these levels of emulation, but it'd be quite a sight! Tim (shoppa@altair.krl.caltech.edu) P.S. Anyone know of 11/60 installations still running? I can point out several examples of 11/70's still going strong, but I've never seen a real working 11/60. Looking over computer architecture books of the 1970's and even early 1980's, the 11/60 seems to have been the "textbook" example of a general-purpose microcoded processor. I suppose it may have been so general-purpose that it was beat out by more economically viable but less general-purpose mini's. (How does a 11/60 stack up against, say, a 11/55?) From lasner@sunSITE.unc.edu Mon Dec 20 20:52:47 EST 1993 Article: 544 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Retro computing to an extreme? Date: 21 Dec 1993 01:28:38 GMT Organization: University of North Carolina, Chapel Hill Lines: 39 Message-ID: <2f5jg6$jf8@bigblue.oit.unc.edu> References: <2f04mv$g70@sousa.ako.dec.com> <18DEC199320424156@almach.caltech.edu> NNTP-Posting-Host: sunsite.unc.edu Xref: bigblue.oit.unc.edu alt.sys.pdp8:544 alt.folklore.computers:53084 In article <18DEC199320424156@almach.caltech.edu>, Timothy D. Shoppa x4256 wrote: > >This is almost an urban legend (the source is a 'friend of a friend'), >but I've heard that WPS for the PDP-8 was developed on a emulator (or >simulator, I can never remember which is which) running on a PDP-11/60. >The emulator supposedly used the 11/60's Writeable Control Store to >implement many of the 8's instructions. At the time (I would guess late 70's, >given what I know about the 11/60) it was the fastest way to execute >PDP-8 software; I heard it was 2-3 times as fast as any of the real PDP-8 >hardware. Anyone know more details of this emulation? Were any of these >machines ever used outside DEC? > To debunk things a little: WPS is a complete O/S unto itself. Implementing "many" PDP-8 instructions means it wouldn't work; implementing *all* of the CPU instructions of the -8/e and a proper interrupt behavior isn't quite enough: you also have to implement the console peripheral, comm ports and LPT port, and also a system device that would likely be an RX01/02. Moreover, while such an emulated or actual machine would be enough to RUN a system like WPS, it's entirely another matter that it would be developed on something that feeble. I know from in-house experience that the minimal machines used to develop WPS generally had RK or RL disks on them, and an RX01/02 to try it out on. I also heard the tale of the emulated faster -8 on the WCS 11/60. And that it could run anything that an -8/e (with the same peripherals) could. But not that it was ever used for anything beyond a hack in-house demo. You can't build WPS from the sources, unless you have an additional more powerful disk device on the machine. But since there aren't any other truly compatible peripherals between 11/60 and Omnibus, and the WPS developers weren't particularly inclined to move all the files on many RX01/02's (assuming the 11/60 had an emulated pdp-8 disk on it and someone had managed to somehow get a bootable OS/8 system to the emulated disk, etc.), any form of "development" on the 11/60 seems pretty unlikely. cjl From lasner@sunSITE.unc.edu Mon Dec 20 20:54:36 EST 1993 Article: 545 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: PDP-8 MainDEC Archive Area Date: 21 Dec 1993 01:52:21 GMT Organization: University of North Carolina, Chapel Hill Lines: 283 Message-ID: <2f5ksl$cba@bigblue.oit.unc.edu> NNTP-Posting-Host: sunsite.unc.edu A new archive area for PDP-8 paper-tape diagnostics has been created on sunsite.unc.edu. Anyone with any files relevant to diagnostics and related issues is requested to place them into the directory: /pub/academic/computer-science/history/pdp-8/Incoming All useful files will be placed into the directory: /pub/academic/computer-science/history/pdp-8/mainDEC Already present is the obligatory README file for ftp purposes, etc. It points the ftp user to a file named DESCRIBE, a copy of which follows: ---------------------------------------------------------------------------- PDP-8 MainDEC Diagnostic Area Welcome to the mainDEC area. This is where official DEC PDP-8 family paper-tape diagnostics and related material are kept. The usual material here is a collection of diagnostic programs originally distributed as binary paper tapes. Originally associated with each tape was a (generally badly-xeroxed) paper listing of an associated write-up file documenting the program, which usually concluded with a highly reduced (and often only barely readable) copy of an assembly listing of the program itself. Often, the user was referred to the listing itself to deal with specific hardware-induced and detected problems, etc. Available Files. 1) Binary Files. In some cases, the only article available will be the binary program itself. In which case, only those already familiar with the program can use it, or else you have to disassemble it yourself and figure out how to! 2) User-provided Help Files. Hopefully, knowledgeable users can fill us in on how to use the program, at least the fundamentals of how to make it run to a successful no-errors-found completion, etc. Many diagnostics halt for all sorts of reasons. Some may be innocuous but require some action to correct. Even the successful exit of the program might be a halt! Without that basic information, the binary files are useless, so a short help file can make the program viable, etc. 3) Machine-readable write-ups. If available, it is hoped that someone will at least submit the front of the write-up, which was usually a plain text file using a paragraph numbering scheme common in DEC documentation. This is usually an adequate form of documentation, except where it refers to specifics within the program listing, etc. The best thing would be to provide the equivalent of the write-up front and also the PAL source program file. With both of these available we can create an equivalent of the absolute original write-up, minus the degradation caused by the poor copying technique DEC often used! 4) Additional Warning Files and Notes. Additionally, associated .BWR files might be present to indicate warnings to would-be users about non-obvious quirks of the program. For example, some diagnostics are actually incompatible with the various operating systems (P?S/8, OS/8, etc.) that would be expected to run them! One would expect the contrary, but some of the programs can merely be stored on these systems, not loaded from them! (And even worse, there may be limitations on the storage method, i.e., attempts to use the system loading utility could create a corrupted copy of the program! For example, the PDP-8/e Random ISZ test assumes that 07600-07777 is the exclusive province of the RIM loader, the BIN loader, and itself! Not only does it access locations in this page (which would destroy OS/8 or P?S/8), but it actually loads code there! Thus, it is acceptable to create a binary file called RANISZ.BN and store that on OS/8, but it is not acceptable to create a file named RANISZ.SV, since OS/8 ABSLDR will "protect" OS/8 and inhibit the loading into 07600-07777. The resultant RANISZ.SV is corrupted and non-functional.) It is conceivable that a patch may be available to allow some form of restrictive loading of a program on an operating system, or some quirk of a system can be exploited to overcome a straight-forward restriction. For example, the problematic RANISZ program could be loaded into field 3 on a 16K or more machine. (Field 2 can be used on some systems!) An additional small program could then move all of field 3 to all of field 0 and start the original program up as intended. As a result of this, OS/8 is wiped out in memory and will need manual re-boot later, but the program can run as intended. Alternately, there is a P?S/8 method that may allow problematic programs to run in a similar manner without requiring extended memory at all. P?S/8 inhibits loading into 07600-07777 in a manner similar to OS/8, and this is done to provide the same kind of protection against system corruption. This is accomplished using the BIN program's /V switch (which is default on certain system configurations). However, the inhibited loading is not totally lost under P?S/8 BIN, because, unlike OS/8 ABSLDR, BIN stores an image of the attempt to load into 07600-07777 in a known save area on the system device. It is possible to write a P?S/8-specific patch to a program requiring only a small patch loading area, and a one-page buffer to temporarily move the 07600-07777 loading into. The patch is started first, and it reads the image of the inhibited loading into the provided page buffer, then moves the data from the buffer to 07600-07777. P?S/8 is destroyed in memory, and will require a re-boot later, but the program is now loaded as intended and can be started up by the patch, etc. Additional changes beyond the diagnostic can be provided. For example, by making a two-word patch to the PDP-8/e extended memory checkerboard, and then providing a very short program to start before starting the main program up, it is possible to have the memory diagnostic performed while a VT8E is running in worst-case DMA graphics mode. (Note: the VT8E can request many back-to-back DMA cycles that can exercise a memory faster than the diagnostic!) During such a test, MM8E 4K and 8K memory modules have been found to fail unless the strobe adjustment is fine-tuned more carefully that would otherwise pass the unpatched test. This enhances reliability, and is always recommended where applicable, etc. This small patch program will be provided in the associated EXMCHK.BWR file for the diagnostic which is itself available as EXMCHK.BN. Thus, it is possible for any specific diagnostic program to have a small collection of hints and kinks associated with it. Some of the methods described are somewhat generic for a class of troublesome diagnostics, so it is likely that the program-specific note file will refer to another file on how to implement the relevant technique, etc. File Formats. Other than the actual programs, all files in this section are ASCII text files. The binary programs will be stored in a variety of ways to allow a variety of purposes. 1) BIN Format. In this format, the original paper-tape is stored frame by frame into 8-bit bytes. The system that stores this archive file must be capable of maintaining the 8-bit characters exactly as provided. This format is the one most likely to be used by a PDP-8 emulator running on another machine where the underlying file structure can maintain the 8-bit frames of the original paper-tape correctly. These files consist of a leader, the binary program in RIM or BIN format, and a trailer. Some files will essentially be composites of this format. For example, FOCAL, 1969 is generally read in as two independent binary tapes spliced together, with leader/trailer between the sections. Whether a file is RIM or BIN should be clear from the file name; most are BIN format. (Some files are actually compatible with both the RIM and BIN loaders. In some special cases, the file may be in some alternate format such as the "help" or "slim" loader format. Utilities such as these were developed to make it easier to load tapes from scratch than even the RIM loader. Generally, the only files in their format are the help-out files that cause RIM and/or BIN to be present as a consequence, etc.) Note: some files may appear to have quite short leader/trailer, and a single ^Z character within the trailer. These files have been processed by OS/8, and are either the output of an assembler, or were converted via OS/8 PIP using the /B option. There is no operational difference between these files and the original paper-tapes, but the precise format of the non-data leader and trailer is admittedly different. (Some paper-tapes included checksum information provided by a program known as "master tape duplicator" which is stripped by this process. The lost information is not related to the binary program's contents, but rather is only meaningful to the tape duplication program, etc.) 2) .BOO format. This is a printably encoded format that is popular on MS-DOS and other systems to transfer 8-bit-oriented files through "hostile" environments such as e-mail. It uses a restricted character set that will pass through many systems, and a limited form of compression. (Note: since the compression is 8-bit oriented, and only compresses zeroes, little PDP-8 binary file compression will tend to occur.) Utilities exist for all popular systems, including OS/8, to encode/decode files into .BOO format for transport between systems. When a .BOO format version of a binary file is decoded on a target system, the resultant file should be identical to the BIN format file described above. The OS/8 version of the utilities ensure that this is true by following the standard OS/8 pack/unpack scheme of the so-called "3 for 2" technique. Thus, all binary and text files will convert correctly through .BOO transfers, etc. 3) ENCODE format. This is a printably encoded format that is currently unique to OS/8. It uses a more restrictive character set than .BOO encoding, to achieve a more robust format that can be transmitted through even more "hostile" environments than .BOO is capable of. (For example, ENCODE format files can survive being transferred as a WPS document. This facility may be unique to ENCODE format. It has already been determined that .BOO and uuencode format cannot pass as a WPS document!) Additionally, ENCODE format can "survive" having the case of all of the letters changed. Any OS/8 file can be transferred through the ENCODE/DECODE utilities, as the method is intrinsically image oriented, so there is no problem encoding .SV or other files, etc. The ENCODE file format is 12-bit oriented, and includes a form of compression that allows any 12-bit data value to be repeat compressed (as opposed to .BOO's 8-bit-zeroes-only compression) if possible. The file includes imbedded commands, file checksums, and encourages internal documentation regarding what the file is about, etc. The OS/8 version include automatically generated comments about the file's creation date, ENCODE file's creation date, etc. An ENCODE file may contain either a single file or multiple files. (Currently, the OS/8 utilities only support a single file.) Each file in turn represents either a single OS/8 file, or an image of an entire OS/8 device, or an approximate "half" of an OS/8 device. (The reason for representing "half" of a device is that on a meager configuration, it may not be possible to convert an entire device image. For example, an OS/8 system device could consist of merely a dual-drive RX01, and no other devices are available. Since an ENCODE image of an entire RX01 is usually larger than a single RX01's capacity to hold that encoded file, it's usually not possible to provide the image file as input to the DECODE utility! (In cases of extraordinary compression, this wouldn't be a problem. For example, a sparsely used RX01 would have a lot of unused space hopefully containing blocks totally consisting of a repeated formatting pattern. In that case, the resultant ENCODE file would be quite small!) By splitting the image into a "first half" and a "second half" it is then possible to store a bootable OS/8 system, the DECODE utility, and a copy of the ENCODE input file on one drive, and write the half-image to the other drive. Repeating the process with the other "half's" file finishes the transfer, etc. The "half" files are an approximate description, because the ENCODE files cover half of the device, but each is subject individually and independantly to the possibility of compression to a somewhat smaller size that will likely vary, etc.) 4) IPL format. This is a format vaguely similar to BIN format, except that it's stripped down like RIM format in terms of loading controls, etc. However, the data is encoded into printable characters instead of paper-tape frames. Thus, the loader has to strip off a "bias" value from the data. As a result, all "white space" and other control characters such as CR, LF, FF, HT, etc. are ignored during the loading. This allows the file to exist as an easily maintained printably encoded text file in any system. The IPL format file is restricted to an implied initial loading address of 0000 and all loading is strictly sequential. The file and loader must agree on the length of the load implicitly, although the usual practice is to load all of 0000 through 7577 to conform with the usual OS/8 and P?S/8 restrictions, etc. (An IPL loader could be written to load 0000-7777 of an available field, such as 3. But 07600-07777 is never available in OS/8 or P?S/8. In OS/8 17600-17777 is never available, and 27600-27777 is often not available. In certain P?S/8 configurations 6000-7777 or perhaps 0000-7777 of the highest implemented field (through 7) may be unavailable, while a lesser field greater than 0 might be available for loading from 0000-7777.) The loading program controls what memory field the program is loaded into, although comments in the IPL file might indicate the intended field, etc. An OS/8 SAVE command is generally given after the loader exits to the keyboard monitor to finish the loading. P?S/8 versions of an IPL loader can exit to the keyboard monitor after having 0000-7777 preserved in the % and $ files with all other memory intact. This accomplishes the equivalent of the OS/8 SAVE command for most files, etc. An advantage of the IPL format is that it allows elaborate leader/trailer comments. The only restriction placed on the leader is that the characters in the leader must be lower-case and devoid of characters from octal 041 (!) through 140 (`). Since space characters (octal 040) are freely allowed anywhere in the file, as well as CR (octal 15) and LF (octal 12), a rather elaborate leader can be constructed. The trailer consists of at least one lower-case character followed by literally anything. Thus, IPL files may have a lower-case comment referring the reader to a mixed-case comment at the other end. Since the only purpose of an IPL file is to load a mutually agreed upon single PDP-8 field, the file cannot be longer than 8K characters, not including formatting overhead and comments, etc. The IPL format was developed to allow a direct transfer between a PDP-8 or DECmate and a "nearby" other system that can transfer the IPL file over a serial line. The IPL loading program is very tiny, although somewhat larger than the RIM loader. The serving system can treat the IPL file as a normal text file; cosmetic alterations such as FF, CR/LF breaks, etc. are allowed to make the file more "palatable" to the serving system as necessary without corrupting the data. The only requirement is that the connection between systems be error-free. (The IPL format is used to distribute Kermit-12 to systems lacking any other form of communication program. Since all of the data is stored in memory, no particular protocol is required; the serving system can send the file as fast as possible once the loading program is started on the PDP-8 end, etc.) 5) Other formats. If there is sufficient interest, uuencode format can be provided, but there is no current PDP-8 uuencode program. Most other systems that have uuencode can also run the .BOO utilities however. The .BOO utilities maintained by Columbia University for MS-Kermit distribution are generally adaptable to most other systems that may require any additional formats, etc. Note: only the latest version of the Columbia .BOO utilities should be used due to longstanding bugs now corrected. The PDP-8 .BOO utilities have never had these problems, etc. [End of file; last edit 19-Dec-1993 cjl] From supnik@human.enet.dec.com Tue Dec 21 10:13:10 EST 1993 Article: 546 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!spool.mu.edu!agate!ames!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik From: supnik@human.enet.dec.com (Bob Supnik) Newsgroups: alt.sys.pdp8 Subject: Re: Retro computing to an extreme? Date: 20 DEC 93 20:38:05 Organization: Digital Equipment Corporation Lines: 22 Distribution: world Message-ID: <2f5k58$ebe@sousa.ako.dec.com> References: <2f04mv$g70@sousa.ako.dec.com> <18DEC199320424156@almach.caltech.edu> NNTP-Posting-Host: human.enet.dec.com In article <18DEC199320424156@almach.caltech.edu>, shoppa@almach.caltech.edu (Timothy D. Shoppa x4256) writes... > [text deleted] >This is almost an urban legend (the source is a 'friend of a friend'), >but I've heard that WPS for the PDP-8 was developed on a emulator (or >simulator, I can never remember which is which) running on a PDP-11/60. >The emulator supposedly used the 11/60's Writeable Control Store to >implement many of the 8's instructions. At the time (I would guess late 70's, >given what I know about the 11/60) it was the fastest way to execute >PDP-8 software; I heard it was 2-3 times as fast as any of the real PDP-8 >hardware. Anyone know more details of this emulation? Were any of these >machines ever used outside DEC? Not a legend at all: the emulator was written by Richie Lary, PDP-8 wizard extraordinaire, and author of the famous maxim: "Any 129 word PDP-8 program can be rewritten in 128 words (also true recursively)." It was indeed the fastest PDP-8 of its time. Today, a streamlined simulator on a decently fast RISC processor would be faster. Bob Supnik >Supnik@human.enet.dec.com >All opinions expressed are those of a hardline microcoder >and do not reflect those of Digital Equipment Corporation From don@zl2tnm.gen.nz Tue Dec 21 13:05:44 EST 1993 Article: 547 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!ames!decwrl!decwrl!waikato!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Retro computing to an extreme? Message-ID: <8083354@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 21 Dec 93 08:10:00 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <2f5jg6@bigblue.oit.unc.edu> Distribution: world Organization: The Wolery Lines: 30 Xref: bigblue.oit.unc.edu alt.sys.pdp8:547 alt.folklore.computers:53129 lasner@sunSITE.unc.edu (Charles Lasner) writes: > I also heard the tale of the emulated faster -8 on the WCS 11/60. And that it > could run anything that an -8/e (with the same peripherals) could. But not > that it was ever used for anything beyond a hack in-house demo. You can't > build WPS from the sources, unless you have an additional more powerful disk > device on the machine. But since there aren't any other truly compatible > peripherals between 11/60 and Omnibus, and the WPS developers weren't > particularly inclined to move all the files on many RX01/02's (assuming the > 11/60 had an emulated pdp-8 disk on it and someone had managed to somehow > get a bootable OS/8 system to the emulated disk, etc.), any form of > "development" on the 11/60 seems pretty unlikely. I believe the 11/60 story, simply because having your binary able to run on the same machine as your cross-development tools and source code would be worth the tweaks required to get it to map onto the 11/60 and (I believe) RSTS/E. RSTS/E is useful for this sort of thing because of its support for multiple run time systems; you'd just tell the standard monitors to go play in the traffic while you run your own that could cope with the PDP-8 emulating microcode. Sure, the inner core stuff would have to be tested on a real live PDP-8, and the final testing would likewise have to be done there, but you can get a heck of a lot more done if you pile all your developers onto a reasonable sized timesharing system with one copy of the source code, cross-development tools and a binary environment to test the higher level stuff. -- Don Stokes, Network Manager, Victoria University of Wellington, New Zealand. don@zl2tnm.gen.nz(home) don@vuw.ac.nz(work) +64 4 495-5052 Fax+64 4 471-5386 From krause@azu.informatik.uni-stuttgart.de Tue Dec 21 13:37:26 EST 1993 Article: 548 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news From: krause@azu.informatik.uni-stuttgart.de (krause) Subject: Re: 8" RX02 floppies on IBM PC Message-ID: <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de> Sender: news@informatik.uni-stuttgart.de Organization: Informatik, Uni Stuttgart, Germany References: <9312171136.AA03042@biomed.abdn.ac.uk> Date: Tue, 21 Dec 1993 10:22:00 GMT Lines: 31 >Maybe this is a FAQ, but I've not managed to find it anywhere. Let me know >if I've missed it, or if there's a better group I should be posting to. > >1/ My questions: > >(i) Can I interface an 8" floppy drive to a standard PC controller on > a PC clone computer? Do I simply need a conversion cable? > I have a 8" (ITT 2020) drive on my -486 PC. It's connected, via an adapter cable to a secondary FDC. I don't know, how to access a secondary FDC via the 'legal' PC-BIOS, but with the shareware programm 'ANADISK' I can make dumps of many floppies from several machines: IBM 5120 (all in EBCDIC!), CP/M-disks and VAX 780 disks. I think, if the RX02 floppies are not hardsectored, it should be possible to read (dump) them too. >(ii) Is there any software around (PD/commercial) which would allow me > to read the RX02 format (written on an RSX system, so I guess this > implies Files-11)? Do some PC BIOSs include 8" floppy support, and > would this be any help to me (since it isn't an MSDOS floppy!) > Look for ANADISK, or if you attach your Drive to the normal controller, there are some BIOS-calls to set the normal FDC to other sector numbers and sizes, some PC-controller clones allow even to set them to single density! I once wrote a turbo pascal programm to read and write CP/M disks, without one line machine code. Klemens Krause University Stuttgart - Germany From lasner@sunSITE.unc.edu Tue Dec 21 13:42:36 EST 1993 Article: 549 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Retro computing to an extreme? Date: 21 Dec 1993 15:13:07 GMT Organization: University of North Carolina, Chapel Hill Lines: 102 Message-ID: <2f73q3$j4a@bigblue.oit.unc.edu> References: <2f04mv$g70@sousa.ako.dec.com> <18DEC199320424156@almach.caltech.edu> <2f5k58$ebe@sousa.ako.dec.com> NNTP-Posting-Host: sunsite.unc.edu In article <2f5k58$ebe@sousa.ako.dec.com>, Bob Supnik wrote: > >In article <18DEC199320424156@almach.caltech.edu>, shoppa@almach.caltech.edu (Timothy D. Shoppa x4256) writes... >> [text deleted] >>This is almost an urban legend (the source is a 'friend of a friend'), >>but I've heard that WPS for the PDP-8 was developed on a emulator (or >>simulator, I can never remember which is which) running on a PDP-11/60. >>The emulator supposedly used the 11/60's Writeable Control Store to >>implement many of the 8's instructions. At the time (I would guess late 70's, >>given what I know about the 11/60) it was the fastest way to execute >>PDP-8 software; I heard it was 2-3 times as fast as any of the real PDP-8 >>hardware. Anyone know more details of this emulation? Were any of these >>machines ever used outside DEC? > >Not a legend at all: the emulator was written by Richie Lary, PDP-8 wizard >extraordinaire, and author of the famous maxim: "Any 129 word PDP-8 program >can be rewritten in 128 words (also true recursively)." It was indeed the >fastest PDP-8 of its time. Today, a streamlined simulator on a decently >fast RISC processor would be faster. Yes, my friend Richie wrote the emulator; to that extent this isn't a legend. However, like any extraordinary fact, it can turn into a legend. Thus, the rest of it is exaggerated. BTW, I heard that the VAX was developed on the WCS of 11/60; any truth to that? As to putting 129 words into 128 (and recursively yet!), this is the premise of much of the code of P?S/8, which is specifically based on the R-L monitor system. (What do you think the "R" and "L" stand for?) (That's one of the reasons we changed R-L to MS/8 ("Mass Storage/8") because no one would believe a system named after its author :-).) Don't forget Jack Burness' corrolary to the maxim: The amount of time it takes to remove another word of code from the page is a function of how many words already removed. There are various techniques to shaving down -8 code. We use all of Richie's techniques and a few more some others invented on top of them. For example, any AND instruction should always be suspected of inefficiency unless it's involved in being (at least one!) an elsewhere-needed constant. All operate instructions should be investigated not only for the ability to form a needed AC,L value which could save a constant, but additionally, the instruction itself could form a needed constant. (A subset of that is to form a needed constant that is also a group II OPR when executed. You investigate whether the instruction will clear the AC, which is often useful, might skip, might never skip, will definitely skip, will definitely not skip, as determined by the context. If the AC,L is predictable enough, you can upgrade might to definite. In any case, the appropriate placement of the constant into the code might including a sacrificial line following to avoid problems. The second line is formed as necessary. For example, a constant 7700 followed by a constant 7772 is placed in-line in the code where the AC is required to get cleared, and is always predictably negative. The 7772 is thus always skipped (good thing! it otherwise would make the program halt!). The AC gets cleared, and the constant 7700 doesn't need another word of code.) Sometimes you can create a constant out of an instruction that isn't quite perfect, but is good enough. Richie was the first to use the OR functionality of KRS with "messy" constants like 1200 (formed by TAD instruction to something positioned at the beginning of the current page) which would OR in the parity bit (as well as the 1xxx) and then compare to something else regarding the specific check (^C, etc.). If the two's complement of the match was otherwise available, you have eliminated two constants. (The conventional way is to use an AND (177) and compare to (-3) but this is longer; depending on the bummability of the program, it could be a tie though.) (Assembly notation note: when I reference a line to fudge a constant, perhaps one only good eough, but not perfect, I create a commented-out literal that signifies the "pure" version of what I am seeking. Thus, if the code ever moves, I know what it requires to restore functionality, etc.) Sometimes, there is a complex relationship between words to make it fit. For example, by positioning a constant on page zero, it gets used on page 0200 as a page-zero literal, and also forms another constant on page 0200 which is an AND instruction to the page-zero literal itself. (So far, this situation isn't that complex!) However, on another page, there is a similar situation involving another critically situated page-zero constant saving another word, etc. But there's an additional dependency: the instruction that requires that page's current-page literal is also used as a pointer to the analogously-formed one on the 0200 page, since this page also requires the very same constant. (The second page of code doesn't have any instructions that reference the specifically-placed literal constant as does the first page, thus it can't form a "clone" of that constant, etc. However, it takes advantage of the fact that the first page is 0200-0377, thus an AND instruction current page can be forced into also being a pointer to where on page 0200 that needed constant is. In this case, it happens to itself be formed out of a current page reference to an unrelated page-zero literal constant, thus the AND instruction that references it is also a pointer to the other one on page 0200.) (Note: all of these interlockings are "protected" against abuse by rigged conditional assembly, which will cause assembly errors if the relationships are broken. At least this is the case in P?S/8 consistently and completely. Some of the OS/8 code that uses these techniques merely points out that something needs to be carefully maintained; the actual words are often quite cryptic. The code is easily broken!) On a machine with only 4096 defined instructions, none of this should be surprising. In any case, this is (part of) why any emulators have to *exactly* follow the PDP-8 instruction set! cjl From lasner@sunSITE.unc.edu Tue Dec 21 13:46:31 EST 1993 Article: 550 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Retro computing to an extreme? Date: 21 Dec 1993 18:05:41 GMT Organization: University of North Carolina, Chapel Hill Lines: 99 Message-ID: <2f7dtl$9go@bigblue.oit.unc.edu> References: <2f5jg6@bigblue.oit.unc.edu> <8083354@zl2tnm.gen.nz> NNTP-Posting-Host: sunsite.unc.edu Xref: bigblue.oit.unc.edu alt.sys.pdp8:550 alt.folklore.computers:53161 In article <8083354@zl2tnm.gen.nz>, Don Stokes wrote: >lasner@sunSITE.unc.edu (Charles Lasner) writes: >> I also heard the tale of the emulated faster -8 on the WCS 11/60. And that it >> could run anything that an -8/e (with the same peripherals) could. But not >> that it was ever used for anything beyond a hack in-house demo. You can't >> build WPS from the sources, unless you have an additional more powerful disk >> device on the machine. But since there aren't any other truly compatible >> peripherals between 11/60 and Omnibus, and the WPS developers weren't >> particularly inclined to move all the files on many RX01/02's (assuming the >> 11/60 had an emulated pdp-8 disk on it and someone had managed to somehow >> get a bootable OS/8 system to the emulated disk, etc.), any form of >> "development" on the 11/60 seems pretty unlikely. > >I believe the 11/60 story, simply because having your binary able to run >on the same machine as your cross-development tools and source code would >be worth the tweaks required to get it to map onto the 11/60 and (I >believe) RSTS/E. RSTS/E is useful for this sort of thing because of its >support for multiple run time systems; you'd just tell the standard monitors >to go play in the traffic while you run your own that could cope with the >PDP-8 emulating microcode. > >Sure, the inner core stuff would have to be tested on a real live PDP-8, >and the final testing would likewise have to be done there, but you can >get a heck of a lot more done if you pile all your developers onto a >reasonable sized timesharing system with one copy of the source code, >cross-development tools and a binary environment to test the higher level >stuff. Your belief doesn't match the situation. After loading the WCS, the machine is no longer an -11, and doesn't even run RT-11, much less RSTS. Assuming a composite was developed, what's the overhead in allowing some -11 cycles and some -8 cycles? The whole point of the hack was to run a faster -8, not a slower one. In any case, RSTS never offered PDP-8 programmers any useful development tools. The sources of WPS are written in PAL8, and are assembled using batch files meaningful only to OS/8. Further, these batch files demand that a reasonably large disk device house all of the relevant source files at once. The only way all of this can be met is if: 1) The emulated PDP-8 already has an emulated disk since no physical disk larger than an RX02 can be moved between an actual -8 and an 11/60. The WCS hack predates the RL01. All of the other peripherals that dismount aren't media-compatible between systems. The media of choice of WPS developers was RK8E, which can't be read on an -11. 2) All of the files would have to be tediously moved across from an -8 on RX01/02 and then reconstructed on the mythical disk on the simulator. There are quite a few files, and it's not likely any developer would do it; more time is lost in the translation than is saved by the speed-up. Unless a machine was definitely available to leave sources around on (frowned upon by management!) the developer can't work unless that particular machine is available (definitely frowned on by management!). The alternative of carrying around one RK8E pack (confirmed to be just about the capacity needed to develop the whole system) looks a whole lot brighter; it was the method of choice of all other PDP-8 system developers at the time, etc. 3) WPS sources maintained on OS/8 produce a binary that writes itself out on the RX01/02, which is then stand-alone booted for test. The program is I/O bound and wastes the speed-up hardware. Even so, the whole thing assembles on a real PDP-8/e in about 10 minutes, assuming you want to assemble it all every time. How much time is saved if a loaded machine that emulates a PDP-8 2-3 times as fast when it's not doing anything else is being used for multiple users? The typical PDP-8/e system in-house at that time had its own line-printer, possibly shared by an adjacent similar system. TECO was the editor of choice, and is freely available on OS/8. There were many such machines available then; most also had fast RF08 head per track disks on them. Some also had special peripherals on them for a specific project. (I got bumped a few times from these systems because the developer of the special-purpose project needed that particular machine, etc. I would just move to another machine, since (at night anyway) there were always more systems available, etc.) There were few 11/60's where the -8 hack exists. Why would someone used to carrying around a listing and an RK pack seeking an available system want to carry around a double-box of RX01 media and wait for it to get loaded/unloaded? The way I heard it was that the hack was definitely done, but only for curiosity value. If you know the development history of the source files of WPS, it just doesn't make sense that it was used for that purpose. And WPS isn't that big a project anyway! Moreover, throughout all of the OS/8 stuff I "inherited" over the years, there has never been a mention of a mythical device for an emulator. (There have been some arcane projects vaguely in the same category, but each has a specific unrelated purpose, etc.) (Of course this doesn't prove that there wasn't an emulated RF08!) Unless the complete environment of the PDP-8 is emulated, people just aren't interested in it. RSTS never even came close. Even PAL10 and a PDP-10-based emulator (forget the name!) didn't cut it. Most stuff cross-developed was brought back to the hardware;once OS/8 became viable, cross-development virtually ceased. This is why PAL10 isn't language compatible with PAL8 on too many key points. Even though relatively minor to implement, no one bothered to keep them in sync on features, etc. Remember the timing: this is pre-DECmate WPS! cjl From lasner@sunSITE.unc.edu Tue Dec 21 13:47:36 EST 1993 Article: 551 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: 8" RX02 floppies on IBM PC Date: 21 Dec 1993 18:37:21 GMT Organization: University of North Carolina, Chapel Hill Lines: 58 Message-ID: <2f7fp1$eet@bigblue.oit.unc.edu> References: <9312171136.AA03042@biomed.abdn.ac.uk> <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de> NNTP-Posting-Host: sunsite.unc.edu In article <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de>, krause wrote: >>Maybe this is a FAQ, but I've not managed to find it anywhere. Let me know >>if I've missed it, or if there's a better group I should be posting to. >> >>1/ My questions: >> >>(i) Can I interface an 8" floppy drive to a standard PC controller on >> a PC clone computer? Do I simply need a conversion cable? >> >I have a 8" (ITT 2020) drive on my -486 PC. It's connected, via an adapter >cable to a secondary FDC. >I don't know, how to access a secondary FDC via the 'legal' PC-BIOS, but with >the shareware programm 'ANADISK' I can make dumps of many floppies from several >machines: IBM 5120 (all in EBCDIC!), CP/M-disks and VAX 780 disks. >I think, if the RX02 floppies are not hardsectored, it should be possible to >read (dump) them too. RX01 disks are FM, but industry standard. I have heard conflicting reports on the ability for a standard PC floppy controller card being able to control FM disks by using special software (BIOS definitely can't help you!) in conjunction with: 1) Nothing. Special software can make it work. 2) Small hardware changes. 3) Only works on some clone cards, not others. Won't work on IBM card. 4) Same as 3), but requires small hardware changes. 5) Same as 3), but requires real IBM card or slavish compatible. The card is based on the 765 chip, which can work with FM disks in principle. > >>(ii) Is there any software around (PD/commercial) which would allow me >> to read the RX02 format (written on an RSX system, so I guess this >> implies Files-11)? Do some PC BIOSs include 8" floppy support, and >> would this be any help to me (since it isn't an MSDOS floppy!) >> >Look for ANADISK, or if you attach your Drive to the normal controller, there >are some BIOS-calls to set the normal FDC to other sector numbers and sizes, >some PC-controller clones allow even to set them to single density! >I once wrote a turbo pascal programm to read and write CP/M disks, without >one line machine code. But the problem is RX02, not RX01. DEC uses an incompatible cross between single and double-density conventions in the RX02. I doubt if any other floppy controller than DEC's "hand-made" one can deal with the format. The headers are FM with MFM ID data and FM data preamble with MFM data in the data areas. The index is pure FM. Most machines are based on packaged floppy chips. Name any that can switch modes in the middle of a record. cjl From billh@comtch.iea.com Wed Dec 22 16:12:19 EST 1993 Article: 552 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!news.intercon.com!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch.iea.com!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: pdp8e emulator Date: 21 Dec 1993 21:20:59 GMT Organization: CompuTech Lines: 1021 Message-ID: <2f7pbr$v0@krel.iea.com> NNTP-Posting-Host: comtch.iea.com Summary: Emulator/philosophy Keywords: emulator, pdp8, EAE, FPP X-Newsreader: TIN [version 1.2 PL1] I have written a pdp8e emulator and sent a copy of it to Charles Lasner. The emulator emulates a DEC PDP-8/e with 32K words memory, console VDU (Video Display Unit--Steuart Dewar's terminology), line printer, PT8E paper tape reader/punch and RK8E hard disk with 4 drives. The user may optionally (via command line options) add EAE (mode A or B), FPP-8/A floating point processor and one of several DK8-xx clocks. For those interested in such things, I hereby submit a posting giving some of my reasoning and emulator philosophy. This posting consists essentially of email sent to Mr. Lasner by me on 1993 Dec 21 as follows: Dear Mr. Lasner, I hereby send the sources for my pdp8e emulator. It works well on my AMIGA, but it seems that every time I make any changes to it, I break it for the IBM PC world. I defined all functions in accordance with ANSI C. Hopefully, you have an ANSI-compliant compiler available. Globally define AMIGA for use on an AMIGA system or MS_DOS for a PC/Clone running MS-DOS. I wanted to use a high level language to make it portable and I also wanted it to execute at high speed. So I execute each pdp8e instruction by vectoring through an array of function pointers indexed by the 12-bit instruction augmented by the User Bit. This requires 8192 array elements in the vector array. Another 4096 element array vectors the FPP-8/A instruction executions. When you get a successful compilation, just execute the single command: pdp8 Doing this should print the following menu: Usage: pdp8 [-option [value]] [...] -file name Set pdp8 memory file e.g. -file pdp8.ram -init [octal-value [start [#locs]]] e.g. -init 7402 1000 200 -dep addr value [... value] e.g. -dep 200 7300 1177 7402 -exam addr [#locs] Display memory e.g. -exam 0 100 -clear Press 'CLEAR' switch -cont [octal] 5-digit start addr e.g. -cont 16000 -count Count pdp8 inst's executed -clock [[type] [ticks]] [out] Specify clock type = dk8ea pdp8a vt78 vt278 dk8ec e.g. -clock dk8ec 100 -eae [mode] [out] EAE emulation in/out e.g. -eae b -fpp [out] FPP-8/A emulation in/out -fpp regs [dec] Display dec FPP registers -fpp trace Trace FPP instructions -fpp count Count FPP inst's executed - octal Specify register value where = link ac mq sr sc gtf sf e.g. -sr 7777 -flags octal Specify FLAGS register value e.g. -flags 5166 -regs Display pdp8 registers -rk8e pack ... Specify up to 4 RK8E pack(s) e.g. -rk8e pack0 pack1 -rk8e regs Display RK8E registers -auxvdu [ioadr] [out] Set up auxilliary VDU e.g. -auxvdu 75 -lpt [device] Lineprinter output file e.g. -lpt lpt.out -mask octal Set breakpoint mask e.g. -mask 77000 -break [addr][inst] Set breakpoint (5 digit addr) e.g. to break at inst 6046: -break 6046 to break at addr 300: -break 00300 -trace [dec] Trace dec instructions e.g. -trace 1000 -dis [dec] Disassemble dec instructions e.g. -dis 150 -exec [dec] Execute dec inst's e.g. -exec 1000000 -tab [file] Output inst usage (to file) e.g. -tab pdp8.tab -hist [file] Output PC histogram (to file) e.g. -hist pdp8.hst -pause Pause before exiting -diag Run a MAINDEC diag program -conout [file] Save pdp8 console to file e.g. -conout pdp8.out -auxout [file] Save pdp8 aux console to file e.g. -auxout pdp8.aux -boot Boot from RK8E disk -hardware List 'hardware' status -res List 'hardware' resources --------------------------------------------------------------------------- I will endeavor to explain the use of options with the pdp8 command. The user may invoke any number of options up to the limit his UNIX system will allow on a command line. I show the actual command line (or fragment) using six '>' and six '<'. All the peripheral registers and certain other information resides in the pdp8e memory file (normally named 'pdp8.ram'). When the user specifies adding a peripheral (e.g. EAE), this information gets stored in the pdp8e memory file. The 'pdp8.ram' file I enclose contains only 91 bytes, but has all the registers for the CPU, EAE, RK8E, PT8E, FPP-8/A and 32K words of zeroed pdp8e memory! If the user removes a peripheral (explained below), that peripheral's registers get removed from the pdp8e memory file and only a flag remains. The emulator assumes octal numbers for most options. --------------------------------------------------------------------------- -file name Set pdp8 memory file e.g. -file pdp8.ram This option specifies the name of the pdp8e memory file to use. The emulator produces a compressed memory file using a very simple, but effective, compression scheme. On invocation, the emulator decompresses the specified memory file. If the user does not specify this option, the memory file name defaults to 'pdp8.ram'. >>>>>> pdp8 -file pdp8orig.ram [other options] <<<<<< will cause the emulator to use the file 'pdp8orig.ram' as its pdp8e memory file. If no pdp8e memory file exists, do not worry. Simply invoking: >>>>>> pdp8 -regs <<<<<< will generate a new one (but with only the CPU, 32K memory, PT8E, LP8E and RK8E--any other 'hardware' desired gets added by invoking other options [described below]). --------------------------------------------------------------------------- -init [octal-value [start [#locs]]] e.g. -init 7402 1000 200 This option sets a range of pdp8e memory addresses to a specified value. Follow the option name [-init] with the desired set value. Follow that with the (up to 5-digit) beginning address. Follow that with the number of consecutive memory address to contain the set value. If the user omits this last item, the remainder of memory will contain the set value. If the user omits the beginning address, all of memory will contain the set value. >>>>>> pdp8 -init 7402 1000 200 <<<<<< will cause memory locations 01000 through 01177 to contain the value 7402 (HLT). --------------------------------------------------------------------------- -dep addr value [... value] e.g. -dep 200 7300 1177 7402 This option acts as the "DEP" switch on the front panel. Follow the option name [-dep] with the (up to 5-digit) pdp8 memory address and follow that with any number of consecutive address values. The user may cross field boundaries with this option. >>>>>> pdp8 -dep 200 7300 1177 7402 <<<<<< will cause locations 200 through 202 to contain the following program: 00200 7300 CLA CLL 00201 1177 TAD 177 00202 7402 HLT As you can readily see, a user can input whole programs to pdp8e memory via scripts (laborious, but possible). --------------------------------------------------------------------------- -exam addr [#locs] Display memory e.g. -exam 0 100 This option acts as the "EXAM" switch on the front panel. Follow the option name with the (up to 5-digit) pdp8 memory address followed by the number of consecutive memory locations the user desires to display. Omitting this last argument causes the display of only the 'octet' in which the memory location exists. >>>>>> pdp8 -exam 0 100 <<<<<< will cause the following display (depending on memory contents, of course): Addr 0 1 2 3 4 5 6 7 00000 0003 6232 5001 7200 1053 3033 4500 7705 ........ 00010 2222 1722 0000 1004 7773 1723 7523 0000 ........ 00020 0000 0000 0200 0200 1200 0211 7607 5372 ........ 00030 6203 0000 1630 7605 2125 1124 0000 0000 ........ 00040 0035 7610 5046 0004 0034 7777 6233 5450 ........ 00050 5601 1664 6544 7605 4000 3700 2020 0070 .......8 00060 0603 0600 0434 0067 6003 0244 0100 0336 ...7.$@^ 00070 0334 7001 6670 0212 0215 0403 0010 7700 \....... >>>>>> pdp8 -exam 1207 <<<<<< will cause the following display (depending on memory contents, of course): Addr 0 1 2 3 4 5 6 7 01200 0404 1163 4423 3020 1160 3013 3017 6031 ........ --------------------------------------------------------------------------- -clear Press 'CLEAR' switch Equivalent to pressing the "CLEAR" switch on pdp8e front panel. >>>>>> pdp8 -clear <<<<<< will cause a CLEAR "switch" depression--also equivalent to executing a 'CAF' instruction. --------------------------------------------------------------------------- -cont [octal] 5-digit start addr e.g. -cont 16000 Equivalent to pressing the "CONT" switch on pdp8e front panel with the added capability to specify an optional continuation address. If the user specifies no address, execution continues at the address specified by the current IF and PC. >>>>>> pdp8 -cont 16000 <<<<<< causes the emulator to 'continue' execution at address 16000. --------------------------------------------------------------------------- -count Count pdp8 inst's executed This option directs the emulator to count the number of pdp8e instructions executed (helpful in certain debug situations). >>>>>> pdp8 -count [other options] <<<<<< (obviously used in conjunction with other options). --------------------------------------------------------------------------- -clock [[type] [ticks]] [out] Specify clock type = dk8ea pdp8a vt78 vt278 dk8ec e.g. -clock dk8ec 100 This option allows specification of the desired 8-Family clock with an added capability to specify the number of ticks per second (which defaults to 100 if not specified). If a clock alreadys exists, the 'out' argument removes it. >>>>>> pdp8 -clock dk8ea <<<<<< installs DK8-EA clock and sets the ticks per second at 120 (Line Frequency Clock). >>>>>> pdp8 -clock out <<<<<< removes the previously installed clock. >>>>>> pdp8 -clock dk8ec 200 <<<<<< causes the DK8-EC clock to install and sets the ticks per second at 200. Exercise care about putting too much confidence in clock resolution. --------------------------------------------------------------------------- -eae [mode] [out] EAE emulation in/out e.g. -eae b This option installs the EAE or removes it. Optionally, the user may specify the starting mode A or B. I suspect I have lots of errors in the EAE implementation, but it correctly executes FORTRAN IV programs that use it. I refer specifically to the "questionable" opcodes. When I did not know how the hardware actually reacted, I guessed. If anyone finds errors, PLEASE let me know by email. >>>>>> pdp8 -eae <<<<<< installs the EAE with initial mode A in effect and enables EAE instructions. >>>>>> pdp8 -eae b <<<<<< installs EAE with mode B initially set and enables EAE instructions. >>>>>> pdp8 -eae out <<<<<< removes the EAE from the emulator's current pdp8e memory file and disables EAE instructions (except the basic ones that come with the pdp8e). --------------------------------------------------------------------------- -fpp [out] FPP-8/A emulation in/out This option installs the FPP-8/A or removes it. I regard much of my implementation of the FPP-8/A as flaky. So many questions (some opcodes not implemented because I could not find any documentation--see the source code file 'pdp8fpp8.c' for questions to which I need answers). It seems, however, to execute FORTRAN IV programs (even with extended precision) correctly. [An aside: While reviewing and rewriting this paragraph, I just received a 'brainstorm' idea for making the EAE emulator much more efficient. I do hope I can remember it long enough to get it down in my 'ideas' file!] >>>>>> pdp8 -fpp <<<<<< installs the FPP-8/A emulator and enables FPP-8/A instructions. >>>>>> pdp8 -fpp out <<<<<< removes the FPP-8/A and disables FPP-8/A instructions. --------------------------------------------------------------------------- -fpp regs [dec] Display dec FPP registers This option displays the current status of the FPP-8/A emulator. The optional decimal argument causes display of that many of the "base registers". >>>>>> pdp8 -fpp regs 2 <<<<<< caused the following display after I had run OS/8 and just executed: .EX FORT6.LD FPP-8/A: RUN MODE DATA COMM STAT APT FPC INDEX BASE OPADR NO LEAV FP 0400 0000 00037 00225 10002 10023 01317 COMM = FP UFLOW=0 32K ENA_INT ~OPADR ~NDX ~BASER ~FAC LEAV APTFIELD INDEX = 10002/ 0000 0000 0000 0000 0000 0000 0000 0000 FAC = 0000 0007 0533 = unnormalized OPADR = 01317/ 0000 0000 0000 = 0. BASE = 10023/ 0000 0000 0000 = 0. 10026/ 0000 0000 0000 = 0. RUN displays the run status of the FPP. MODE displays the execution mode-- LEAV=interleaved with pdp8e CPU or LOCK=CPU locked out (with certain exceptions). DATA displays FP=single precision floating point, EP= extended precision floating point and DP=double precision integer. COMM displays the last command executed, STAT displays FPP status, APT displays the effective APT address, INDEX displays the address of the base of the FPP index registers, BASE displays the address of the "base FP registers" and OPADR displays the last operand address. The COMM line gives a bit-by-bit description of the contents of the FPP-8/A command register. In the event of a non-zero STAT register, a line would also display for that. The INDEX line shows the address of the FPP-8/A's index register set and displays the contents of all 8 registers. The FAC line displays the content of the FPP FAC in the mode currently set. An extended precision mode would have displayed a 6-word FAC. The last operand address and FP contents display on the OPADR line. The "base registers" (up to 128) display starting at the BASE address. Although not apparent in the above listing, FP values display as octal digits followed by an equal sign and decimal numbers in floating point format. --------------------------------------------------------------------------- -fpp trace Trace FPP instructions This option causes all FPP-8/A instructions to output a trace. Presently, they display to stdout. In my Amiga implementation, the emulator uses a separate window and trace output goes to stdout--therefore no intermixing of the emulator and trace outputs. I plan to change this in the future to allow specification of an output file for FPP trace output. The command: >>>>>> pdp8 -rk8e pack1 -boot -fpp trace <<<<<< brought up OS/8. Emulator output to the console VDU: ---------------------------------------------------- .DATE Tuesday December 21, 1993 .TYPE FORT6.FT DOUBLE PRECISION PI, E, EPI PI = 3.14159265358979323846D0 E = -2.71828182845904523536D0 EPI = E * PI WRITE (4,200)EPI 200 FORMAT (1H1,B17.13) STOP END .EX FORT6 -8.5397342210747 .CLEAR ---------------------------------------------------- and yielded the following FPP trace output: Soft/pdp8 version 1993.12.21.0050 (c) Bill Haygood, billh@comtch.iea.com FPC INDX STAT FAC 05333 0050 STARTE 0005 0000 0000 0000 0000 0000 0000 = 0.(EP) 05334 0000 FEXIT 0004 0000 0000 0000 0000 0000 0000 = 0.(EP) 04157 3000 TRAP3 03600 2000 0000 0000 0000 = 0.(FP) 04160 3600 03737 1030 JA 04163 0001 0000 0000 0000 = 0.(FP) 03740 4163 04163 3000 TRAP3 04036 2000 0000 0000 0000 = 0.(FP) 04164 4036 04200 1031 JA 10000 0001 0000 0000 0000 = 0.(FP) 04201 0000 10000 1031 JA 10160 0001 0000 0000 0000 = 0.(FP) 10001 0160 10160 1111 SETB 10023 0001 0000 0000 0000 = 0.(FP) 10161 0023 10162 1101 SETX 10002 0001 0000 0000 0000 = 0.(FP) 10163 0002 10164 0100 LDX 0002,0 0002 0001 0000 0000 0000 = 0.(FP) 10165 0002 10166 0100 LDX 0003,0 0003 0001 0000 0000 0000 = 0.(FP) 10167 0003 10170 0050 STARTE 0005 0000 0000 0000 0000 0000 0000 = 0.(EP) 10171 0235 FLDA BR+35 (10152) 0005 0002 3110 3755 2421 0264 3021 = 3.14159265358979(EP) 10172 6222 FSTA BR+22 (10111) 0005 0002 3110 3755 2421 0264 3021 = 3.14159265358979(EP) 10173 0100 LDX 0004,0 0004 0005 0002 3110 3755 2421 0264 3021 10174 0004 = 3.14159265358979(EP) 10175 0233 FLDA BR+33 (10144) 0005 0002 2557 6052 1305 0535 5124 = 2.71828182845905(EP) 10176 0003 FNEG 0005 0002 5220 1725 6472 7242 2654 = -2.71828183032169(EP) 10177 6216 FSTA BR+16 (10075) 0005 0002 5220 1725 6472 7242 2654 = -2.71828183032169(EP) 10200 0100 LDX 0005,0 0005 0005 0002 5220 1725 6472 7242 2654 10201 0005 = -2.71828183032169(EP) 10202 0216 FLDA BR+16 (10075) 0005 0002 5220 1725 6472 7242 2654 = -2.71828183032169(EP) 10203 4222 FMUL BR+22 (10111) 0005 0004 5672 7237 6461 7636 2500 = -8.53973422852524(EP) 10204 6220 FSTA BR+20 (10103) 0005 0004 5672 7237 6461 7636 2500 = -8.53973422852524(EP) 10205 0100 LDX 0006,0 0006 0005 0004 5672 7237 6461 7636 2500 10206 0006 = -8.53973422852524(EP) 10207 0005 STARTF 0001 0004 5672 7237 = -8.539736(FP) 10210 3000 TRAP3 00220 2000 0004 5672 7237 = -8.539736(FP) 10211 0220 00116 0401 FLDA 10136,0 (10136) 0006 0001 0003 2000 0000 = 4.(FP) 00117 0136 00120 0000 FEXIT 0000 0003 2000 0000 = 4.(FP) 10216 0050 STARTE 0005 0003 2000 0000 0000 0000 0000 = 4.(EP) 10217 0220 FLDA BR+20 (10103) 0005 0004 5672 7237 6461 7636 2500 = -8.53973422852524(EP) 10220 3000 TRAP3 00207 2004 0004 5672 7237 6461 7636 2500 10221 0207 = -8.53973422852524(EP) 03353 3400 FDIV 03763,0 (03763) 0006 0005 0000 3324 7400 2174 6551 0500 03354 3763 = 0.85397342210747(EP) 03355 0000 FEXIT 0004 0000 3324 7400 2174 6551 0500 = 0.85397342210747(EP) 03760 6400 FSTA 04566,0 (04566) 0006 0005 0000 3324 7400 2174 6551 0500 03761 4566 = 0.85397342210747(EP) 03762 0000 FEXIT 0004 0000 3324 7400 2174 6551 0500 = 0.85397342210747(EP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7774 3146 3146 = 0.05(FP) 03354 3763 03355 0000 FEXIT 0000 7774 3146 3146 = 0.05(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7771 2436 5604 = 0.005(FP) 03354 3763 03355 0000 FEXIT 0000 7771 2436 5604 = 0.005(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7766 2030 4466 = 0.0005(FP) 03354 3763 03355 0000 FEXIT 0000 7766 2030 4466 = 0.0005(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7762 3215 5611 = 0.00005(FP) 03354 3763 03355 0000 FEXIT 0000 7762 3215 5611 = 0.00005(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7757 2476 1324 = 0.000005(FP) 03354 3763 03355 0000 FEXIT 0000 7757 2476 1324 = 0.000005(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7754 2061 5734 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7754 2061 5734 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7750 3265 7706 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7750 3265 7706 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7745 2536 3070 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7745 2536 3070 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7742 2113 4054 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7742 2113 4054 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7736 3337 1571 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7736 3337 1571 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7733 2577 2772 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7733 2577 2772 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7730 2145 7141 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7730 2145 7141 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7724 3411 3401 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7724 3411 3401 = 0.(FP) 03353 3400 FDIV 03763,0 (03763) 0006 0001 7721 2641 1147 = 0.(FP) 03354 3763 03355 0000 FEXIT 0000 7721 2641 1147 = 0.(FP) 05163 1400 FADD 04566,0 (04566) 0006 0005 0000 3324 7400 2174 6551 6200 05164 4566 = 0.85397342210747(EP) 05165 0000 FEXIT 0004 0000 3324 7400 2174 6551 6200 = 0.85397342210747(EP) 10222 0005 STARTF 0001 0000 0007 0533 = unnormalized 10223 3000 TRAP3 00206 2000 0000 0007 0533 = unnormalized 10224 0206 10225 0100 LDX 0007,0 0007 0001 0000 0007 0533 = unnormalized 10226 0007 10227 1031 JA 10240 0001 0000 0007 0533 = unnormalized 10230 0240 10240 0100 LDX 0010,0 0010 0001 0000 0007 0533 = unnormalized 10241 0010 10242 1130 JSR 00223 0001 0000 0007 0533 = unnormalized 10243 0223 00223 3000 TRAP3 01317 2000 0000 0007 0533 = unnormalized 00224 1317 Runtime = 0:00:30 The FPC, of course, refers to the Floating Program Counter. The INDX column datum, if present, displays the contents of the CURRENTLY referenced FPP index register. The STAT column displays the FPP status. The FAC column displays the FAC in the current mode--single or extended precision. Everything to the LEFT of the FPP instruction displays the address and contents BEFORE instruction execution and everything to the RIGHT of the FPP instruction displays information as it exists AFTER instruction execution. The FAC often displays as "unnormalized" because it often gets used as an indirect address pointer. Otherwise, it displays as a decimal number with the current mode displayed in parentheses (FP, EP or DP). --------------------------------------------------------------------------- -fpp count Count FPP inst's executed >>>>>> pdp8 -fpp count [other options] <<<<<< counts FPP-8/A instructions executed. See above for pdp8 -count . --------------------------------------------------------------------------- - octal Specify register value where = link ac mq sr sc gtf sf e.g. -sr 7777 This options allows the user to set a register to a specific value without having to execute pdp8e code to do so. >>>>>> pdp8 -link 1 -ac 4567 <<<<<< cause the L and AC to set as indicated. >>>>>> pdp8 -ac 14567 <<<<<< causes an action identical to the one above. >>>>>> pdp8 -mq 7701 -sr 7777 -sc 21 -gtf t -sf 143 <<<<<< sets the MQ/7701, the SR/7777, the step counter SC/21, the EAE GreaterThanFlag GTF/ON and the Save Field SF/143. --------------------------------------------------------------------------- -flags octal Specify FLAGS register value e.g. -flags 5166 This options allows direct setting of all the bits in the flags register. >>>>>> pdp8 -flags 6012 <<<<<< causes the setting of the LINK (bit 0), the GTF (bit 1), IF/1 and DF/2. --------------------------------------------------------------------------- -regs Display pdp8 registers This option displays the contents of the pdp8e registers. For example, after executing: >>>>>> pdp8 -rk8e pack1 -boot -exec 1000000 <<<<<< caused the following to display: Soft/pdp8 version 1993.12.21.0050 (c) Bill Haygood, billh@comtch.iea.com Flags Bits: 0:Link 1:GTF 2:IReq 3:IInh 4:IEna 5:UF 6-8:IF 9-11:DF DI PC Code Instruction (Dir) ((Indir)) Flags L AC MQ SR EAE SC GTF 001206 3017 DCA 17 (0000) 1000 00000 0000 0000 A 00 001207 6031 KSF Runtime = 0:00:02 This displays shows the Data Field (the D in the DI at the left margin), the Instruction Field (the I next to the D at the left margin), the PC, the pdp8e code fetched from that address and the disassembled pdp8e instruction. If an direct reference exists, it displays within a single pair of parentheses. If an indirect reference exists, its contents display within a double pair of parentheses. The CPU registers (FLAGS, L, AC, MQ, and SR) display. The individual bit meanings of the FLAGS word display in the banner. If EAE installed, its registers display also. If not, these headings disappear and no info displays. The last instruction executed displays complete with register contents. The next instruction (not yet executed) displays for user inspection. --------------------------------------------------------------------------- -rk8e pack ... Specify up to 4 RK8E pack(s) e.g. -rk8e pack0 pack1 This option allows the user to specify which files to use as RK05 packs. The user may specify up to 4 packs. One great advantage here: the user may specify a pack (other than the first) that does not exist and the emulator will create it--thus making new packs very easy to create. >>>>>> pdp8 -rk8e pack0 pack1 pack2 pack3 -boot <<<<<< causes the emulator to use files pack0/1/2/3 as if packs inserted into RK05 drives 0/1/2/3. The '-boot' option causes the emulator to load the RK8E boot code into the proper page zero locations and execution to start at the correct address. The emulator loads the following for the RK8E: 00027 6007 CAF 00030 6743 DLAG 00031 6741 DSKP 00032 5031 JMP 31 The emulator emulates the actual RK8E instructions so that a file image of an OS/8 boot disk set up for the RK8E will boot directly. --------------------------------------------------------------------------- -rk8e regs Display RK8E registers This option displays the internal registers of the RK8E emulator. Executing: >>>>>> pdp8 -rk8e regs <<<<<< displayed the following: RK8E: COMM STAT UNIT CURAD BLOCK WDCT LOCK WRIT 0100 0000 0 00200 1634 128 F F COMM displays the contents of the RK8E command register, STAT displays the status register, UNIT shows RK05 unit number, CURAD displays the next pdp8e memory address, BLOCK displays the next RK8E block address, WDCT displays the pdp8e word count (128=half block, 256=full block), LOCK displays the status of the RK05 front panel LOCK switch (once set, cannot unset) and WRIT displays whether last access executed as a WRITE access. All numbers display as octal except WDCT. --------------------------------------------------------------------------- -auxvdu [ioadr] [out] Set up auxilliary VDU e.g. -auxvdu 75 This option currently works only on the AMIGA implementation. It opens a second window for use by a second Video Display Unit. The user may specify the start of an I/O address pair for use by the 2nd VDU. If the user omits this I/O address, it defaults to 40/41. If the user specifies an I/O address where "common" conflicts occur (such as 74 [RK8E disk]), the emulator will reject the request. >>>>>> pdp8 -auxvdu <<<<<< opens a second VDU window and enables IOT instructions for this VDU at I/O addresses 40/41. >>>>>> pdp8 -auxvdu 75 <<<<<< opens a second VDU window and enables IOT instructions for this VDU at I/O addresses 75/76. >>>>>> pdp8 -auxvdu out <<<<<< "pulls out the module from the OmniBus" for the 2nd VDU. --------------------------------------------------------------------------- -lpt [device] Lineprinter output file e.g. -lpt lpt.out This option allows the user to specify a file or device for printer output. >>>>>> pdp8 -lpt lpt.out [other options] <<<<<< causes all printer output (via IOT 6666) to go to the specified file. --------------------------------------------------------------------------- -mask octal Set breakpoint mask e.g. -mask 77000 This option sets a mask for use with a breakpoint as explained below. --------------------------------------------------------------------------- -break [addr][inst] Set breakpoint (5 digit addr) e.g. to break at inst 6046: -break 6046 to break at addr 300: -break 00300 This option allows the user to specify where or on what instruction a breakpoint will exist. If the user specifies a 4-digit or less argument, the emulator will break on the first INSTRUCTION it sees with that value. If the user specifies a 5-digit argument, the emulator will break when it encounters that ADDRESS. Thus, "-break 6046" breaks at the first TLS instruction encountered, but "-break 06046" breaks only if the IF/PC equals 06046. The instruction at the breakpoint will NOT execute. If the user has also specifed a mask (see above), the emulator applies the mask to the break instruction or break address (performs an AND operation) first to see if a match has occurred. For example, to break on ANY EAE instruction, the following would do the trick: >>>>>> pdp8 -mask 7401 -break 7401 [other options] <<<<<< Another example: to break only on the IOT instruction 6747: >>>>>> pdp8 -rk8e pack0 pack1 -boot -break 6747 <<<<<< --------------------------------------------------------------------------- -trace [dec] Trace dec instructions e.g. -trace 1000 This option allows the user to specify a CPU/EAE instruction trace (very handy for pdp8e debug situations--very helpful in implementing the emulator also!). The optional argument specifies the number of instructions to trace. If the user omits the argument, it defaults to 16. The following command: >>>>>> pdp8 -rk8e pack1 -boot -trace 50 yielded this trace output: Soft/pdp8 version 1993.12.21.0050 (c) Bill Haygood, billh@comtch.iea.com Flags Bits: 0:Link 1:GTF 2:IReq 3:IInh 4:IEna 5:UF 6-8:IF 9-11:DF DI PC Code Instruction (Dir) ((Indir)) Flags L AC MQ SR EAE SC GTF 000027 6007 CAF 0000 00000 0000 0000 A 00 000030 6743 DLAG 0000 00000 0000 0000 A 00 000031 5030 JMP 30 0000 00000 0000 0000 A 00 000030 6741 DSKP 0000 00000 0000 0000 A 00 000032 0035 AND 35 (0006) 0000 00000 0000 0000 A 00 000033 3436 DCA I 36 (0342) ((0000)) 0000 00000 0000 0000 A 00 000034 5000 JMP 0 0000 00000 0000 0000 A 00 000000 1412 TAD I 12 (0200) ((4207)) 0000 04207 0000 0000 A 00 000001 3413 DCA I 13 (7600) ((4207)) 0000 00000 0000 0000 A 00 000002 1414 TAD I 14 (0047) ((7607)) 0000 07607 0000 0000 A 00 000003 2016 ISZ 16 (7760) 0000 07607 0000 0000 A 00 000004 6211 CDF 1 0001 07607 0000 0000 A 00 100005 3415 DCA I 15 (7647) ((7607)) 0001 00000 0000 0000 A 00 100006 6201 CDF 0 0000 00000 0000 0000 A 00 000007 2017 ISZ 17 (7600) 0000 00000 0000 0000 A 00 000010 5000 JMP 0 0000 00000 0000 0000 A 00 000000 1412 TAD I 12 (0201) ((5000)) 0000 05000 0000 0000 A 00 000001 3413 DCA I 13 (7601) ((0000)) 0000 00000 0000 0000 A 00 000002 1414 TAD I 14 (0050) ((7607)) 0000 07607 0000 0000 A 00 000003 2016 ISZ 16 (7761) 0000 07607 0000 0000 A 00 000004 6211 CDF 1 0001 07607 0000 0000 A 00 100005 3415 DCA I 15 (7650) ((0000)) 0001 00000 0000 0000 A 00 100006 6201 CDF 0 0000 00000 0000 0000 A 00 000007 2017 ISZ 17 (7601) 0000 00000 0000 0000 A 00 000010 5000 JMP 0 0000 00000 0000 0000 A 00 000000 1412 TAD I 12 (0202) ((0000)) 0000 00000 0000 0000 A 00 000001 3413 DCA I 13 (7602) ((0000)) 0000 00000 0000 0000 A 00 000002 1414 TAD I 14 (0051) ((7607)) 0000 07607 0000 0000 A 00 000003 2016 ISZ 16 (7762) 0000 07607 0000 0000 A 00 000004 6211 CDF 1 0001 07607 0000 0000 A 00 100005 3415 DCA I 15 (7651) ((0000)) 0001 00000 0000 0000 A 00 100006 6201 CDF 0 0000 00000 0000 0000 A 00 000007 2017 ISZ 17 (7602) 0000 00000 0000 0000 A 00 000010 5000 JMP 0 0000 00000 0000 0000 A 00 000000 1412 TAD I 12 (0203) ((0033)) 0000 00033 0000 0000 A 00 000001 3413 DCA I 13 (7603) ((0000)) 0000 00000 0000 0000 A 00 000002 1414 TAD I 14 (0052) ((7621)) 0000 07621 0000 0000 A 00 000003 2016 ISZ 16 (7763) 0000 07621 0000 0000 A 00 000004 6211 CDF 1 0001 07621 0000 0000 A 00 100005 3415 DCA I 15 (7652) ((0000)) 0001 00000 0000 0000 A 00 100006 6201 CDF 0 0000 00000 0000 0000 A 00 000007 2017 ISZ 17 (7603) 0000 00000 0000 0000 A 00 000010 5000 JMP 0 0000 00000 0000 0000 A 00 000000 1412 TAD I 12 (0204) ((7602)) 0000 07602 0000 0000 A 00 000001 3413 DCA I 13 (7604) ((0000)) 0000 00000 0000 0000 A 00 000002 1414 TAD I 14 (0053) ((0000)) 0000 00000 0000 0000 A 00 000003 2016 ISZ 16 (7764) 0000 00000 0000 0000 A 00 000004 6211 CDF 1 0001 00000 0000 0000 A 00 100005 3415 DCA I 15 (7653) ((0000)) 0001 00000 0000 0000 A 00 100006 6201 CDF 0 0000 00000 0000 0000 A 00 000007 2017 ISZ 17 Runtime = 0:00:00. --------------------------------------------------------------------------- -dis [dec] Disassemble dec instructions e.g. -dis 150 This option allows the user to simply disassemble pdp8e CPU/EAE code. Code disassembly starts at the current IF/PC setting. The optional argument specifies the number of instructions to disassemble. If the user omits the argument, it defaults to 16. No comparable option exists to disassemble FPP-8/A code. I may add that later. >>>>>> pdp8 -dis <<<<<< yielded the following: Soft/pdp8 version 1993.12.21.0050 (c) Bill Haygood, billh@comtch.iea.com Addr Inst Program 00007 2017 ISZ 17 00010 5000 JMP 0 00011 5437 JMP I 37 00012 0204 AND 4 00013 7604 CLA OSR 00014 0053 AND 53 00015 7653 CLA SCA SHL 7765 00017 7604 CLA OSR 00021 0000 AND 0 00023 0000 AND 0 00025 0000 AND 0 00027 0000 AND 0 00031 5030 JMP 30 00033 3436 DCA I 36 00035 0006 AND 6 00037 7605 CLA MUY 6741 Since data so often gets located close to instructions, the emulator disassembles everything it sees as pdp8e code. Obviously, a disassembled listing takes some interpretation. Above, for example, an experienced pdp8e programmer would see that the emulator has mistaken the "instruction" in location 15 as a wierd EAE instruction. --------------------------------------------------------------------------- -exec [dec] Execute dec inst's e.g. -exec 1000000 This option allows the user to specify that execution stop after some number of instructions have executed. If the user omits the argument, it defaults to 10,000,000 (about 20 seconds on my AMIGA). I used this option to determine emulator execution speed. --------------------------------------------------------------------------- -tab [file] Output inst usage (to file) e.g. -tab pdp8.tab The user may specify a "tab" file in which a count of each of the possible 4,096 pdp8e instructions gets counted. (Sometimes helpful in some debug situations--such as emulator implementation.) --------------------------------------------------------------------------- -hist [file] Output PC histogram (to file) e.g. -hist pdp8.hst The user may specify a "histogram" file to determine where most of the "work" of the program gets done. --------------------------------------------------------------------------- -pause Pause before exiting This option causes the emulator to pause before exiting. Mainly for use on the AMIGA implementation to allow the user to fully read the text in the emulator window before it closes. --------------------------------------------------------------------------- -diag Run a MAINDEC diag program Some MAINDEC diagnostics test for time-critical hardware flags' setting or clearing. Since the emulator only checks for a VDU keyboard strike or VDU output character every 1,000 pdp8e instruction emulations, these diagnostics will fail. This option tells the emulator to check on the I/O characters at the end of EVERY instruction emulation. --------------------------------------------------------------------------- -conout [file] Save pdp8 console to file e.g. -conout pdp8.out This option allows the user to specify a "capture" file for all emulator output to the console VDU. The output also still displays normally when the emulator runs. --------------------------------------------------------------------------- -auxout [file] Save pdp8 aux console to file e.g. -auxout pdp8.aux This option allows the user to specify a "capture" file for all emulator output to the auxilliary VDU. Presently, only the AMIGA implementation supports this option. --------------------------------------------------------------------------- -boot Boot from RK8E disk This option causes the emulator to treat the previously specified system device file as a bootable device (presently only the RK8E supported). --------------------------------------------------------------------------- -hardware List 'hardware' status This option causes a 'concise' listing of the 'hardware' status for the CPU/EAE and all peripherals currently existing in the pdp8e memory file. >>>>>> pdp8 -hardware <<<<<< caused the following listing: Soft/pdp8 'hardware' status: PDP8: DF/0 IF/0 PC/0007 L/0 AC/0000 MQ/0000 SR/0000 IB/0 UB/F UF/F SF/000 INTENA/OFF INTINH/OFF DELAY/OFF IOFLAGS/RK8E INTENAB/CONIN CONOUT CONOUTCHAR/012 EAE: MODE/A SC/00 GTF/F RK8E: COMM/0000 STAT/0000 CURAD/00400 BLOCK/0 UNIT/0 WDCT/256 LOCK/F WRITE/F FPP8: RUN/NO PAUSE/NO MODE/LEAV DATA/FP COMM/0400 STAT/0000 APT/00037 FPC/00225 NDX/10002 BASER/10023 OPADR/01317 FAC/0000 0007 0533 2174 6551 6200 Some registers display as True or False, some as On or Off. For example, in the above, the GTF displays as False. --------------------------------------------------------------------------- -res List 'hardware' resources This option lists the 'hardware' resources presently existing in the pdp8e memory file. Using the enclosed 'pdp8.ram' file, executing: >>>>>> pdp8 -res <<<<<< displayed the following: Soft/pdp8 Resources: (IOADR) PDP-8/E with 32K memory KE8-E Extended Arithmetic Element FPP-8/A Floating Point Processor (55/56) RK8-E Hard Disk with 4 drives (74) Console Video Display Unit (03/04) LP8-E Line Printer (66) PT8-E Paper Tape Reader/Punch (01/02) The emulator ALWAYS contains 32K memory. No provision exists for removing any memory. Most pdp8e owners always DREAMED of 32K anyway. Well, here we have it! --------------------------------------------------------------------------- Some notes on my pdp8e emulator implementation: Originally, the module 'pdp8.c' contained the code that executed the pdp8e and EAE instructions. When that module became so large that my C compiler could not optimize it, I moved it to 'pdp8run.c'. Interestingly, though, the SAS/C optimizer had no trouble with the much larger 'pdp8fpp8.c'. 'pdp8run.c' contains several 'run' loops. The particular option combination the user invokes determines which 'run' loop executes. I probably did not always arrange the logic consistently, but fundamentally I tried to set up the emulator to invoke a particular 'run' loop that would cause the least overhead. The largest 'run' loop (and with the most overhead) results from invoking an instruction trace. The least overhead results from invoking a bare-bones 'hardware' configuration (EAE, however, causes virtually no overhead) such as no FPP-8/A, no clock, no breaks, no trace, etc... I originally made some of the following comments in a README file I sent to Jim Van Zee. So they may seem somewhat out of context here. I just included them so you could see some of the history of my implmentation. I made a significant change in the way an AUXVDU gets added to the 'hardware' configuration. When you specify the option '-auxvdu', you may follow the option with an octal device address which specifies the I/O address of the AUXVDU keyboard. The AUXVDU display screen's I/O address becomes one greater than that. E.g. '-auxvdu 60' specifies an AUXVDU at I/O octal addresses 60 and 61. The emulator initialization code 'plugs' the instrution execution vector table entries to reflect the AUXVDU I/O address you specify so that AUXVDU I/O instructions will execute correctly. If you do not specify an AUXVDU I/O address, the AUXVDU defaults to I/O addresses 40/41. When you do specify an AUXVDU I/O address, avoid any conflict with other I/O addresses since unpredicatable results may occur. The emulator checks for certain obvious conflicts such as a clock's presence with an AUXVDU specified at I/O addresses 12 or 13. I left in Jim Van Zee's code for IOTs to handle the various clocks (DK8-EA, DK8-EC, VT-78, VT-278 and PDP8-A), but I left unsupported the DK8-EP programmable clock. I MAY look at that later. I changed the method by which the various 'hardware' registers get stored in the PDP8.RAM file. A byte-by-byte store scheme saves a lot of room and I reduced the space for 'hardware' registers. All multi-byte data get stored in big-endian order to make the memory files portable across differing architectures. I added a data compression scheme for the PDP8.RAM file when the pdp8 emulator exits. Running the program 'CLEAR.SV' from the emulator will save the OS/8 date word and clear all of memory to zeroes and cause a pdp8 emulator exit. This allows the emulator to compress the PDP8.RAM file to a mere few bytes. In fact, if all of pdp8e memory contains a single value (e.g., zero), the pdp8e 32K-word memory portion of the memory file compresses to just 4 bytes! The FPP-8/A Floating Point Processor emulator does not emulate the hardware as closely as the PDP8 CPU emulator. The emulator carries out floating point calculations by first converting the pdp8 multi-word datum to double precision floating point format, performing the calculation by calling the appropriate library function, then converting the result back to multi-word, pdp8 format. This may sound like big time requirements to do FP calculations. I tested the more obvious way of doing the calcs--by manipulating the 3-word and 6-word data directly and this method required MORE execution time (not to mention having to do multi- precision arithmetic in software [and yes, I know how to implement software floating point routines--I wrote Digital Research's floating point routines in assembly language for both their Motorola and Intel library packages])! The actual hardware carries 6-word FP calculations to a precision of 60 bits. The emulator (since it uses double precision to do its work) carries 6-word FP calculations to a precision of around 54 bits. The emulator creates the double precision data in a hardware independent manner. The emulator performs a rounding away from zero on every single-precision FP calculation. I could not determine from the documentation available to me the functions of instructions 5100-5177. I also could not determine the formats of the instructions IMUL, IMULI, LEA and LEAI. I implemented these latter as a "guess". I would appreciate any information anyone may have about these gray areas. I did not implement the FPP feature of "wrapping" around within a single memory field. I plan to look at this later. In those cases where the FPP emulator outputs trace information, please note the differences compared to trace information output for the PDP8 CPU emulator. For example, the FPC displays only 5 octal digits which indicates the 5-digit value (no IF or DF involved). Some FPP instructions occupy and trace output displays two 12-bit pdp8 words. When an INDX value appears, it represents the content of the currently addressed FPP index register. The STAT value displays the FPP status register. When an FAC value appears, it represents the current contents of the 3-word or 6-word FPP Floating Point Accumulator. In both the CPU and FPP trace output cases, all values displayed to the left of the instruction represent the CPU/FPP status PRIOR to execution of the instruction and all values displayed to the right of the instruction represent the CPU/FPP status AFTER execution of the instruction. If the user has invoked both CPU/EAE and FPP traces and the FPP runs in INTERLEAVE mode, the trace output will show a CPU/EAE instruction trace followed by an FPP instruction trace and so on. A word of advice: the CPU/EAE trace generates a LOT of output in very short order. If one just wants to see the CPU/EAE and FPP interleave in the trace, prepare to wade through many thousands of CPU/EAE trace outputs before the first FPP trace appears. I recommend tracing the CPU instruction execution only for very short traces. Short FORTRAN IV programs generally only output a few hundred lines of FPP trace information. The emulator presently runs on my AMIGA 68040 CPU running at 33 MHz at a best-case speed of 500,000 PDP-8 instruction emulations per second. I would guess that a PC/clone running an Intel i486 at the same speed would do as well. Jim Van Zee's idea for using IOTs to close the paper tape reader and punch I have supported. IOTs 6017 and 6027 close the reader and punch respectively and IOT 6770 supports the DOS and SHELL commands. I also added IOT 6750 (called ZEROMEM) to clear all of PDP8 memory and cause an emulator exit. I welcome any ideas of a better way to support special commands through IOT 6777. Should the PDP8 AC contain the argument ? Should the emulator clear the AC on return ? Once you get OS/8 up and running, executing a .DOS command will cause the host OS to execute one command (the argument to the .DOS command). >>>>OS/8>>>> .DOS ls *.c <<< NNTP-Posting-Host: comtch.iea.com Summary: lsi11 software whereabouts Keywords: emulator rt-11 X-Newsreader: TIN [version 1.2 PL1] I have not located an lsi11 or pdp11 discussion group. So, I hesitatingly post this to the pdp8 discussion group. My newness to the Internet may lead me into error, so I tread very lightly and ask your indulgence. In an earlier posting today, I spoke about my pdp8e emulator. I have also written z80 and lsi11 emulators. I did finally locate a copy of CP/M Plus and hope to soon get that up and running on my 1MB bankswitched z80 emulator. Could someone point me to a copy of RT-11 (preferably a binary disk image and, hopefully available via FTP on the Internet)? I would willingly pay a reasonable fee. I also need documentation and diagnostics. I would appreciate ANY information anyone may have. Kindest regards in E-Prime, Bill Haygood |"There is no such thing as absolute truth." billh@comtch.iea.com | -- British scientist Jacob Bronowski in Voice/AnsMach/Fax: 509-233-2555| his PBS series "The Ascent of Man" From don@zl2tnm.gen.nz Wed Dec 22 16:59:58 EST 1993 Article: 554 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!olivea!hal.com!decwrl!waikato!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Retro computing to an extreme? Message-ID: <10202355@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 22 Dec 93 08:30:51 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <2f7dtlgo@bigblue.oit.unc.edu> Distribution: world Organization: The Wolery Lines: 51 Xref: bigblue.oit.unc.edu alt.sys.pdp8:554 alt.folklore.computers:53262 lasner@sunSITE.unc.edu (Charles Lasner) writes: > Your belief doesn't match the situation. After loading the WCS, the > machine is no longer an -11, and doesn't even run RT-11, much less RSTS. > Assuming a composite was developed, what's the overhead in allowing some > -11 cycles and some -8 cycles? The whole point of the hack was to run a > faster -8, not a slower one. I know you don't like to admit the pdp11 is useful, Charles, but... The WCS allows you to extend the instruction set, and there is a lot of free space in the -11's instruction set that can be used for new instructions. In fact, if you don't mind not being able to use an FPP you can use the whole 17xxxx range, which happens to be a full 12 bits wide. (Note that the pdp11 has a standard set of FP instructions that are present on most processors, including the 11/60. The FPP was available as an option for the larger -11s, and is by no means a requirement for most software to run, certainly not operating systems. Just because you don't have an FPP doesn't mean you can't do floating point -- it just goes a bit slower.) So, you can then emulate to your heart's content, simply by stuffing the top four bits of the -8's address space with 17 and having the -8 microcode only operate on the bottom 12. That leaves the rest of the instruction set untouched so that the OS can run. This just leaves the question of I/O -- and mapping -8 disk instructions into RSTS/E file system or block I/O calls onto an -8 formatted disk or container file isn't really terribly difficult. Anything too hard for the -8 microcode can just be punted to a pdp11 trap to be dealt with. Running under RSTS/E would give the illusion of multiple virtual pdp8s. The worst case for development would be simply to develop using pdp8 tools. > 2) All of the files would have to be tediously moved across from an > -8 on RX01/02 and then reconstructed on the mythical disk on the Filesystem conversion is trivial. Look at all the foreign filesystem utilities floating around for practically every system on the planet. You'd do most of your work on the faster -11 and only move back onto the -8 for final testing. Anyway, much of this is idle speculation -- whether it was done or not (and I still believe it was, at least for later development of the micro versions) it is certainly possible and even fairly likely given that the 11/60 microcode hack was in fact done. -- Don Stokes, Network Manager, Victoria University of Wellington, New Zealand. don@zl2tnm.gen.nz(home) don@vuw.ac.nz(work) +64 4 495-5052 Fax+64 4 471-5386 From secrist@kxovax.enet.dec.com Wed Dec 22 17:00:29 EST 1993 Article: 555 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!crl.dec.com!crl.dec.com!jac.zko.dec.com!kxovax.enet.dec.com!secrist From: secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) Newsgroups: alt.sys.pdp8 Subject: z80 and lsi11 emulators ? Date: 22 DEC 93 07:50:41 Organization: Digital Equipment Corporation Lines: 11 Message-ID: <2f9g2c$bm2@jac.zko.dec.com> NNTP-Posting-Host: KXOVAX Cool ! Are they ftp'able ? Regards, rcs .............. . . . . . . . . . . . . . . . . Richard C. Secrist "The superior man understands +-+-+-+-+-+-+-+ Digital Equipment Corp. what is right; the inferior man |d|i|g|i|t|a|l| secrist@kxovax.enet.dec.com understands what will sell." +-+-+-+-+-+-+-+tm .............. . . . . . . . . . . . . . . . . From lasner@sunSITE.unc.edu Wed Dec 22 17:00:55 EST 1993 Article: 556 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: pdp8e emulator Date: 22 Dec 1993 21:12:10 GMT Organization: University of North Carolina, Chapel Hill Lines: 5 Message-ID: <2fad7a$3oij@bigblue.oit.unc.edu> References: <2f7pbr$v0@krel.iea.com> NNTP-Posting-Host: sunsite.unc.edu Keywords: emulator, pdp8, EAE, FPP Bill Haygood's emulator source code will be shortly available on sunsite. Look for changes in the emulators directory area, etc. cjl From lasner@sunSITE.unc.edu Wed Dec 22 17:03:33 EST 1993 Article: 557 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Retro computing to an extreme? Date: 22 Dec 1993 21:59:49 GMT Organization: University of North Carolina, Chapel Hill Lines: 100 Message-ID: <2fag0l$42ca@bigblue.oit.unc.edu> References: <2f7dtlgo@bigblue.oit.unc.edu> <10202355@zl2tnm.gen.nz> NNTP-Posting-Host: sunsite.unc.edu Xref: bigblue.oit.unc.edu alt.sys.pdp8:557 alt.folklore.computers:53299 In article <10202355@zl2tnm.gen.nz>, Don Stokes wrote: >lasner@sunSITE.unc.edu (Charles Lasner) writes: >> Your belief doesn't match the situation. After loading the WCS, the >> machine is no longer an -11, and doesn't even run RT-11, much less RSTS. >> Assuming a composite was developed, what's the overhead in allowing some >> -11 cycles and some -8 cycles? The whole point of the hack was to run a >> faster -8, not a slower one. > > I know you don't like to admit the pdp11 is useful, Charles, but... > >The WCS allows you to extend the instruction set, and there is a lot of >free space in the -11's instruction set that can be used for new >instructions. In fact, if you don't mind not being able to use an FPP >you can use the whole 17xxxx range, which happens to be a full 12 bits >wide. You are changing the problem in midstream. The original notion was whether someone was loony enough to actually use an 11/60 to develop WPS. You are guessing why you feel it's worth doing. I am providing reasons why logistically no one would've bothered to beyond demonstrating the hack of an unloaded 11/60 could be demoed running -8 code at 2-3 times the speed of an -8/e. The overall development requirements preclude that it ever happened. Any existing or proffered utilities you suggest wouldn't be as useful as the dozens of existent -8's the developers had as a much more viable alternative. The overhead of even considering such a stunt more than cancels any alleged benefit. > >(Note that the pdp11 has a standard set of FP instructions that are present >on most processors, including the 11/60. The FPP was available as an option >for the larger -11s, and is by no means a requirement for most software to >run, certainly not operating systems. Just because you don't have an FPP >doesn't mean you can't do floating point -- it just goes a bit slower.) > >So, you can then emulate to your heart's content, simply by stuffing the >top four bits of the -8's address space with 17 and having the -8 microcode >only operate on the bottom 12. Perhaps true, but the demo was for a faster -8, not one convenient for the host WCS -11. > >That leaves the rest of the instruction set untouched so that the OS can >run. This just leaves the question of I/O -- and mapping -8 disk >instructions into RSTS/E file system or block I/O calls onto an -8 >formatted disk or container file isn't really terribly difficult. You underestimate the overhead of perfect emulation of the PDP-8 peripherals required by WPS. OS/8 is another story, since it runs without interrupts and only needs block service, etc. Again, unless it's both a perfect timing-wise emulation *and* also fast, it's worthless for this purpose. >Anything too hard for the -8 microcode can just be punted to a pdp11 trap >to be dealt with. Which isn't useful to the stated task. > >Running under RSTS/E would give the illusion of multiple virtual pdp8s. >The worst case for development would be simply to develop using pdp8 tools. Multiple developers of any application divide down the alleged performance boost. Better overall to just go use a stand-alone -8. It's guaranteed to be 1/2-1/3 of the best-case expectation of the RSTS system according to your own idealistic notions. > >> 2) All of the files would have to be tediously moved across from an >> -8 on RX01/02 and then reconstructed on the mythical disk on the > >Filesystem conversion is trivial. Look at all the foreign filesystem >utilities floating around for practically every system on the planet. >You'd do most of your work on the faster -11 and only move back onto >the -8 for final testing. Totally wrong. There is no justification in using the -11 filesystem at all. It totally lacks the development tools needed, except for an editor, which OS/8 itself has. The entire -8 development effort *must* be performed under emulation. People aren't going to tolerate large amounts of wait times moving floppies back and forth, especially when a single RK pack solves all problems! > >Anyway, much of this is idle speculation -- whether it was done or not >(and I still believe it was, at least for later development of the micro >versions) it is certainly possible and even fairly likely given that the >11/60 microcode hack was in fact done. Sorry to burst that bubble as well. All the DECmate versions are straight OS/278. The venue moved to RX50, and everyone had one in their own cubicle. Way too much trouble to even think about it. Besides, how late do you think DEC even had in-house WCS-capable 11/60's running? > >-- >Don Stokes, Network Manager, Victoria University of Wellington, New Zealand. >don@zl2tnm.gen.nz(home) don@vuw.ac.nz(work) +64 4 495-5052 Fax+64 4 471-5386 cjl From billh@comtch.iea.com Fri Dec 24 11:54:20 EST 1993 Article: 558 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!news.intercon.com!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch.iea.com!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Bill Haygood's pdp8 emulator Date: 23 Dec 1993 17:59:21 GMT Organization: CompuTech Lines: 9 Message-ID: <2fcm9p$i1r@krel.iea.com> NNTP-Posting-Host: comtch.iea.com X-Newsreader: TIN [version 1.2 PL1] Bob Supnik at DEC sent me a list of his observations so far of mis- implementated items in my pdp8 emulator. I plan to correct those and get a new copy of the emulator to Charles Lasner so he can make it available at sunsite. I need this kind of feedback to make the emulator as bug-free as possible. -- Bill Haygood From lasner@sunSITE.unc.edu Mon Dec 27 21:49:12 EST 1993 Article: 560 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Haygood emulator now available Date: 24 Dec 1993 17:55:24 GMT Organization: University of North Carolina, Chapel Hill Lines: 15 Message-ID: <2ffaec$lpo@bigblue.oit.unc.edu> NNTP-Posting-Host: sunsite.unc.edu The PDP-8 emulator from Bill Haygood has been added to the PDP-8 archive on sunsite.unc.edu. The emulator directory has been eliminated and is replaced by a directory named emulators. The former contents of emulator, Neil A. B. Gray's PDP-8 emulator, has been moved to emulators/gray/*. Bill Haygood's files are in emulators/haygood/*. As more emulator authors come forth with submissions, additional directories will be created. The full path is still: /pub/academic/computer-science/history/pdp-8 emulators is the next directory down, etc. cjl From billh@comtch.iea.com Mon Dec 27 21:50:16 EST 1993 Article: 561 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch.iea.com!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Bill Haygood's pdp8 emulator Date: 26 Dec 1993 06:57:16 GMT Organization: CompuTech Lines: 18 Message-ID: <2fjckc$abr@krel.iea.com> NNTP-Posting-Host: comtch.iea.com Summary: Misimplementations, etc Keywords: emulator, pdp8 X-Newsreader: TIN [version 1.2 PL1] My pdp8 emulator recently made available via ftp from sunsite has some problems which do not manifest themselves on my Amiga implementation. Bob Harper and Steve Chamberlain have actually got it up and (flakily) running on their machines. I think the problems probably tracable to some kind of portability issue. Bob Supnik at DEC pointed out several actual misimplementations in the EAE emulator and non-portable code in the ASR & LSR functions. Bob Harper thinks, and I agree, that problems exist in the RK8E emulator code. Needless to say, I find it embarassing to see the emulator running on my Amiga as solid as a rock and yet so flaky on other machines. When I bring it up on the BBS's UNIX system that I use, it runs quite flaky there, also. I could not even delete an OS/8 file. I will send new sources to Charles Lasner for anon-ftp on sunsite as soon as I can get the bugs fixed. I appreciate your patience. -- Bill Haygood From dicks@math.ohio-state.edu Mon Dec 27 21:58:33 EST 1993 Article: 562 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!math.ohio-state.edu!not-for-mail From: dicks@math.ohio-state.edu (Ethan Dicks) Newsgroups: alt.sys.pdp8 Subject: Re: Bill Haygood's pdp8 emulator Date: 27 Dec 1993 15:35:26 -0500 Organization: Department of Mathematics, The Ohio State University Lines: 24 Message-ID: <2fngue$2tr@math.mps.ohio-state.edu> References: <2fjckc$abr@krel.iea.com> NNTP-Posting-Host: math.mps.ohio-state.edu Keywords: emulator, pdp8 In article <2fjckc$abr@krel.iea.com>, Bill Haygood wrote: >My pdp8 emulator recently made available via ftp from sunsite has some >problems which do not manifest themselves on my Amiga implementation... >I will send new sources to Charles Lasner for anon-ftp on sunsite as >soon as I can get the bugs fixed. I appreciate your patience. I have a request... PKware has a PKZIP for the Amiga (PKAZIP). It cannot unpack PKZIP 2.0 format files. Please do not pack archives for the Amiga that cannot be unpacked natively. I had to hump the file around to unpack it. Lha or Lharc are much more common. Hell, I'd prefer .tar.Z to a 2.0 .zip file... at least I can unpack it without stooping to a DOS box. Thanks, -ethan -- This message was (fortunately) not brought to you by Intel... "Intel: bringing you the "backward" in backward compatibilty." dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org From edmoran@netcom.com Mon Dec 27 21:59:00 EST 1993 Article: 563 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!agate!ames!decwrl!decwrl!netcomsv!netcom.com!edmoran From: edmoran@netcom.com (Ed Moran) Subject: Anybody got a .gif of - The Bug - ? Message-ID: Keywords: bug Organization: his desk X-Newsreader: TIN [version 1.2 PL1] Date: Mon, 27 Dec 1993 21:32:41 GMT Lines: 18 G'mornin all! Long ago, I remember a picture from Time, Newsweek, or the like, of the notebook entry where the -= Moth of Infamy =- was plucked from the flying armatures of a relay-relay logic machine, creating the term... A Bug Anybody got a scanned copy? P.S. Spent the day at the library, and found a book with the schematic of the ENIAC adder!!! I'll write a poop on it if anyone's interested..? - Ed -- edmoran@netcom.com Box 720072 San Jose, California 95172-0072 408-287-9576 The above opinions are not suitable for re-use. Please dispose of properly. From lasner@sunSITE.unc.edu Mon Dec 27 21:59:55 EST 1993 Article: 564 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bill Haygood's pdp8 emulator Date: 28 Dec 1993 02:58:30 GMT Organization: University of North Carolina, Chapel Hill Lines: 32 Message-ID: <2fo7cm$ftd@bigblue.oit.unc.edu> References: <2fjckc$abr@krel.iea.com> <2fngue$2tr@math.mps.ohio-state.edu> NNTP-Posting-Host: sunsite.unc.edu Keywords: emulator, pdp8 In article <2fngue$2tr@math.mps.ohio-state.edu>, Ethan Dicks wrote: >In article <2fjckc$abr@krel.iea.com>, >Bill Haygood wrote: > >I have a request... PKware has a PKZIP for the Amiga (PKAZIP). It cannot >unpack PKZIP 2.0 format files. Please do not pack archives for the Amiga that >cannot be unpacked natively. I had to hump the file around to unpack it. >Lha or Lharc are much more common. Hell, I'd prefer .tar.Z to a 2.0 .zip >file... at least I can unpack it without stooping to a DOS box. Two responses to two posters: To Bill Haygood: What version of what ZIP utility created the copy given to me? I cannot create a copy quite so compressed using available zip 1.9 or PKZIP 2.04g. Also, unzip (version? comparable to zip 1.9) cannot unzip it, but -v can view it at least. 2.04g has no problems with it, but cannot quite recreate something that tight, etc. To Ethan Dicks: What's the best PKZIP version Amiga can handle? I could for example use PC PKZIP 1.10 if it'll help, etc. Anyone: Is pkz204g.exe the best available? cjl From dicks@math.ohio-state.edu Wed Dec 29 04:53:44 EST 1993 Article: 565 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!not-for-mail From: dicks@math.ohio-state.edu (Ethan Dicks) Newsgroups: alt.sys.pdp8 Subject: Archivers (was Re: Bill Haygood's pdp8 emulator) Date: 29 Dec 1993 02:47:09 -0500 Organization: Department of Mathematics, The Ohio State University Lines: 23 Message-ID: <2frclt$jvp@zaphod.mps.ohio-state.edu> References: <2fjckc$abr@krel.iea.com> <2fngue$2tr@math.mps.ohio-state.edu> <2fo7cm$ftd@bigblue.oit.unc.edu> NNTP-Posting-Host: zaphod.mps.ohio-state.edu Keywords: emulator, pdp8 In article <2fo7cm$ftd@bigblue.oit.unc.edu>, Charles Lasner wrote: >>In article <2fngue$2tr@math.mps.ohio-state.edu>, >>Ethan Dicks wrote: >> >>I have a request... PKware has a PKZIP for the Amiga (PKAZIP). It cannot >>unpack PKZIP 2.0 format files... >What's the best PKZIP version Amiga can handle? I could for example use >PC PKZIP 1.10 if it'll help, etc. If you want to use ZIP, PC PKZIP 1.10 should be just fine. Zoo, arc, lharc and lha are also dandy. Thanks, -ethan -- This message was (fortunately) not brought to you by Intel... "Intel: bringing you the "backward" in backward compatibilty." dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org From billh@comtch.iea.com Thu Dec 30 13:20:25 EST 1993 Article: 566 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!umn.edu!gaia.ucs.orst.edu!connected.com!krel.iea.com!comtch.iea.com!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Bill Haygood's pdp8 emulator Date: 29 Dec 1993 02:29:36 GMT Organization: CompuTech Lines: 189 Message-ID: <2fqq2g$8r6@krel.iea.com> NNTP-Posting-Host: comtch.iea.com Summary: pdp8 emulator questions Keywords: pdp8, emulator X-Newsreader: TIN [version 1.2 PL1] I thought the following conversation contained some interesting points about pdp8 emulation that other pdp8 lovers might find interesting. On Tue, 1993 Dec 28, Charles Lasner wrote: > > > On Tue, 28 Dec 1993, Bill Haygood wrote: > > > On Tue, 1993 Dec 28, Charles Lasner wrote: ----- One of the key points I make against using the RK8E in an emulator is ----- its (unnecessary) complexity. Just how much of the beast is emulated? ----- A true emulator has to pass all of the relavent diagnostics, including ----- that maintainence IOT. Do you really expect to simulate all the proper ----- timings of all of the RK registers shiftable a bit at a time? > > > > I have made no attempt to emulate every register of the RK8E. My emulator > > does not support IOT 6747. Rather, I attempted to emulate sufficiently > > that a file with sector by sector contents looking like an RK05 pack could > > boot. I have never had interest in simulating timings of the actual > > hardware. In other words, if my PT8E runs twice as fast as the actual > > hardware, then I just pretend I have a PT8E that reads at 600 cps. > > Obviously, this may trip up those MAINDECs that check for these kinds of > > timings. > > So, I take it that you are certain that none of the conditions that look > like "errors" can happen, and every normal combination of disk address > info can be passed to DLAG to start a transfer, including setting the > one-page transfer bit. I also assume that DLAG leads to immediate > completion of I/O, and to DSKP skipping, etc. Thus, interrupts can only > occur on non-I/O instructions when the code running is the OS/8 handler. Some errors do get flagged. See 'pdp8misc.c' for details in routines whose names start with 'rk8'. I have re-written some of this based on notes received from Bob Supnik. I have not taken the time to completely implement interrupt service for the RK8E emulator. Obviously, I have not taken time to think through all the issues. > Do you treat attempts to access the disk past the end of RKB0: as an > error? Yes, in that sense, I tried to make it look like a real RK05 pack. > A "real" RK only has 6496 sectors, so the handler is organized as > 3248 RKAu: and 3248 RKBu: where u is 0-3. By patching PIP, RKAu: can be > 4096 blocks, and it's real easy to start RKBu: on record 4096, resulting > in a much smaller size, but the first one is full-size. (Alternatively, > the system area could be made smaller so that the B portion was 4096, but > I doubt if anyone bothered; I do know that the former was done though!) > Thus, it can be argued that an "authentic" emulator wants to have errors > at record 6496, but a "useful" one would allow up to record 8191. That > would allow a 4096 record A and a 4096 record B as well. If it's an error > to access record 6496 and beyond, then you have to emulate all of the > error recovery correctly, including the recalibrate sequence, > heads-in-motion bit, and the more general resets. All of these things can > come about in practical handler code that exists. By allowing a larger > disk, the error stuff can all be avoided. (If you have a good data scheme > for the pack data, then only rarely would blocks past the end get > referenced, so most could be dormant unless the handler accesses all of > them. But the standard handler will occasionally have to deal with the > boundary condition since there are bugs in various programs that allow > access to non-existant blocks. BTW, on the DECmate, to avoid the problem, > the logical size of the RX50 is indicated deliberately slightly too small, > to avoid destruction of the "slushware" tracks further up on the device. > In that case, the records physically exist, but would be endangered by one > of these programs that accesses too far in case it wrote there! I aimed to make RK05 'pack' files portable across big- and little-endian architectures by treating them as byte streams and storing the pdp8 12- bit words in big-endian order with no gaps between words. Thus, I store 2 pdp8 words in 3 bytes in sequential high-to-low bit order. While this may slow the I/O somewhat, the emulator allocates a 32-sector (one cylinder) buffer for each "RK05 drive" and all reads and writes occur to that buffer until the emulator need access to a new cylinder. The emulator maintains a "dirty" flag for each buffered cylinder for each "RK05 drive". In this manner, the emulator does not write the "old" cylinder back to disk unless a "write" occurred to that cylinder from the RK8E emulator. > > > ------- ------- On my Amiga, I deleted the old 'pdp8.ram' and brought up the ------- emulator with the following command: ------- ------- pdp8 -rk8e pack0 -boot ------- ------- Then I executed the following OS/8 commands: ------- ------- .DA ------- .DEL CLEAR.CF ------- .QUIT ------- ------- The '.QUIT' causes the emulator to exit with a 'pdp8.ram' file ------- of about 11K. ----- ----- What determines the size of that file; thus what was so particular about ----- this one? ----- > > > > The contents of the 'hardware' registers and the contents of memory > > (after compression) determine the contents and size of 'pdp8.ram'. The > > 'pdp8.ram' referred to above contained nothing special except that I could > > compare it to the 'pdp8.ram' file on my Amiga after the two versions of > > the emulator executed identical commands. This just proved to me that the > > emulator instruction executions resulted in identical memory conditions at > > the conclusion of each instance of emulation. Thus, I think that the two > > versions of the emulator agreed on CPU emulation. So, I could profitably > > spend time looking at IOT and RK8E emulation. > > > > In other words, after identical executions on the two versions of the > > emulator (Amiga and BBS), the 'pack' files contained the ONLY differences. > > Hence, I believe the RK8E emulator contains the source of the problem. > > While I agree with your reasoning, please note that OS/8 doesn't save > memory that much, thus you are largely looking at the keyboard monitor in > all cases! There isn't much difference between identical takes on the > same machine even if you interchange the order of some of the commands, etc. I agree, but I looked for any straw I could grab! > > > ----- I assume you wrote some hack QUIT.SV that executes some reserved IOT to ----- exit out of the emulator. If so, what's in it? ----- > > > > Jim Van Zee implemented QUIT in the CCL. It simply loads a HLT into > > location 07577 and jumps to it. This allows a restart with a '-cont' > > option at 07600 to restart OS/8 without a reboot. > > What you are saying is that the emulator can be started on a system with > the memory contents defined already? If so, is this the same as a real > machine with core memory in that sense, and not a specific kludge for > OS/8? Thus, if memory of say, field 7 and field 0 where setup > appropriately, a restart at some location, such as 00353 could be done? Yes, yes and yes. Just prior to exit, the emulator compresses all 32K of pdp8 memory and stores the compressed image in the 'pdp8.ram' file. Worst case compression: 52K, best case: 4 bytes. I designed the compression method for speed. At next invocation, the emulator unpacks the 'pdp8.ram' file and a user option of, say, "-cont 353" or "-pc 353 -cont" would "continue" pdp8 instruction execution at location 00353. A "-clear" option would "depress the CLEAR switch" also, if needed. > > > ----- [remainder deleted] ----- ----- cjl ----- > > > > I hope this proves helpful. > > Certainly has. > > cjl > > > > Since submitting the sources to Charles Lasner for anon-ftp on sunsite, I have completely rewritten the EAE to make it more efficient. The new pdp8 initialization sequence loads the instruction vectors for EAE only if the user specified the EAE as an option (-eae). Doing it this way does away with all those "if (EAE)" statements, thereby speeding EAE emulation. If your compiler provides for automatic in-lining of functions, I recommend compiling the EAE emulator (pdp8eae.c) with that option. Until I feel assured that I have the EAE "right", I want to leave some functions to call other functions (e.g., the function which executes "SCA MUY" only does the "SCA", then calls another function to do the "MUY"). Later, I can re-write it for much greater efficiency. I would appreciate some info on "RX50". My absence from and inattention to the pdp8 world for so many years has left me ignorant of the RX50. I would appreciate any specifics you may have. If this has the potential of providing us with a common medium for both the actual hardware and on machines running emulators, then I must undertake a study of how to access the floppy drives on my Amiga. Since I have a program to enable reading/writing of a 3 1/2" floppy in MS-DOS format, this tells me that I can do the same for a pdp8 formatted 3 1/2" floppy--provided I can find the necessary documentation. (The Amiga documentation exists--but I do not understand the need for so much complexity [e.g. the explanation on how to access the serial port takes 12 pages].) -- Bill Haygood "I absolutely reject absolutism." From lasner@sunSITE.unc.edu Thu Dec 30 15:11:21 EST 1993 Article: 567 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Bill Haygood's pdp8 emulator Date: 30 Dec 1993 19:37:59 GMT Organization: University of North Carolina, Chapel Hill Lines: 134 Message-ID: <2fvamn$mdq@bigblue.oit.unc.edu> References: <2fqq2g$8r6@krel.iea.com> NNTP-Posting-Host: sunsite.unc.edu Keywords: pdp8, emulator In article <2fqq2g$8r6@krel.iea.com>, Bill Haygood wrote: >> Thus, if memory of say, field 7 and field 0 where setup >> appropriately, a restart at some location, such as 00353 could be done? > >Yes, yes and yes. Just prior to exit, the emulator compresses all 32K of >pdp8 memory and stores the compressed image in the 'pdp8.ram' file. Worst >case compression: 52K, best case: 4 bytes. I designed the compression >method for speed. At next invocation, the emulator unpacks the 'pdp8.ram' >file and a user option of, say, "-cont 353" or "-pc 353 -cont" would >"continue" pdp8 instruction execution at location 00353. A "-clear" option >would "depress the CLEAR switch" also, if needed. The question about field 7 and field 0 00353 is not a random one. This means that P?S/8 for RK8E should also work under the same emulator! The P?S/8 memory convention is that the system is restarted at 07600 just as in OS/8. However, memory is not saved ever by this operation, and thus more resembles the OS/8 specific of restarting at 07605. (There is no need to save memory, since that function can be handled from ODT; all of field 0 is automatically saved in the two scratch files named % and $ by ODT before exiting to the keyboard monitor. Thus, the vast majority of program exits to 07600 avoid the OS/8 overhead of needlessly saving memory before reloading a downsized keyboard monitor that only occupies 1K and only has 9 commands, and then requires swapping in CCL to execute anything else! The P?S/8 keyboard monitor is 4K long including a built-in line editor and file buffer, etc. When a program is loaded or debugged, etc., it can be controlled by ODT for core-save purposes.) When the specific RK8E version of P?S/8 is restarted at 07600, the keyboard monitor is read in from the disk into 00000-07577. This includes a copy of the file $ if optionally enabled (to allow editing a small text file file auto-save and auto-load). Then the keyboard monitor is restarted at 00353. The system handler that accomplishes the read/writes resides partially in 07600-07777. The rest is in field 7 in 6000-7777. The reason for so much code space is that this is the worst-case allowance for "problematic" devices such as the RK8E. (Note, the RK isn't all that troublesome! However, reserving this much space allows a handler to be written for such a problematic case as a DECmate II,III,III+ RX50 byte-mode system handler, a case OS/8 cannot handle at all! On these machines, OS/8 allows only 12-bit-mode handlers, which wastes 25% of the disk space, and makes the ENCODE and DECODE programs useless for the purpose of transferring entire RX50 images of other systems' disks. Thus, only an ENCODEd OS/278 disk image can be used there, etc. I am working on a P?S/8 non-system handler for the byte-mode case that would be callable from OS/278 as a "TSR" to use the MS-DOS term for it. That would indirectly allow OS/8 to be upgraded for the RX50 handling purpose, etc. P?S/8 non-system handlers are allowed to be up to an entire field. Unlike OS/8 handlers that are restricted to one or two pages and must run in field 0, P?S/8 handlers can be up to 32 pages long, and are page *and* field relocatable. Thus, a P?S/8 byte-mode RX50 handler could totally reside in some part of field 7 under OS/278. OS/278 has the means of limiting access to programs regarding memory size, thus "protecting" the P?S/8 handler now resident in field 7. A dummy handler can be written for OS/278 that comfirms the existence of the P?S/8 handler in field 7, and calls it with a transcribed copy of the arguments of its own caller. Thus, OS/278 is faked out into believing it can handle "foreign" devices, in this case all 400K bytes of a complete RX50 instead of 3/4 of that amount, where the data is "shredded" every 16 bits, i.e., only 12 of every 16 bits are accessible, and the 4 wasted bits are zeroed upon every write operation.) P?S/8 system handlers come in two flavors: the simple case where the entire handler fits into 07600-07777 as does usually the corresponding OS/8 handler, and the "problematic" case where it also is given access to 6000-7777 in the highest field available. (Which is usually field 7; it's the handler's responsibility to determine the proper field and self-relocate at boot time. The only assumption made is that field 1 is available at boot time to initially load into, etc.) Thus, the RK8E version will typically wind up in 76000-77777. The reason for the "troublesome" aspect of the RK8E for P?S/8 purposes is that P?S/8 addresses logical blocks to the nearest half-record on an RK8E while OS/8 "lucks out" and addresses to the physical record. (Note: both systems support page-oriented handler calls. However, OS/8 cannot access a second-half record only; the record can only be accessed to the first half or both halves. Additionally, writing on the first half of an RK8E record will write 0000 to all of the words in the other half. This action only comes about as a consequence of SAVE commands with odd-page-size arguments. OS/8 strictly forbids any attempts to access the second half of a record, thus the SAVE command takes arguments such as 000-177 or 000-377, but *never* 200-377! As thoroughly documented, any reference to the second page forces reference to the first page as well, thus specifying 200-377 is taken as if it was 000-377! Thus, all load and save operations can ask for odd page counts, but only on a first-half record boundary basis. Thus, the only requirement placed on the handler is that should a record be written on the first half of a logical record, the entire record is also readable at a later time without error. The contents of the second half of the record are allowed to be destroyed when writing the first half! The hardware of the RK8E allows this operation by setting a specific one-page bit. Reads will inhibit DMA transfer of the second page; only CRC calculations will be performed on that data. Writes will write 0000 on the second page portion of the record, etc.) Thus, the P?S/8 handler maintains a buffer within the handler. This is used to access the appropriate half of any record involved in a half-sized transfer. Note that the RK8E hardware one-page bit does resolve the case of a request for the first half of the record. To read the second half, the entire record is first read into the buffer, then the second half data is moved to the caller's transfer address. Writing is more complex: first the affected record is read into the buffer, then the caller's data is moved from the caller's transfer address to the appropriate half of the buffer, then the entire record is written out, thus preserving the other half of the buffer not involved logically with the latest operation. Any portion of the caller's disk request that involves either entire record reads or writes are handled identically to the OS/8 handler; normal DMA read or write is used specifying the caller's transfer address for the transfer, etc. Thus, for disk requests with "good" boundary conditions such as most file operations, there is no special overhead associated with this. (The P?S/8 file structure happens to always start on an even boundary and file buffers are even multiples, etc. However, some programs, such as ODT, could require an odd-length call, etc.) The code that accomplishes all of the requisite operations fits comfortably in two pages next to the two-page disk buffer. Thus, there are 4 free pages in the system handler. Future versions may support throughput enhancement such as an elementary cache, etc. (This would improve performance in several situations: P?S/8 DUMP and/or BLKODT can be used for disk patching. THe programs read in a logical block, operate on it in their own buffer, then write out the logical block. The handler always does each of these operations ignorantly. However, the data to be written out just happens to still be in the disk buffer; it need not be read in again before being written out with the new caller data in one half, since the other half is still present from the previous read! Other programs perform sequential reads into a one-page buffer. Thus, the data for the other half is accessed and wasted. If the cache were enabled, the data for the other half of the record, likely needed the next time the handler is called, would already be read in thus saving a disk access!) cjl From lasner@sunSITE.unc.edu Thu Dec 30 19:05:26 EST 1993 Article: 568 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: alt.sys.pdp8 archives available Date: 31 Dec 1993 00:04:29 GMT Organization: University of North Carolina, Chapel Hill Lines: 12 Message-ID: <2fvqad$dj8@bigblue.oit.unc.edu> NNTP-Posting-Host: sunsite.unc.edu The archives of this newsgroup are now available through the end of November, 1993, filed monthly. The earliest file is 9209.asp for September, 1992 (date of inception of the newsgroup) and the latest is 9311.asp for November, 1993. Anonymous ftp to sunsite.unc.edu to gain access to the files. They are stored in the directory: /pub/academic/computer-science/history/pdp-8/usenet/alt.sys.pdp8/*.asp cjl From mbg@world.std.com Fri Dec 31 02:28:17 EST 1993 Article: 569 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!decwrl!world!mbg From: mbg@world.std.com (Megan) Subject: Format of .SV files? Message-ID: Organization: The World Public Access UNIX, Brookline, MA Date: Fri, 31 Dec 1993 00:18:03 GMT Lines: 6 I have been unable to find a description of the format of a .SV file. Can someone possibly post it? Megan Gentry From greelish@news.delphi.com Fri Dec 31 02:29:11 EST 1993 Article: 570 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!paladin.american.edu!europa.eng.gtefsd.com!MathWorks.Com!bigboote.WPI.EDU!noc.near.net!news.delphi.com!news.delphi.com!not-for-mail From: greelish@news.delphi.com (GREELISHT@DELPHI.COM) Newsgroups: alt.sys.pdp8 Subject: David Greelish Date: 31 Dec 1993 00:15:13 -0500 Organization: Delphi Internet Services Corporation Lines: 8 Message-ID: <2g0ch1$aop@news.delphi.com> NNTP-Posting-Host: news.delphi.com Summary: Historical Computer Society Keywords: chac hcs brew history computer Hello, I am the president of HCS. We are a national group dedicated to enthusiasts of old computers. Not so much the technical side but the nostalgia. We publish a bimonthly newsletter called "Historically Brewed". We are looking for a good story about the PDP to run if anyone would be interested. If you would like to subscribe to HB, send $15.00 to: HCS - 10928 Ted Williams Place - El Paso, TX 79934. You can e-mail me on AOL as "Historical". Thanks, -DG From lasner@sunSITE.unc.edu Fri Dec 31 02:29:30 EST 1993 Article: 571 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Format of .SV files? Date: 31 Dec 1993 07:28:14 GMT Organization: University of North Carolina, Chapel Hill Lines: 113 Message-ID: <2g0kae$g2k@bigblue.oit.unc.edu> References: NNTP-Posting-Host: sunsite.unc.edu In article , Megan wrote: > >I have been unable to find a description of the format of a .SV >file. Can someone possibly post it? > > Megan Gentry > There have been several extensions written to the .SV file from various releases of the OS/8 family. I doubt if OS/278 supports some of the extensions which are associated with the KT8A. In any case, I can lookup the exact details if need be. From memory though: It contains a count of up to something like 9 entries that are arguments to be passed to a handler consisting of the page count and field in the proper bits in one word with bit[0] and [9-11] clear (page count in [1-5] with 00000=40 octal, field in [6-8]) and the transfer address in the other word. I think the next word after the count is the overall Job Status Word for the image which gives info such as whether 00000-01777 should/should not be saved before loading, likewise 10000-11777 when this program swaps with the USR or command decoder, etc. The remaining words are the pairs of the entries themselves followed by junk. After this header block comes the image data itself. The minimum size would be a record where the first half is loaded and the other half of the record is junk. The entry for that data would indicate a one page transfer, etc. The maximum size for that part of the image would be 32 pages or 16 records. Even counts always load whole records while odd sizes indicate that the last record in the data segment is to be only first-half loaded, etc. Further, the order of the image is supposed to be highest loading field first so that the problem of how to load field 0 is done only after all other loading is complete. This allows the data to be transferred to scratch blocks on the system device so that a final call to the handler can bring in the remaining data. Note that this means that you cannot tell where the file actually is, since the program is started from that last call (whoops! I forgot a header word which is the starting address!). Note: at that criticl point, that call to the system device just halts on an error return! (No part of OS/8 is left in memory to handle errors!) One problem of version creep in OS/8 is that the JSW bits aren't consistently handled! As of OS/8 V3D, a bit (I believe [5]) was added for the dubious purpose of execution restriction to implement what was originally known as "OS/78" mode. The idea (invented by a long departed manager) was to implement a "less is more" campaign where OS/78 mode inhibits the "R" "RUN" and "GET" commands, but only if this bit is set. This requires that CCL be present to avoid the inability to access the program. (Note, in an infamous event at a DECUS Symposium, this manager was publicly embarassed when an astute user walked over to his demo machine and typed "CCL " and made his system self-destruct! The command "CCL" is the CCL command to disable CCL entirely. The only way to reenable it is to type "R CCL". However, the image of CCL.SV has the infamous bit set, thus this wasn't allowed! Thus, the system was permanently and hopelessly corrupted until the image of CCL.SV could be modified from another system/program that wasn't influenced by OS/78 mode, etc.) Somehow, as of OS/278, there is a problem with OS/78 mode's implementation. Whatever OS/278 mode is, it's clearly a superset of OS/78 mode. However, the images within OS/278 don't have the bit set, nor are they particularly sensitive to it. Instead, if an image has a perverse combination of bits set, an unwanted byproduct is that you cannot use the three commands (R, RUN, GET). For example, ABSLDR.SV has most of the optimization bits set. This eliminates some of the overhead regarding memory swapping of the first quarters of fields 0,1 regarding command decoder and usr. By clearing the optimization bits somewhat, it's then possible to use R ABSLDR in OS/278, yet the stock version cannot. Also, it's clear that the bit does the intended function also (it takes noticeably longer on an RX50, etc.). Clearly all of this is repairable, but the sources of OS/278 have to be finely searched for newly introduced bugs. Note that this has nothing to do with the DECmate hardware, and was likely introduced in either OS/278 V1 which was never publicly released (but shows up on utility disks) or in OS/78 V4 (which was riddled with bugs and was intended for use on 8/e, 8/a and DECmate I). Additionally, there are bugs that interact with the SAVE command in OS/278, which can be demonstrated to fail in ways former systems do not, and this includes mis-settings within the JSW as an additional problematic consequence. (I have documented some of this in the Kermit-12 .BWR file k12mit.bwr.) In any case, the lowest level of data in a .SV file is the 12-bit word. Thus, any cross-system representation of a .SV cannot be based on any 8-bit byte scheme as can a .BN or any text format (such as .PA). It is hoped that someone can formulate an appropriate 12-bit format for 8-bit-byte-oriented machines so that a version of PDP-8 ENCODE can be written for these machines. If the ENBOO utility is used and MSBPCT is used on the 8-bit end, the results of what is a .SV file on the 12-bit end has to be reconstructed on the 8-bit end using the standard "3 for 2" pack/unpack method of constructing 2 12-bit words from 3 adjacent 8-bit bytes in the stream of data. To accurately render the original .SV file, a utility must also be prepared to confirm that the file is an exact multiple of 256 12-bit words in length. This principle is used in the DECODE utility automatically. At the EOF, the DECODE utility demands that there be little or new "overhead" bytes left, and also that they would decode to a single (partial) grouping of encoded data, all members of which are 0000. (Or alternatively, since compression is supported, that the file ends on a block of compressed data.) Any other form of ending is a sure sign of file corruption, etc. As an aside, there used to be a utility called EPIC.SV that was used to create files that were formerly .SV files, but instead could be represented in the form of 8-bit bytes at some level. Presumably it was reversible in function. In essence, this sounds like what .BOO encoding accomplishes except that there isn't any printable encoding, thus the epic file could potentially be smaller. (Note: ENCODE and .BOO support elementary repeat compression; epic clearly didn't, so certain images could compress to a smaller size with .BOO or ENCODE, etc.) cjl