What if I use a 74132 Quad Schmitt Trigger NAND Gate instead (a NAND gate could be used as an inverter). Would this work as well? I can just use this single 74132 chip to replace the 7414 and the 7400 chips.
That's what's in the whole-computer schematic at the top of the "circuit potpourri" page, at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU . Be sure the "HC" is in the number though. 74132 or even 74LS132 will have way too much input current for the circuit. The circuit, as drawn, requires that the logic input be very high impedance. Note that generally Schmitt-trigger-input gates will have longer propagation delays than non-Schmitt-trigger ones; it won't matter in this case though.
I'm at work now so I have to hurry. Hopefully I didn't make any major mistakes in my hurry.
What if I use a 74132 Quad Schmitt Trigger NAND Gate instead (a NAND gate could be used as an inverter). Would this work as well? I can just use this single 74132 chip to replace the 7414 and the 7400 chips.
That's what's in the whole-computer schematic at the top of the "circuit potpourri" page, at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU . Be sure the "HC" is in the number though. 74132 or even 74LS132 will have way too much input current for the circuit. The circuit, as drawn, requires that the logic input be very high impedance. Note that generally Schmitt-trigger-input gates will have longer propagation delays than non-Schmitt-trigger ones; it won't matter in this case though.
I'm at work now so I have to hurry. Hopefully I didn't make any major mistakes in my hurry.
Ah yes I see! You have used an 74HC132 for the reset circuit as well. So that would work great!
I made a simple prototype of the keyboard to be able to test it. This is my first ever PCB .
Of course I made some mistakes so I added some patches.
The shift key did not have a pull-down resitor so I added it and the 7493 counters weren't cascaded so I had to cut a trace and add a bit of wire there as well.
I also forgot to pull the unused pins (I did not use all rows and columns available) of the 74151 to ground (not sure if this is needed but I think it does to prevent false registered clicks).
I tested it on an Arduino and it seems to work but when I click one of the keys the strobe of the 74151 is on for a while and the counters keep on counting meanwhile so it looks like more keys are clicked. Can I fix this in hardware? Could a debounce circuit work?
I'm not sure if it will be a problem with the 65C22 if I use the strobe to trigger an interrupt on CA1:
When reading the Peripheral Port (PA or PB), the contents of the corresponding Input Register (IRA or IRB)
is transferred onto the Data Bus. When the input latching feature is disabled, IRA will reflect the logic levels
present on the PA bus pins. However, with input latching enabled and the selected active transition on
Peripheral A Control 1 (CA1) having occurred, IRA will contain the data present on the PA bus lines at the
time of the transition. In this case, once IRA has been read, it will appear transparent, reflecting the current
state of the PA bus pins until the next CA1 latching transition.
I came up with a simple solution. What if I add two NAND gates to stop the clock if the strobe is high.
One to invert the strobe signal and the other one with the result of the inverted strobe and the clock signal.
I'm not sure if this will work in practice but in theory it does.
I came up with a simple solution. What if I add two NAND gates to stop the clock if the strobe is high.
One to invert the strobe signal and the other one with the result of the inverted strobe and the clock signal.
I'm not sure if this will work in practice but in theory it does.
You'll definitely need to take measures to prevent glitches. If the timing of the strobe results in the φ0 input clock getting a pulse that's less than the minimum width the system will work with, the computer will crash. A "runt pulse" would be when the pulse is so short it doesn't even quite have time to fully get to the opposite logic state and back. That would sometimes cause crashes too. Putting and RxC followed by a Schmitt-trigger inverter on the inputs (whether for rows or columns) can be used for debouncing; but I might prefer a software solution. (Or maybe I haven't understood your problem correctly.)
I came up with a simple solution. What if I add two NAND gates to stop the clock if the strobe is high.
One to invert the strobe signal and the other one with the result of the inverted strobe and the clock signal.
I'm not sure if this will work in practice but in theory it does.
You'll definitely need to take measures to prevent glitches. If the timing of the strobe results in the φ0 input clock getting a pulse that's less than the minimum width the system will work with, the computer will crash. A "runt pulse" would be when the pulse is so short it doesn't even quite have time to fully get to the opposite logic state and back. That would sometimes cause crashes too. Putting and RxC followed by a Schmitt-trigger inverter on the inputs (whether for rows or columns) can be used for debouncing; but I might prefer a software solution. (Or maybe I haven't understood your problem correctly.)
Here is a schematic of my idea.
I hope this helps to understand what I want to achieve. U6 (7400) is used to stop the clock until the button is released, this way the counters will stop counting.
On my Arduino when I click a button it is registered as many clicks and the counter continues to count so it is registered as many clicks of different switches. I want to prevent this from happening. But I don't know if this is a good solution. Perhaps it could be done in software as you suggest. I like to hear your opninion.
I came up with a simple solution. What if I add two NAND gates to stop the clock if the strobe is high.
One to invert the strobe signal and the other one with the result of the inverted strobe and the clock signal.
I'm not sure if this will work in practice but in theory it does.
You'll definitely need to take measures to prevent glitches. If the timing of the strobe results in the φ0 input clock getting a pulse that's less than the minimum width the system will work with, the computer will crash. A "runt pulse" would be when the pulse is so short it doesn't even quite have time to fully get to the opposite logic state and back. That would sometimes cause crashes too. Putting and RxC followed by a Schmitt-trigger inverter on the inputs (whether for rows or columns) can be used for debouncing; but I might prefer a software solution. (Or maybe I haven't understood your problem correctly.)
Here is a schematic of my idea.
ViridiKeyboardProto2.jpg
I hope this helps to understand what I want to achieve. U6 (7400) is used to stop the clock until the button is released, this way the counters will stop counting.
On my Arduino when I click a button it is registered as many clicks and the counter continues to count so it is registered as many clicks of different switches. I want to prevent this from happening. But I don't know if this is a good solution. Perhaps it could be done in software as you suggest. I like to hear your opninion.
I don't want to stop the computer clock entirely I only want to stop the clock signal getting to the counter IC's.
I found some time to build a new version of my keyboard prototype and the keyboard matrix works now. I did not add anything jet to stop the clock signal getting to the counters. I will see what happens now I fixed some issues. I still have a problem with the caps lock feature. I added a pull down resistor to my shift key I forgot that in my previous version so that works better now. But when I press my caps lock button now it turns on but when I push it again it won't turn off. Can anyone see what the problem might be?
Here is the part of the schematic with my caps lock/shift circuit:
Obviously here you've used an XOR gate for U1C so that if shift lock is enabled, shift will return to lower case; if either shift or shift lock is active, the output is 'shift', so that's fair enough.
Assuming a shift lock hasn't happened yet, the output of U1B is low, so it's holding the input of U1A low via R2. U1B is acting as a simple inverter (one input is held high), so the output of U1A is high. U1A is also acting as an inverter. So by default, C1 is (slowly) charged high through R1.
When SW10 is pressed, it's discharged through R2, and a brief pulse high will appear at U1A, triggering the output of U1A low, and rattling through the chain to set U1B output and U1C output high. While the button is pressed, the voltage at C1 and the input of U1A is a clear high, around 90% of Vcc; when it's released, C1 will slowly charge to Vcc; the input of U1A is held high.
When SW1 is pressed a second time... the intent is that the lack of charge on C1 will produce a low pulse on U1A and reverse all the above sequence. But I suspect that it just ends up as a potential divider between R2 and R1, so remains high. I don't think that the circuit as shown can work (though I'm always willing to be surprised!)
If you have a spare half of an HC74 lying around, you may be able simply to use that: use the shift lock (it may need debouncing) as the clock input with the D input held high; use a gate of HC86 as you have U1C to select between shift lock and shift.
Obviously here you've used an XOR gate for U1C so that if shift lock is enabled, shift will return to lower case; if either shift or shift lock is active, the output is 'shift', so that's fair enough.
Assuming a shift lock hasn't happened yet, the output of U1B is low, so it's holding the input of U1A low via R2. U1B is acting as a simple inverter (one input is held high), so the output of U1A is high. U1A is also acting as an inverter. So by default, C1 is (slowly) charged high through R1.
When SW10 is pressed, it's discharged through R2, and a brief pulse high will appear at U1A, triggering the output of U1A low, and rattling through the chain to set U1B output and U1C output high. While the button is pressed, the voltage at C1 and the input of U1A is a clear high, around 90% of Vcc; when it's released, C1 will slowly charge to Vcc; the input of U1A is held high.
When SW1 is pressed a second time... the intent is that the lack of charge on C1 will produce a low pulse on U1A and reverse all the above sequence. But I suspect that it just ends up as a potential divider between R2 and R1, so remains high. I don't think that the circuit as shown can work (though I'm always willing to be surprised!)
If you have a spare half of an HC74 lying around, you may be able simply to use that: use the shift lock (it may need debouncing) as the clock input with the D input held high; use a gate of HC86 as you have U1C to select between shift lock and shift.
Neil
Thank you Neil,
Dr Jefyll suggested this circuit for caps-/shift lock:
bounceless switch.png (2.88 KiB) Viewed 2592 times
As I already used a HC86 as an xor gate I wanted to use some of the gates as an inverter to reuse unused ports of this chip. I see the original schematic has a HC14 which is an Schmitt triggered inverter. Perhaps I should be using that instead.
But when I press my caps lock button now it turns on but when I push it again it won't turn off.
viridi, I expect the bounceless pushbutton circuit would work fine with or without the Schmitt-trigger function, so I don't think that's where your difficulty lies. (And the way you've replaced each inverter with an XOR is also perfectly alright.) So, I'm a bit puzzled.
You mentioned using 74HC86. But by any chance is it actually a 74HCT86?
A detailed description of how the pushbutton circuit works is posted here.
If you *are* using a 74HC86 (as shown in your diagram), then here's the next troubleshooting step I'd suggest.
With the circuit powered up (and without pushing the pushbutton), add a temporary connection so that the input of the first "inverter" (pin 1 of the '86) connects to 0 volts (ground). Use a 'scope or DMM to verify voltages as follows: The output of the 2nd inverter should also be 0. The output of the first inverter should be +5V and the capacitor should be almost +5V.
Then remove the first temporary connection and instead temporarily connect the input of the first inverter to +5 volts. Verify voltages as follows: the output of the 2nd inverter should also be +5V. The capacitor and the output of the 1st inverter should be at 0.
If you *are* using a 74HC86 (as shown in your diagram), then here's the next troubleshooting step I'd suggest.
With the circuit powered up (and without pushing the pushbutton), add a temporary connection so that the input of the first "inverter" (pin 1 of the '86) connects to 0 volts (ground). Use a 'scope or DMM to verify voltages as follows: The output of the 2nd inverter should also be 0. The output of the first inverter should be +5V and the capacitor should be almost +5V.
Then remove the first temporary connection and instead temporarily connect the input of the first inverter to +5 volts. Verify voltages as follows: the output of the 2nd inverter should also be +5V. The capacitor and the output of the 1st inverter should be at 0.
-- Jeff
Hi Jeff,
I checked if it is a 74HCT86 instead of an 74HC86 and it is a 74HCT86. I'm not sure if I have a 74HC86. But I need a 74HC86 instead of a 74HCT86?
I tested the circuit with my multimeter and it works exactly like you say it should work. It seems like pressing the button multiple times disables it eventually.
I just found a 74HC86 so I replaced the 74HCT86 with this 74HC86 but it does not make much difference. I need to press the button multiple times to toggle the caps lock function. Do I need some debouncing of the switch?
The circuit does its own de-bouncing, so you don't need to worry about that. Using the 74HC86, please run the voltage tests again. If all seems as it should be then I'll begin to suspect that the actual pushbutton switch itself is flaky -- you could try using a different one.
.