16 Feb
2021
16 Feb
'21
1:13 a.m.
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