On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk < cctalk@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