9 Nov
2006
9 Nov
'06
1:54 p.m.
Gooijen, Henk wrote:
I am still wondering if the messages "(Console
V3.40C)", "(Program)",
and the prompt ">>>" come from the same source ...
As I don't have much clues, I decided to swap the MFM board (M7096).
No luck, the symptoms are the same.
Then I figured, if you can not halt the CPU, that must be "control".
So, first I placed the original MFM board back in and the swapped the
CTRL board (M7095).
There is some progress, after I enter ^P, I get the response "(Program)"
and the the prompt ">>>" !
I did the T and the E command, but for T/E and D commands I get "?CP halt".
OK, makes sense ... but the H command gives the response "?Failed to halt".
The RUN light remains on.
So CTRL *seems* to be a partial solution. Any thoughts ?
The above behavior of the console now appears to be normal (^P gets you to
the >>> prompt; trying to do T/E with the CPU in 'run' mode gets you the
?CP halt error, indicating you must halt the cpu via H before running these
commands). Now when you give the H command the CPU does not appear to halt.
For my 11/34 and 11/44 I found that when I first got them they would become
'mechanically' unreliable if I let them sit without jiggling boards around
for more than a couple of months. Finally I broke down and bought a contact
cleaner package from CAIG Labs (DeoxIT) and went over all the gold fingers
on each of the boards. I have not seen a problem since then; the systems
have
been in place for almost 9 mos without any board reseating done.
I had similar problems with my PDP-8m and the over-the-top connectors
(really
the same DEC backplane connector) on omnibus modules. I found several
instances
where some contacts had developed high resistance (50-100ohm) vs the
normal sub
one ohm. I had suspected bad logic, but it was really just a high resistance
connection (which old TTL just does not tolerate very well, due to
reasonably
high I/O current). I suspected I had bad boards in my 8m EAE, but in reality
all the logic turned out to be fully functional, it was just bad
connections.
I know back at DEC when we had a unibus CPU problem, the first thing we
almost
always did was pull the boards, run the trusty eraser up and down the
fingers,
and then seat/reseat the boards a couple of times. This invariably worked.
Just a thought.