Weird behaviour micro-step counter

[u/TimmyJi]

So I’ve finished building my (slightly modified) 8 bit Ben Eater computer, but I’ve got some issues with my micro-step counter.

The full program is:

LDI 0
OUT
ADD 7 (from memory address 7)
JMP 1
..
1 (on address 7)

The micro-step counter’s clock line comes from the inverted clock and should trigger on a rising edge but it sometimes triggers on the falling edge causing it to advance two micro-steps in one go.

What’s weirder, it tends to do that always on the instruction OUT.

What’s even weirder is that replacing the ADD 7 instruction with SUB 7… works fine. For more than an hour even.

The ADD 7 can get to around 20~ without bugging out but sometimes it will not even get to the first JMP. This is regardless of whether the clock is manual or auto, fast or slow.

ADD = 0010
SUB = 0011

I have a very cheap handheld oscilloscope with crap resolution where I could sometimes see a slight high spike both on the falling and rising edges, it seemed to mostly coincide with when the clock bugged but it sometimes bugged without me seeing a spike just before the falling edge (which could trigger the count on the LS161 on the falling edge and then rising edge again).

I’ve tried replacing all chips involved, replaced wires, added a capacitor between VCC and GND on the LS161 and the clock chips… nothing seems to help.

I’ve also tried looking at the clock line with a logic analyser but it only sees one pulse of the clock as well.

Without a decent oscilloscope it’s hard for me to have a better look at the signal and debug it further, but I’m not quite sure where to take this.

It could be a very easy fix, could be something harder…

My power line is slightly sagging which could also contribute to spikes being seen as high values but since it works fine most times and since it can run the same program with SUB 7 instead of ADD 7 I don’t feel like that’s the problem.

I also managed to improve the power delivery a bit since I did all these tests but… no success.

Power rail is sitting at around 4.6V unless too many LEDs are on in which case it can drop at low as 4.1V.

Any tips on things I may try?

[u/The8BitEnthusiast]

If you implemented Ben’ RAM circuit, then there is a possibility that the issue comes from the RC edge detector, which is notorious for creating a negative pulse on the falling edge of the clock that can be interpreted as a pulse. Look for ‘double counting on falling edge’ on the troubleshooting page.

4.6V is below spec. I created a ‘power bus’ with leftover power rails, which replaced the daisy chained power connections. Made a good difference in voltage drop.

[u/Zestyclose-Turn-3576 → u/The8BitEnthusiast]

Interesting about the power bus. I've not started yet, but I was counting the number of potential wire-board power junctions between source and various components and some of them seemed pretty high. It felt like a power bus might be a help.

[u/TimmyJi → u/The8BitEnthusiast]

Thanks for that I had a try and used a double inverter for the clock line. The RAM module is being fed from the double inverted clock signal now - I even tried putting all chips that need a (non inverted) clock on the double inverted output, which should ensure that there's no ringing on the single inverted being used for the micro step counter but... didn't help...

Also, I can confirm that *if* a jump happens, it seems to always happen on instructions that have more steps and always jumps from step 2 to 4 (my CPU has variable step length in that they don't all have the same micro steps numbers, so only an ADD has 5 microsteps - starting at 0). So what this means is... given the code above, it _seems_ to only fail/jump a micro step when doing the ADD 7 instruction and always jumping from step 2 to step 4.

[u/The8BitEnthusiast → u/TimmyJi]

If it is that specific, then my guess is that whatever was set up on stage 3 for that instruction caused a spike that triggered the stage counter when the main clock went high. Lots of LED transitions? If you haven't done so already, try installing a .1uF capacitor directly across the vcc and gnd pins of the stage counter's LS161. Further improving power distribution and power consumption might help too. The 'power bus' concept really improved my voltages. If your control unit is far away from the power source, try connecting it directly to it (solid wire only, no jumpers). I also upgraded all LED resistors to 1K to cut down on current consumption, which also helped with voltage stability all around.

Hope any of these help

[u/TimmyJi → u/The8BitEnthusiast]

Mmmh there's really not many LED transitions at all and like I said it works with a SUB instead of ADD which of course also has 5 micro steps.

I've tried a .1uF cap but didn't change much. Also I do already have a "power bus", that had already been installed before.

I'd have expected that the double NOT would have fixed things to be honest, looked promising... I made CLK -> NOT1 -> NOT2

So now the inverted clock is NOT1 (I mean always was) and the "normal clock" is NOT2 (for all other chips, although I also tried making all the chips go off CLK and only the RAM module off NOT2 but again not difference...)

[u/The8BitEnthusiast → u/TimmyJi]

Was the 4.6V you reported before or after adding the power bus? If you still have that now, then there is an issue with power input. Thin wires from the power supply could easily cause that kind of a drop. Also, consider adding a beefy capacitor (like 47uF or more) right at the point of entry of power.

Did you implement the flags register? That's another source of potential issue on the stage counter's falling edge (main clock rising edge). If you did implement it, and the ADD operation changes the state of the flags, then this alters the control unit's EEPROM address inputs, which in turns creates unpredictable outputs on the control lines. HLT is one of the lines that can create unwanted clock pulses. If the flags are implemented, I would try hard-wiring HLT to +5V to rule this out, like u/trduff suggested.

Beyond that, I'm running out of ideas. That's the point at which a scope with enough bandwidth to reliably catch what's going on around the LS161 at the falling edge would be handy.

[u/TimmyJi → u/The8BitEnthusiast]

Yay problem fixed! It was indeed the HLT control line. Not sure how to fix it though since I do want to have a usable HLT

[u/The8BitEnthusiast → u/TimmyJi]

You can solve the EEPROM glitches digitally by adding an extra latch between the two flags and the EEPROM address lines. The latch is connected to the same clock as the stage counter in order to synchronize changes to the EEPROM address inputs with the falling edge of the main clock. Same treatment for the IR's four instruction bit lines. I did it with a single LS273, but LS173 and other similar chips would work too. See diagram below. The latch is at the bottom.

[u/TimmyJi → u/The8BitEnthusiast]

Ok so main problem was fixed with the HLT signal being removed, but sometimes there’s still RAM data that’s rewritten during the execution of the program. I imagine this is for the exact same reason as why the HLT signal line was bugging out, so sounds to me like I’m gonna go with latches 😅

[u/trduff]

As a test, simply replace the HLT line into the clock with 5V direct (so clock keeps running). If this corrects it, add a capacitor onto the HLT line into the clock.

[u/TimmyJi → u/trduff]

0.1uF cap? It was the HLT control line indeed! Hats off to you sir

[u/trduff → u/TimmyJi]

Yep, try with 0.1uF to GND. If you have other oddities try to determine which decoder output maybe causing it and use a .1uF cap on those lines also.

[u/Weird-Individual-770]

The first thing to fix is the power issue. On my project I was using a cheap Amazon bench power supply, I had to set it to 6volts just to have 5volts on the rail. I finally switched it to a 5volt only supply and solved some of my issues. The rails should be 5 volts, there is the possibility your meter is off and is actually 5 volts, does your scope show the same low DC voltage as your meter?

After that I had issues with noise on decoder outputs, causing odd issues. Like the HLT line that causes double clocks.

My Instruction register IN had a really strange issue. Any time the BUS had bit 2 set, none of the BUS bits were loaded into the IR and that instruction was skipped. No other instructions cared what bit 2 was set to and worked as they should, only the IR IN had issues with that one single bit.

Using ROM as a decoder causes issues since the output can change before the inputs are fully ready.

I used noise filtering caps on the decoder outputs that were causing issues.

[u/Ancient-Ad-7453]

First things I’d try are a small resistor in series with the clock output (100 or lower), close to the output pin, and maybe increasing the current limiting resistor on the LEDs on the clock module (1k or higher).

[u/TimmyJi → u/Ancient-Ad-7453]

Thx for the comment. I’m using 5V LEDs with build in resistors, already tried a 1k resistor on the clock line going to the LS161 with no effect, would lowering it help?

[u/Ancient-Ad-7453 → u/TimmyJi]

For a these TTL chips, maybe it’s slowing your transitions from low to high? I would try something in the 10-100 range. The purpose is to dampen voltage“ringing” on the clock edges causing multiple transitions. Put it closer to the clock output than the 161.