Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 7 May 91 03:04:13 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 7 May 91 03:00:50 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09067; Tue, 7 May 91 02:38:25 EDT Received: from gsusgi2.gsu.edu by mc.lcs.mit.edu id aa03773; 7 May 91 2:38 EDT Received: by gsusgi2.gsu.edu (5.65+bind 1.5+ida/901025.SGI.UNSUPPORTED.PROTOTYPE) (for PDP8-LOVERS@MC.LCS.MIT.EDU) id AA07225; Tue, 7 May 91 02:38:54 -0400 Date: Tue, 7 May 91 02:38:54 -0400 From: "Ken A. Sturrock" Message-Id: <9105070638.AA07225@gsusgi2.gsu.edu> To: PDP8-LOVERS@mc.lcs.mit.edu Subject: does this still exist? Date: Tue, 7 May 91 02:38:54 -0400 From: "Ken A. Sturrock" To: PDP8-LOVERS@mc.lcs.mit.edu Subject: does this still exist? does this list still exist? If so, I'd like to join! -ken sturrock ------------------------------------------------------------------------------- Ken Sturrock (internet) antkasx@gsusgi2.gsu.edu (bitnet) antkasx@gsuvm1 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 7 May 91 16:45:32 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 7 May 91 16:42:07 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA25100; Tue, 7 May 91 12:29:03 EDT Received: from sunic.sunet.se by mc.lcs.mit.edu id aa05773; 7 May 91 12:28 EDT Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.192) id AAsunic26749; Tue, 7 May 91 18:27:56 +0200 Date: Tue 7 May 91 18:25:36 From: Johnny Billquist Subject: Some stuff... To: pdp8-lovers@mc.lcs.mit.edu Message-Id: <910507182536.26.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Tue 7 May 91 18:25:36 From: Johnny Billquist Subject: Some stuff... To: pdp8-lovers@mc.lcs.mit.edu Well, I finally got a new modem for my pdp8, so now I'm online again... While I'm at it, I might as well try to say something. First of all. I still miss an archive site. Since this seems to be not so easy to setup as I hoped, I'll try to organize things a little. Everybody how knows somewhere where we can possibly set up an archive, please let me know, and I'll try to dig further into it. I'd also recommend everybody who has pdp8's to get Charles Lasners ENCODE/DECODE program. Available together with his KERMIT12 on watsun.cc.columbia.edu (Charles, correct me if I'm wrong, and I don't know what directory). The files are K12ENC and K12DEC I think. I think we should use these programs for all binary file trasnfers. If anybody is interested in how the programs work, ask the author. Also, I might have promised some DECtapes to somebody, whose address and name I have lost. If that person still needs 'em, let me know. Another thing: If people need media convertions, and can't get it from somewhere else, I have RX01, DECtape, Papertape, magtape, RK05, RL02 on my eights. Also, I'm always looking for more hardware. Things I'd like to get my hands on now is: KE8-E EAE, FPP8-A, RL8A. I'd like to buy, trade or recieve that stuff. Things I have, that I might trade: KK8-E, KK8-A, KM8-A, DKC8-AA, PC8-E, maybe some core memory (8K cards), plus maybe some other stuff. Ask me... If anybody knows of some hardware that isn't needed somewhere, let me know, PLEASE! I live in Sweden, but I'll pay shippings. Actually all king of hardware might be interesting, but not whole boxes, just cards. Just as a teaser, so that we might get an archive site: I have a *much* improved (over DEC) FORTRAN IV here. Also, my own KERMIT, which only runs on omnibus pdp8, but is very nice. Lots of smaller CUSPs. Also, when we get an archive site, we should be able to put a lot of OS/8 there. I can't think of anything more to say right now. Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 7 May 91 16:47:03 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 7 May 91 16:43:36 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA25155; Tue, 7 May 91 12:30:47 EDT Received: from sunic.sunet.se by mc.lcs.mit.edu id aa05787; 7 May 91 12:30 EDT Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.192) id AAsunic26858; Tue, 7 May 91 18:29:54 +0200 Date: Tue 7 May 91 18:27:20 From: Johnny Billquist Subject: Re: does this still exist? To: antkasx@gsusgi2.gsu.edu Cc: PDP8-LOVERS@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9105070638.AA07225@gsusgi2.gsu.edu> Message-Id: <910507182720.26.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Tue 7 May 91 18:27:20 From: Johnny Billquist Subject: Re: does this still exist? To: antkasx@gsusgi2.gsu.edu Cc: PDP8-LOVERS@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9105070638.AA07225@gsusgi2.gsu.edu> It sure exists, a little low on traffic sometimes, but it exists. I hope RS have added you by now. Otherwise, a hint is to write to pdp8-lovers-request asking to be added to the list. (Same node). Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 7 May 91 18:05:48 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 7 May 91 18:02:06 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04475; Tue, 7 May 91 17:38:07 EDT Received: from MINTAKA.LCS.MIT.EDU by mc.lcs.mit.edu id aa06843; 7 May 91 16:11 EDT Received: from watsun.cc.columbia.edu by mintaka.lcs.mit.edu id aa02742; 7 May 91 16:03 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA10547; Tue, 7 May 91 15:46:14 EDT Date: Tue, 7 May 91 15:46:13 EDT From: Charles Lasner To: PDP8-LOVERS@mc.lcs.mit.edu Subject: Archiving, etc. Message-Id: Date: Tue, 7 May 91 15:46:13 EDT From: Charles Lasner To: PDP8-LOVERS@mc.lcs.mit.edu Subject: Archiving, etc. It really is unfortunate that we still don't have an archive site :-(. As Johhny Billquist says, we should all be using my ENCODE/DECODE program to move "ASCII-fied" versions of binary files around. This solves several problems: TECO macros are not quite "printable" ASCII files. Encoding them preserves the original contents. Binary files of all descriptions (.RL .BN .SV, etc.) have to be encoded because only OS/8 knows how to use them properly. All other systems will mangle them badly. Some sources need the precise nature of the and preserved. Since unix is a likely part of the "path" between us, the use of the encoding will prevent loss. Some binary files (mostly .SV files) have large regions of repeating words, like 7402 octal or 0000. Any other commonly available encoding scheme is not 12-bit oriented, so the repetition of a pattern which is only accessible in 3-for-2 form (OS/8 file strung out into 8-bit bytes) won't look like a one-byte repeating pattern. While LZW-oriented compression will pick this up, all run-length methods will break down. The ENCODE/DECODE program finds up to 256 occurrences of any 12-bit pattern, and compresses it down to a sample and a repeat count. So, unless you want to store files we can't (currently) deal with on the -8 directly, use the ENCODE program to save storage space while you're at it. A forerunner of the ENCODE program used six-bit encoding, similar to uuencode/uudecode, and no compression. The new format is five-bit encoding with run-length compression. The release file K12MIT.SV, which is the "standard" assembly of KERMIT-12, my KERMIT for all -8's and DECmates, compresses into LESS total space with the new method, even though the encoding is theoretically inferior (but more robust). Thus is the importance of compression. The ENCODE/DECODE program is available from watsun.cc.columbia.edu via anonymous ftp. The encoder is known as k12enc.pal and the decoder is k12dec.pal. The encoder is not guaranteed to be assemblable with "ancient" versions of PAL8; the decoder has been written with a "brain-dead" implementation of PAL8 in mind - my recollection of PAL8 V1 as provided on the original version of PS/8. The file k12pl8.enc is PAL8 VB0 from OS/278 V2, and k12crf.enc is the companion CREF VB0. These are DECODEable with the running copy of DECODE.SV you can create with your own "lesser" version of PAL8 (hopefully any version will do :-)). Once they are available, you can assemble the ENCODE program. PAL8 and CREF VB0 should work fine on any OS/8 system. I have hand-checked the binary looking for errant IOTs and OPRs. I am glad to say that there are none. There are only two minor things to worry about: This version of the programs works with OS/278 V2 which has a major dangerous bug. The bug is that if the largest empty on a device is at the end of the device (often true), it is claimed to be two larger than actual! This was apparently erroneously added as an "answer" to an older bug in OS/8 - that any empty involving record 7777 would be claimed to be one too few (which was always safe). As long as the empty is either not fully filled, or isn't the one on the end of the device, the program will work fine. All OS/278 versions of programs should be suspect relative to this problem. KERMIT-12 assumes that the returned count is a "lie" by two, and handles it as such. The only problem is that theoretically, a file full situation occurs unnecssarily, and thus foreshortens a possibly long file. There is no situation that will destroy the device such as possibly PAL8 and CREF, or any other OS/278 program. Probably, most of these programs err on the conservative side when used with OS/8, so there is no real danger. There is an interaction between all OS/278 programs and prior versions of the TTY: handler. Because of the hardware incompatibility of the DECmate, it is mandatory to do KRB after KSF skips. Further, KSF will not skip again. This is true on the -8 also, although the KRB clears the flag, not the KSF as on the 6120-based machines. Since PAL8 (and CREF) does <^C> checking, the flag cannot stay up for non-<^C> purposes as in prior OS/8 situations. This affects the TTY: handler where is allowable to hit <^Z> to terminate the handler input when it should be otherwise null. Consider the following assembly: .R PAL8 FOO at the time of the first one. This is because pass-two input isn't needed in this situation, and the OS/8 TTY: handler will find the ^Z and terminate with null input back to the caller (PAL8). When using PAL8 Version B0, the flag doesn't stay up, so it is necessary to press the <^Z> when the handler is waiting at the beginning of the second pass, not earlier as you formerly could. A third consideration is that this PAL8 is a 128K-supporting version, identical to a few prior releases. The major difference is that the source truncates one column earlier, and the listing is one column narrower because the full address portion of the listing is one digit wider. Unlike all prior versions of CREF, CREF Version B0 does this correctly :-), so you can finally get a proper listing again. I strongly advise against using PAL8/CREF combinations past V10A and before VB0. (Note the reversal of the version number, another OS/278 quirk.) Here is a sample ftp session to locate the KERMIT and ENCODE/DECODE files. The file k12mit.dsk describes all of the files as situated on two release disks in RT-11 RX02 format. $ ftp ftp> open watsun.cc.columbia.edu Connected to watsun.cc.columbia.edu. 220 watsun FTP server (Version 4.169 Mon Mar 19 11:02:20 EST 1990) ready. Name (watsun.cc.columbia.edu:lasner): anonymous 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> cd kermit/d 250 CWD command successful. ftp> dir k12*.* 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. -rw-rw-r-- 1 4505 1327 526 Sep 13 1990 k12clr.pal -rw-rw-r-- 1 4505 1327 7961 Sep 13 1990 k12crf.enc -rw-rw-r-- 1 4505 1327 29175 Sep 13 1990 k12dec.pal -rw-rw-r-- 1 4505 1327 12092 Sep 13 1990 k12enc.doc -rw-rw-r-- 1 4505 1327 28978 Sep 13 1990 k12enc.pal -rw-rw-r-- 1 4505 1327 2556 Sep 13 1990 k12glb.enc -rw-rw-r-- 1 4505 1327 8831 Sep 13 1990 k12mit.ann -rw-rw-r-- 1 4505 1327 28356 Oct 7 1990 k12mit.bwr -rw-rw-r-- 1 4505 1327 112616 Sep 13 1990 k12mit.doc -rw-rw-r-- 1 4505 1327 16274 Sep 13 1990 k12mit.dsk -rw-rw-r-- 1 4505 1327 11536 Sep 13 1990 k12mit.enc -rw-rw-r-- 1 4505 1327 14716 Sep 13 1990 k12mit.lst -rw-rw-r-- 1 4505 1327 224685 Sep 13 1990 k12mit.pal -rw-rw-r-- 1 4505 1327 4976 Sep 13 1990 k12mit.upd -rw-rw-r-- 1 4505 1327 24305 Sep 13 1990 k12pch.pal -rw-rw-r-- 1 4505 1327 11617 Sep 13 1990 k12pl8.enc -rw-rw-r-- 1 4505 1327 1231 Sep 13 1990 k12prm.pal 226 Transfer complete. remote: k12*.* 1122 bytes received in 0.26 seconds (4.2 Kbytes/s) ftp> quit 221 Goodbye. $ Re media conversion: I can handle the following media: DECtape LINCtape paper-tape RX01 RX02 RK8E certain forms of magtape (800,1600,3200) SyQuest SQ-400 (SQ-555 45 MByte drives) CESI HD floppies (5.25" 1.2 MByte) as well as my fixed disk (80 MByte on OMTI 5400 SCSI controller) I can also handle PC formats: 1.2 MBytes and 360KBytes 5.25" floppies 720KBytes and 1.44 MBytes 3.5" floppies SyQuest SQ-400 (SQ-555 45 Mbyte drives) Colorado Memories DJ10 (jumbo) tape cartridges (40 MBytes and 60 MBytes) I don't like to send RK05s in the mail :-), but all the other removable media can be shipped as necessary. Charles Lasner (lasner@watsun.cc.columbia.edu) cjl Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 10 May 91 19:12:03 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 10 May 91 19:08:36 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24264; Fri, 10 May 91 18:52:24 EDT Received: from sunic.sunet.se by mc.lcs.mit.edu id aa23021; 10 May 91 18:51 EDT Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.192) id AAsunic02299; Sat, 11 May 91 00:51:18 +0200 Date: Sat 11 May 91 00:48:30 From: Johnny Billquist Subject: Re: Archive site. To: SPG@alpha.sunquest.com Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <910509214056.290076f8@ALPHA.SUNQUEST.COM> Message-Id: <910511004830.12.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Sat 11 May 91 00:48:30 From: Johnny Billquist Subject: Re: Archive site. To: SPG@alpha.sunquest.com Cc: pdp8-lovers@mc.lcs.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <910509214056.290076f8@ALPHA.SUNQUEST.COM> Well, Steve. If you can get things working, it sure would be nice. It might be possible to set up a FTP site at MIT, but nothing for sure yet. Keep working on it!!! Johnny Summary-line: 9-May SPG@alpha.sunquest.com #Archive site. Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 10 May 91 11:32:54 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 10 May 91 11:29:28 EDT Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07672; Fri, 10 May 91 11:10:35 EDT Received: from Alpha.Sunquest.COM by mc.lcs.mit.edu id aa19523; 10 May 91 0:41 EDT Date: Thu, 9 May 1991 21:40:56 -0700 (MST) From: Steve Gibbons Message-Id: <910509214056.290076f8@ALPHA.SUNQUEST.COM> Subject: Archive site. To: pdp8-lovers@mc.lcs.mit.edu X-Vmsmail-To: SMTP%"pdp8-lovers@mc.lcs.mit.edu" Date: Thu, 9 May 1991 21:40:56 -0700 (MST) From: Steve Gibbons Subject: Archive site. To: pdp8-lovers@mc.lcs.mit.edu X-Vmsmail-To: SMTP%"pdp8-lovers@mc.lcs.mit.edu" Some assumptions: 1) I can obtain a uVAX 2) I can obtain an IP implementation for 1) 3) I can obtain a link to the rest of the IP world 4) I have enough storage Items 1 and 2 are reasonably certain. Item 3 should come soon. item 4 is in question (unless someone would like to donate an RD53 to the cause...) My estimation is that 50-70 MB (read RD-53) would be about optimal for a PDP-8 archive server. FTP and ListServer... I don't mean to get anyone's hopes up, but this _might_ actually work out... Any thoughts? ____________________________________________________________________________ | Steve Gibbons, H.I.S. Interfacing | 602/885-7700x2649 or 602/296-8936(Fax) | | Sunquest Information Systems | spg@{alpha|beta|charon}.sunquest.com | >----------------------------------------------------------------------------< | Never tell people how to do things. Tell them what to do and they will | | surprise you with their ingenuity. | | - George S. Patton, "War As I Knew It", 1947 | `----------------------------------------------------------------------------' Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 13 May 91 17:24:26 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 13 May 91 17:21:00 EDT Received: from vax.ftp.com by life.ai.mit.edu (4.1/AI-4.10) id AA14629; Mon, 13 May 91 16:57:39 EDT Received: by vax.ftp.com id AA24277; Mon, 13 May 91 16:57:27 EDT Received: by bootsie.UUCP (5.58/smail2.5/09-28-87) id AA19098; Mon, 13 May 91 15:56:52 EDT Date: Mon, 13 May 91 15:56:52 EDT From: bootsie!olson@ai.mit.edu (Eric K. Olson) Message-Id: <9105131956.AA19098@bootsie.UUCP> Reply-To: olson@endor.harvard.edu X-Mailer: Mail User's Shell (6.4 2/14/89) To: pdp-8-lovers@ai.mit.edu Subject: Is this list alive? Date: Mon, 13 May 91 15:56:52 EDT From: bootsie!olson@ai.mit.edu (Eric K. Olson) Reply-To: olson@endor.harvard.edu X-Mailer: Mail User's Shell (6.4 2/14/89) To: pdp-8-lovers@ai.mit.edu Subject: Is this list alive? I sent mail asking to be added to this list to pdp-8-lovers-request@ai.mit.edu, a while ago. Am I not on the list (pdp-8-incoming%bootsie.uucp@vax.ftp.com)? Or is the list silent at the moment (which question this message will probably answer for me). Cheers! -Eric -- Eric K. Olson, Editor, Prepare() NOTE: olson@bootsie.uucp doesn't work Lexington Software Design Internet: olson@endor.harvard.edu 72A Lowell St., Lexington, MA 02173 Uucp: harvard!endor!olson (617) 863-9624 Bitnet: OLSON@HARVARD Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 13 May 91 21:54:51 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 13 May 91 21:50:52 EDT Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA03822; Mon, 13 May 91 21:32:47 EDT Received: by rice-chex (4.1/AI-4.10) id AA08439; Mon, 13 May 91 21:32:35 EDT Date: Mon, 13 May T 21:32:33 EDT Message-Id: <9105140132.AA08439@rice-chex> From: Jan Brittenson To: olson@endor.harvard.edu, pdp-8-incoming%bootsie.uucp@vax.ftp.com, pdp8-lovers@ai.mit.edu Subject: Re: Is this list alive? Date: Mon, 13 May T 21:32:33 EDT From: Jan Brittenson To: olson@endor.harvard.edu, pdp-8-incoming%bootsie.uucp@vax.ftp.com, pdp8-lovers@ai.mit.edu Subject: Re: Is this list alive? > From: bootsie!olson (Eric K. Olson) > I sent mail asking to be added to this list to > pdp-8-lovers-request@ai.mit.edu, a while ago. Am I not on the list > (pdp-8-incoming%bootsie.uucp@vax.ftp.com)? No, you were not on the list. I think RS has been too busy to take care of this (and any other administrative requests you PDP-8 eficionados may have pending). So I added you. If anyone else is waiting for the adm server (aka RS) to complete their priority requests, just reissue them to me and I'll see what I can do about it. At worst they will get defered back to RS. -- Jan Brittenson bson@ai.mit.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 13 May 91 22:39:37 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 13 May 91 22:36:06 EDT Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA04619; Mon, 13 May 91 22:09:04 EDT Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.193) id AAsunic01704; Tue, 14 May 91 04:08:57 +0200 Date: Tue 14 May 91 04:05:23 From: Johnny Billquist Subject: Re: Is this list alive? To: olson@endor.harvard.edu Cc: pdp-8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9105131956.AA19098@bootsie.UUCP> Message-Id: <910514040523.21.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Tue 14 May 91 04:05:23 From: Johnny Billquist Subject: Re: Is this list alive? To: olson@endor.harvard.edu Cc: pdp-8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <9105131956.AA19098@bootsie.UUCP> There has been some traffic the last few days, so you should be recieving some stuff... Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 17 May 91 23:22:45 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 17 May 91 23:19:14 EDT Received: from plains.NoDak.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21340; Fri, 17 May 91 22:58:36 EDT Received: by plains.NoDak.edu; Fri, 17 May 91 21:57:00 -0500 Date: Fri, 17 May 91 21:57:00 -0500 From: Todd Enders - WD0BCI Message-Id: <9105180257.AA12301@plains.NoDak.edu> To: pdp8-lovers@ai.mit.edu Subject: PDP9, Anyone seen one? Date: Fri, 17 May 91 21:57:00 -0500 From: Todd Enders - WD0BCI To: pdp8-lovers@ai.mit.edu Subject: PDP9, Anyone seen one? I was just looking through an old DEC Logic Handbook (positive logic edition, (C) 1969), and in the back there were thumbnail sketches of the various DEC minis extant at the time. They had pdp-8, pdp-9, pdp-10 and pdp-12, complete with representative pictures of a system of each type. Now the pdp-9 looks to me like a real neat machine. Up to 32k words of 18 bit memory (yes indeed, this was an 18 bit machine!), 1 microsecond instruction cycle time, up to 256 i/o devices, etc. And an *awesome* front panel with *lots* of lights and switches! :-) :-) :-) All this in a 6 foot high by about 30 inch wide cabinet. Anyone ever see one of these beasts in action? Was it as nice as it seems from reading the sales hype? Know where I could lay my hands on one? Thanks! =============================================================================== Todd Enders - WD0BCI ARPA: enders@plains.nodak.edu Computer Center UUCP: ...!uunet!plains!enders Minot State University or: ...!hplabs!hp-lsd!plains!enders Minot, ND 58701 Bitnet: enders@plains "The present would be full of all possible futures, if the past had not already projected a pattern upon it" - Andre' Gide =============================================================================== Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Sat, 18 May 91 00:29:16 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Sat, 18 May 91 00:25:47 EDT Received: from Shiva.COM by life.ai.mit.edu (4.1/AI-4.10) id AA22260; Fri, 17 May 91 23:48:14 EDT Received: from Rosebud.Shiva.COM by Shiva.COM (1.34b) Fri, 17 May 91 23:50:53 EDT From: Phil Budne Received: by Rosebud.Shiva.COM (Spike-2.0) Fri, 17 May 91 23:48:17 EDT Date: Fri, 17 May 91 23:48:17 EDT Message-Id: <9105180348.AA12929@Rosebud.Shiva.COM> To: enders@plains.nodak.edu, pdp8-lovers@ai.mit.edu Subject: Re: PDP9, Anyone seen one? From: Phil Budne Date: Fri, 17 May 91 23:48:17 EDT To: enders@plains.nodak.edu, pdp8-lovers@ai.mit.edu Subject: Re: PDP9, Anyone seen one? > Up to 32k words of 18 bit memory (yes indeed, this was an 18 bit > machine!) As were the 1, 4, 7 and 15! When I worked at DEC on 36 bit software, I met a few '15 folks who seemed almost as sad as we were in the end! I think I saw '7 in DEC salvage once. Bore a resemblance to a PDP-6 (dull blue with metal trim). I'm enclosing Mark Crispin's excellent PDP summary, since it hasn't been re-posted in a while! ================ From RS%AI.ai.mit.edu@mc.lcs.mit.edu Thu Jun 8 00:28:01 1989 Date: Thu, 8 Jun 89 00:09:28 EDT From: "Robert E. Seastrom" Subject: What's a PDP-x ?? To: pdp8-lovers@mc.lcs.mit.edu If you folks have already seen this, please disregard it. If you haven't, keep it handy - it could come in handy some day. ---Rob PS: In case you didn't know (I didn't until 2 years ago), PDP stands for Programmed Data Processor... Date: Wednesday, 20 August 1986 03:42-EDT From: Mark Crispin To: TOPS-20@SU-SCORE.ARPA, Boken@RED.RUTGERS.EDU Re: DEC's PDP's Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 A number of people have requested my list of all the DEC PDP's, so I thought I'd bore you all with it. The PDP-1 was an 18 bit machine. It was DEC's first computer, and some of the first timesharing systems were designed for it. It's also unique in being one's complement; all later DEC computers were two's complement. Some machines, such as one of MIT's PDP-1s, were in operation until the late '70s. The PDP-2 was a designation reserved for a 24 bit machine, but as far as I can tell it was never even designed and definitely none were ever built. The PDP-3 was a 36 bit machine that was designed but never built by DEC. However, Scientific Engineering Institute built one in 1960. The PDP-4 was an 18 bit machine that was intended to be a cheaper, slower alternative to the PDP-1. It was so slow that it didn't sell well, although it was interesting for its auto-incrementing memory registers. It was not program-compatible with the PDP-1, but its instruction set was the basis of DEC's future 18 bit computers. The PDP-5 was a 12 bit machine designed to be a small laboratory system. It used many of the ideas in the LINC (Laboratory Instruction Computer, designed by Lincoln Labs at MIT, some of which were built by DEC). The PDP-6 was a 36 bit machine and the first machine to implement the most wonderful computer architecture known to man. It was rather expensive and difficult to maintain, and not many were sold. As a result, DEC cancelled 36 bit computers for what was to be the first of many times. The PDP-7 was an 18 bit machine and the sucessor to the PDP-4. It was a major price/performance win over the PDP-4 and the first DEC computer to use wire-wrapping. The PDP-8 was a 12 bit machine and the sucessor to the PDP-8. It basically defined the term "minicomputer", and went through several incarnations. The original PDP-8 was followed by the extremely slow PDP-8/S (as bad as the PDP-4 was to the PDP-1, but at least the /S was program-compatible). DEC recouped with the PDP-8/I (using MSI integrated circuits) and the smaller PDP-8/L, and somewhat later came out with the "Omnibus 8" machines -- the PDP-8/E, the PDP-8/F (a half-sized version of the PDP-8/E), the PDP-8/M (an OEM version of the PDP-8/F), and the final machine, the single board PDP-8/A. The PDP-8/A still exists after a fashion as a current DEC product. The PDP-9 was an 18 bit machine and the sucessor to the PDP-7. It had a faster memory than the PDP-7 and was the first microprogrammed DEC computer. Modulo a 300 wire(!) ECO required in the first machines, the PDP-9 was a reliable machine and some are still in operation today. There was a short-lived PDP-9/L. The PDP-10 was a 36 bit machine and the sucessor to the PDP-6. It is especially noted for its software, which represents the pinnacle of DEC software engineering and has never been equalled. The first KA10, largely installed in universities, created a whole generation of timesharing hackers. The follow-on KI10, with paging and using IC's instead of discrete components but otherwise unexciting, mostly was sold to commercial organizations. The KL10 went through several incarnations and is today the most representative of this marvelous machine. The KS10 was a small, low-speed (approximately KA10 performance) processor which was DEC's last successful implementation of this architecture. The PDP-11 was a 16-bit machine that went through more implementations and operating systems than can be counted. Presently it superceded the less powerful PDP-8 as the representative minicomputer. While the PDP-11 used octal, it was in its deep heart of hearts a hexidecimal machine, and the first indicator of the creeping IBMification of DEC that took full fruit in the VAX. [I can hear the flames now...] Rather than fight it the customers loved it; more PDP-11's have been sold than any other DEC computer (possibly more than all the others combined). The PDP-12 was a 12 bit machine and the sucessor to the PDP-8. It combined a LINC and a PDP-8 type processor in the same box and basically was a new model of the LINC-8 which was the same thing. No PDP-13 was ever designed or built. Even DEC gets superstitious. The PDP-14 was a 12 bit machine with a 1 bit register. It was used as a process control engine in applications that were felt to be too rugged for a PDP-8, and basically replaced a set of relays. Later DEC made PDP-8's suitable for this sort of thing, but it didn't stop them from the ultimate silliness of building a PDP-14 that used a PDP-8 as its console processor! The PDP-15 was an 18 bit machine and the final one of this design built by DEC. More PDP-15's were built and sold than any of the others, and it went through several incarnations including some which used a PDP-11 as a front end. Apparently the cancellation of the PDP-15 came as a great surprise to the "Tiger Team" who worked on it, although considering its general ungainliness compared to comparable performance PDP-11's it wasn't surprising. In many ways the PDP-15 died for the same reason the PDP-10 did. The PDP-16 was a "roll your own" 16 bit machine based on various "building blocks". Every PDP-16 was essentially custom-designed by the customer. It got a fair amount of attention when it was announced but evidentally didn't sell very well. There was no PDP-17 or any other designator. DEC apparently decided that "PDP" had a perjorative ring to it. Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Mon, 20 May 91 20:26:20 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Mon, 20 May 91 20:22:49 EDT Received: from ama.Caltech.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA07698; Mon, 20 May 91 20:02:37 EDT Received: by ama.Caltech.EDU (0.8/SMI-4.1) id AA10023; Mon, 20 May 91 17:05:28 PDT Date: Mon, 20 May 91 17:05:28 PDT From: ph@ama.caltech.edu (Paul Hardy) Message-Id: <9105210005.AA10023@ama.Caltech.EDU> To: enders@plains.nodak.edu Cc: pdp8-lovers@ai.mit.edu In-Reply-To: Todd Enders - WD0BCI's message of Fri, 17 May 91 21:57:00 -0500 <9105180257.AA12301@plains.NoDak.edu> Subject: PDP9, Anyone seen one? Date: Mon, 20 May 91 17:05:28 PDT From: ph@ama.caltech.edu (Paul Hardy) To: enders@plains.nodak.edu Cc: pdp8-lovers@ai.mit.edu In-Reply-To: Todd Enders - WD0BCI's message of Fri, 17 May 91 21:57:00 -0500 <9105180257.AA12301@plains.NoDak.edu> Subject: PDP9, Anyone seen one? I saw a PDP-9 in a hallway about ten years ago; looked like it was on its way to the happy hunting ground in the sky. The two things I remember about it (impressions from a quick inspection) were that the display LEDs were flourescent NIXIE tubes and there was some sort of round scope attached to the main unit -- was this the console?! --Paul Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 22 May 91 07:20:09 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 22 May 91 07:16:38 EDT Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00689; Wed, 22 May 91 07:02:50 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA04188; Wed, 22 May 91 05:17:26 EDT Date: Wed, 22 May 91 5:17:25 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Message-Id: Date: Wed, 22 May 91 5:17:25 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu From: Charles Lasner Subj: Corrections and commentary on Mark Crispin's PDP list I have found "grievous" errors in Mark Crispin's descriptions of PDP-xx computers from DEC, so herewith are some corrections: PDP-1, 2, 3 I have no fundamental problem with this description, however, I would note that there is a story circulating that the original machine was called PDP, *not* PDP-1. The manual for the PDP was PDP-1, and they intended it to stop there. PDP-2 and PDP-3 are therefore tentative or actual notation for more manuals. I will not comment other than this mention of the PDP-2, 3 memorial golf course :-) PDP-4 I once saw one of these in the Mill with a baudot teletype (model 28) hooked up to it; no further comment. PDP-5 The PDP-5 is nearly compatible with the PDP-8. It has the program counter in location zero. Storing value-1 in 0000 is the same as a jump to value. This is how FOCAL, 1969 tests for running on the -5, since interrupts must be moved from 0001 to 0002. All other references to 0000 are disallowed, as are certain operate instructions. These restrictions seem arbitrary, and this was corrected in the PDP-8. It's probably not unreasonable to modify this machine to be -8 compatible, although a little slow due to 8 microsecond memory. Extended memory is totally compatible, but EAE is not, it's more like a peripheral than a processor option. The bus can't do 3-cycle data break, but the early 555 DecTape ran on it in 1-cycle mode using the current Data Field as the break field (which in turns means no interrupts are allowed while the DMA is in progress!). Other than that, through use of a physical bus convertor (don't have the number, but I mean a passive device that merely changes the connectors), the -5 likes -8 negative bus peripherals. An -8 expander box (804) was once hooked to a -5 containing the -8's plotter interface for a Calcomp plotter, etc. Rumor has it that someone modified the CPU of a -5 to gain the few operations necessary to make it -8 compatible, and that an 8K version was running OS/8 on some undisclosed peripheral. I wouldn't give too much creedence to the story because all of the early disk peripherals were 3-cycle except the aforementioned 555 DecTape (as opposed to TC01 et al which is three-cycle). The PDP-5 is clearly the PDP-8's father. It is not known if it used the PC in 0000 kludge as an economy measure, or just plain foolishness at the time, but clearly, had it been slightly upgraded to PDP-8 processor compatibility by DEC, it would have been supported more readily. Many of the changes subsequently made to FOCAL, 1969, etc. depend on removing restrictive operations caused by supporting the -5 and the even more demented 8/s (see below). These restrictions mean that you can't use combined operates such as CMA RAL because these two can't do it. In the -5's case, it's almost excusable, but in the -8/s case it is not. PDP-6 The story I heard is that Alan Kotok virtually single-handedly got all of the few made to work by using other people's memory. Most wound up in MIT at one time or another anyway. The PDP-6 lacked certain features required by later -10 systems, but was always welcome to ITS. PDP-7 It is interesting to note that a small class of peripherals were introduced for either the -7/9 series or the -8. I know of at least two: the AA01A for the -8, and the type 884 sychronous modem interface. Each was delivered in two parts. One part was bus specific, and the other was plugged into whichever first type you had installed appropriately. I personally participated in modifying the D-A part of a AA01A to become an -8-only peripheral, because the trivial -8 interface was a waste of valuable black block racks, and the empty space on the AA01A was available to wrap on an -8-only interface complete with daisy-chain. I also once used a PDP-15 with a negative bus converter which had the negative interface and 884 assembly for a synchronous modem connection to an outside dedicated line. It has been told to me that the TC58/59 class of tape controllers consists of a generic subsystem called TC50 internally, which is wrapped to a 7/9 bus or -8 bus specific portion to become the TC58 or TC59. In this case, the two are wrapped together, not cabled together, and are thus more or less permanently attached. PDP-8 and PDP-12 Since the PDP-8 is the standard bearer of our group, we can't leave any stone unturned here. First off, the obvious typo in that the -8 is the successor to the -5, not itself :=). While the -8/s may be extremely slow, it is also *not* compatible with the -8. Please note that OS/8 does *not* run on either the -5 or the 8/s. This also applies to P?S/8, which it should be noted runs on the entire -8 family from PDP-8 through DECmate III+, whereas OS/8 has different "family" members that each do part of this in an overlapping fashion. I am part of a group which desires to release OS/8 Version 5, to run on the entire family. Note, when all concerned parties discuss the "family of 8" the -8/s and -5 are specifically omitted. I have once discussed the feasibility of upgrading the -8/s, and the consensus was that it could be done, but it might run a bit slower, and in any case would require a rack of cards hanging out of it. It is also noteworthy that the -8/s was originally a different project known as PDP-10! It was to have 32K memory implemented as drum-style memory as in earlier computers, and the memory was what became the basis for the 32K PDP-8 fixed disk peripheral called DF-32. I guess they didn't pay close attention to the improvements in processor OPR instructions the -8 made over the -5, because the -8/s is *worse* than the -5 in terms of compatibility. It is also a fully *serial* computer, not parallel. It should also be noted that many DATA GENERAL Nova-type machines and micros were serial or at least not fully parallel. Later models, the -8/i and -8/l did come out. Early -8/i's had Red-handled modules like the -8, even though the cards were TTL and eventually became maroon (M modules). There were even a few -8's with 8K in them ala the -8/i, because they had -8/i-type memory kludged into them! The -8/i originally had a negative bus, for compatibility with the vast majority of existing peripherals made expressly for the -8. The -8/l is essentially a stripped-down -8/i, and as such can have only 8 (or 12) K and a positive bus, whereas later -8/i's could have either bus. The LINC-8 was an attempt to bring DEC some income from the MIT LINC project. After early on realizing that an independent LINC peripheral would be difficult to pull off, the LINC-8 was born by making moderate modifications to the -8 CPU and memory interface, and adding a "captive" processor. Many operations had to be simulated for complete pseudo-compatibility with the *real* LINC, which in turn was constructed of the same System Modules as the PDP-5. The LINCtape peripheral is actually an -8 peripheral, whose major registers are the LINC processor's registers, which are "borrowed" because the LINC CPU is totally disabled while the -8 runs the tape peripheral. In certain ways, the LINC-8 is a "cadillac" implementation of the -8, in that it has certain niceties such as GMT 3 grasshopper fuses on all power busses, and many fans, etc. Also, the lamp drivers for all front panel lamps are on actual small modules wrapped in, not one massive (and damage-prone) lamp driver panel. The bulbs still are soldered in here though :-( The PDP-12 is a positive bus-only -8/i with a built-in DMA multiplexor option eventually, as well as push-down stack hardware and priority interrupt (KF-12B) as late-production standard features. All of the LINC stuff is "real" including the dual console. There are less actual lights than the LINC-8 because there is now only one set of registers for a dual-mode processor, not two complete processors with each's set of major registers displayed. A standard option allows read/write of DECtape, whereas only user modifications could do this on the LINC-8 eventually. The FPP-12 was born here, and included PDP-8 CPU lockout mode option, although this was reborn in the FPP-8/e,a for the Omnibus years later. Clearly, the -12 was the one model that got the benefit of "proper" hardware engineering, whereas subsequent models seem to get ever shorter ends of the hardware "stick". Curiously, a few modules come from the LINC-8 project, because it was too much work to recreate the function in TTL rather than negative voltage logic, so they merely level converted and used a few R-series cards :-). Some PDP-12 modules actually say they are specifics for the "LINC-8/i" which was apparently its original designation. The PDP-12 is the only model where the number is also the word length :-). Many DEC-ignorant computer types actually believe that the PDP-8 is an 8-bit machine! Newer models of -8's are all for the Omnibus, which defines all processor and I/O signals on four DEC-feet or quad-width slot. Various incarnations are either wider or deeper, but all have the same bus. The standard is the -8/e, which is always 20 slots (optionally 40) in the full-depth box, complete with bulky analog power supply. The entry level is the -8/m, which was designated for OEM's, and didn't include the standard -8/e-type front panel with incandescant lamps. The -8/f is an -8/m including an LED variant of the lamp panel, and this panel is an option for the -8/m as well. Thus, the -8/m with panel and -8/f differ only in color scheme and silk-screened name on the panel. Both have a slightly balky switching supply which is much smaller than the -8/e supply, as well as much less power capability. These machines are "bread-box" size, and only allow for 20 slots in the box. The newer breed of Omnibus boxes are all usually known collectively as -8/a, but they came in various flavors: a short-lived 10-slot box with many restrictions, a 12-slot box with somewhat more versatility, and a 20-slot box with large power capability. Theoretically, any of these systems could be expanded from virtually any model's box as an add-on to the base system, so standard options included upgrading a 40-slot to 80-slot, or making a 20-slot -8/f grow to 40 or optionally 60 slots using the same external -8/e-type box, etc. The FPP-8/A was meant to go in the -8/a 12-slot box, which, like all -8/a boxes, is hex-wide internally, not quad. The sixth foot is electrically non-existent and the fifth foot has only a few signals optionally available later to various memory extension options beyond 32K. When sold this way as an add-on for a 40-slot -8/e, the entire option is known as FPP-8/e, including the BC-80C cable and 12-slot hex-wide box, as well as the two hex-wide FPP cards. My own machine is a 40-slot -8/e, with a 20-slot -8/a box as an expander. The -8/a series also sports an optional octal digit LED readout front panel, similar to an 11/34 in general appearance. Most of the -8/a models use a single slot CPU, the KK8A, which has the bus pullups on it (at the *wrong* end electrically of the bus!) which disallows the bus terminator, and is thus limited to what fits in any one box, or at most 20 slots. Some use the -8/e processor (KK8F) which requires a terminator card (M8320) in the furthest slot away from the CPU. Some configurations reverse the apparent beginning and ending, but always obey this rule. This allows at least 40 slots (-8/e box or two -8/a boxes) or at most 80 slots (two -8/e boxes). It is possible to discover which CPU is present due to specific CPU-model-dependent quirks, but you can't tell more than that. Some -8/a boxes are really -8/e machines with -8/a memory options and all else is from an -8/e! PDP-8/a systems get numeric suffixes like -100, -400, -500, and -600 as well as model-option changes to make it something like -625, etc. Since there is much "plug and play" here, it is not too useful to describe an -8/a system by model, but rather by specific components. All -8 models are backwards compatible with earlier bus arrangements, and also there is a feeble attempt at forwards compatibility called the DW-8/E. This partially allows some Omnibus stuff to work in the pre-Omnibus machines, but has many restrictions. A hacked-up version of the RK8E called RK8F is the only DMA option for the DW8E. The Omnibus machines support the positive bus via the KA8E and KD8E(s). The KA8E outputs a completely compatible positive transfer bus, and each KD8E outputs a compatible DMA interface. The Omnibus does any priority multiplexing. The negative bus is in turn supported by the DW08A option, so it is reasonable to find a TC01 on an -8/a. I have an -8/e with a TC01 and TU55 myself. (This requires an ECO to the W103 cards to become W123.) PDP-9 and PDP-9/l The -9/l had a pink color scheme, and was apparently a stripped-down -9. The -9 was often sold with a -7 because there was some software that ran on both simultaneously. Apparently, the -7 became a dedicated controller for the DECtape drives relative to the -9, because the -7 had a feeble interface ala the TD8E on the -8/e, etc. Later, the -9 got its own TC02 DECtape, thus relieving the -7 requirement. I don't understand Mark Crispin's description of the -9 as being microprogrammed. Perhaps this is merely a misstatement of the fact that the operate instructions, like in the -8, can be *user* microprogrammed together such as: SMA SZA CLA /skip if the AC is either negative or zero, /and then clear the AC regardless. The -9 is not materially different in architecture from the -8, so I can't imagine this meaning anything else. I also understand that the 7/9/15 can microprogram more of these operations than the -8 can. The -8 is restricted to groups which can combine sub-operations, whereas the 18-bit machines can combine almost anything at once! PDP-10 The PDP-10 spawned much software development, and eventually encouraged the use of BLISS. It is noteworthy that much of the VAX software is lifted directly from TOPS-20 because of the close compatibility of the various (later) BLISS implementations. However, purists will note that BLISS-10 is *not* BLISS-36, while BLISS-32 just about is. This was done on purpose to rip off the -10 stuff for the benefit of the VAX. Perhaps this also means that some newer stuff can come back to the 36-bit world as well :-) PDP-11 Since the early days of the RISC discussion, it has become debatable whether the PDP-11 is more powerful than many designs, not just the -8. I guess it all depends on how you measure the power. The PDP-11 certainly had more hardware engineering effort applied, but was the benefit worth the cost? Measured this way, you could say the -11 is DEC's weakest machine. Look at how well the PDP-8 has fared while being "negatively marketed" as compared to the -11! Also, LCG had to put controls on -11 marketing when salesmen were quoting -11 systems that were a) impossible to implement (or at least highly impractical), and b) were clearly short-changing a customer willing to shell out PDP-10-sized bucks for a computer. DEC also made lots of money selling the 11-03, but I guess -11 freaks don't want to talk much about that :-) Various academic works have pinpointed the weaknesses of the -11 in terms of pure architectural considerations. The user group largely consists of people who don't really know much about the -11, but rather are in love with its software, and make the fatal mistake of measuring the worth of a machine by how useful it is to them, not its intrinsic value. This merely means that DEC threw a lot of money at the -11, not that it is a good design. If RT-11 were known as RT-15 for the PDP-15 family, and DEC implemented an RT-11-like system for the -15 (which is totally feasible, considering what a -15 is, and what RT-11 is), how many of these people would be raving about how powerful the -15 is? :-) As a side note, there seems to be much interest in an RT-11-like system for the VAX, presumably to be called RT-32. As is alluded to in THE SOUL OF A NEW MACHINE, the PDP-11 was born over a weekend, appealing to the ego of certain individuals who could pull strings in DEC, to pull the plug on what was to be known as DATA GENERAL and the NOVA. Considering the rocky road of the -11, it is curious that DEC never sued DATA GENERAL over the NOVA's very existence. cjl Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Fri, 24 May 91 22:42:51 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Fri, 24 May 91 22:39:18 EDT Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA04817; Fri, 24 May 91 22:11:23 EDT Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.194) id AAsunic16057; Fri, 24 May 91 22:51:07 +0200 Date: Fri 24 May 91 22:47:05 From: Johnny Billquist Subject: Nostalgia trips anybody...? To: pdp8-lovers@ai.mit.edu Message-Id: <910524224705.18.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Fri 24 May 91 22:47:05 From: Johnny Billquist Subject: Nostalgia trips anybody...? To: pdp8-lovers@ai.mit.edu I'm proud to announce the existance of an pdp-8/i on the internet. The address is 130.238.4.9 (name is CRAP-1.UPDATE.UU.SE) The machine is, as I said, an 8/i, with 8k core, four TU55 DECtape drives. Anybody who cares is welcome to run on it, but it is a little slow, due to swapping on the DECtape. Please notify me if you hang the machine, so that it can be rebooted. Please do not clear the system dectape. If you are unfamiliar with OS/8, the following commands and programs whould be used carefully: Commands: ZERO DELETE Programs: FOTP PIP BUILD (Should probably not be used at all unless you know OS/8) There exists an help, as well as the command "COMMANDS", which lists all available commands. Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 28 May 91 23:16:35 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 28 May 91 23:12:56 EDT Received: from vx.acs.umn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02414; Tue, 28 May 91 22:59:46 EDT Received: from boombox.micro.umn.edu by vx.acs.umn.edu; Tue, 28 May 91 11:50 CDT Received: from [128.101.95.11] by boombox.micro.umn.edu; Tue, 28 May 91 12:01:24 CDT Date: Tue, 28 May 91 11:46:11 CST From: grg@boombox.micro.umn.edu Subject: PDP-8 Emulator, Software To: pdp8-lovers@ai.mit.edu Message-Id: <1536691322.grg@boombox.micro.umn.edu> X-Envelope-To: pdp8-lovers@ai.mit.edu Date: Tue, 28 May 91 11:46:11 CST From: grg@boombox.micro.umn.edu Subject: PDP-8 Emulator, Software To: pdp8-lovers@ai.mit.edu X-Envelope-To: pdp8-lovers@ai.mit.edu Hello All, It's been many a year since I programmed on PDP-8's, but I havent forgotten how much fun it was. A nice small machine that took some effort to program, but paid off with nice small tight programs. I now work on Mac's, so I wrote a PDP-8 emulator for the Mac. I expect it should run about as fast as a PDP-8/E on my MacIIci. It emulates the basic instruction set and 32K of memory. And a simulated TTY 03/04. And the rudiments of a simulated RK05. Eventually I'd like to be able to boot OS/8 on it. And make it available to one and all. *But* I need some test programs to wring out the bugs out of the instruction set. I'm pretty sure I have the basics of memory anddressing, indirection, auto increment, and pending CIF's working. It's just some of the subleties of OPR that I probably havent polished. Does anyone have all those wonderful MAINDEC's available on the net? I seem to remember a large number of CPU test MAINDEC's. I sure could use them right about now..... Thanks in advance. ---------------------------------------------------------------------------- George R. Gonzalez Microcomputer and Workstation Networks Center grg@boombox.micro.umn.edu University of Minnesota Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Tue, 28 May 91 23:54:27 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Tue, 28 May 91 23:50:48 EDT Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03155; Tue, 28 May 91 23:37:58 EDT Received: from kicki.stacken.kth.se by mintaka.lcs.mit.edu id aa05791; 28 May 91 23:36 EDT Return-Path: Received: from AIDA.CSD.UU.SE by KICKI.STACKEN.KTH.SE; Wed, 29 May 91 5:25:48 +0200 In-Reply-To: <1536691322.grg@boombox.micro.umn.edu> Date: Wed 29 May 91 05:20:56 From: Johnny Billquist To: grg@boombox.micro.umn.edu Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se Subject: Re: PDP-8 Emulator, Software Message-Id: <910529052056.7.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Return-Path: In-Reply-To: <1536691322.grg@boombox.micro.umn.edu> Date: Wed 29 May 91 05:20:56 From: Johnny Billquist To: grg@boombox.micro.umn.edu Cc: pdp8-lovers@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se Subject: Re: PDP-8 Emulator, Software Aaargh. I have the MAINDEC's on papertape. If you cant get 'em from somewhere else I might be persuaded to load them down. However, since the OPR's are pretty easy, you should be able to figure out if they are correct anyway. Need a short, but exact, description? Johnny Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 29 May 91 02:20:04 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 29 May 91 02:16:21 EDT Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06997; Wed, 29 May 91 02:02:57 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA12850; Wed, 29 May 91 02:02:17 EDT Date: Wed, 29 May 91 2:02:17 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Maindec availability and PDP-8 emulators (to GRG, etc.) Message-Id: Date: Wed, 29 May 91 2:02:17 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Maindec availability and PDP-8 emulators (to GRG, etc.) First of all, you DO need the diagnostics to successfully debug an emulator. This is not the first time this has been done. Someone once remarked that the "most effective software" for the PDP-15 was OS/8 and P?S/8 running under an emulator for the -8 written by Mark Hyde. This program got read in standalone in PDP-15 loadable paper-tape (the -15 has a hardware RIM loader), and it just self-starts. The program starts by booting the DECtape on drive 0 - the PDP-8 DECtape that is! The idea is that all PDP-8 instructions up until certain "sacred" IOT's in specific places are encountered are emulated conventionally. The special IOT's trigger a "smarter" mode of operation: the contents of appropriate PDP-8 memory locations are examined, and the proper course of action is taken. The emulator supports the standard DEC OS/8 system and non-system handlers, and the P?S/8 extended unit system handler (which supports drives 0-7 directly, unlike OS/8 where each handler only accesses one drive). There is no DECtape support for loose instructions, or other handlers such as my own replacement TC01/08 OS/8 system handler with drive one support coresidently and intelligent initial search direction guesswork (same as in P?S/8's handlers). The point is that the emulator can do the DECtape I/O in real-time, so the overall emulator efficiency is rather good. Devices supported are the console 03/04, high-speed reader/punch, the DECtape drives, and if the -15 has the extend memory option, a 4-platter DF32 faked in PDP-15 memory. Using this emulator allowed direct access to dismountable PDP-8 DECtapes which you could take off your -8 and bring to the -15. I believe that a recent version also added LPT: support as well. MainDEC diagnostics help prove an emulator totally works, because there are sometimes complex interactions between instructions and real-time. For example, the PDP-8/e diagnostics check such things as how many cycles go by (I think only one) before an SRQ instruction actually skips after the TFL instruction sets the 04 output flag. Or just how CIF instructions precisely inhibit interrupts, affect GTF instructions, etc. The code looks somewhat pragmatic in the diagnostic sources, but in any case, they enforce the precise definition of a running machine. Curiously enough, the PDP-8 memory checkerboard program located an error in the PDP-15 memory that skipped by the PDP-15 equivalent! The diagnostic correctly complained about the bad contents, which ultimately led to PDP-15 modules being replaced :-). Another point about emulators: there can be high overhead for emulating PDP-8 interrupts. A good emulator should have a mode where the ION mode goes away to enhance non-interrupt driven emulation. Also, emulating devices like RF08 and DF32 require "throttling" of the emulation. i.e., deliberately slowing down the simulated transfer so the diagnostics can work with expected timing, etc., lest insufficient simulated CPU cycles get executed in favor of simulated DMA cycles, etc. Since some of the emulator authors are on the internet, I suggest they access watsun.cc.columbia.edu for my KERMIT-12 sources. Within this collection is documentation for the PDP-8 ENCODE/DECODE implementation I wrote with the aid of Frank Da Cruz of Columbia Kermit fame. This is an alternative to uuencode, etc., and is totally PDP-8 oriented. Using this format, we can send the MainDECs to the emulator authors unscathed by unwanted network "editing" of the binary files. I am sure that most of us who have the diagnostics, such as Johnny Billquist, can turn his paper-tape copies of the diagnostics into OS/8 files and then ENCODE them for internet e-mail usage. The authors will have to figure out the format from the documentation, and then write local tools to pseudo-load them into their PDP-8 emulator's "memory" and start them up. This involves decoding and checking the received files into the equivalent of certain OS/8 binary formats, such as .SV and .BN, and then subsequently pseudo-loading the files according to what they represent. Probably the best way is to stick with OS/8 .BN files, because the underlying format is 3-for-2 packed paper-tape binary image. This would be the closest format to desirable because core-image would require whole pages to be loaded, even if containing junk. Binary paper-tape format would allow unneeded locations to remain set to emulator-specific values. This would allow an emulator to report an apparent branch to unreferenced memory for example, which would indicate an error in the emulator, since MainDEC programs are generally well-behaved. (Also a good emulator feature to implement if you want to develop and debug new PDP-8 programs or changes.) Another subject is what devices to emulate. Beyond the basic instructions and 32K extended memory, there is the console device 03/04, and perhaps the line printer, device 66. It is suggested that the device 01/02 reader and punch be emulated as files such as READER.BIN and PUNCH.BIN because if the emulator is good enough to run OS/8 or P?S/8, then the paper-tape portions become somewhat vestigial. However, emulation by file allows for ease in running MainDECs at the early debugging stages, so perhaps a local utility needed early on is a tool to take the ENCODEd files, decode them, and "de-OS/8" them into paper-tape images to become the designated READER.BIN files. There needs to be a way to set the simulated front panel switches beause the diagnostics all use them. Additional devices that can be emulated reasonably include the RF08 and or DF32 and the RK8E. On MS-DOS and other systems where the basic physical block structure is 512 bytes/sector, the RK8E can be done as a pre-allocated collection of sectors the size of the physical RK8E disk. Unfortunately, the overhead of the I/O operation is high for the RK8E due to the PDP-8 code helping the controller a bit too much. This tendancy is furthered in devices like the RX01/02 (or DECmate's RX50) where the hardware is even cheaper and the software has more work to do. A possible alternative to all of this is to emulate the CESI MDC8 SCSI controller. The software basically sets up an SCSI command, and then says "you go do that command" to another processor, in this case a 6809 in the "real" MDC8. Should it include DMA, such as reads or writes, the 6809 connects to the Omnibus to do it directly. The command itself is referenced in PDP-8 memory by the 6809 because the IOT's just point the 6809 at the SCSI command. This is a perfect low-overhead device to emulate. The actual I/O overhead past command setup is quite minimal, so no special-purpose kludges are required. Handlers exist for OS/8 and P?S/8 for floppies and fixed (and removable cartridge) disks. I have even written a "backbone" system called MENU-8 which preselects which of several possible operating system images are further up the device, and which to boot indirectly to. This is sort of what the PC does on a hard disk with a partition table. In theory, you could have multiple systems on a disk (CP/M-86, UNIX, MS-DOS) and each is bootable under some usage, but only one "owns" the disk. I have an arrangement for multiple copies of P?S/8 and OS/8 to "co-exist" on a large disk in this manner. All you need is to emulate an MDC8 and give SCSI commands that address a large region of a disk. This could be quite practical on a PC environment, where it is best that the PDP-8 disk be "separate" from the normal DOS environment (or UNIX). A further benefit of using the MDC8 example, is that the floppy format is directly supportable by the emulator, as long as you can read/write PC 5.25" disks. Many machines "like" this format, so PDP-8's can boot this floppy directly, and so can the emulator if so implemented. This is analogous to the PDP-15 emulator cited above. The floppy format is exactly IBM-PC High Density two-sided format EXCEPT for one change: The PC format is 15 sectors of 512 bytes, and the PDP-8 format is 26 sectors of 256 bytes. All other track, etc. considerations are identical. This format is readable/writable on a PC with a little helpout to the hardware. (You can't do it through the BIOS, but you can talk to the floppy controller yourself and do it.) This allows PDP-8 MDC8 users (like me :-)) to interchange PDP-8 programs directly with emulated PDP-8 w/MDC8 users wherever they may spring up. Rumor has it that such a program is being developed for 286 (or better) -based PCs. There is also a VAX Fortran-based emulator floating around. I wouldn't expect too much performance from it in turns of emulating the SPEED of an -8, but it is rumored to work. cjl Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 29 May 91 11:04:27 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 29 May 91 11:00:44 EDT Received: from cs.umn.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14502; Wed, 29 May 91 10:41:16 EDT Received: by cs.umn.edu (5.61/1.14) id AA07568; Wed, 29 May 91 09:40:47 -0500 Date: Wed, 29 May 91 09:40:47 -0500 From: "Lawrence T. LeMay" Message-Id: <9105291440.AA07568@cs.umn.edu> To: pdp8-lovers@ai.mit.edu Subject: PDP8/E core memory Cc: lemay@cs.umn.edu Date: Wed, 29 May 91 09:40:47 -0500 From: "Lawrence T. LeMay" To: pdp8-lovers@ai.mit.edu Subject: PDP8/E core memory Cc: lemay@cs.umn.edu I have two sets of PDP8/E core memory boards, and i'm trying to figure out EXACTLY what I have... Perhaps someone here has the correct manuals and could look these boards up for me... Set 1: board A: 8K XY Driver Board 2074 PCC board B: (Core memory board) Dec P/N H212 Size 8K X 12 (175) board C: G104C Sense Inhibit Set 2: board D: G227C board E: G619A Planar Stack Board (Electronic Memories Inc, Core memory) (Dec H220) board F: G111C Sense Inhibit I'm assuming that Set 1 is 8K because of board A, but I'm not sure... And set 2 I have no idea, but could be the same as set 1 (but then, why are the board numbers all different?). BTW, is it possible to get these boards tested/repaired?? I thought I heard something about a year ago about someone who was repairing PDP8 memory boards... Ah well, wishfull thinking no doubt. -Larry LeMay lemay@cs.umn.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 29 May 91 12:24:32 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 29 May 91 12:20:57 EDT Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21387; Wed, 29 May 91 12:00:04 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA17579; Wed, 29 May 91 11:59:27 EDT Date: Wed, 29 May 91 11:59:26 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: 8/e memories Message-Id: Date: Wed, 29 May 91 11:59:26 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: 8/e memories From: Charles Lasner To: "Lawrence T. LeMay" Subject: Re: PDP8/E core memory In-Reply-To: Your message of Wed, 29 May 91 09:40:47 -0500 You have a 4K and an 8K set of -8/e memory boards in that order. The 8K designation is misleading, but what they mean is that the board etch is theoretically interchangeable, BUT not really when populated with different or more/less stuff. Also the 4K board for use with the 8K version became obsoleted in favor of the board your 8k set has in it. The deal is that the about 1000 earliest 8K sets tried to carry out the premise of the etch you mentioned, and those early card sets were very finicky. All 4K sets have to tuned *AS A SET* as it is, but the 8K versions were more critical still. One advantage of the 8K newer cards is that each card is adjusted to a spec, not a local set, so 8K boards should be totally interchangeable. On an irregular basis, I repair omnibus boards, including -8/e memory cards. When I am done with them, they are literally better than new. The reason is that late in the -8/e era came out the VT8E. If you patch the diagnostic for -8/e memory checkerboard for example to NOT do CAF instructions (two locations), and manually start the program, the diagnostic runs just fine on virtually any 8K stack, or whatever. The manual start is just as good as the NOP'ed instructions because you use a manual clear. Now here's where it gets interesting: DEC's spec for the final adjustment of the sense amp timing is to specify that therre are generally 4-5 settings of the tap switch that work without causing errors while running this program. Use the "centermost" of them. Well, what if there are FOUR settings, not five, which do you use? Also, the center one may not be the best after all. I toggle in a short VT8E program which starts it up in graphics mode, the worst case DMA mode, with it using a suspect memory as the designated buffer. (You can make the whole program self-relocate and then it's arbitrary.) When the suspect memory is subjected to the tighter timing of a fast series of bus cycles "attacking" portions of the memory, it is getting a worse test than the checkerboard program! In core memory, reads are worse than writes. The way it works is that the read is destructive and yields what the immediate FORMER contents WAS. Then, the contents have to be written back. All of this has to be done in one DMA cycle! Technically, there is one mode faster than this to "punish" the memory, namely to make it execute WITHOUT DMA a series of one-cycle jumps and operates, essentially like the LEAPFROG program of the LINC from years ago. In this mode, all instructions are 1.2, whereas longer instructions are a mix of 1.2 and 1.4, and the memory doesn't participate in the 1.4-long cycle unless it is a TAD or AND. (If a DCA, it merely has to write, but the others have to read, and then have lots of time to restore the aftermath of the destructive read. ISZ is a strange one, the destructive read is followed by an increment from the CPU, and then the updated contents are written back in the next cycle. The point is that only operates and JMP are truly 1.2 per cycle. Unfortunately, there are no programs for the -8 that do this and check for reliable memory contents afterwrds. My patched checkerboard program is therefor subjected to the next worst thing: a series of 64 DMA cycles, which are 1.4 each, and otherwise do the same thing, namely read sequential areas of memory, and each has to "fixup" after the destructive read. If it doesn't get done in time, then the checkerboard's testing code will pick up the discrepancy. So, this way, it narrows down the acceptable settings to 1-3 notches, instead of 5. Also, if faced with an even choice count, I will always choose the earlier strobe setting as this seems to be slightly less noise-prone, although most seem to get 3 options thus avoiding the quandry. I may be persuaded to fix some "outside" boards, but I've never done this; I'm not in "the business" :-). I suppose some "hobbyist rate" can be determined for my time (clearly much less than my "consulting rate" is :-). cjl (have oscilloscope, WON'T travel, with apologies to Paladin...) Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 29 May 91 15:08:06 EDT Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 29 May 91 15:04:19 EDT Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22049; Wed, 29 May 91 14:36:52 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA19678; Wed, 29 May 91 14:36:15 EDT Date: Wed, 29 May 91 14:36:14 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: reply to GRG Message-Id: Date: Wed, 29 May 91 14:36:14 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: reply to GRG Glad my ideas helped this potential emulator author. A few words about the technique of emulating the hardware of the RK8E: There is some overhead in what he is attempting to do, because the RK8E makes the PDP-8 participate in the I/O controlling. The code is NOT merely a setup of a disk read/write and just wait for it, rather there are kludgy things like checking for track overflow and setting/not setting a "don't check id's" bit, etc. between individual record transfers. Also, since this is a one-at-a-time device, there is multiple occurrences of this overhead. The point I was trying to make is that only certain pragmatic occurrences of the handler's IOT's were allowed on the PDP-15-based DECtape emulation. These were in "standard" places like P?S/8's system handler, and OS/8's system and non-system handlers. Once detected, the emulator abandonded the emulation, and examined the call at a higher level, namely it understood the system call and attendent arguments. The requested operation was done totally with "real" I/O to carry the whole operation out. PDP-8 emulation continues by returning to past the arguments as if the entire call were done by -8-code. This avoids ALL of that overhead! Using the MDC8 as an alternative, you don't have to deal with any special pragmatic cases, because there is the same level of emulation, namely that the PDP-8 code is processing the arguments of the call, and setting up in PDP-8 memory an image of an SCSI command. Then, the IOT's happen which merely point the "hardware" at the command. The -8 expects its on-board controller to do all the work, while it merely periodically checks a done flag or gets interrupted EVENTUALLY after the fact. This is ideal for an emulator, because you just emulate the SCSI command, and then restart the -8 after the fact. For the benefits of interrupts, the command getting actually executed on the physical bus can restart the emulation process, and when the host machine gets interrupted for actual I/O completion, the emulator can make the done flag emulation skip when necessary. This allows the partial overlap desired should interrupt-driven PDP-8 I/O be desired, yet minimizing the usual non-interrupt I/O emulation overhead. Since every SCSI command is a complete entity in andd of itself, every call translates into just one SCSI command, so effectively you get the emulation speed of the PDP-15/DECtape example, without having to have the special-purpose pragmatisms of "knowing" the inner-workings of handlers and applications and diagnostic programs, which incidentally are CURRENTLY being developed. (The CESI product is not "dead" in that there are some currently supported systems that use it. I write diagnostics for the beast, etc., and am still quite active in this area. A properly configured emulator could run MDC8 diagnostics :-) PDP-8 quirks. GRG is quite correct, there is a strange bug of the original PDP-8 and LINC-8 with extended memory. If a CDF to a non-existant field is attempted, then the next instruction is used as a pointer address to where another instruction is, which is then executed. Assuming the inadvertantly pointed-to instruction isn't a JMP or JMS or itself skips, then the PC is incremented to skip around the next instruction past the bad CDF! I have a memory test routine used in P?S/8 to find out the machine's core size which uses this fact to detect memory size on PDP-8's while also doing other things for other model's quirks. It is partially based on the routine found in the PS/8 and OS/8 technical reference manuals, which is DEFECTIVE! This is responsible for bugs when running OS/8 on an -8/l specifically. Otherwise, that code works on most models; my code is size-optimized, but uses most of the ideas in the OS/8 example, and an additional check that an -8/l can't screw up. The P?S/8 checking code is based on the fact that field zero exists, and ALL ELSE is optional, whereas OS/8 also needs field one (perhaps two also) to exist as well. The -8/l bug is that there is an -8/l quirk that CDF to a non-existant field is a NOP, NOT a CDF to another field that does exist somewhere else, or addresses fresh air. This is what most of the other models do. Since the -8/l treats it as a NOP, then the LAST CDF is still in effect. Most -8/ls are 8K, so the last "legal" CDF is CDF 10. Then they attempt CDF 20. That becomes a NOP here, so attempts to access memory "work" in that they find addressable memory, and it isn't in field zero (a check that exists because of the PDP-8 quirk mentioned earlier; they force an -8 to essentially store over field zero location zero if a "bad" CDF happens on an -8, so they check for inadvertent destruction of 00000.) The problem is that this is FIELD ONE's test location, NOT field two as expected, so the routine is "fooled" into believing that field two exists, and by iteration, fields 3-7 as well :-). So, this stupid code reports a 32K 8/l instead of 8K! (Real 4K -8/l's don't have this problem, but 8K and 12K -8/l's do.) The P?S/8 solution is to ALWAYS do CDF 00 BEFORE attempting the next test field. This way, field ZERO's test location will get zapped, and that will be picked up by the PDP-8 quirk test code. The sequence is CDF 0 then CDF testfield, not CDF 10, CDF 20, CDF 30, etc., as in the defective OS/8 example. I believe this invalid code is still in programs like PAL8, etc., so beware of -8/l usage! I would recommend implementing the -8/e instruction set for an emulator, and forget about other quirks. The memory check would be that non-existent memory just can't be stored into and read back with the same value. This is the gist of the main test loop typically anyway. Then, a feature can be added to the emulator we would really like, namely that execution of SUPERSET instructions like BSW and CAF can be trapped back to the emulation level. This will allow detection of instructions in OS/8 programs that prevent their use on the -8, etc. P?S/8 is carefully scrutinized for this, as I run it on straight -8s and my own 4K LINC-8. OS/8 used to be as good, but over the years has gotten very sloppy, and was subjected to "management tyranny" specifically over the use of OS/8 on "pre-Omnibus machines" as they called it when they dropped support. All of this turmoil over avoiding the use of a small few instructions. The easy way to prevent this could have merely insists that all programs be assembleable using PAL8 both with and without a header file containing the EXPUNGE pseudo-op and a suitably re-defined symbol table containing only PDP-8-worthy symbols, no extensions. The P?S/8 PAL assembler source itself literally contains those usages in the beginning of the source. The binary output of the assembly of P?S PAL does include superset symbols like BSW for the benefit of users of PAL, but it makes no internal dependency on them for subsequent execution. An emulator capable of (optionally) trapping superset instructions specified in various lists would allow us to find these past problems and correct them. Usually, they can be patched out using short sequences; BSW is always replaceable with three RTL or RTR instructions depending on the author's intent, or somesuch. I personally have used things like JMS I [ROL6] in my code, so it calls a subroutine containing RTL;RTL;RTL. If the program discovers it is running on an -8/e or better, then it patches itself with BSW over all of the JMS's for better execution speed maintaining compatibility. Using techniques like this, and just plain being careful, has led to why KERMIT-12 will run on any model, from PDP-8 through DECmate III+, even though the underlying operating system is an OS/8 family member that can only run on a few models. These few pesky instructions are all that prevents more universal application. I am committed to OS/8 Version 5, which, like P?S/8 DOES CURRENTLY, WILL RUN on the entire hardware family of PDP-8 (which excludes the -8/s and -5 as most of you already know :-( :-) For myself, I would like to see an emulator also have a serial port to the outside world, so KERMIT-12 could be run on the emulator :-). cjl