On 2022-Mar-28, at 4:07 PM, Noel Chiappa via cctalk wrote: >> I don't think the CPU is working at all. The reason being that there is >> absolutely no LED activity. Including an LED that is supposed to indicate >> a clock. > > Looking at the KDF11-U prints, I finally found that LED (it's pretty low > level - I was worried that it might be a bit in a register, and driven by > software, but it's not, it's actually driven directly by the the CPU's > internal clock signal; it's on page K1 of the prints, 'Clock, State Decode', > in the very upper left corner). (The source of the CPU's internal clock is > just an RC circuit, in the lower middle of that page, and the trim pot that's > part of it - along the upper edge of the board - can be adjusted to set the > clock speed 'properly', per the note at the back of the prints on the page > which lists the configuration switches. The 2MHz crystal along the upper edge > drives the baud rate generator.)
But the LED and CPU clock are not driven directly by that RC oscillator - there's a bunch of logic in-between the oscillator and the LED / CPU clock. [RC clock] => K1 OSC H/L --> [4-bit counter w parallel load] => K1 MCLK H/L --> LED --> [driver] => K1 CHIP CLK H (fonz CPU clock) The 4-bit counter looks to be generating some additional phases, but it's also controlled by a bunch of other signals. One of those signals is K6 BUF DCLO L which can hold the counter in reset, i.e. disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived on-board from K2 P FAIL H, which is derived from K2 BUS ACLO L which is input from BF1-in-funky-hex-box which I presume is a bus connector pin. Tony mentioned checking ACLO. Even if ACLO is good, there's a whack of logic on the CPU board - including two monostables - just to get from ACLO to DCLO to enable the CPU clock, as well as those other signals controlling the phase counter. ref: pdfPg.152,etc of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf