A project log for STUPID Computer

A 12-bit TTL-based Microprogrammed Computer

steve-tonerSteve Toner 04/04/2018 at 03:560 Comments

OK, let's see if anyone can explain this:

After making the changes shown in the previous log, I fires it up with the same microcode that was in before the changes (changes are fully backward-compatible), and everything seemed to work fine.  So I put the decrement back in the microcode instead of the workaround I had failed miserably.  Couldn't even make it through the power-on self test.  The most common failure mode had it branching to E2F when the microinstruction said to branch to E1F.  Bad build?  I reassembled and burned the Flash again and...same thing.  Maybe the counter chip's gone bad (very low probability, but easy to check).  Swapped chips around.  Same thing.  Verify input signal is valid & setup time OK.  But the middle counter (there are 3 cascaded 74F161 counters providing a microcode address) was already at 2 - I can't tell if it's failing to load that counter, or if it loads the 1 and then increments it.  Well, what does the clock signal look like?  Attach an oscilloscope probe to the clock input of the counter chip and...everything works.  And the clock signal looks fine.  Just a small amount of ringing.  Well, this is the end of a run (clock drives 6 loads across 3 boards, so it's not a true bus).  Try Thevenin termination.  No change.  Fails without scope lead attached, works with it attached.  Let's see...the scope adds capacitance, which will slow the rise time of the signal.  74F chips have a very fast rise time.  Let's try a 74S instead.  They're fast but from what I've seen, don't have as fast a rise time on the leading edge.  No difference.  Well, how about a 74LS?  Fails miserably in a different manner than the F & S chips. 

Hmmm, I've got a 74HC chip here, let's try that... Everything works! wtf???

The signal I'm looking at is CLK2.

There's no pullup on the input to the other half of the flip flop (pin 12), which is driven by a 74S374, but that part works fine as well.  The MIR9 signal is not connected to any other inputs, so it's not seeing much of a load.  So really just reduced noise immunity there, which, as I said, is not (currently) showing up as a problem.

So what's going on?  It doesn't seem like a reflection issue, as terminating the signal line should have at least helped with that.  The hardware change was in the ALU, which is on another board and does not see the CLK2 signal, though the CLK2 signal is present on that board (clocks the "result=0" flip flop).  Crosstalk causing a glitch on the clock signal?  Enough to trigger the counter but not the logic analyzer?  Scope probe capacitance filters it out, and higher output voltage of the HC chip keeps it from crossing the logic threshold levels?  And why did it work OK until I changed the microcode???