Oops, I forgot to mention a few other checks that I did ...
AC LO and DC LO are some 4.6V. Both have a 130 mV ripple, no spikes.
That seems OK to me.
Sure, those sound OK to me too. But you would have felt a right idiot if you
had spent days working through the microcode and CPU logic only
to find the real cause was something like that. Yes, I've been there,
done that...
[...]
Thanks for the tip checking the microcode program
counter. I hope to
get to that next weekend. Also, with the correct module on extenders
I will check what toggling LOAD ADDRS does signal-wise. Looking at
the console LEDs it does nothing :-/
In general on a microcoded system, assuming a listing of the microcode
is available (as here), the microcode program counter a good place
to start testing.
You should look for several things :
Is the microcode running, or is it stuck in a particular address?
If the latter, should it be stuck there, perhaps it is waiting for
some external input (like a console switch :-)). Try to find some
way of giving it that input and see what happens.
If the former, is the sequence of states reasonable (does it correspond
with something the microcode could ever do, evem if it shouldn't
be doing that now). Is it a possible sequence of states for what the
machine should be doing (What I mean here is that if the microcode
is say fetching something from memory, interpretting it as a particular
instruction, doing that, and repeating, then the microcode is doing
something that sometimes it should be doing (e.g.. when running a program)
even if it shoudn't be doing it when you have halted the machine from
the console, whereas if the microcode is jumping through an apparently
random set of states then I would suspect the microcode program
counter register, the control store ROMs, jump logic, etc.
Incidentally, is this an 11/10 or an 11/10S (what are the M-numbers on the
CPU boards)?
-tony