M8195 SLU died while in use

Aaron Jackson aaron at aaronsplace.co.uk
Wed Sep 27 17:37:49 CDT 2017

Hi Noel,

Thanks for the very useful information. I'll do some investigation this
weekend and keep an eye out for a spare SLU. Being in the UK makes it
quite difficult to find these things.

Thanks again,


Noel Chiappa via cctalk writes:

>     > From: Aaron Jackson
>     > a PDP-11/73, M8192 CPU, two M8067 RAM, M7195 ... While playing in ODT,
>     > the console completely stopped responding.
>     > ...
>     > The CPU shows 1000, which I believe is fine, and means it's in ODT. The
>     > SLU card has 1111. I've had a Google and I believe this means it can't
>     > communicate with the CPU.
>     > ...
>     > Does anyone have any ideas? It was working and then it wasn't :(
> Hmm. Well, it's possible something just died. Dead boards are not un-common,
> I've found, but to have one die while it's being worked with is a bit of bad
> luck... Alas, I can imagine a zillion failures that could produce this symptom
> (from EIA driver chip, down to a bus transceiver chip on the CPU).
> OK, to start with, those LED values. When you say 1000 on the CPU, there's
> some ambiguity as to which direction you're reading them; so, which LED is
> on? From above the board (component side up), with the contact fingers at the
> bottom, the one on the left, or the one on the right? I'm going to assume the
> one on the right, which does indeed mean the CPU is claiming it's in ODT.
> While we're on the CPU, is it set to halt on power-up (power up mode 1) or
> try and start the ROM (power up mode 2)? I always set mine to halt, on the
> grounds that it's easy to start the ROM.
> I'm not familiar with the MXV11-B (M7195), and I couldn't turn up a manual
> online, but likely those LEDs are set by software (I can't imagine how one
> would turn on a "can't communicate with the CPU" bit in hardware ... unless
> it's a flop that's set on power-on, and cleared by the first bus cycle to the
> card)...
> Anyway, there are two approaches to solving this problem. 
> So, one option (depending on your budget) is to buy spare boards so you can
> board-swap to localize the problem to one board.
> I would recommend getting the spare boards anyway since I would recommend
> always having a spare minimal set of boards (CPU, serial line) etc. Without a
> 'working' machine - at least to the point of running ODT - it's hard to do
> much poking into problems without a lot of pain (i.e. hard work with things
> like a logic analyzer or oscilloscope). Being able to board-swap to at least
> localize the problem to one board is a big help.
> So, start with another serial card (QBUS serial cards are pretty easy to find
> on eBay, and not too expensive), and swap out the MXV11-B, and hope the
> serial card you bought works. There are a ton of boards that can do this -
> M7940, M8017, M8028, M8043 (the first 3 single line, the last is a quad, but
> uses the same connector as the MXV11-B, unlike the first 3). (If that option
> is out, I can lend you a known working serial card.)
> If it's not the serial card, the next thing to buy is a spare CPU; -11/23's
> are not too expensive, you don't need a /73 to debug hardware issues.
> The other approach is to debug the hardware. You mention an oscilloscope; do
> you also have a logic analyzer? Some things (e.g. checking that when you type
> a character, the serial interface presents it to the CPU) are going to be hard
> with only an oscilloscope - although I suppose one could program one's
> computer to send a constant stream of characters (probably DEL) to the -11.
> I couldn't find a set of MXV11-B prints online - does anyone know of a set?
> Without that, if the problem is in the MXV11-B, finding it's going to be
> painful.
> Anyway, you could check on the QBUS to make sure the processor is actually
> cycling, trying to read the console input status register, waiting for the
> 'input character ready' bit to go on. So look at BSYNC and BRPLY, to see if
> they are hopping up and down.
> Oh, I guess there's a third option: send the CPU and MXV11-B to someone who
> has a working system, so they can board-swap and check them out. (I've done
> this for people...)
> Bottom line, though: if the fault is in the MXV11-B, unless we can find some
> prints for it, you're probably stuck with buying at least a replacement
> console serial card.
> 	Noel

Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham

More information about the cctalk mailing list