Rodents anyone ?
Posted: 27 Apr 2018 09:49
Hot on the heels of the PS2/USB Keyboard interface, now it's the Mouse's turn!
The PS2 mouse protocol is handled by an ATmega328, that converts the serial data from the mouse into 4 directional on/off signals plus left and right button.
Those 6 signals are then pushed onto the keyboard sense lines when the keyboard scanning routine drops the relevant drive line low.
To keep integration with existing software as simple as possible the 18V8 GAL maps the 4 directions map to the cursor keys, while the buttons map to home and return.
Diodes on the sense line ensure that the GAL doesn't interfere with the normal keyboard scanning.
The board is build with a 20 pin male header, which allows it to be connected in parallel with the keyboard using a normal 3 plug IDE cable. A 5v power supply from the MTX is needed. Pin 11 of the Port 7 socket is one source, but there are others that are reasonably easy to tap.
There are a couple of shortcomming in the MTX keyboard handling that need to be "worked around" The CALL #0079 scanning routine stops as soon as it finds one key dow. So although the GAL could be setting anywhere between 0 ( no movement) and 4 (diagonal movement with both buttons down) keys, the OS only ever finds one.
Any code that reads the key matrix directly, bypassing the OS would be able to "find" multiple key presses.
The othe issue that cause problems is the resistors that pull the drive lines high on the MTX motherboard are slow. During normal scanning if there are no keys down the scanning sequence is:
Drive port 5, bit 2 low to check control
Drive port 5 bit 6 low to check both shift keys
Drive port 5 bits 0 to 7 low in sequence to read the rest of the keyboard.
The drive lines in port 5 aren't reset after each test, they're just left as they are until the next sense line is selected. Checkimg the drive lines with a logic analyser to find out why the mouse was generating incorrect key presses, I found that with the mouse board attached, the resistors take 4us or so to pull the drive lines back to a valid high after they released. With a 4mhz Z80 that's 16 cycles. The MTX follows the OUT5 to set the drive lines with an IN 5 to read the main keyboard port, that instruction is completed within those 16 cycles. Which means that there are actually 2 drive lines that are low. The one activly being checked, and the previous one being pulled up by the resistor.
In normal use, that's not a problem, however with both the mouse and keyboard providing input, that was leading to false keys being recorded, as the GAL on the mouse board could be driving the sense line base on the "old" drive line while the scanning routine was actually checking the "new" one.
The solution was to monitor not just the 5 drive lines the mouse needs, but also the lines that follow those in the scanning sequence. The revised GAL code then releases the sense line if it detects the next drive line going low. The speed of the GAL means the sense line is release within nano seconds and eliminates the phantom keys.
The PS2 mouse protocol is handled by an ATmega328, that converts the serial data from the mouse into 4 directional on/off signals plus left and right button.
Those 6 signals are then pushed onto the keyboard sense lines when the keyboard scanning routine drops the relevant drive line low.
To keep integration with existing software as simple as possible the 18V8 GAL maps the 4 directions map to the cursor keys, while the buttons map to home and return.
Diodes on the sense line ensure that the GAL doesn't interfere with the normal keyboard scanning.
The board is build with a 20 pin male header, which allows it to be connected in parallel with the keyboard using a normal 3 plug IDE cable. A 5v power supply from the MTX is needed. Pin 11 of the Port 7 socket is one source, but there are others that are reasonably easy to tap.
There are a couple of shortcomming in the MTX keyboard handling that need to be "worked around" The CALL #0079 scanning routine stops as soon as it finds one key dow. So although the GAL could be setting anywhere between 0 ( no movement) and 4 (diagonal movement with both buttons down) keys, the OS only ever finds one.
Any code that reads the key matrix directly, bypassing the OS would be able to "find" multiple key presses.
The othe issue that cause problems is the resistors that pull the drive lines high on the MTX motherboard are slow. During normal scanning if there are no keys down the scanning sequence is:
Drive port 5, bit 2 low to check control
Drive port 5 bit 6 low to check both shift keys
Drive port 5 bits 0 to 7 low in sequence to read the rest of the keyboard.
The drive lines in port 5 aren't reset after each test, they're just left as they are until the next sense line is selected. Checkimg the drive lines with a logic analyser to find out why the mouse was generating incorrect key presses, I found that with the mouse board attached, the resistors take 4us or so to pull the drive lines back to a valid high after they released. With a 4mhz Z80 that's 16 cycles. The MTX follows the OUT5 to set the drive lines with an IN 5 to read the main keyboard port, that instruction is completed within those 16 cycles. Which means that there are actually 2 drive lines that are low. The one activly being checked, and the previous one being pulled up by the resistor.
In normal use, that's not a problem, however with both the mouse and keyboard providing input, that was leading to false keys being recorded, as the GAL on the mouse board could be driving the sense line base on the "old" drive line while the scanning routine was actually checking the "new" one.
The solution was to monitor not just the 5 drive lines the mouse needs, but also the lines that follow those in the scanning sequence. The revised GAL code then releases the sense line if it detects the next drive line going low. The speed of the GAL means the sense line is release within nano seconds and eliminates the phantom keys.