Getting a Verilog PS/2 interface working

[asmi]

I have some alternative PS/2 interface modules to try as well, might give them a try.

Don't do this. Instead find a spec for the interface and implement it properly as per spec. It's not complicated enough to warrant looking for third-party code and trying to get it to work.

[nockieboy]

I have some alternative PS/2 interface modules to try as well, might give them a try.

Don't do this. Instead find a spec for the interface and implement it properly as per spec. It's not complicated enough to warrant looking for third-party code and trying to get it to work.

I appreciate the sentiment, but I don't see the point in re-inventing the wheel.  I've actually got the interface working now using some code provided by Digikey.  It's in VHDL, but was pretty much just drag-n-drop into the project.  The only tweak I needed to make was to double the debounce timer to get a non-repeated output. 

I want to keep the keyboard interface as simple as possible, but one thing this PS/2 interface can't do is transmit data for simultaneous keys being pressed - it doesn't send break codes - so there's no way of knowing if multiple keys are being pressed.  It's already as capable as the serial console that I've been using up to now, so this shouldn't be an issue (it handles SHIFT/CAPS/CTRL etc) but if I want to be able to read multiple key presses, like the up arrow and right arrow being pressed at the same time, I'll need to modify the code a little.  I'd do this by merging the arrow keys into one byte before it is transmitted to the host - so the 'up' arrow could be b0, 'down' would be b1, etc. and just tweak the code on the host Z80 side so that if it receives a key press in a 16-byte range, then it just needs to decode that byte into the binary representation of which arrow keys are being held down.  Does that sound about right?

[BrianHG]

Wouldn't is work something more like a 'Key['#'] Down' and 'Key['#'] Up' ?  So each key being pressed down transmits a activate signal.  And only when the key is released would it send a de-activate for that key?

This way, your Z80 will see any number of keys being pressed on and off simultaneously, or one after another, or held down for any amount of time?

[nockieboy]

Wouldn't is work something more like a 'Key['#'] Down' and 'Key['#'] Up' ?  So each key being pressed down transmits a activate signal.  And only when the key is released would it send a de-activate for that key?

This way, your Z80 will see any number of keys being pressed on and off simultaneously, or one after another, or held down for any amount of time?

Well, that's the way PS/2 keyboards work, yes.  The interface module I'm using dumbs that down a bit so it only sends 'key down' (or 'make') codes and doesn't send on the 'break' codes.  It would involve some work on the host side to buffer 'make' codes and respond to the running program with a list of keys that are pressed at that instant, for little benefit currently.  That's something I can work on later as and when the need arises.

[BrianHG]

Wouldn't is work something more like a 'Key['#'] Down' and 'Key['#'] Up' ?  So each key being pressed down transmits a activate signal.  And only when the key is released would it send a de-activate for that key?

This way, your Z80 will see any number of keys being pressed on and off simultaneously, or one after another, or held down for any amount of time?

Well, that's the way PS/2 keyboards work, yes.  The interface module I'm using dumbs that down a bit so it only sends 'key down' (or 'make') codes and doesn't send on the 'break' codes.  It would involve some work on the host side to buffer 'make' codes and respond to the running program with a list of keys that are pressed at that instant, for little benefit currently.  That's something I can work on later as and when the need arises.

Well in the Z80, for normal keyboard operation, we are talking code as simple as when a 'make' is received, set that as a single strike and do nothing else, ignoring everything until ANY 'break' is received.  Natural exception would be flags for combo keys like 'shift' and 'ctrl' and 'alt'.  Only special apps like games would need direct access to 1 stage earlier.  We are talking something like 8-12 assembly commands, not counting a lookup table if you need to translate to ascii.

Or, in fact, maybe something like a lookup jump table, where whenever a 'make' is set, the jump would fill in the ascii or shift/ctrl/alf flags and a 'break' would clear the normal keys.  This strategy may waste a good 64 to 128, or 256 additional bytes of program space, but, it would be stupid quick and difficult to mess up.

Or, you can partially hold the flags and decode the basic ascii in verilog, and have 2 keyboard bytes to read.  1 for base bottom ascii code, the second byte for shift/ctrl/alt status and 'make' / 'break' being set, plus maybe an interrupt enable.