PDP-11/44 problem - RUN stays on

Don North ak6dn at mindspring.com
Sun Nov 12 21:30:44 CST 2006


Gooijen, Henk wrote:
> I pulled all boards from the 11/44 backplane and used an eraser
> to clean all the contact fingers. Then I vacuumed the slots.
> After wiping the boards clean of any small particles, I reseated
> the boards ... the system still shows the same problem, the RUN
> LED stays on and I don't get the >>> prompt.
>
> Then I swapped the CTRL (M7095) board. ^P gives me the >>> again.
> However, "H" (halt) gives the response "?Failed to halt".
> The "T" (selftest) command seems OK, the LED on the MFM board is
> briefly ON. As the MFM board was also suggested to be causing
> problems, I replaced the MFM board.
>
> Now the RUN LED stays OFF! However, I get an other problem.
> The VT100 displays:
> CONSOLE
> ?22 CP HUNG
>
> I can enter the T and the H command. That works fine.
> But, for example, an E (examine) command gives the ?22CP HUNG.
>
> When I install the original MFM board again, the RUN LED stays
> ON, but the "E 2" command gives the response
> "  P 00000002  000001"
> and the H command says "?Failed to halt".
> According to the documentation you can do EXAMine commands
> while the system is running, but you can not do a DEPosit.
> Proof: I entered "D 2 2" and the response is "?Halt CP".
>
> So, one MFM board gives "?22 CP HUNG", but the RUN LED is OFF,
> the other MFM board allows examine, but the RUN LED stays ON,
> and you can not halt the processor.
> I am still reading, but give these symptoms perhaps clues?
>
Well, that's kind of a bummer that it wasn't just a dirty contact.

What I'd do at this point is verify all the P/S voltages are within
spec, and then pull all the boards that are not necessary (FPU,
CACHE, and any UNIBUS I/O) for basic system operation. Run with just
the base CPU and a memory card.

I'd try the exam and deposit commands with the /TB (take bus) option
to see if you can access memory directly (you still have to be able
to halt the CPU).

If the behavior is still not normal, try the CPU microstep commands
and see if you can step thru the microcode cycle by cycle, and that
the flow makes sense (the microflows are in the printset).

 From looking at the prints the RUN signal is just a FF triggered by
a one shot on the CPU control board. For either board combo (the one
that never comes out of RUN, or the one that stays in RUN) I'd back
track thru the logic too see if I could find something wrong.

Sorry, but I haven't had this kind of behavior in my 11/44, so can't
suggest a more specific place to look.

Don






More information about the cctech mailing list