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  <enders@plains.nodak.edu>
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  <enders@plains.nodak.edu>
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 <Qobi@zermatt.lcs.mit.edu>
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 <Qobi@zermatt.lcs.mit.edu>
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: <lasner@watsun.cc.columbia.edu>
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 <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Todd Enders question about -8-on-a-chip
Message-Id: <CMM.0.90.0.661125382.lasner@watsun.cc.columbia.edu>

From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: Todd Enders - WD0BCI <enders@plains.nodak.edu>
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 <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
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 <D89.JOHNNY-BILLQUIST@aida.csd.uu.se>
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


