PS2 Keyboard Numlock problems

[andyhhp]

Hello,

I am having a problem implementing a PS2 Keyboard driver. I have read the wiki, related links and searched google but I cant find any relevent information so I was wondering if someone here has had similar experiences and might be able to help.

A quick background (not revelvent to the specific problem but included because this isnt a typical OS Dev project):

I have an internship in which we (3 of us) are building a SMP type supercomputer from 36 Altera DE2 boards. We have a NIOS core running a small C program, with a custom written PS2 interface on an Avalon Memory Mapped slave. The custom PS2 interface is written in System Verilog and does little more than "speak the PS2 line protocol". It deals with parity checking, resends when needed and resetting the keyboard (command 0xFF) on a full system reset.


The problem I am having is with translating the scancodes that the keyboard generates. (I am using http://www.computer-engineering.org/ps2 ... odes2.html as a reference)

The problem is with using number lock.

When pressing the NumLock key, the make and break codes for the set of keys including Insert, Home, Page Up, Page Down, Delete, End and Page Down.

After a keyboard reset, the scancodes are as listed on the reference. However, after pressing Numlock once, those keys (and possibly others but I done exhaustive testing yet) change their scancodes to have a 4 byte make code (e0, first byte, e0, second byte) and a 6 byte break code (e0, f0, second byte, e0, f0, first byte).

Subsiquent presses of the NumLock key switch the behaviour between those two modes.

Does anyone have any idea why this is happening?

Thanks in advance,

~Andrew

[alethiophile]

I think these would be the fake shift-up and shift-down codes inserted for compatibility with old software. If you look at it, you should see that the 'first byte' of the make code (after the first e0) and the 'second byte' of the break code should be consistent regardless of which of the affected keys you press. The way you deal with this is just throw out the fake shift codes.

[andyhhp]

Hehe - I just read that reference and wondered if that might be the problem but dismissed the idea because that was only having 8 bytes from the keyboard controler not 10.

However, thinking about it, I dont have a keyboard controler sitting between my driver and the keybord so the break commands are still coming as (f0, byte) rather than (byte | 0x80).

Thanks,

~Andrew

[jal]

However, thinking about it, I dont have a keyboard controler sitting between my driver and the keybord so the break commands are still coming as (f0, byte) rather than (byte | 0x80).

I think this has normally to do with the scancode set. Perhaps the emulated PS/2 interface is bad. Try your code on a normal PS/2 keyboard on a PC and see what results you get...


JAL

[andyhhp]

Perhaps the emulated PS/2 interface is bad.

The interface isnt bad. It simply does nothing more than translate between the PS2 Line protocol and bytes for the soft processor (and parity checking).

I have solved the problem. The bug in the driver was assuming that e0 12 was always the start of the PrtScn button, whereas in actualy fact, the PrtScn button always sends the fake shift code irrispective of the state of numlock and the two other shift keys.

My code for working out which physical button was pressed now registers but ignores the fake shift scancodes, whereas the code for working out which character is generated does take this into account.


Either way, the verilog hardware interface and C driver code are now working completely and have been fully tested.

Thanks for the help,

~Andrew