PDP-11/70 progress (and a cry for help)

[Josh Dersch]

On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:

> Hi Josh,
>
> In the situation you describe, I guess I would first chip clip '174s for a
> slice of both PCA and PBC on the LA, run the troublesome instruction
> sequence, and look at the trace.  Check that CLKPCA H and CLKPCB H are
> happening when and only when expected, and that all the timing there looks
> okay.
>
> You would also be able to see good-data-clocked-in-but-bad-data-presented
> on that trace, indicating more failed '174, or see any bad data arriving
> from the ALU upstream.
>
> I'll take a look through the flows after dinner.  The "0002" might be one
> operand used to increment the PC, but the other operand shows up as all
> zeros because of a bad ALU setup?  I guess I'd trace to definitively rule
> out PCA and PCB first, and then move backward around the chain from there
> verifying the ALU, ALU muxs, mux sources, etc.?
>
>         --FritzM.
>

Thanks, Fritz, that's a good idea.  I'm a bit short on dip clips at the
moment so I had to read PCA and PCB on separate passes (and just the low 6
bits); and right now the clock's still hooked up to RACA CLKA RAR H (which
clocks when the ucode ROM address changes) so it's not quite as fine
grained as I'd like (I have to move everything around to get the logic
analyzer's clock signal hooked up to the main clock and it's just too late
tonight...).  But still, this is fairly revealing.  This is an execution of
a MOV #1, R0 instruction poked in at address 40:

Addr PCB PCA
334  40  40
260  40  40
343  42  42
022  42  44
027  44  44
205  44  44
260  44  44
343  03  03
010  03  05
316  03  05
164  03  05
240  03  05
352  03  05
170  03  05

(Note that the sample is taken at the beginning of the microinstruction).

Based on this, it's clear that things get messed up during 260 (FET.10).
The operations performed during this instruction are:

t1: BA <- PCB; BC <- DATI
t2: <SHFR <- PCB + 2>
t3: BRQ STROBE
t4: BUS PAUSE
t5: PCA <- PCB + 2
t6 IR <- BUS; BR <- BUS
    PCB <- PCA
t3 FPA <- BA

My money's on t5 going wrong -- an ALU input mux or operation being
selected incorrectly, possibly.  This also somewhat explains why execution
doesn't trap due to executing a HALT from an odd address -- it isn't
actually executing from the wrong address, because the bus address is
loaded from a still-good PCB in t1.

More investigation later this week...

- Josh