From frank@rover.uchicago.edu Thu Feb 2 10:11:02 EST 1995 Article: 1178 of alt.sys.pdp8 Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!bloom-beacon.mit.edu!crl.dec.com!decwrl!pagesat.net!internet.spss.com!uchinews!rover.uchicago.edu!frank From: frank@rover.uchicago.edu (Frank R. Borger) Subject: Re: DEC part number for RL02 unit number plugs ? Message-ID: Lines: 41 Sender: news@uchinews.uchicago.edu (News System) Organization: Radiation Therapy, Michael Reese Hospital References: <3g8vjn$rbu@hustle.rahul.net> <3gbu4u$bui@nntp1.u.washington.edu> <30JAN199518581687@siva.bris.ac.uk> Distribution: usa Date: Tue, 31 Jan 1995 16:37:43 GMT Xref: bigblue.oit.unc.edu comp.os.vms:85313 alt.sys.pdp8:1178 In article <30JAN199518581687@siva.bris.ac.uk> ard@siva.bris.ac.uk (PDP11 Hacker .....) writes: >In article <3gbu4u$bui@nntp1.u.washington.edu>, seymour@u.washington.edu >(Richard Seymour) writes... >> it's 12-12691-00 (for unit zero... break pins for other numbers) >Not on an RL-drive. There are 2 pins that encode what number it is, and the >shape of the top and bottom edges of these pins is what matters. There is no >easy way of converting one plug into another. Well, kinda. I've converted a couple of '2' plugs to '0' plugs just by cutting some plastic off with a moto-tool, but doing the inverse requires adding some material, a harder thing to do. FWIW, here is the coding. Look at the back of the plug. It looks something like this -------- |______| top pin Bit 0 coding ------> - - <- bit 2 coding | | | | | | | | plug inserted coding-> |_| |_| <- bit 1 coding Viewed from the side, each _________ pin looks something like this _________\__ ------------ _____/ If the plastic extends almost to the end of the pin, it actuates a switch when the plug is inserted, and that data bit is read as a '1'. If it is trimmed back, it is short, it reads a 0. Bit 2 coding goes nowhere on the RL02. The drive won't function unless the plug is in, similar to the operation of similar CDC and Ampex drives. Hope this helps From pi92ts@pt.hk-r.se Thu Feb 2 10:11:21 EST 1995 Article: 1179 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!udel!news.sprintlink.net!pipex!sunic!news.lth.se!news.lu.se!news From: pi92ts@pt.hk-r.se (Tommy Stendahl) Subject: Sparepart for RK05 needed Message-ID: <1995Jan31.081101.24623@nomina.lu.se> Sender: news@nomina.lu.se (USENET News System) Nntp-Posting-Host: krokis.pt.hk-r.se Reply-To: pi92ts@pt.hk-r.se Organization: College University of Karlskrona-Ronneby Date: Tue, 31 Jan 1995 08:11:01 GMT Lines: 7 One of my RK05 is missing one of the controler card (or what ever I should call them) at the back end of the unit. It is the M7680 card, thats the one you set the unit number on. Does anyone has a spare that you can sell to me? Tommy From ivie@cc.usu.edu Thu Feb 2 10:12:36 EST 1995 Article: 1180 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu (Roger Ivie) Newsgroups: alt.sys.pdp8 Subject: Re: DM2 formatter for RD53? Message-ID: <1995Jan31.100737.39936@cc.usu.edu> Date: 31 Jan 95 10:07:37 MDT References: <1995Jan29.211618.39752@cc.usu.edu> <3glgnm$17rr@bigblue.oit.unc.edu> Organization: Utah State University Lines: 27 In article <3glgnm$17rr@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes: > I have the so-called "clandestine" formatter in binary executable form. > It's apparently standalone, thus can be wrapped around any form of > OS/(27)8 system or could even be transferred to COS or P?S/8 accordingly, > etc. It's "distributed" on an OS/278 RX50 without documentation, but all > you need to give it (manually on the keyboard) are the # of cylinders and > heads. It does (most of) the rest. Want to send it my way? I even have a spare RD54 to try it out on. > I so far have been lucky in that I've found disks with no apparent > problems. Perhaps it's because DEC writes lower-density disks than the > rest of the industry? (Remember, DEC formats for 16 512 byte > sectors/track, not 17 as in PC's, etc.) That shouldn't make a difference. It just makes it more likely that the bad spot will wind up in an intersector gap. BTW, the RQDX1 for the MicroPDP-11 formatted hard disks with 18 sectors/track. > 2) I cannot confirm how large CP/M-80 volumes can be, but again I 8MB is the max CP/M can handle. That is 16 bits of 128-byte records. -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready' From rla@rahul.net Thu Feb 2 10:13:00 EST 1995 Article: 1181 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!news.moneng.mei.com!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!rla.a2i!rla From: Bob Armstrong Newsgroups: alt.sys.pdp8 Subject: Re: circuit diagrams for the VT78 Date: 31 Jan 1995 18:52:06 GMT Organization: a2i network Lines: 11 Message-ID: <3gm0sm$3dl@hustle.rahul.net> References: <1995Jan23.162607.1@psiclu.psi.ch> <3g1jlg$4h3@ixnews2.ix.netcom.com> <1995Jan25.095613.39182@cc.usu.edu> NNTP-Posting-Host: bolero.rahul.net NNTP-Posting-User: rla In <1995Jan25.095613.39182@cc.usu.edu> ivie@cc.usu.edu writes: >I have a print set for the VT52, but it certainly did _me_ no good when my >VT78's power supply decided to become a paperweight. The VT78 uses the same power supply as the VT62 (not the 52, as you said) and the VT61. It's an H7832. I do have prints for this power supply if anybody wants to try and fix theirs. -- Bob Armstrong Group: alt.sys.pdp8, Item 1239 (Current Item Range #1238 - #1239) Subject: Re: Sparepart for RK05 needed From: geremin@decus.org.au, DECUS Australia Date: 2 Feb 95 22:41:59 EST In article <1995Jan31.081101.24623@nomina.lu.se>, pi92ts@pt.hk-r.se (Tommy Stendahl) writes: > One of my RK05 is missing one of the controler card (or what ever I should > call them) at the back end of the unit. It is the M7680 card, thats the one > you set the unit number on. Does anyone has a spare that you can sell to me? > > Tommy > -- Hello Tommy, I/we/us etc have a number of spare RK05 drives plus a box of spare parts. If you dont get any offers from close to home please contact me again. Only problem is that 'the collection' has just been moved into new premises of the Australian COMPUTER MUSEUM Society and we have to spend lots of time sorting and cataloguing before we can find anything quickly. Regards, John G. (alias 'megaJOHN') v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v John Geremin, HARDWARE SIG Chairman, DECUS Australia. John Geremin, PDP-11 Support Consultant, MEGATRONICS, Aust. IN%"geremin@decus.org.au" voice: 61-2- 764 4855 (9am-9pm) John Geremin, V.P. and Treasurer, Aust. COMPUTER MUSEUM Society Inc. IN%"geremin@decus.org.au" or fax: 61-2- 764 4679 (24 hours). a/h President, Peugeot Car Club of NSW Inc. -^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^- From russ@cs.indiana.edu Tue Feb 7 09:24:28 EST 1995 Article: 1183 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!howland.reston.ans.net!spool.mu.edu!news.cs.indiana.edu!russ@cs.indiana.edu From: "J Russ" Subject: Re: whereabouts of Gary Coleman Message-ID: <1995Jan31.193014.2582@news.cs.indiana.edu> Organization: Computer Science, Indiana University References: <3gjrlu$19fj@bigblue.oit.unc.edu> Date: Tue, 31 Jan 1995 19:30:09 -0500 Lines: 22 In article <3gjrlu$19fj@bigblue.oit.unc.edu>, Charles Lasner wrote: >In article , >Al Kossow wrote: >>Has anyone heard from Gary Coleman? >>I thought if there was anyone who might know if Gary Coleman of >>Allen Bradley in Cleveland was, it would be here. He was a BIG >>8 collector in the early 80's, had a pdp12 in his basement. > >I haven't heard of Gary Coleman in years. > >However, I and several people I know have far larger collections. > >cj "What, you only have *one* PDP-12 in your basement?" l > >ps: Jeff Russ, who still hasn't contacted me, might know his >whereabouts. If someone can get Jeff to contact me, it would be >appreciated. (Gary too :-).) I bought Gary's PDP12/FPP about 3 years ago. As far as I know he is still in Cleveland. The last time I saw him was at the Dayton Hamfest two years ago. From kgg@mv.mv.com Tue Feb 7 09:24:40 EST 1995 Article: 1184 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!news.sprintlink.net!mv!mv.mv.com!kgg From: kgg@mv.mv.com (Kenn Goutal) Subject: Whither Gordon College PDP-12? Distribution: usa Message-ID: Nntp-Posting-Host: mv.mv.com Sender: usenet@mv.mv.com (System Administrator) Organization: MV Communications, Inc. Date: Wed, 1 Feb 1995 05:58:30 GMT Lines: 8 Does anyone happen to know what became of the PDP-12 that was at Gordon College in Wenham, MA? Last I heard, it had gone to nearby high school (perhaps private), but there the trail has gone cold. -- Kenn Goutal kenn@mv.mv.com http://www.mv.com/users/kgg/kenn.html From bqt@Krille.Update.UU.SE Tue Feb 7 09:24:50 EST 1995 Article: 1185 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!panix!bloom-beacon.mit.edu!eru.mt.luth.se!news.luth.se!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: page wrap for PDP-8? Date: 4 Feb 1995 16:40:27 +0100 Organization: Update Computer Club Lines: 19 Message-ID: <3h075p$nvg@Krille.Update.UU.SE> References: <3gd92t$qcd@Krille.Update.UU.SE> <1995Jan28.193148.39659@cc.usu.edu> NNTP-Posting-Host: krille.update.uu.se In <1995Jan28.193148.39659@cc.usu.edu> ivie@cc.usu.edu writes: >In article <3gd92t$qcd@Krille.Update.UU.SE>, bqt@Krille.Update.UU.SE (Johnny Billquist) writes: >> I think the PC, as all other auto-incrementing stuff is incremented >> before it is used. >If that were the case, you would have to enter the address of the >instruction before the instruction you wanted to start into the switches. Yeah, I realized my glitch right after posting, but didn't feel like cancelling the reply, since it was correct on the answer. Just like me to have go rambling away until I put my foot in the mouth. :-) Johnny -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From jones@pyrite.cs.uiowa.edu Wed Feb 8 13:24:29 EST 1995 Article: 1186 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!news2.near.net!news.mathworks.com!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: comp.sys.dec.micro,alt.sys.pdp8 Subject: Re: DecMate 2 doc conversion Date: 7 Feb 1995 21:47:58 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 13 Distribution: world Message-ID: <3h8pqe$57b@nexus.uiowa.edu> References: NNTP-Posting-Host: pyrite.cs.uiowa.edu Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3623 alt.sys.pdp8:1186 >From article , by robinr@primenet.com (Robin Robbins): > Anybody know where to get a document generated on an old DecMate converted to > something readable by a DOS PC? Recall that the DECmate is a member of the PDP-8 family. There are people who frequent alt.sys.pdp8 who have working DECmates. Some of them will convert DECmate WPS format to other forms, either for cash or as a way to get more 8" floppy disks. Doug Jones jones@cs.uiowa.edu From geremin@decus.org.au Wed Feb 8 13:24:52 EST 1995 Article: 1187 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!munnari.oz.au!news.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!decus!geremin Newsgroups: decus.nop,alt.sys.pdp8 Subject: Re: Sparepart for RK05 needed Message-ID: <1995Feb2.224159.15174@decus.org.au> From: geremin@decus.org.au Date: 2 Feb 95 22:41:59 AEST References: <1995Jan31.081101.24623@nomina.lu.se> Organization: DECUS Australia Lines: 28 In article <1995Jan31.081101.24623@nomina.lu.se>, pi92ts@pt.hk-r.se (Tommy Stendahl) writes: > One of my RK05 is missing one of the controler card (or what ever I should > call them) at the back end of the unit. It is the M7680 card, thats the one > you set the unit number on. Does anyone has a spare that you can sell to me? > > Tommy > -- Hello Tommy, I/we/us etc have a number of spare RK05 drives plus a box of spare parts. If you dont get any offers from close to home please contact me again. Only problem is that 'the collection' has just been moved into new premises of the Australian COMPUTER MUSEUM Society and we have to spend lots of time sorting and cataloguing before we can find anything quickly. Regards, John G. (alias 'megaJOHN') v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v John Geremin, HARDWARE SIG Chairman, DECUS Australia. John Geremin, PDP-11 Support Consultant, MEGATRONICS, Aust. IN%"geremin@decus.org.au" voice: 61-2- 764 4855 (9am-9pm) John Geremin, V.P. and Treasurer, Aust. COMPUTER MUSEUM Society Inc. IN%"geremin@decus.org.au" or fax: 61-2- 764 4679 (24 hours). a/h President, Peugeot Car Club of NSW Inc. -^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^- From lasner@sunSITE.unc.edu Wed Feb 8 13:25:36 EST 1995 Article: 1188 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: comp.sys.dec.micro,alt.sys.pdp8 Subject: Re: DecMate 2 doc conversion Date: 8 Feb 1995 18:25:19 GMT Organization: University of North Carolina, Chapel Hill Lines: 48 Message-ID: <3hb2af$p5v@bigblue.oit.unc.edu> References: <3h8pqe$57b@nexus.uiowa.edu> NNTP-Posting-Host: president.oit.unc.edu Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3625 alt.sys.pdp8:1188 In article <3h8pqe$57b@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article , >by robinr@primenet.com (Robin Robbins): > >> Anybody know where to get a document generated on an old DecMate converted to >> something readable by a DOS PC? > >Recall that the DECmate is a member of the PDP-8 family. There are >people who frequent alt.sys.pdp8 who have working DECmates. Some of >them will convert DECmate WPS format to other forms, either for cash >or as a way to get more 8" floppy disks. > > Doug Jones > jones@cs.uiowa.edu The word "old DECmate" can be misleading. The DECmate I supports RX01/02 8" format while the DECmate II can, albeit rarely, do the same as an obscure option (RX78 which prevents a hard disk; uses the same slot). In any case, he may be referring to RX50 format, common to DM II, III, III+. Using OS/278 and Kermit-12, the files can be transmitted to another site. Using an APU/XPU option on one of these three allows conversion to CP/M or possibly MS-DOS format. In any case, the resultant diskette is readable on a suitably configured PC, etc., meaning 1.2 MB HD 5.25" drive and DOS software such as 22DISK or Raindos/RX50DRVR as required, etc. Even if the machine is a DECmate I, OS/(2)78 and Kermit-12 can send the files to another site directly. The OS/8 solution involves running WPFLOP to make OS/8 files out of the WPS documents. Kermit-12 itself is available from the net, and can be downloaded onto the DECmate through the printer port from a PC. (This is documented in the Kermit-12 file set.) Thus, the only requirement is to get him OS/(2)78 in the first place, since likely he doesn't have it. (DEC didn't help here, since virtually all of these machines were erroneously sold as if they were dedicated word processors, which all of us know isn't the case!) And of course, if the machines *is* a DECmate II or higher, he can obtain RX50 images directly of all relevant software for the machines right from the net. Teledisk is needed so the PC can recreate the RX50 disks, etc. cjl From stewart_andy@decus.org.au Thu Feb 9 06:52:40 EST 1995 Article: 1189 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!news.sprintlink.net!cs.utexas.edu!uwm.edu!msunews!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!decus!stewart_andy From: stewart_andy@decus.org.au Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8 Subject: Re: DEC part number for RL02 unit number plugs ? Message-ID: <1995Feb8.161929.15177@decus.org.au> Date: 8 Feb 95 16:19:29 AEST References: <30JAN199518581687@siva.bris.ac.uk> Followup-To: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8 Organization: DECUS Australia Lines: 26 Xref: bigblue.oit.unc.edu comp.os.vms:85977 alt.sys.pdp8:1189 In article , jlothian@castle.ed.ac.uk (J Lothian) writes: > PDP11 Hacker ..... (ard@siva.bris.ac.uk) wrote: > : In article <3gbu4u$bui@nntp1.u.washington.edu>, seymour@u.washington.edu (Richard Seymour) writes... > : > it's 12-12691-00 (for unit zero... break pins for other numbers) > > : Not on an RL-drive. There are 2 pins that encode what number it is, and the > : shape of the top and bottom edges of these pins is what matters. There is no > : easy way of converting one plug into another. > > A nail-file, he said darkly, works wonders... > > James Oh, the memories! Many Many moons ago, I bought an Twin Tub 11/23 that had been run as drives 2  3 for an identical system. Unit nos 0 and 1 long gone, no terminator either. A kindly DEC FS gave me a part used kit of unit nos. and Terminator, missing Unit no 0. I borrowed a unit no 0 and carefully checked the differences. Application of a hobby type high speed drill with used dental diamond drill to a spare unit no 3 made the drive respond to unit 0. More fine grinding on the face and a black permanent marker create a zero on the front. Andy. PS. Stupid question. I missed the orignal message. Is he after unit nos? From bqt@Krille.Update.UU.SE Sat Feb 11 19:26:44 EST 1995 Article: 1190 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!rutgers!rochester!udel!news.mathworks.com!uhog.mit.edu!bloom-beacon.mit.edu!eru.mt.luth.se!news.luth.se!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail From: bqt@Krille.Update.UU.SE (Johnny Billquist) Newsgroups: decus.nop,alt.sys.pdp8 Subject: Re: Sparepart for RK05 needed Date: 9 Feb 1995 16:44:42 +0100 Organization: Update Computer Club Lines: 32 Message-ID: <3hdd9o$pga@Krille.Update.UU.SE> References: <1995Jan31.081101.24623@nomina.lu.se> <1995Feb2.224159.15174@decus.org.au> NNTP-Posting-Host: krille.update.uu.se In <1995Feb2.224159.15174@decus.org.au> geremin@decus.org.au writes: >In article <1995Jan31.081101.24623@nomina.lu.se>, pi92ts@pt.hk-r.se (Tommy Stendahl) writes: >> One of my RK05 is missing one of the controler card (or what ever I should >> call them) at the back end of the unit. It is the M7680 card, thats the one >> you set the unit number on. Does anyone has a spare that you can sell to me? >> >> Tommy >> >-- > Hello Tommy, > I/we/us etc have a number of spare RK05 drives > plus a box of spare parts. If you dont get any offers from close to > home please contact me again. *Blush* Actually, I owe him that card. I just haven't had time to fix this. Noone can even guess how shameful I feel about this. I have even forgotten it. Tommyy, just kick my ass. Anyway, we'll fix that card one way or another. I have a few extra RK05 drives we can grab it from. How do you want it sent to you? (Or can you come by and pick it up?) Johnny -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From isemmel@ibm.net Tue Feb 14 12:30:13 EST 1995 Article: 1191 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!swiss.ans.net!newsgate.advantis.net!news-m01.ny.us.ibm.net!news From: isemmel@ibm.net Newsgroups: alt.sys.pdp8 Subject: Memories of PDP8 Date: 11 Feb 1995 15:42:07 GMT Lines: 16 Message-ID: <3hilsf$1o92@news-s01.ny.us.ibm.net> Reply-To: isemmel@ibm.net NNTP-Posting-Host: slip168-69.sy.au.ibm.net X-Newsreader: IBM NewsReader/2 v1.09 I worked on PDP8s back in the 60s and reading this newgroup brought back a lot of memories. I remember developing a system one which was targeted for a disk system but the only machine available for testing was one with only a DECTAPE as a bulk storage device. I forget the OS version (OSS/8?) but I had it configured as though I was working on a multiple disk system. As this particular task involved writing a disk-based sort program, you can imagine the time I spent watching the tape wind up and down as it read records from one file, then from another and wrote results to a third and fourth etc. When I think of the power we could program into 4K (and sometimes 8!), I wonder at today's programmers who seem to have trouble achieving much more with megabytes (apart from having the ability to display pretty icons on a screen). Ian Semmel From lasner@sunSITE.unc.edu Tue Feb 14 19:54:49 EST 1995 Article: 1192 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Generated Links, or how NOT to program a pdp-8 Date: 15 Feb 1995 00:47:44 GMT Organization: University of North Carolina, Chapel Hill Lines: 473 Sender: Charles Lasner Message-ID: <3hrivg$13tr@bigblue.oit.unc.edu> NNTP-Posting-Host: president.oit.unc.edu Summary: Avoid poorly implemented features merely because they're there Certain people have inquired about the PDP-8 assembly language feature known as automatically generated links. They assume that the use of this quirk is a "feature" of the machine, since it's found in most of the assemblers for the PDP-8 (PAL8, P?S/8 PAL, PAL-12, PAL-12, DIAL-10, PAL-D, etc.). Link generation is not for the beginner, since it can "bite" you if you don't understand what's wrong with it. (And curiously, the more you know about it, the more you don't want to use it!) A generated link is an attempt to use assembler syntax to cover impossible cases of off-page addressing, and the assembler's (poor) attempt to synthesize a valid instruction to cover the user's intention. PDP-8's have a fixed addressing range, which is basically that addresses must either be on page zero, or on the current page where the instruction itself resides. This applies to direct references to instruction operands. Indirectly, any address in the 4096 word field the current instruction is in can be referenced. However, the pointer address that contains the address of any of these 4096 locations is itself subject to the same rules as the direct reference. These rules are not negotiable! They are intrinsically in the architecture of the machine. (Sometimes programmers think it's merely some demented "punishment" imposed on them by the assembler :-).) Extending the rules slightly, if the machine supports extended memory (which most do), then there are auxiliary registers referred to as the instruction field and the data field. Either can be set to any value in the range of 0-7 (other than in some extended addressing machines using uncommon KT8A or MEC8 hardware; we leave these cases out since they don't contribute to the mechanics of link generation, etc.). If the instruction field is changed (using an instruction such as 62N2 where N is the desired field 0-7) then the next instruction that is a JMP or JMS will transfer the value from the 62N2 instruction (since execution of the 62N2 this value is being held in a buffer known as the instruction field buffer) into the instruction field itself. This means that at that point, the immediate next instruction will be fetched from the new field N, i.e., all further execution occurs in the 4096 words of field N; the old field is lost. (Note: interrupts are inhibited when 62N2 is executed and are allowable again only after the new field is established. This prevents interrupt-driven interaction with the field change!) This hardware allows the programmer to write cross-field callable subroutines that require some additional housekeeping instructions to manage the disposition of the calling field, etc. It is the programmer's responsibility to both design and maintain the conventions to be applied, etc. (A practical example will be presented later.) The data field can be changed at any time using an instruction of the form 62N1 where N is 0-7 to specify a new choice of data field. The data field is the field used whenever any of the following instructions are used: AND I xxxx TAD I xxxx ISZ I xxxx DCA I xxxx Explicitly, instructions of the form JMS I xxxx and JMP I xxxx *DO NOT* use the data field. This is actually the crux of the matter in the problem with link generation. Assuming that cross-field callability isn't a consideration, subroutines are generally called as follows: *200 CALLER, JMS I PSUB /CALL THE SUBROUTINE *377 PSUB, SUB *1000 SUB, .-. /SUBROUTINE HEADER . /BODY OF SUBROUTINE . /" . /" JMP I SUB /RETURN TO CALLER Thus, by using a local pointer to the subroutine SUB, callers can call the subroutine from any page. If there are sufficient callers, it could make sense to move the pointer to page zero: *177 PSUB, SUB This would allow all callers to use the same pointer, thus saving current page space on each page making one or more calls, etc. An acceptable embellishment to this process is the use of literals. Literal generation imposes a restriction on the design of the program. Specifically, the programmer gives up access to the end of each current page and also to the end of page zero. In exchange for this, tables are automatically generated in these locations to contain the pointers as required, etc. Thus, the example can be embellished to: *200 CALLER, JMS I (SUB) which puts the pointer to SUB into 0377. Or if there are sufficient callers to warrant a page zero reference: CALLER, JMS I [SUB] which puts the pointer to SUB into 0177. In all cases, literals are generated with addresses decrementing as required. A PE or Page Exceeded error is the case where the highest address of the code stream or user-defined storage or constants would overlap with the lowest address of the table, i.e., there isn't enough room on the page for that many instructions and literals. Something must be moved off the page to make it fit correctly. (Note: there is no "punishment" here! If no literals were being used, and each instruction referenced a user-defined address, the code still would be too large to fit. However, the exact address of the first noted assembly error could perhaps be in a different place.) Similarly, a ZE or page Zero Exceeded error means the same thing has occurred on page zero. So far, the programmer has complete addressing control of his program (other than the automatic table generation within the scope of literal generation if opted for). Now we come to link generation. A lazy programmer (LP) can ask the assembler to "fake" certain things for him using literals. For example, the LP can use the following syntax *200 CALLER, JMS SUB (rest of example is as above) What the assembler is prepared to do (if link generation is enabled and not flagged as an error) is to FAKE the operation using precisely what the syntax of the literal form would be. Thus, the ACTUAL instructions generated are: *200 CALLER, JMS I 0377 *0377 SUB In fact, if the syntax were mixed, i.e., some cases of using JMS I (SUB) and some lazy usages of JMS SUB, the literal generator would even optimize the code and use the same literal! (Score one point in favor of the lazy programmer! :-)) LP's will defend their laziness with some "interesting" notions. For example, they "know" that the assembler will just "figure out" all of the inappropriately called subroutines, so they never have to worry about where the calls wind up, etc. While this is largely true, there are some shortcomings: 1) If there are sufficient callers on different pages to a subroutine on yet a different page, then it would be more space efficient to elect to use a page zero pointer for all of the calls. This would eliminate the space wasted by all of the different current page links. 2) Link generation encourages general sloppiness, i.e., no attempt is made to group subroutines to fit on the same page as the bulk of their callers. In many situations, proper ordering of code can eliminate most if not all links entirely. Similarly, if programs do occasional JMP instructions to another page, the generated link can make the LP's intention generate code to match the attempt, albeit taking more space than it might, etc. So far, the use of link generation isn't "fatal" since the program *does* still follow the intended logic, even if sloppy. However, the link generation mechanism DOES NOT follow the above mechanism. Instead, ALL addressing instructions use the same assembler mechanism to attempt to fix up the LP's input, even if the hardware doesn't support it! Consider the following: *200 TAD TOOFAR *400 TOOFAR, This sequence will of course generate the same code as: *200 TAD I 0377 *0377 400 Assuming the program strictly operates in a 4K machine, the link generation would be valid. But if the machine actually has extended memory hardware (8K or more), the assembler has no way of knowing what the dynamic data field of the moment is at the point of execution! Thus, the following represents an unrecoverable sloppiness: *200 CDF 00 JMS SUB *400 CDF 10 JMS SUB *1000 SUB, .-. TAD TOOFAR JMP I SUB *1200 TOOFAR, In this case, the TAD TOOFAR actually generates TAD I 1177 where 1177 in turn gets the value 1200. In the cases where the data field incidentally matches the program's instruction field, the generated link actually works as intended. But in the other case where the data field is set to another field, the code erroneously references location 1200 in that other field! In essence, use of generated links means that the LP has to also be non-lazy, but in a different way: The LP has to hand inspect a listing of his program, searching out each and every assembler statement where a LG (link generated) exists. If this is not flagged as an error, the only indication is that the octal value of the instruction is appended with a ' character to indicate the generated link. For each and every link-infested line, the programmer must determine if the link pertains to a JMP or JMS. For all others, the programmer must then spend time analyzing the extended memory consequences of whether the data field would ever differ from the instruction field at that particular point of the code. Since the assembler never makes any distinction, it's always necessary to perform this manual check. It would appear to be more productive to merely NEVER USE LINKS in the first place! Thus, a well-organized program would use no links, and instead make link generation either an error, or a disabled feature. In PAL8, links cannot be disabled, but they can be made into assembly errors using the /E switch. In P?S/8 PAL, there are actually four possibilities. Links generation requires literal generation as a subset. In P?S/8 PAL, literal generation is itself an option. Thus: Do not generate literals or links /Q Generate literals; do not generate links /O Generate literals and links, but flag links as errors /Q and /O Generate literals and links, don't flag LG errors The last two cases are equivalent to what PAL8 does. If links are disabled, the error reduces to the PAL III-compatible Illegal Reference IR error, meaning an attempt to reference an address off the current page. Note: in all cases, syntax such as: JMS I TOOFAR PAGE TOOFAR, Is flagged as at least an Illegal Indirect II error, since the instruction is already indirect and not possibly a candidate for a link generation. In P?S/8 PAL with links disabled, this is merely an IR error. (Note: the reason for the first two P?S/8 options is that P?S/8 PAL is a 4K assembler that takes advantage of 8K or more only if available. Thus, if certain features are disabled, it may still be possible to assemble small programs in less memory. PAL8 always runs in 8K minimum, thus there was never felt a design need to make the assembler more "frugal". Thus, there are a small class of assembler options in P?S/8 PAL that are deletable only to allow the possibly better use of remaining memory, etc. When P?S/8 PAL concludes an assembly, it reports the minimum amount of memory actually required to assemble a program given the options enabled. This value is actually reported to the nearest 1K, as P?S/8 configurations may involve fractions of a field, etc. Thus, the user has an idea of how much memory would be needed were the program assembled on a smaller machine, etc. Options may have to be deleted to accommodate this value as necessary, etc.) A practical cross-field-callable subroutine mechanism is included here: By restricting the data field to be that of the calling field, a subroutine can do all things subroutines ordinarily do, such as parsing off arguments, making in-line/skipped returns, etc. Arguments must either have implicit fields, or alternatively must be restricted to being in the same field as the caller. Consider the P?S/8 system handler call: FIELD 3 /AN ARBITRARY FIELD *200 /AN ARBITRARY ADDRESS CDF 30 /SET THE DATA FIELD TO OUR OWN FIELD CIF 00 /THE SUBROUTINE IS IN FIELD 0 JMS I (7640) /THE SUBROUTINE ENTERS IN 07640 ADDRESS /ADDRESS OF DISK BUFFER IN FIELD 4 200+40 /READ TWO BLOCKS INTO FIELD 4 100 /WANT TO READ BLOCK 100 AND 101 HLT /RETURNS HERE FIELD 4 /AN ARBITRARY FIELD *1000 /AN ARBITRARY ADDRESS ADDRESS, /DISK BUFFER HERE In this case, the caller indicates calling from field 3 by setting the data field accordingly. Inline arguments are allowed which indicate all parameters of a read call involving a totally different field. A fragment of the system handler to deal with this might look like this: FIELD 0 /WHERE THE HANDLER IS *7640 /WHERE IT ENTERS HANDLER,.-. /ENTRY POINT OF HANDLER CLA /CLEAN UP; DIRTY CALLERS COULD HURT! RDF /GET CALLING FIELD TAD (CIF CDF) /FORM CIF CDF CALLING FIELD DCA EXITINS /STORE FOR LATER TAD I HANDLER /GET FIRST ARGUMENT IN CALLER'S FIELD DCA WHAT1 /STASH IT ISZ HANDLER /BUMP TO NEXT ARGUMENT TAD I HANDLER /GET SECOND ARGUMENT FROM CALLER AND (70) /JUST FIELD BITS TAD (CDF) /FORM CDF TO CALLER'S DISK BUFFER DCA DSTRINS /STORE FOR LATER ISZ HANDLER /BUMP TO THIRD ARGUMENT TAD I HANDLER /GET BLOCK ARGUMENT DCA BLKWHAT /STORE FOR LATER ISZ HANDLER /BUMP PAST LAST ARGUMENT CDF 00 /WE NEED TO OPERATE ON OUR OWN FIELD . /BODY OF HANDLER . /" DSTRINS,.-. /WILL BE CDF TO CALLER'S DISK FIELD . /MORE HANDLER . /" EXITINS,.-. /WILL BE CIF CDF CALLER'S FIELD JMP I HANDLER /RETURN TO CALLER PAST HIS ARGUMENTS The body of the subroutine operates in field 0. At some point, it needs to access the caller's disk buffer using a CDF to that field, so an in-line instruction for that purpose is manufactured. Eventually, the program exits using a CIF CDF instruction to the caller's field. Other mechanisms are possible, such as passing the address of where in an implied field an argument must be. In P?S/8 non-system handlers, a pointer to a group of three arguments is used, similar to the above example. The only restriction is that the three argument group must itself be in the caller's field. The pointer to the group is one of the passed arguments in-line to the call and skipped around when exiting back to the caller, etc. As bad as generated links are, there is an assembler that takes this process to a "higher plane" called PAGE8. In PAGE8, PDP-8 code need not be organized according to the conventional page boundaries! Instead, the code is faked using link generation as a starting point. Considering the following subroutine: *371 /REAL NEAR THE END OF A PAGE SUB, .-. /ENTRY POINT TAD I SUB /GET IN-LINE ARGUMENT DCA TEMP /STORE IT ISZ SUB /SKIP PAST IN-LINE ARGUMENT CLA /SOME MORE INSTRUCTIONS NOP /" JMP I SUB /RETURN TO CALLER TEMP, .-. /TEMPORARY STORAGE How could such an example work? The answer is that the following code gets generated: *371 /REAL NEAR THE END OF A PAGE SUB, .-. /ENTRY POINT TAD I SUB /GET IN-LINE ARGUMENT DCA I 0375 /STORE IT JMP I 0376 /CONTINUE ON NEXT PAGE TEMP NEXTPAGE JUMPRET,JMP I SUB /NEEDED TO EXIT *400 ISZ I 577 /SKIP PAST IN-LINE ARGUMENT CLA /SOME MORE INSTRUCTIONS NOP /" JMP I 576 /JUMP BACK TO THE "JMP I SUB" TEMP, .-. /TEMPORARY STORAGE *576 JUMPRET SUB In essence, if a subroutine can't fit, a JMP I SUB instruction is reserved at the end of the page because the only way to execute this instruction is on the original page. In fact, any form of indirect addressing requires some fixup code generation, possibly in the form of subroutines merely to execute an indirect instruction from the only page where it can do the proper thing, but called from the page of the additional fixup, etc. Additional literal-like words are generated as various forms of fixup on either side of the hardware page break to allow each portion of the split code to create indirect instructions that carry out the intention of the original code, etc. There are numerous holes in this exercise where the data field can make the entire thing break down as in the more trivial case of generated links! (Note: the examples here are mythical; PAGE8 actually uses a syntax reminiscent of IBM 360/370 assembler including DC, EQU, etc. However, the essential logic of the code generation is presented accurately enough to point out the shortcoming regarding the inability to depend on the data field, etc. As to whether anyone wants to program the PDP-8 using older IBM-like assembler syntax is an entirely different matter!) Thus, anyone considering programming in PDP-8 assembly language is advised to use features that actually match the hardware. It's not necessarily true that all available utilities adhere to that requirement! cjl From jones@pyrite.cs.uiowa.edu Wed Feb 15 23:55:46 EST 1995 Article: 1193 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!rutgers!rochester!udel!news.mathworks.com!news.alpha.net!uwm.edu!news.moneng.mei.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Emulators Date: 14 Feb 1995 15:43:35 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 57 Distribution: world Message-ID: <3hqj37$oep@nexus.uiowa.edu> References: <3hq58t$mj8@lyra.csx.cam.ac.uk> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <3hq58t$mj8@lyra.csx.cam.ac.uk>, by sgp13@cus.cam.ac.uk (Stephen Pratt): > what exactly is the operation of the CAF instruction. CAF is exactly the same as hitting the CLEAR switch on the front panel. I checked the schematic to verify this! AC and LINK are cleared; PC is not changed. The INITIALIZE signal goes to each device. The documentation is indeed vague about whether or not this disables interrupts, but the schematics make it clear that the INITIALIZE signal does disable interrupts! My emulator does the following: link = 000000; ac = 00000; irq = 0; enab = 0; enab_del = 0; Note that the initialize signal also has an effect on each device, and that the response of the device is arbitrary and defined by the device designer -- you've got to read the writeup on each device you emulate to see if this causes that device to enable or disable interrupts. The standard is that the device ready and done flags are reset and the device specific interrupt enable flag is set, but not all devices conform to this standard! > > Also could someone fill me in on the exact meanings of bits 3 and 4 > of the flags register as listed on page 3.14 of the 'Small Computer > Handbook'? I'd love to help, but what edition of the Small Computer Handbook are you referring to? I've got just about all of them at home, but the copy I have at work (1973) has no flags register on page 3-14. If you mean the flags register returned by GTF, page 4-8 of the 1973 handbook gives these as: AC3 = interrupt inhibit flipflop AC4 = interrupt enable flipflop The interrupt enable flipflop is the one set and reset by the ION and IOF instructions. Usually, it's the only one you care about. The interrupt inhibit flipflop belongs to the KM8E memory management unit. My schematics for that are at home, so I can't answer definitively, but note that many KM8E instructions inhibit interrupts until the next JMP or JMS instruction. I believe that is the function of the inhibit flipflop. If you haven't looked at the documentation available from my web page, check out http://www.cs.uiowa.edu/~jones/pdp8/index.html Among other things, you'll find a fairly well developed PDP-8 emulator there, with complete and fairly good support for X-windows. Doug Jones jones@cs.uiowa.edu From lasner@sunSITE.unc.edu Thu Feb 16 00:10:59 EST 1995 Article: 1194 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Emulators Date: 16 Feb 1995 05:09:33 GMT Organization: University of North Carolina, Chapel Hill Lines: 53 Message-ID: <3hummd$1ae3@bigblue.oit.unc.edu> References: <3hq58t$mj8@lyra.csx.cam.ac.uk> <3hqj37$oep@nexus.uiowa.edu> NNTP-Posting-Host: president.oit.unc.edu In article <3hqj37$oep@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: > > AC3 = interrupt inhibit flipflop > AC4 = interrupt enable flipflop Actually, there is a problem here. There are actually three variations: 1) The paper version of the PDP-8/e manual. 2) The real hardware of the PDP-8/e computer. 3) The revised nature of how the 6120 handles this differently. The PDP-8/e manual claims that the interrupt inhibit flip-flip can be read back with GTF. You can see the bit on the front panel, but you cannot read it back in the hardware. Several diagnostics pragmatically check for it to be that way. The designers of the PCM-12 6100-based machine rolled their own extended memory hardware. They assumed the manual was correct, but then their machine flunked the diagnostics. So they added a jumper to make it the "right" way or the "DEC" way. So on that machine, you can do it as documented or compatibly deficient, your choice. On the 6120, things are a bit different. To avoid the entire mess, bit[3] is the power-on flip-flip, which just means that you haven't issued a CAF yet, and are in the state of POST, so you can allow yourself some once-only initialization, etc. Bit[4] on the 6120 reads back a 1 always. The reason is the differing behavior for RTF. On the -8/e, RTF always enables interrupt. On the 6120, RTF loads AC[4] into the ION flip-flop. This way, interrupt sequences that start with GTF and end with RTF are compatible, although what's happening in bit[4] is quite different fore and aft! A related change: the 6120 clears the AC after the RTF. A good thing, since by definition this information is worthless (it is always loaded from a saved copy in memory my nature, thus this makes the interrupt handler a cycle/instruction shorter.). But for compatibility with the -8/e, you have to do a CLA after the RTF anyway, thus this is only for truly 6120-based interrupt routines, etc. In any case, all machines agree that RTF inhibits interrupts until the next JMP or JMS (assuming RTF did enable the interrupt, an issue only on the 6120.) BTW, the 6120 also has GCF, get current fields. Same layout as GTF, but it's the current info, not what's saved on an interrupt. I guess they had to do something with all of those extra instructions returned by no possibility of KT8A or time-share trap compatibility :-). cjl From sgp13@cus.cam.ac.uk Fri Feb 17 14:10:49 EST 1995 Article: 1195 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!jussieu.fr!news.oleane.net!pipex!lyra.csx.cam.ac.uk!camcus!sgp13 From: sgp13@cus.cam.ac.uk (Stephen Pratt) Newsgroups: alt.sys.pdp8 Subject: Emulators Date: 14 Feb 1995 11:47:41 GMT Organization: U of Cambridge, England Lines: 18 Message-ID: <3hq58t$mj8@lyra.csx.cam.ac.uk> NNTP-Posting-Host: ursa.cus.cam.ac.uk I am currently writing an emulator for the PDP8/e Please could someone out there help me with the following: what exactly is the operation of the CAF instruction. Specifically, does it have any effect on the interrupt system, in the way of enabling/disabling interrupts? Also could someone fill me in on the exact meanings of bits 3 and 4 of the flags register as listed on page 3.14 of the 'Small Computer Handbook'? Thank you -- ----------------------------------------------------------------------- Stephen Pratt 34 Grantchester Street CAMBRIDGE CB3 9HY 'The discerning heart seeks knowledge' ----------------------------------------------------------------------- From bb@informatik.uni-hannover.de Wed Feb 22 08:15:48 EST 1995 Article: 1196 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.rwth-aachen.de!newsserver.rrzn.uni-hannover.de!news From: bb@informatik.uni-hannover.de (Bernhard Baehr) Subject: Macintosh PDP-8/E Simulator Message-ID: <1995Feb17.100427.26319@newsserver.rrzn.uni-hannover.de> Sender: news@newsserver.rrzn.uni-hannover.de (News Service) Reply-To: bb@informatik.uni-hannover.de Organization: RRZN Date: Fri, 17 Feb 1995 10:04:27 GMT Lines: 40 I announce the availability of the final version 1.0 of my simulator for the DEC PDP-8/E minicomputer running on the Apple Macintosh computer. The simulated machine is a PDP-8/E with 4K words of memory and an ASR 33 console teletype. Optionally a MC8-E Memory Extension (with up to 32K words of memory), an EAE, an auxiliary ASR 33 teletype, a high speed paper tape reader and punch, a RK8-E disk system, a LP8-E line printer and a Real Time Clock can be attached to the simulated PDP-8/E. The simulator is based on the PDP-8/E emulator of Bill Haygood. It is known to run on a wide variety of 680x0 and PowerPC Macintoshs running System 6.0.4 to 7.5. (Probably it runs on any Macintosh with System 4.1 or better and 128K ROMs.) The current version of the simulator does not contain native PowerPC code. On the fastest 68040 Macintoshs the simulated PDP-8/E runs nearly with the speed of a hardware PDP-8/E. The simulator provides a comfortable user interface for running, writing and debugging PDP-8 software. For each device, there is a separate window which displays the internal state of the device (e. g. register and - disassembled - memory content). Register and memory content can be modified by mouse clicking. Other features of the simulator are breakpoints, break opcodes, single step execution, a trace mode for the PDP-8/E and much more. The simulated ASR 33 teletypes provide all comfort of Macintosh text editor windows. There is no manual for the PDP-8/E Simulator, but the program has full Balloon Help support, and there is a help window which gives detailed information about the PDP-8 instruction set implemented by the simulator and hints for operating the simulator. Anybody who wants to get the simulator may ask me to send him a copy of the program by E-mail. Bernhard Baehr bb@informatik.uni-hannover.de From ivie@cc.usu.edu Wed Feb 22 08:17:11 EST 1995 Article: 1197 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!ncar!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu (Roger Ivie) Newsgroups: comp.org.decus,alt.sys.pdp8 Subject: Re: 12 bits x 250 lbs Message-ID: <1995Feb20.135936.42321@cc.usu.edu> Date: 20 Feb 95 13:59:35 MDT References: <8A39599.040600075B.uuout@compudata.com> Distribution: world Organization: Utah State University Lines: 21 Xref: bigblue.oit.unc.edu comp.org.decus:6234 alt.sys.pdp8:1197 In article <8A39599.040600075B.uuout@compudata.com>, david.razler@compudata.com (DAVID RAZLER) writes: > > HELP! > > PDP-8 stroke nuthin in need of parts for rehabilitation. I am in > desperate need of either: a tabletop base, walnut panels and plastic module > covers OR plans for same, spare modules, especially R200 series (I need a > whole EAE OR plans for "uninstalling" one) DECOLOG and other print material > and software for my original - beast was first used in the only nuke plant > in Vermont in a custom rack, I'm trying to convert it into a textbook > design classic desktop + ASR-33 4K system. Have some DEC gear to trade, > including a great deal of 18-bit doc. > dmr > [david.razler@compudata.com] I've crossposted this to alt.sys.pdp8, as some folks there should be able to help. Personally, I don't have a complete -8 stroke nothin'. -- ----------------+------------------------------------------------------ Roger Ivie | Never underestimate the bandwidth of a ivie@cc.usu.edu | truckload of tapes From jones@pyrite.cs.uiowa.edu Fri Feb 24 10:24:50 EST 1995 Article: 1198 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: Emulators Date: 22 Feb 1995 14:55:13 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 22 Distribution: world Message-ID: <3ifj8h$a7g@nexus.uiowa.edu> References: <3idgre$gt3@lyra.csx.cam.ac.uk> NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article <3idgre$gt3@lyra.csx.cam.ac.uk>, by sgp13@cus.cam.ac.uk (Stephen Pratt): > If I issue the following sequence on a PDP8/e - does the interrupt > system end up enabled or disabled? > > ION > IOF The answer is in Figure 3-99 in the PDP-8/E Maintenance Manual, Volume I, April 1971 edition. ION enables interrupts with a one instruction delay by setting the interrupt enable flipflop, which is clocked into the interrupt delay flipflop one instruction later; the output of the interrupt delay flipflop actually controls whether interrupts are enabled. IOF disables interrupts by resetting both the interrupt enable and interrupt disable flipflops. Therefore, the sequence ION;IOF leaves interrupts disabled. Doug Jones jones@cs.uiowa.edu From sgp13@cus.cam.ac.uk Fri Feb 24 10:24:58 EST 1995 Article: 1199 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!news.moneng.mei.com!howland.reston.ans.net!news.sprintlink.net!pipex!lyra.csx.cam.ac.uk!camcus!sgp13 From: sgp13@cus.cam.ac.uk (Stephen Pratt) Newsgroups: alt.sys.pdp8 Subject: Emulators Date: 21 Feb 1995 20:01:50 GMT Organization: U of Cambridge, England Lines: 15 Message-ID: <3idgre$gt3@lyra.csx.cam.ac.uk> NNTP-Posting-Host: ursa.cus.cam.ac.uk If I issue the following sequence on a PDP8/e - does the interrupt system end up enabled or disabled? ION IOF Cheers Stephen -- ----------------------------------------------------------------------- Stephen Pratt 34 Grantchester Street CAMBRIDGE CB3 9HY 'The discerning heart seeks knowledge' ----------------------------------------------------------------------- From lasner@sunSITE.unc.edu Fri Feb 24 11:02:15 EST 1995 Article: 1200 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Emulators Date: 24 Feb 1995 16:02:44 GMT Organization: University of North Carolina, Chapel Hill Lines: 110 Message-ID: <3ikvv4$1k89@bigblue.oit.unc.edu> References: <3idgre$gt3@lyra.csx.cam.ac.uk> <3ifj8h$a7g@nexus.uiowa.edu> NNTP-Posting-Host: president.oit.unc.edu In article <3ifj8h$a7g@nexus.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: > > ION enables interrupts with a one instruction delay by > setting the interrupt enable flipflop, which is clocked > into the interrupt delay flipflop one instruction later; > the output of the interrupt delay flipflop actually controls > whether interrupts are enabled. > IOF disables interrupts by resetting both the interrupt enable > and interrupt disable flipflops. ^^^^^^^ delay IOF turns off interrupts immediately regardless of whether they were pending or not. ION turns interrupts on after a one-instruction delay. However, if there is an extended memory control present, then CIF, or any other instruction that loads the instruction field, will inhibit interrupts from occurring until the next JMP or JMS occurs. On the PDP-8/e and -8/a, RTF enables interrupts and also causes the same one instruction delay. This is to ensure that a 4K -8/e or -8/a without an extended memory controller still gets the one-instruction interrupt delay. Thus, if extended memory control is also present, interrupt gets enabled, one-instruction delayed, and also inhibited, all at the same time. The usual sequence of instructions is RTF CLA JMP I xxxx The CLA is necessary because the AC contained the reload value, presumably from a former GTF at the point of interrupt. Practical interrupt handlers also need something like TAD SAVEAC after the CLA to reload the AC to what it was before the interrupt as well, etc. The xxxx is usually 0000 in a simple interrupt handler, but stack-oriented interrupt handlers (where an interrupt routine is itself interruptible after it clears the source of the interrupt but not yet has handled the consequences, etc.) may pull the return address off of a stack, and thus need not use 0000. On the 6120, it works a bit different. The GTF instruction always reads back a 1 in the bit which on the -8'e is the "is interrupt on" (bit[4]). Thus, when RTF is executed, this bit is a 1. The 6120 RTF doesn't necessarily enable interrupts unless this AC bit is set, else it clears it. But since the GTF sets the bit to a one, the combination works effectively the same as on the -8's. Additionally, the 6120 RTF clears the AC, thus 6120-specific interrupt routines can be one instruction shorter eliminating the CLA after the RTF. On the front panels of the Omnibus machines, you can see the "no int" bit[3]. But the instructions such as GTF *do not* read the bit back. The manual is wrong on this point since it claims that it does happen, but said claim is false. The -8/e diagnostics won't work if you follow the manual! The *light* will come on if you execute CIF or RMF or RTF, etc. but you cannot read it back with an instruction. On the 6120, GTF and GCF read this bit as a 0 always as well etc. The designers of the PCM-12 6100 machines got "bit" on this point as well. They designed a board that went by the manual. As a result, it can't pass some diagnostics. The added a jumper to to it the "right" way or the "DEC" way. On the Intercept or PCM-12 6100 machines, the front panel is emulated in software using a variable clock that causes CP interrupts. The faster it updates, the slower the effective -8 speed is, and you can also disable it if desired, etc.. Unless you enable the bit to read back the no int state with GTF (which is part of the CP front panel routines), the front panel won't light the no int light when it ought to! I have written some code for a PDP-12 with a minimum of 4K. Some of it is interrupt driven, and in spots uses LINC instructions. The LINC is not only incompatible, it has its own interrupt location (00040) and rarely is LINC interrupt uses. Thus, LINC code has to prevent interrupts in general. The ION one instruction delay is insufficient since LINC code tends to be several instructions long before returning to PDP-8 mode. IOF in front of the code is unacceptable because you cannot know the former state of the interrupt within this code. (On the -8/e, you can use SKON to determine whether to restore interrupts later.) Well, it turns out that even a 4K PDP-12 has extended memory control! Just use CIF 00 in front of the LINC instruction etc. and it can't be interrupted. (Note: LINC JMP instructions must be avoided!) (Note: the LINC instruction set is 1K oriented with a 1K data field. Thus even a 4K -12 is considered to have extended memory. If a PDP-8 interrupt routine fails to perform the appropriate RMF instruction, it won't restore the LINC extensions to the appropriate 1K-oriented values. The PDP-8 extended memory instructions have been modified to incorporate the LINC 1K extensions for interrupt purposes. Thus, RMF restores more than just the PDP-8 IF and DF, etc. So, as a result, CIF was implemented with interrupt inhibit even in the basic machine, etc. Should a LINC JMP instruction occur after a CIF, you wind up in the 0th quarter of LINC memory, an unwanted quirk! Thus, short LINC sequences better not use JMP if after CIF. Interrupt routines must use RMF to completely restore the LINC memory considerations. Alternatively, a complicated routine could be written using the extended definition of RIB for the PDP-12 which reads back the LINC memory quarter values as well as the PDP-8 values for 32K by fields. Appropriate instructions could then be created in-line to deal with it. But it's a whole lot easier to just use RMF, and additionally is compatible with the same code for straight PDP-8 operation. All of this is prior to the Omnibus style of the GTF/RTF sequence, and is the only way to write generic interrupt routines for all PDP-8 models, such as is found in FOCAL, 1969 etc.) cjl From n1ist@netcom.com Sat Feb 25 03:17:14 EST 1995 Article: 1201 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!ix.netcom.com!netcom.com!n1ist From: n1ist@netcom.com (Michael L. Ardai) Subject: Re: Att: MIS Employees Message-ID: Organization: Utopia Planetia Shipyards - Mars References: Date: Fri, 24 Feb 1995 22:14:19 GMT Lines: 12 Sender: n1ist@netcom4.netcom.com In article sigurds@husc.harvard.edu (Dirk Sigurdson) writes: -Attention: MIS Employees -The nations largest recruiting company is looking for you! Oh goodie! Now I can put my PDP-8 experience to some good use :-) /mike -- \|/ Michael L. Ardai N1IST Teradyne ATB, Boston MA -*- ------------------------------------------------------------------------- /|\ ardai@maven.dnet.teradyne.com n1ist@netcom.com