What is your clock frequency? Do you have any idea what the clock signal looks like? Rise and fall times are important. LS-TTL likes edges in the 5-10ns range. I doubt that your 555 timer setup is giving you anything anywhere near that. How much logic are you driving with that clock. You might be able to clean it up (fix the edges) by running it through some sort of schmitt trigger.

Using those types of breadboards play hell with grounds and parasitic noise.

those breadboards are good for things that don't move a bunch of digital signals around. I think you mentioned not having an oscilloscope. Can you borrow one? You may be quite surprised at how much noise and other extraneous junk is on your clock, VCC, and ground.

Noise on your ground may be a root cause of a lot of your problems.

 

Clock is super slow, I can watch an LED blink on and off to it, maybe its 5Hz or so. (It's variable, sometimes 1-2 Hz, sometimes up to 10-20Hz).

I'm back up and running now once I built that diode I described above.

That being said, I can borrow an oscilloscope, I'll try that if I run into any other bugs, but probably anyway just b/c it would be so educational.

Thanks!

-Alex

 

Could be ground bounce. Current through the ground wires causes the ground voltage to vary significantly from one part of the circuit to another. If this happens, adding more capacitors might not help. What would help is to run a decent-sized wire from the ground where the power supply is wired in, to each board's ground, using a separate wire from power ground to each board, no hooking them all on one wire (unless it's a pretty heavy wire).

 

Did you replace any NE555 or LM555 with TLC555 or LMC555 as someone mentioned before?
Change all your TTL 555 to CMOS 555.

 

Hi there Alex, did you fix the problem?

I'm having the same issue you're describing.

 

This is just my opinion, but...

The idea of trying to build something that complex on a solderless breadboard gives me hives...
It's like trying to build a house of cards in a sandbox, on a windy day.

Each connection gives poor reliability, add up all those connections and the reliability becomes horrible, you'll spend 99 % of your time trying to keep it barely working, chasing bad connections instead of learning.

Not to mention the horrible electrical properties of these boards! So many complex and annoying failure modes await you, all ready to suck the enthusiasm out of your effort.

I would build and test each section on the solderless board, then re-build it using wire-wrap on some nice perf board, with a solid ground plane.

Then you can spend your time learning advanced digital design, instead of drowning in frustration and confusion.

 

I'm aware this is an old thread, but I was having the exact same issue as aroetter (and apparently Porir) and while trying to google solutions this thread kept coming up. Since I finally solved what was wrong with mine, I figure I would post here for future googlers.

tldr; use a Scmitt trigger on clock output, and make sure you try another IC to make sure you didn't get a bad one.

I am also following Ben Eater's excellent 8-bit breadboard computer project and building something similar for fun.

And I also ran into a problem with the counter IC. The same exact problems - only the 2 least significant bits were being used (2 higher significant bits were always dark) and they were not counting properly. There was no rhyme or reason to what a clock pulse would do. It certainly wasn't counting in binary.

After trying far too many things, I finally got some success when I put a schmitt trigger on the clock output. I didn't try it earlier, because my clock pulse looked very clean on the oscilloscope (debounce protection when manually pulsing it, etc). But I kept seeing recommendations for schmitt triggers on clock signals (people mentioning "hysteresis"?). The counter IC liked that input much better, and started counting in binary properly. Unfortunately though, still only using the least 2 significant bits.

Finally I swapped out that IC for another identical chip of the same model and it fully worked. It was a bad chip. I don't know how often that happens cause I'm new to EE, but in the future I'm definitely not spending 6 hours debugging something without first making sure the chip isn't damaged.

Perhaps it's that specific IC that is fragile, and the higher 2 significant bits get fried easy. At any rate, lesson learned.

I hope you're still working on your 8-bit computer aroetter!

 

Welcome to AAC!

It was a bad chip. I don't know how often that happens cause I'm new to EE, but in the future I'm definitely not spending 6 hours debugging something without first making sure the chip isn't damaged.

It happens, probably more frequently than you'd like.

Semiconductors have a few major failure modes: infant mortality, random failures, and wear out.

I spent several days debugging what I thought was a timing problem caused by rise/fall time differences between the outputs of a CMOS D flip flop. While troubleshooting, I managed to inadvertently short the outputs too long and killed the device. I swapped in a new one and the timing problem went away too.

 

Thank you for the welcome! And the advice, that's good to know. I'm not looking forward to my first random failure, that sounds like the hardest ghost to chase.

I think what took me so long to 'try another chip' was that the IC was mostly working. Coming from the software side of things, I thought hardware would only fail catastrophically (either it all works, or nothing works). It never occurred to me a chip could continue to work while partially broken. Nice to know SW and HW aren't so different after all?

Last week I ran into an issue that was because a resistor was incorrectly color-coded / had 10 times the ohms marked. That and this have taught me:

1) Semiconductor manufacturers are not perfect.
2) Verify everything with a multimeter/oscilloscope.
3) Once you're sure you're not frying the chip with too much voltage, try another one if you're getting weird behavior.

 

Nice to know SW and HW aren't so different after all?

Both have standard troubleshooting methods. I cut my teeth troubleshooting refrigerator sized computers made with TTL to the component level.

I don't test/measure components before using them. If a circuit isn't working as expected, you just probe the circuit in strategic spots to isolate something that isn't working as expected. If you find a bad component, mark it as bad; discard if it's otherwise useless.

 

Clock is super slow, I can watch an LED blink on and off to it, maybe its 5Hz or so. (It's variable, sometimes 1-2 Hz, sometimes up to 10-20Hz).

I'm back up and running now once I built that diode I described above.

That being said, I can borrow an oscilloscope, I'll try that if I run into any other bugs, but probably anyway just b/c it would be so educational.

Thanks!

-Alex

For what it's worth, if anyone else comes along looking for this solution as I did. The program counter circuit already contains a diode - a light-emitting one. A resistor pulls the clock signal to another row/column on the breadboard, which then has the LED plugged in. Just draw your clock signal from the same row/column as the LED (the blue one, if you're using the kit) and you will have solved this issue.

Also, thank you OP for posting your problem and solution for me to find 4 years later!