You are right it is more risky than doing it in software. Something similar as what you describe is how it was done in the older computers like the Commodore machines and the BBC Micro I have looked at how they did it. Perhaps I could use some programmable logic that would also reduce the number of chips and that is also reprogrammable in case of mistakes. But I don't have any experience with that except for programming a ROM chip if that counts as programmable logic.

It's not just the scan/decode choice.

If you have a completely cpu driven keyboard scan (i.e. the main CPU, not an auxiliary part) then it has to spend a certain amount of it's time just scanning the keyboard, as well as managing the debounce and rollover in software. If you have a completely hardware approach, you need to know when a key is ready, so probably an interrupt, as well as handling (probably) debounce and rollover.

Similarly for something like PS/2, you either need to poll the clock line - rapidly - or have it trigger an interrupt (again, processor time) to decode the data, and you still need to sort out the keydown/keyup messages as well (you might want both edges of a key press, as Windows did (does? I'm out of touch) in an event loop).

My split the difference approach I think will be to use an external processor to mediate a PS/2 keyboard, read the individual packets, and spit them out as serial data - so I'll still need to sort out keydown/up messages at the processor, but the PS/2 sorts everything else out. (Or I can make it just send the keydowns as they happen and sort out control and shift there.) As it happens, I already have an SPI uart, so adding another is no great shakes.

I could do this with an eight-pin part, but I have a box full of STMs with 48 pin, so that's what it'll likely be.

(Or alternatively, use the same STM to handle an external UART channel and talk to it by SPI, let it sort out streams from serial port and keyboard. Time to play.)

Neil

Windows does keep track of the make/break state of each key on the keyboard (somewhat) for video games.

Imagine if you will a typical modern game these days that likes to use WSAD for forward, backward, left, and right movement. Very often players will push Some combination of Forward+Side or Backward+Side.

They may also have something like 'F' to interact, or 'Space' to jump.

If all you want to do is type, then yea, keeping detailed track of the make/break codes doesn't make sense. Last key pressed is good enough, but if the game engine forgot you were pressing "forward" when you hit "jump" and you ended up falling into the bottomless pit because of it, you wouldn't have very happy players.

Can't I just handle the incoming keypress with the 6522, the 6522 can trigger an interrupt on the 6502 right?



I'm not sure if I need keydown/keyup messages. Windows did/does this but did those older computers have have keydown/keyup messages? Something like the C64 or the Acorn BBC Micro?

You may not need them but if you use a PS/2 keyboard then you'll get them because that's how they work... Although the 'driver' can hide it all from you. Making a PS/2 keyboard present a 7-bit + strobe interface is relatively easy with a micrcontroller.

(The other issue with PS/2 keyboard is language - some keys are in the wrong place)

If using your own matrix/polling scheme then it's entirely up to you - one thing that may influence that decision is games (or even some non-game tasks) if you want to detect e.g. how long a button is pressed - think of something like space invaders - simple left/right/fire controls, but if you can only get keypressed then you push a key to start moving then you need to push another key to stop moving/change direction rather than simply let the key go. Or even moving a cursor - auto-repeat has to be implemented... somehow...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Ok clear. Thanks drogon. In the design I found that the keyboard is scanning constantly by some clock circuitry (perhaps I can use the system clock for that). All columns are scanned by the 74154 4-Line to 16-Line Decoder/Demultiplexer (with a 4-bit binary counter as input). The rows are scanned by the 74150 (with second 4-bit binary counter as input). When a key is pressed the 74150 captures that and strobes when the row of that key is active. Then the keyboard should output 7-bits these come from both the 4-bit counters and shifting/control logic. I could also send a strobe bit to the 6522.

I guess the keyboard would send data many times to the 6522 if the user holds down a key and the 6502 wil get interrupts every time then left/right/up/down movement would be appear. Please correct me if I'm wrong.