> > 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
