I just took the clock input for the program counter from pin 3 of the 74LN32 OR Gate (on the clock BB), which is behind the AND gate, which acts as a 'buffer' from the RC clock pulse. No additional gates needed.
Sounds like a good idea. Though in my case, I built my clock using 2 NAND chips instead of the 3 AND/OR/NOT chips. Also, after messing around with that RC issue for several days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter completely. (If you care to read through the other comments/replies in this video, you'll see why.)
So I had the exact problem you described in your last video. Instead of filtering it through the nand gates, I came up with what I think is a simpler solution. What I did was to put the clock signal through a diode feeding into the RC circuit on the NAND gate. This way, you don't get any feedback onto the clock that causes the jitters and weirdness. However, this causes a problem whereby the resistor cannot discharge and go low. To fix this, all I did was put a 10K resistor on the other leg of the capacitor. This allows the RC circuit to function as Ben intended without having to discharge back through the clock circuit!
After messing around with that RC issue for many days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter. From what I’ve read, the CLOCK SIGNAL should remain pure at all times. Sticking a Resistor/Capacitor on it messes with the integrity of the whole system - as I found with my PROGRAM COUNTER. My idea of isolating the Resistor/Capacitor circuit behind a GATE buffer also falls into the taboo category of messing with the CLOCK SIGNAL. I removed the Resistor/Capacitor and removed my double inverter GATE buffer. I can’t find anything in the data sheet that says the 74LS189 has a 10μs maximum write time, and it clearly doesn’t as you can press and hold the manual pulse button indefinitely, and the data will still get written. From what I've read, the right way to handle this is to send the main CLOCK SIGNAL into a 555 where a RESISTOR/CAPACITOR pair can safely be used to get the 10μs, and then send the OUTPUT from the 555 to the INPUT of the NAND GATE. As one youtuber wrote in response to a video I posted about this problem, “You cannot capacitively couple TTL signals, it level shifts them by -2.3v to +2.3v. If you need a 10uS triggered pulse, that's what 555s and 74123s are for.” So I think all that mucking about with the Resistor/Capacitor was a colossal waste of time. However, I’m wiser for the experience.
Interesting. I just disconnected the RC circuit entirely, and as you say it seems to work fine. That said, my recollection when I was testing the RAM module on its own was that I was getting a write signal on both the rising and falling edge of the clock. I'll have to play around and see if there are any bad consequences. Another issue I had was that my RAM module was triggering a write every time I switched from run to program mode. It seems that for some reason the input pin from the manual program pushbutton to the 74LS157 multiplexer was floating low for an instant on the changeover, which instantly wrote whatever was on the 8 bits of the DIP switches to the currently selected memory address. I had to put a 10K pullup on it to prevent this, and it seems to work fine now.
Thanks for the insight about the other issue. I had the exact same problem with my RAM module. (As you said, it was triggering a write every time I switched from run to program mode.) I never got around to solving that one myself. I put the project on hold once I got caught up with Ben's videos. Then the weeks flew by, and now my semester has started up again so I don't have much time to mess with it. (Though at the moment it doesn't matter because he hasn't put any new videos in a while.) But that issue where my RAM would get overwritten every time I switched from run to program mode was very annoying. I worked around the issue just by making sure that I CAREFULLY input my program all at once, and then switched to run mode and left it there. When I would switch back to program mode, I never knew what to expect. Sometimes I would only have 1 memory location that was overwritten, but I think sometimes I would have several. I did quiet a bit of testing on this issue where I hooked up my oscilloscope to see when the write pulse was being triggered. I do remember that test verifying that it was the run/program switch that was causing it, but I never thought of a solution. So thanks for your feedback. I'll definitely have to give the pullup resistor a try.
Incidentally, I'm also having the exact same problem as you on your other videos where you have the spurious "47" show up on the output display. I have a few more 74LS173s, so I'll probably replicate what you did to fix that. It's kind of interesting how Ben never seemed to run into any of these problems on his setup.
Ah, good to know. I don't know anyone else who had that "47" problem. But everyone who commented said they used the 74LS173's to begin with, so naturally they wouldn't have had that problem. It's very odd to me how lucky Ben has been throughout the series.
Adding basically an RC filter on the CLOCK line the whole integrity of the signal is altered (in some designs you will find RC circuit to improve clock integrity but not the case here) From what I measured jitter is a big problem (and is amplified by the use of breadboards) when adding this "edge detector" and 161 from DS is quite sensitive to clock jitter. Best way is to use a digital edge detector. Ben may have avoided this because he uses rally high quality breadboards or he is just lucky to have marginal levels of clock jitter.
Having, had the same issue. I am currently isolating all of my led outputs through noninverting buffers. For a jittery counter, disconnect your clock LED- check voltages, 10k tie down to ground? Things get funky when voltages get into the grey area :)
BTW earlier you mentioned using 373s because they latch data on the rising clock. NO. 373s are _transparent_ latches; that means they reflect whatever is at the input so long as the clock is HIGH, and latch it on the falling edge. This is exactly what was exploited in the 808x series past the 8085, when they added multiplexed address and data: the latch signal for the address bus goes high for about 100nS (at 1MHz) then falls, at which time you latch the lower address bus. Using a 373 part for this instead of a _rising_ edge triggered latch buys you an extra 100nS address access time. Because ale goes high at the same time the address bus is appearing on the micro, you must wait that 100nS for the data to stabilize before latching it - this is why we use transparent latches. This is not relevant at your clock speeds, but this may be directly related to some of the problems you are seeing. You're doing well with a clock delay circuit using those gates, but what would be much better is a string of hex inverters. That will give you 6x20nS, or about 120nS clock delay. This gives your input data time to settle before latching it into the next stage. The main clock is separated into quadrature components inside the 8085 micro; this gives you two sequential rising and falling clock pulses per microinstruction. Some earlier processors (like the 6502) actually had a two phase clock input for the micro. This trait was exploited by Woz when he invented the ingenious graphics system - by accessing memory alternately between CPU and graphics engine, neither knew the other was there. The tradeoff is you need twice as fast access time on your ram. Using a two phase clock allows you to patch an output into an input per clock cycle - one clock drives the op, the next latches the data from it. If you have 8 inputs all toggling, and then latch the data while that's happening, what do you get? You get garbage. You have to allow time for propagation delay through the other register before latching it. A transparent latch with a high clock pin is nothing more than an 8 bit buffer and bus driver - essentially a 74xx245.
Thanks for the reply. I am getting good voltages all over the board. That is one thing I've tested repeatedly because I had a lot of power problems early on due to low quality breadboards and loose jumper wires. I was pretty far along in the project - but I decided the breadboards I was using were complete garbage. As much as it pained me, I bought all new boards and moved everything over. Made all the difference in the world.
I'm using Jameco part # 2157706 breadboards now. I'm sure there are breadboards that are even better than those if you want to spend even more per breadboard. But for this project at least, these boards seem to deliver power with no issue.
If you can manage it, get all your breadboards at once so that you can get the price discount where you save 56 cents per board. That's a pretty good savings when you're buying 14 or more of these things. I'm using 14 of them for my breadboard computer, and 2 more for my EEPROM programmers. (Though for those EEPROM programmers, you could use any breadboard.) Another thing I found out is that you don't want to try to mix and match breadboards in the main build. The way breadboards connect to each other apparently isn't completely standard. Early on in my project, I had two modules on 2 different brands of breadboards, and when I needed to snap the boards together, it was physically impossible. The tabs on the one brand didn't match the size and spacing of the slots on the other. So whichever brand you go with, make it your standard and use it all throughout.
As mentioned in your original video, there's another solution to this with some explanation here: ruclips.net/video/hRJO97PbPlw/видео.html And my kit from Ben just arrived... so perhaps I'll be facing this problem soon! :)
You have a ttl clock signal coupled through a capacitor. The input voltage of ttl chips is what? 0-5V. What happens when you capacitively couple something? It's a bit amazing your circuit did not latch up. If you have an oscilloscope, put that cap and resistor back and check the input to that pin - I'm sure you will find your capacitively coupled clock pulse is varying -2.3v to +2.3v. What's wrong with this picture? You cannot capacitively couple ttl signals, it level shifts them just like a coupling capacitor in your stereo. If you need a 10uS triggered pulse, that's what 555s and 74123s are for.
I am interested in implementing this. How would I achieve this with a 555? Would the clock input feed into the trigger pin on the 555 and run the 555 in monostable mode? If the trigger pin is active low then would I need to invert the CLK signal first?
It is a power supply issue and you need to put capacitor across the power and negative just like was done on the clock.. Program counter chip will skip.. I having issues with it from chips I picked up from NEWART and or CHINA.. so I am looking for better way to making a counter in a into better latch.
In my case, it wasn't power issues. I thoroughly checked all my breadboards for power supply problems and all my boards were getting 4.5V - 5.0V. (Also - this video is almost 3 years old at this point and I haven't had any problems (power or otherwise) since completing this breadboard computer 2+ years ago.) After messing around with that RC issue for many days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter. From what I’ve read, the CLOCK SIGNAL should remain pure at all times. Sticking a Resistor/Capacitor on it messes with the integrity of the whole system - as I found out with this PROGRAM COUNTER issue I was having. I removed the Resistor/Capacitor and removed my double inverter GATE buffer because I can't find ANYTHING in the data sheet that says the 74LS189 has a 10μs maximum write time, and it clearly doesn’t have that requirement as you can press and hold the manual pulse button indefinitely, and the data will still get written. So, I have no idea where Ben got that 10μs maximum write time thing from. So I think all that mucking about with the Resistor/Capacitor is a colossal waste of time and people should just skip that part.
![ADD cycle problem [Part 2] - (Ben Eater 8-bit Computer) SAP-1](http://i.ytimg.com/vi/m41kM1QsIwE/mqdefault.jpg)
![ADD cycle problem [Part 2] - (Ben Eater 8-bit Computer) SAP-1](/img/tr.png)
I just took the clock input for the program counter from pin 3 of the 74LN32 OR Gate (on the clock BB), which is behind the AND gate, which acts as a 'buffer' from the RC clock pulse. No additional gates needed.
Sounds like a good idea. Though in my case, I built my clock using 2 NAND chips instead of the 3 AND/OR/NOT chips. Also, after messing around with that RC issue for several days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter completely. (If you care to read through the other comments/replies in this video, you'll see why.)
So I had the exact problem you described in your last video. Instead of filtering it through the nand gates, I came up with what I think is a simpler solution. What I did was to put the clock signal through a diode feeding into the RC circuit on the NAND gate. This way, you don't get any feedback onto the clock that causes the jitters and weirdness. However, this causes a problem whereby the resistor cannot discharge and go low. To fix this, all I did was put a 10K resistor on the other leg of the capacitor. This allows the RC circuit to function as Ben intended without having to discharge back through the clock circuit!
After messing around with that RC issue for many days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter. From what I’ve read, the CLOCK SIGNAL should remain pure at all times. Sticking a Resistor/Capacitor on it messes with the integrity of the whole system - as I found with my PROGRAM COUNTER. My idea of isolating the Resistor/Capacitor circuit behind a GATE buffer also falls into the taboo category of messing with the CLOCK SIGNAL. I removed the Resistor/Capacitor and removed my double inverter GATE buffer. I can’t find anything in the data sheet that says the 74LS189 has a 10μs maximum write time, and it clearly doesn’t as you can press and hold the manual pulse button indefinitely, and the data will still get written.
From what I've read, the right way to handle this is to send the main CLOCK SIGNAL into a 555 where a RESISTOR/CAPACITOR pair can safely be used to get the 10μs, and then send the OUTPUT from the 555 to the INPUT of the NAND GATE.
As one youtuber wrote in response to a video I posted about this problem, “You cannot capacitively couple TTL signals, it level shifts them by -2.3v to +2.3v. If you need a 10uS triggered pulse, that's what 555s and 74123s are for.”
So I think all that mucking about with the Resistor/Capacitor was a colossal waste of time. However, I’m wiser for the experience.
Interesting. I just disconnected the RC circuit entirely, and as you say it seems to work fine. That said, my recollection when I was testing the RAM module on its own was that I was getting a write signal on both the rising and falling edge of the clock. I'll have to play around and see if there are any bad consequences.
Another issue I had was that my RAM module was triggering a write every time I switched from run to program mode. It seems that for some reason the input pin from the manual program pushbutton to the 74LS157 multiplexer was floating low for an instant on the changeover, which instantly wrote whatever was on the 8 bits of the DIP switches to the currently selected memory address. I had to put a 10K pullup on it to prevent this, and it seems to work fine now.
Thanks for the insight about the other issue. I had the exact same problem with my RAM module. (As you said, it was triggering a write every time I switched from run to program mode.) I never got around to solving that one myself. I put the project on hold once I got caught up with Ben's videos. Then the weeks flew by, and now my semester has started up again so I don't have much time to mess with it. (Though at the moment it doesn't matter because he hasn't put any new videos in a while.)
But that issue where my RAM would get overwritten every time I switched from run to program mode was very annoying. I worked around the issue just by making sure that I CAREFULLY input my program all at once, and then switched to run mode and left it there. When I would switch back to program mode, I never knew what to expect. Sometimes I would only have 1 memory location that was overwritten, but I think sometimes I would have several.
I did quiet a bit of testing on this issue where I hooked up my oscilloscope to see when the write pulse was being triggered. I do remember that test verifying that it was the run/program switch that was causing it, but I never thought of a solution. So thanks for your feedback. I'll definitely have to give the pullup resistor a try.
Incidentally, I'm also having the exact same problem as you on your other videos where you have the spurious "47" show up on the output display. I have a few more 74LS173s, so I'll probably replicate what you did to fix that. It's kind of interesting how Ben never seemed to run into any of these problems on his setup.
Ah, good to know. I don't know anyone else who had that "47" problem. But everyone who commented said they used the 74LS173's to begin with, so naturally they wouldn't have had that problem. It's very odd to me how lucky Ben has been throughout the series.
Thanks this solved my issue.
Adding basically an RC filter on the CLOCK line the whole integrity of the signal is altered (in some designs you will find RC circuit to improve clock integrity but not the case here) From what I measured jitter is a big problem (and is amplified by the use of breadboards) when adding this "edge detector" and 161 from DS is quite sensitive to clock jitter. Best way is to use a digital edge detector. Ben may have avoided this because he uses rally high quality breadboards or he is just lucky to have marginal levels of clock jitter.
Having, had the same issue. I am currently isolating all of my led outputs through noninverting buffers. For a jittery counter, disconnect your clock LED- check voltages, 10k tie down to ground? Things get funky when voltages get into the grey area :)
BTW earlier you mentioned using 373s because they latch data on the rising clock. NO. 373s are _transparent_ latches; that means they reflect whatever is at the input so long as the clock is HIGH, and latch it on the falling edge. This is exactly what was exploited in the 808x series past the 8085, when they added multiplexed address and data: the latch signal for the address bus goes high for about 100nS (at 1MHz) then falls, at which time you latch the lower address bus. Using a 373 part for this instead of a _rising_ edge triggered latch buys you an extra 100nS address access time. Because ale goes high at the same time the address bus is appearing on the micro, you must wait that 100nS for the data to stabilize before latching it - this is why we use transparent latches. This is not relevant at your clock speeds, but this may be directly related to some of the problems you are seeing. You're doing well with a clock delay circuit using those gates, but what would be much better is a string of hex inverters. That will give you 6x20nS, or about 120nS clock delay. This gives your input data time to settle before latching it into the next stage.
The main clock is separated into quadrature components inside the 8085 micro; this gives you two sequential rising and falling clock pulses per microinstruction. Some earlier processors (like the 6502) actually had a two phase clock input for the micro. This trait was exploited by Woz when he invented the ingenious graphics system - by accessing memory alternately between CPU and graphics engine, neither knew the other was there. The tradeoff is you need twice as fast access time on your ram. Using a two phase clock allows you to patch an output into an input per clock cycle - one clock drives the op, the next latches the data from it.
If you have 8 inputs all toggling, and then latch the data while that's happening, what do you get? You get garbage. You have to allow time for propagation delay through the other register before latching it. A transparent latch with a high clock pin is nothing more than an 8 bit buffer and bus driver - essentially a 74xx245.
could it be a voltage issue. check your voltages all over the board. you may be getting low voltage that is causing trigger issues.
Thanks for the reply. I am getting good voltages all over the board. That is one thing I've tested repeatedly because I had a lot of power problems early on due to low quality breadboards and loose jumper wires. I was pretty far along in the project - but I decided the breadboards I was using were complete garbage. As much as it pained me, I bought all new boards and moved everything over. Made all the difference in the world.
What breadboards are you now using?
I'm using Jameco part # 2157706 breadboards now. I'm sure there are breadboards that are even better than those if you want to spend even more per breadboard. But for this project at least, these boards seem to deliver power with no issue.
Thanks. I just so happen to have a free shipping code for Jameco they sent me yesterday
If you can manage it, get all your breadboards at once so that you can get the price discount where you save 56 cents per board. That's a pretty good savings when you're buying 14 or more of these things. I'm using 14 of them for my breadboard computer, and 2 more for my EEPROM programmers. (Though for those EEPROM programmers, you could use any breadboard.)
Another thing I found out is that you don't want to try to mix and match breadboards in the main build. The way breadboards connect to each other apparently isn't completely standard. Early on in my project, I had two modules on 2 different brands of breadboards, and when I needed to snap the boards together, it was physically impossible. The tabs on the one brand didn't match the size and spacing of the slots on the other.
So whichever brand you go with, make it your standard and use it all throughout.
As mentioned in your original video, there's another solution to this with some explanation here: ruclips.net/video/hRJO97PbPlw/видео.html
And my kit from Ben just arrived... so perhaps I'll be facing this problem soon! :)
You have a ttl clock signal coupled through a capacitor. The input voltage of ttl chips is what? 0-5V. What happens when you capacitively couple something?
It's a bit amazing your circuit did not latch up. If you have an oscilloscope, put that cap and resistor back and check the input to that pin - I'm sure you will find your capacitively coupled clock pulse is varying -2.3v to +2.3v. What's wrong with this picture?
You cannot capacitively couple ttl signals, it level shifts them just like a coupling capacitor in your stereo. If you need a 10uS triggered pulse, that's what 555s and 74123s are for.
You are correct except the signal will vary from -5 to 5V rather than -2.3 to 2.3 V ....
I am interested in implementing this. How would I achieve this with a 555? Would the clock input feed into the trigger pin on the 555 and run the 555 in monostable mode? If the trigger pin is active low then would I need to invert the CLK signal first?
It is a power supply issue and you need to put capacitor across the power and negative just like was done on the clock.. Program counter chip will skip.. I having issues with it from chips I picked up from NEWART and or CHINA.. so I am looking for better way to making a counter in a into better latch.
In my case, it wasn't power issues. I thoroughly checked all my breadboards for power supply problems and all my boards were getting 4.5V - 5.0V. (Also - this video is almost 3 years old at this point and I haven't had any problems (power or otherwise) since completing this breadboard computer 2+ years ago.)
After messing around with that RC issue for many days, and after reading comments from many other people and doing a bit of my own research, I decided to remove the RC filter. From what I’ve read, the CLOCK SIGNAL should remain pure at all times. Sticking a Resistor/Capacitor on it messes with the integrity of the whole system - as I found out with this PROGRAM COUNTER issue I was having.
I removed the Resistor/Capacitor and removed my double inverter GATE buffer because I can't find ANYTHING in the data sheet that says the 74LS189 has a 10μs maximum write time, and it clearly doesn’t have that requirement as you can press and hold the manual pulse button indefinitely, and the data will still get written.
So, I have no idea where Ben got that 10μs maximum write time thing from.
So I think all that mucking about with the Resistor/Capacitor is a colossal waste of time and people should just skip that part.
David Courtney Interesting. Am now at exactly this point when building the Ben stuff. I’ll skip the RC circuit and will see where it brings me.