6502.org

So I am using a 74HC14 and 2 74HC595's to take the KBCLK and KBDATA, shift in the 11 bits of the scancode, and then plan to just snag the 8 bits that represent the key and use that to output the key to the LCD (just a carbon copy of a hungry youtube fella). I tried to draw this three times and this is my best attempt, so have mercy. the SR and RCLKs are connected to the second '595 and the last bit rolls to the (edit: SER) of the second '595. And the OE of the 595 connected to ground is not connected to the KBDATA, I just suck at drawing. I have the cheapest logic probe known to man but the bleeps and bloops appear to be behaving themselves going from the '14 to the '595s but there is no output, or more specifically the outputs are all high. They don't twiddle dee or twiddle dum, just steady high.

I did notice that the signal coming out of pin 7 on the '14 seemed to not light the probe as brightly (bright L, dim H when twiddled) but even after passing it through another inverter that made it go bright it didn't make a difference. I would expect, at this point, for it to put out something, even if it is just garbage. But nothing? not sure, probably a classic case of rookie chuckleheadedness.

EDIT: just for completeness, the Resistor is 30K, the Diode is a 1N4004, and the Capacitor is 10nF. This is meant to hold the IRQ low for the entire duration of the transmit so the IRQ is serviced after all bits are available on the outputs and have had time to settle.

This is the circuit I think you've described. A few things:

• * The output of the first shift register should go to pin 14 (usually called SER), not QA. QA is an output.
  * On the 6502, /IRQ is level-sensitive. An interrupt will be triggered as soon as it goes low.
  * Pin 7 on a 74x14 is GND. There shouldn't be any signal on it. What are you actually measuring?
  * Using an RC delay doesn't feel right, but I don't have a concrete suggestion to replace it.
  * The PS/2 interface is open-collector. There must be pull-up resistors somewhere. Are they in the keyboard? I don't know. It can't hurt to add 10K pull-ups at your end.

The capacitor is charged immediately through the diode when KBCLK goes low, then slowly discharged through the resistor when KBCLK goes high. I'm guessing that the intention is to have /IRQ and SACLK go low as soon as data starts coming in, then rise some time after it's finished? That would make sense.

As I said, /IRQ is level sensitive on the 6502. You'll get an interrupt as soon as data starts coming in, then another as soon as the handler ends, and this will repeat until /IRQ goes high again. A much better solution would be to use something like a 74x74. Have the rising edge of this signal clear it, then assign some I/O signal so the interrupt handler can set it when it runs. And of course, if there are any other interrupt-generating parts in the system, you'll need open collector outputs or some other way to ensure that they're not pulling the signal in two directions at once.

The /IRQ is going to a 6522. That part might need fixing but doesn't explain why the '595s aren't outputting anything. The QH' is going to SER I'm just a derp and mentally translated that to going out of QA. The inputs of the 74HC14 that I am not using are being grounded to pin 7. Nothing there is being measured. I'll have a look at your schematic and try some things out, thank you!

EDIT: included the program that will be used to read and translate the keyboard to LCD. Might clear up any q's about anything going to the 6522. I didn't really include much about that because I'm trying to get the bits to twiddle out of the 595's first.

I pulled one of the TI SN74HC595's and hooked it up to an arduino and some LED's. Its happily incrementing to 255 in binary. So at the very least we know the chip is good. I am going to just disassemble what I have built with the '14 and the '595s and just start over, taking suggestions into account. Something is obviously fubar.

Ok, so I'm not 100% sure why what I did works, but it does. The first thing I did was swap the 1N4004 diode for a 1N5817 Schottky diode for faster response and lower voltage drop. Then I hooked the SRCLK to the KBCLK raw signal and the RCLK to the same pulse the /IRQ uses. Having the SRCLK hooked to the /IRQ pulse didn't make any sense. Now on the LEDs I get decipherable scancodes for the letters and if I mash a key there isn't any errant twiddling of bits or weirdness I was having before when I initially started getting output to the LED's. So, basically, I accidentally fixed it. BUUUUT the CPU/VIA isn't taking the data and now I am using one less inverter on the '14 than in the video I watched so something is still messed up and I am magic.

I'm still hoping to see a schematic of some kind. Without one, it's very hard to offer advice. Do you think you could make a printout of the image below, pencil in the parts that are missing or different, then take a photo and post it?

This is an edited version of the diagram John West posted (thx, John!). I altered one connection (in red); am pretty sure this is what he actually intended.

-- Jeff

The schematic I posted wasn't one that I thought should work - it's what I thought the (non-working) circuit being described was. I was having trouble following the layout-oriented diagram and thought a function-oriented version might help.

That is how I have it hooked up now Jeff, sorry for being a pain in the butt. However, it was also working without inverting the KBCLK before putting it into RCLK as well. I'm still kind of confused, not about how the circuit works, that makes sense, but why mine seems to change when it works. I SWEAR it was working last night without that inversion. I even had someone press a key without me looking and then decoded their keypress by looking at LED's. Well, whatever, the key (no pun intended) problem is solved, the SR's are outputting. At this very moment I have everything hooked up exactly as Jeff's diagram shows and can press a key and decode it via LED's. Thanks everyone for sorting that out.

EDIT: I need to stop editing posts every time I think something has changed. I do experience issues during typing tests where the LED's will all go off when I press a key and will come back on after an arbitrary number of key presses. I will poke around with my multimeter to make sure power is steady.

Whoops -- I misunderstood. And I agree a functional diagram is more helpful (as opposed to one which depicts actual physical layout).
This is only mildly surprising. Some circuits will tolerate such a change. Sorry but ATM I don't have time to look up the waveforms that're to expected out of a PC keyboard.
Sounds like a construction problem (rather than a design problem). Or, it could be the power, as you say. Some photos of your circuit might help. Glad to see you making progress, though!

-- Jeff

I've fixed the intermittency issues and also moved the entire design over to protoboard. I can now get consistent LED readouts on all button presses even when mashed and i see significantly less flutter in the LED's during press/release phases of the keypress. I still can't get the LCD to print anything. I'm guessing, based on old posts, the initialization of the LCD is not timed properly. I'm going to be taking a short break from this project and begin to dive more into 6502 assembly so I can be sure of how to go about fixing all of this and not relying on other peoples programs with my fingers crossed. Thanks for all the help folks!