PDP-11/45: RK11 VI - "Pole" and Interrupt Issues

Thu 08 June 2017 by Fritz Mueller

Replaced the failed 7401 in the RKDA to RKDB data path, and verified that the RKDB stuck bit 11 problem was fixed. Ran the system for another couple hours to rewrite a fresh RT-11 pack, then another problem developed: read operations would successfully obtain the bus, but would never complete.

Some investigation with a KM11 on the RK11 controller showed that POLE was now incorrectly asserted continuously (did they mean "poll"?). Tracked this down to a failed 7420 (E1 on the M141 at A26, sheet RK11-C-12). Replaced, and reads were working again. I guess with a machine this age there is going to be a lot of this sort of thing where marginal parts give up after a few hours of use. Hopefully after some prolonged operation things will settle down a little bit...

In any case, still unable to boot any of my RT-11 packs. I Decided to step back and run MAINDEC diagnostic ZRKK. This is the RK11 dynamic diagnostic that destructively modifies a pack, and I had not previously run it -- I had just optimistically jumped to trying to boot existing packs after the drive restore and calibration. The diagnostic ran successfully for a while, through various format and read and write tests over the whole pack (encouraging!), then hung up consistently on test 35 (octal), which tests whether the RK11 interrupts the processor correctly when IDE is set.

So it could be the case that my RT-11 boots hang up when they first start trying to make use of interrupts. Verified that I can run MAINDEC ZKWA, which tests interrupts from the KW11-L line clock, so interrupt fielding in the CPU looks good.

Re-ran MAINDEC ZRKK, and noted that the CPU is waiting in micro-state BRK.00 (154) on page FLOWS 12 of the engineering drawings. This state has a wait for Unibus INTR to be asserted, so it looks like a problem with interrupt signaling on the RK11 side.

I have a bit of travel coming up, so I probably won't get back to this for a week or two. But the next sensible step I think will be to work with a logic analyzer on the backplane of the RK11, slot A6 where the M7820 interrupt control flipchip goes, and see what is/isn't happening with the interrupt signaling on that end. I suspect there will probably be a failed IC on the M7820.