PDP 11 Line Time Clock (LW11L) M787 and EIS board, (KE11E) M7238
billdegnan at gmail.com
Mon Feb 13 12:42:46 CST 2017
On Mon, Feb 13, 2017 at 1:22 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> > From: William Degnan
> > PDP 11 KE11E M7238 EIS board (for PDP 11/40) which causes the CPU to
> > crash when installed; front panel not responsive
> > ...
> > I installed a removable jumper so I can flip jumper configs back and
> > forth between EIS installed/not installed. Without the EIS the system
> > works fine
> To understand this symptom, one needs to understand how the EIS interacts
> with the main CPU. Both include microcode, and what is supposed to happen
> that when an EIS instruction happens, control is passed to the microcode on
> the EIS board (the actual microcode words being fed back to the main CPU
> through those three over-the-back jumper cables). The microcode on the EIS
> board can then control the data paths, etc in the main CPU, to feed the EIS
> data, and take back the results of the computation performed on the EIS
> I'm trying to understand what W1 does, but I'm not there yet. It's shown on
> the KD11-A print K3-8 (pg. 48), in the lower left corner, but its effects
> somewhat obscure.
> To start with, the array of odd chips E6-E7 (74H60's) and E17 (74H53) are
> expandable AND-OR gates. I'd never seen these before, but the lines running
> to and from pins 11 and 12 on the 'H53 join the other three gates below it
> into it - i.e. that whole array of AND gates all feed into one NOR gate
> (output on pin 8 of the 'H53).
> So far, so good, but from there I'm still lost. When W1 is inserted (no
> it grounds the signal ECIN00, which comes in from off-board (as shown by
> "A05S2", which is the pin it arrives on). The output of that giant NOR gate
> is CIN00, which is immediately sent off-board (pin 'A05P1'). I have yet to
> try and chase these signals down, and work out what they do; the KD11-A
> Manual is fairly cryptic on the subject.
> Note also that, IIRC, the front console operates under control of
> So I'm _guessing_ that what is happening is that somehow the EIS is, when
> enabled, messing up the operation of the microcode in the main CPU, causing
> it to freeze.
Probably would not be a bad idea to test the cable and the connectors as
well as the board. There could also be a fault with the UWord module
(M7232) associated with signal processing too.
More information about the cctech