> 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
