Sorry, I was unclear: you have eight bits representing the state of the keyboard in some fashion, but no obvious way to say when a key is ready to be handled.
The classic way to handle that is to use one line to interrupt the processor, and for the processor to reset that interrupt bit. But I don't see anything to indicate that in (admittedly incomplete) drawing. So I wondered if you were using just seven bits of data - which would let you have all the ascii set, but give some difficulty with e.g. the cursor keys, F keys, and handling control and alt combinations - and somehow using the remaining bit to flag that a key is waiting.
Or perhaps you're going to let the 6502 handle the key combinations and just pass the real-time key values - though that requires all eight bits to collect the full set. So you still have to find some way to tell the processor that there's something to handle, with the added complication that only about a third of the key codes are equivalent to a key being pressed, so the processor might be a bit busy.
To be honest, I'd decode in the AVR, probably buffer the output, and encode the keys I care about into eight bits (this is what I am doing with my Pi Pico vga chip interface) and find some way to generate an interrupt (though you'll still need some way to clear that interrupt before the next keystroke).
I was just curious... I'm always ready to rip off someone else's better ideas, er, I mean, research alternative approaches
For what it's worth, I tried a couple of fairly recent (= cmos) PS/2 keyboards and they're quite happy at 3v3, and don't take more than a few milliamps.
Neil
Login
Register
FAQ
Search
