Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Wed, 12 Dec 90 12:18:23 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 12 Dec 90 12:16:05 EST Received: from plains.NoDak.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19879; Wed, 12 Dec 90 12:01:53 EST Received: by plains.NoDak.edu; Wed, 12 Dec 90 11:02:20 -0600 Date: Wed, 12 Dec 90 11:02:20 -0600 From: Todd Enders - WD0BCI Message-Id: <9012121702.AA26383@plains.NoDak.edu> To: pdp8-lovers@ai.mit.edu Subject: pdp-8 on a chip? Date: Wed, 12 Dec 90 11:02:20 -0600 From: Todd Enders - WD0BCI To: pdp8-lovers@ai.mit.edu Subject: pdp-8 on a chip? I was looking at some old microprocessor info I had laying about and I saw something about the INMOS 6100 chip. It appears that this bugger is (was???) a pdp-8 CPU on a chip. They were making these in about the same timeframe as the Intel 8080 (late 70's). I suppose if they make these anymore, they are either rediculously cheap (like 8080's) or relatively expensive (limited production product). Anybody know if they make these chips anymore? It'd be interesting to see if one could fabricate replacement pdp-8 CPU boards from these chips. =============================================================================== 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; Wed, 12 Dec 90 19:40:58 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Wed, 12 Dec 90 19:38:40 EST Received: from ZERMATT.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04318; Wed, 12 Dec 90 19:27:04 EST Received: from WHIRLWIND.AI.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 71863; 12 Dec 90 19:16:54 EST Date: Wed, 12 Dec 90 19:15 EST From: Jeffrey Mark Siskind Subject: pdp-8 on a chip? To: enders@plains.nodak.edu, pdp8-lovers@ai.mit.edu Cc: Qobi@ai.mit.edu In-Reply-To: <9012121702.AA26383@plains.NoDak.edu> Message-Id: <19901213001527.5.QOBI@WHIRLWIND.AI.MIT.EDU> Date: Wed, 12 Dec 90 19:15 EST From: Jeffrey Mark Siskind Subject: pdp-8 on a chip? To: enders@plains.nodak.edu, pdp8-lovers@ai.mit.edu Cc: Qobi@ai.mit.edu In-Reply-To: <9012121702.AA26383@plains.NoDak.edu> I don't know what the status of the 6100 is but here is something else which might interest you. A number of years back, I wrote a silicon compiler called MacPitts which took a behavioral description of a digital system (in a language somewhat like ISPS) and automatically generated a full custom layout for a chip which implemented that system in 3 micron nMOS using the Mead-Conway design rule (including burried contacts). One of the many sample systems we designed using this compiler was a PDP-8. The description is about 4 pages of code (maybe even less). We never fabricated the chip but we were able to do a transistor level switch simulation on a schematic which was node extracted from the layout so it is very likely that the chip would work. I could probably resurect the CIF (mask data) file for you but that probably wouldn't help you much since we never implemented EAE, fields, or a mechanism for handling IOT instructions since our purpose was to show how easy it was to desing a chip. These things can be added trivially to the behavioral spec and then recompiled but the compiler has suffered code rot and would have to be resurrected. It might be possible to do this depending on the level of interest. Jeff From lasner@watsun.cc.columbia.edu Thu Dec 13 17:16:17 1990 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA20950; Thu, 13 Dec 90 17:16:15 EST Received: from LIFE.AI.MIT.EDU by cunixf.cc.columbia.edu (5.59/FCB) id AA16622; Thu, 13 Dec 90 17:17:55 EST Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09708; Thu, 13 Dec 90 16:55:21 EST Received: by watsun.cc.columbia.edu (5.59/FCB) id AA20776; Thu, 13 Dec 90 16:56:22 EST Date: Thu, 13 Dec 90 16:56:22 EST From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Todd Enders question about -8-on-a-chip Message-Id: From: Charles Lasner To: Todd Enders - WD0BCI Subject: Re: pdp-8 on a chip? In-Reply-To: Your message of Wed, 12 Dec 90 11:02:20 -0600 The 6100 Chip came from Intersil and later their licensee Harris. Intersil called it IM6100 and Harris called it HM6100. Intersil made various small micro boards that were not complete systems, and were also not compatible with anything in particular, but they were running 8-code. Eventually they made a whole machine called the Intercept. It includes a compatible 03/04 interface that even supports reader run and current loop to run a teletype. There is a memory extension control and 4-k memory boards each with battery backup. The buss is so well isolated that it is legal to remove the memory boards without loss as long as the machine is halted and you are grounded (no static electricity problems). A custom interface board for the Intercept was made by DSD for their RX01 superset (it can format, DEC's can't!) known as the DSD-210. Intersil sold this drive as an Intercept option. Complete systems could exist with two-four drive DSD-210s and 4K-32K RAM memory. (The CP memory program is ROM resident plus a scratch-pad RAM for a small portion of Page Zero of CP memory. There is a front panel which is simulated by using Control Panel (CP) memory. Periodically, clock ticks force the machine to enter the PDP-8 *incompatible* mode after saving context. The CP routines handle all simulated front panel activities except the run/hlt line which is real. For those unfamiliar with the Control Panel mechanism, CP interrupts even remember if the PDP-8 side was halted, and when the front panel routines exit, the machine is an -8 and it halts again as if the CP stuff never happened. The front panel can read the function switches and output to LEDs via direct memory-mapped I/O, not IOTs. I/O capability exists to change the indirect memory references to point to main PDP-8 memory or CP memory. This is needed so the CP program can reference both itself and the normal main -8 memory when it does simulated front panel operations like examine which puts the value of the location corresponding to the front panel switches (read with LAS) into the LEDs (using DCA CP 100). The overhead of the CP interrupts can be adjusted with a front panel clock speed adjust knob, or even disabled. The trade-off is that the lights update quickly and the machine crawls or the lights update slowly and the machine runs faster. This machine was sold commercially optionally bundled with a software product called IFDOS. IFDOS was a version of P?S/8 (my operating system for the -8) licensed to Intersil by me (Yeah, I got paid!), since DEC expressed some concern for selling DEC software on non-DEC hardware, and P?S/8 is *NOT* a DEC product. This was a non-exclusive arrangement, so P?S/8 is not in any way owned by them. A company called Pacific CyberMetrix (PCM) made two Intercept-compatible machines called PCM-12 and PCM-12A. I have an Intercept with 12K and a PCM-12. PCM also made peripherals for the machines such as digital I/O, etc. The machines are buss-compatible and PCM actually sold Intersil's memory boards and extended memory controller and DSD's DSD-210 controller and drives. All chips throughout these machines are CMOS and are very low power. (And are very slow!) The standard machines are based on the premium grade-out (4 MHz) 6100 chips, which run at about 2/5 the speed of the 8/e. It is virtually impossible to add EAE to this chip since not enough is brought out to the pins to do it. Eventually, Intersil brought out an extended memory controller chip, but the extended memory boards are roll-your-own with many chips like the standard M837 of the 8/e. It is notable in passing to mention the Program Interface Element or PIE chip. This is an I/O chip that allows custom interfaces to be built for the 6100 machine rather easily, but not in a software-compatible way. The biggest difference is that each device flag (there are four of them) can optionally interrupt, but in any case must be tested with instructions that skip on AND clear the flag. Notice that this is incompatible conceptually with the console keyboard interface where KSF skips and skips again if the flag is not cleared with KCC or KRB. This is the essence of ^C handling in that the KRS instruction is used to test for ^C without disturbing the flag if KSF skips. Then the program can exit to the keyboard monitor which tests the flag again with KSF which skips again. KRB reveals the character to be ^C and the appropriate action is taken. If a PIE chip-type approach is taken, then this can't be done (more on this subtle yet very important difference later). Eventually DEC dealt with Harris for the HM6100, but only bought cheap grade-outs of the chips, which were used in the VT-78. They are only 2.3 Mhz and are thus *VERY* slow. Much of the "grief" associated with writing handlers for the RX01/02 stems from attempts to make the handlers fast enough on the slow VT-78. Most handlers fail to keep up with the RX01, and thus run very slowly since typically the disk is setup for two-way interleave (two passes transfers all sectors) and it misses every time and takes thirteen times as long (twenty-six passes to get all twenty-six sectors!). The P?S/8 RX01 handler succeeds in keeping up with the disk interleave because there is a speed-optimized sector mapping routine that is unavailable from OS/8. (P?S/8 system handlers can be nine pages long; OS/8 system handlers can be only two pages long. P?S/8 non-system handlers can be 32 pages long; OS/8 non-system handlers can be only two pages long. You can't do everything an RX01 demands in only two pages, so one thing that suffers is speed when run on a VT-78. The OS/8 handler runs fine on the Intercept or PCM-12 because they are almost twice as fast as the VT-78.) Except for speed, the 6100-based machines are usually software compatible with any non-EAE application. All of the interfaces (not based on the PIE chip) from Intersil, PCM, or DEC (within the VT-78 are a reasonable quantity of standard interfaces, although no options) are totally compatible with 8/e, 8/a hardware. There is even a superset in the VT-78 in that the serial interfaces have an LSB instruction to load the baud rate from one of sixteen standard speeds up to 19,200 baud. This IOT is ignored on 8/e. (Warning, it might clear the keyboard flag, advance the reader if a teletype, and possibly skip on older interfaces!) Eventually, Harris was contracted by DEC to make a replacement chip called the 6120 for the newer product line that was to become the DECmates. This chip has the extended memory control built-in for 32K of both main and CP memory, and has the beginnings of an interface for EAE (DEC never implemented it!). This chip is as fast as an 8/e; some instructions are marginally slower, and some are marginally faster. The 6120 is clearly a step forward. A major problem developed: The 6120 has a companion PIE chip called 6121. It, like its predecessor, is *NOT* compatible with existing keyboard interfaces. It was apparently designed foolishly to be compatible with the earlier PIE chip of the 6100, and does *NOT* program compatibly with either the old PIE chip or the PDP-8. Ludicrously it is *ALMOST* compatible with the PDP-8 console (Yeah, and the software *ALMOST* runs on this hardware, but it still does *NOT* work!). Here are the differences: 6030 KCF Clear the keyboard flag (8/e) becomes SET the keyboard flag on the 6121. 6031 KSF Skip on keyboard flag (8/e) becomes skip on and CLEAR the keyboard flag on the 6121. 6032 KCC Clear AC, keyboard flag (8/e) becomes clear AC only on 6121. 6033 LSB Set baud rate (VT-78 only, NOP on 8/e) on 6121. Not a problem. 6034 KRB Read latest character in buffer, do not disturb flag (8/e) becomes re-read same character last read by 6036 on 6121. New keystrokes are buffered by CP memory routines and don't affect this. 6035 KIE Load interrupt enable per AC[11] for both 03 and 04 (8/e) becomes load interrupt enable per AC[11] for 03 ONLY on 6121. 6036 KRB Read latest character in buffer, clear flag. While superficially this is identical on all machines, a vital difference is that 6036 is MANDATORY should 6031 skip, else 6031 will never skip again even if further keystrokes. The machine has to be RE-BOOTED to recover! 6040 TFL Set terminal flag. No problem. 6041 TSF Skip on terminal done flag becomes skip on and CLEAR on 6121. This can be a slight problem with some software that tries to initialize the flag because it winds up clear instead of set! 6042 TCF Clear terminal done flag becomes clear the AC on 6121. This can be a minor problem if the AC needed to be maintained. 6044 TPC Output character without clearing the flag which later leads to it being set on character completion. No problem on the 6121 but only because the flag is handled (incorrectly) elsewhere. 6045 TSK Skip on KL-8 device is interrupt enabled and either input or output flag is set becomes load interrupt enable per AC[11] for device 04 only. Totally incompatible, but only a consideration for interrupt-driven routines. The original purpose of this seldom used instruction was to minimize polling overhead on the terminal on the theory that it was a low-speed device in general, so one flag test goes faster than two when you are seeking other sources of interrupt. When an actual interrupt occurs on the terminal, it causes overhead since you have two more flags to check. Interrupt routines should not use this instruction for this purpose, and must instead load the interrupt enable with it, and then use a NOP after it in case the machine is an 8/e where it might skip. 6046 TLS Clear terminal done flag and output character which eventually leads to the flag being set when the character is done. On the 6121, there is no flag clearing because normal programming of this instruction follows execution of 6041 which has now cleared the flag already. This should not cause a compatibility problem as long as the flag is in a known state before using the 6046 instruction. Interrupt-driven routines can carefully be written that will work on the 6121 and any -8 as long as the initialization is *VERY* carefully done. Much older code that won't run can be patched (like FOCAL). OS/8 DOES NOT RUN HERE! The OS/278 system is a wimpy attempt to deal with this deficient hardware. All OS/278 code had to be rewritten from the original OS/8 stuff, and ^C handling doesn't work at all! Some programs, such as OS/278 PIP will actually print the "^C" themselves to "fake" ^C handling. However, it doesn't really work, since BATCH operations are not terminated should PIP be running under BATCH. When running on an 8/e, OS/278 similarly wimps out since it now uses a subset of the console interface acceptable to both the 8/e and 6121. I have devised a mechanism to fix this problem. I have incorporated it into P?S/8 which now runs on any -8 from the classic PDP-8 through the DECmate II (assuming RX01 is the media). I propose that a similar mechanism be incorporated into a new OS/8 to be called Version 5. Details are available, but basically it is this: a) Remove all extraneous instructions like BSW or IAC RTL that have crept into the code so it will work on any -8. This is already true for PAL-8 Version B0 and CREF Version B0 but not much else. I have done this for KERMIT-12 so it runs on any OS/8 family system. (Note: ^C is handled internally by KERMIT-12 and is not an abort back to the OS, so this is totally true. There is no proper mechanism currently in OS/8 to make KERMIT able to tell OS/8 that it aborted even if so desired. The new scheme would allow this.) b) Add a new software flag to allow ^C abort independent of the hardware. There is an available bit for this in 007601[11]. I have also heard of other efforts with these CMOS chips including the SBC-8 using the 6120 from CESI, and various 6100 projects, but these are the main ones. Charles Lasner lasner@watsun.cc.columbia.edu (home of KERMIT-12 and other fine KERMITs) Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 20 Dec 90 12:14:56 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 20 Dec 90 12:12:39 EST Received: from rpi.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10834; Thu, 20 Dec 90 11:56:56 EST Received: from MTS.RPI.EDU by rpi.edu (4.1/RPI-ITS-SM54); id AA05290; Thu, 20 Dec 90 11:55:00 EST for PDP8-LOVERS@ai.mit.edu Date: Thu, 20 Dec 90 11:56:38 EST From: John_Wilson@mts.rpi.edu To: PDP8-LOVERS@ai.mit.edu Message-Id: <2093166@MTS.RPI.EDU> Subject: RK8E Date: Thu, 20 Dec 90 11:56:38 EST From: John_Wilson@mts.rpi.edu To: PDP8-LOVERS@ai.mit.edu Subject: RK8E I recently got an RK8E for my 8/E and I'm trying to set it up. Does anyone have documentation on it that I could copy? I'm looking for anything, but most importantly I need programming information (I know most of the IOT opcodes are the same as the RK08P but somehow I doubt the AC formats are the same), and also I need to know what cables I should be looking for. My RK05 documentation implies that the Unibus cables that go with my RK11D won't work, the picture shows what looks like the usual 40-pin ribbon cable, which would explain the berg connectors on the RK8E. If anyone actually has these cables I'd be interested in buying them but just knowing the part number would be enough for me to get screwed by ESS again. Which is better than nothing. Also, is an M930 still the right thing to use for a terminator? John Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 27 Dec 90 08:59:57 EST Received: from life.ai.mit.edu by ELI.CS.YALE.EDU; Thu, 27 Dec 90 08:57:38 EST Received: from sunic.sunet.se by life.ai.mit.edu (4.1/AI-4.10) id AA05085; Thu, 27 Dec 90 08:41:55 EST Received: from AIDA.CSD.UU.SE by sunic.sunet.se (5.61+IDA/KTH/LTH/1.168) id AAsunic16125; Thu, 27 Dec 90 14:41:50 +0100 Date: Thu 27 Dec 90 14:40:28 From: Johnny Billquist Subject: Re: RK8E To: John_Wilson@mts.rpi.edu Cc: PDP8-LOVERS@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <2093166@MTS.RPI.EDU> Message-Id: <901227144028.17.D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE> Date: Thu 27 Dec 90 14:40:28 From: Johnny Billquist Subject: Re: RK8E To: John_Wilson@mts.rpi.edu Cc: PDP8-LOVERS@ai.mit.edu, D89.JOHNNY-BILLQUIST@aida.csd.uu.se In-Reply-To: <2093166@MTS.RPI.EDU> I have pretty complete docs for the RK8E if you can't get it from anywhere closer (I'm in sweden). The cable from the controller to the first drive is different than for the RK11. The cables between the RK05s can be UNIBUS cables. The M930 is the correct terminator. Unfortenately I don't have any spare cables for the RK8E. I have only the same number of cables as controllers, and one cable is broke. I can check out the number that is printed on the card, though. The cable from the RK8E to the RK05 is velded (?) (I'm swedish...) to a card which is plugged into the RK05. Johnny