AT/PS2 Keybord - PIC Interface?

[mytekcontrols]

Kamikaze47:

Also, could you post this subroutine: modstart_KBinit

This is not actually a separate subroutine, but just a different entry point into the KBmain routine.

Kamikaze47:

If you could post your code that decodes the keyscan codes that would be excellent. I tried writing my own but the code was so long that it wouldn’t fit on the PIC16F84A that im using. It may be the case that I need to go with a different PIC?

I should warn you Doing a full decode of a PS2 keyboard is not trivial, and does require a substantial amount of code. There are shortcuts, but usually this will leave you without many of the features people come to expect from these style of keyboards. The first problem is that the keyscan codes as they are called, do not follow a very logical pattern. This was made even worse by the evolution from the older 84 key keyboards to the modern 104+ key keyboards. It is really unfortunate that a better standard wasn't developed early on.

To develop my decode routines; I first did as you probably have done, looked around the net for something that was close. There is a lot of info out there, but not too much that is geared towards a PIC, and nothing I could find that would do it in PBP. What I did find, and which was my inspiration, is this piece from Craig Peacock written in 1998 for a 68HC705 Interfacing the AT keyboard. Understandably it is written for an entirely different processor (CISC instead of RISC), but I had a good grounding in 6502 from my early Atari days as a hobbiest assembly language programmer, and this was fairly close to 68HC705 syntax. So I initially took on the task of translating the 68HC705 code over to PBP. The end result worked, but it was massive!

The next step of the process was one of refinement. The biggest memory drain were the extensive tables required in order to decode the convoluted keyscan code mess, into usable ascii codes. I decided what was needed first and foremost was to transform the keyscan codes into something more sequential, without all the gaps and disorder of the original. This way much of the decoding could then be done through purely mathamatically methods of adding or subtracting an offset value in order to get an ascii number code that equated to a given key or ctrl+key/shift+key combination. I ended up calling my keyscan translation "keycodes". Here is a look at both the keycodes and the ascii mapping that I used (includes extended numbers for non-ascii keypresses such as the function keys): KEYS.pdf.

And here is the actual table code utilized:

keycode_tbl:
asm
    movlw  Low keycode_tbl
    movff  WREG, _ktable
    movlw  High keycode_tbl
    movff  WREG, _ktable + 1
endasm

    Readcode ktable + scancode, keycode
    Return

asm
keycode_tbl
    DB 0x80,0x39,0x80,0x35,0x33,0x31,0x32,0x3C
    DB 0x80,0x3A,0x38,0x36,0x34,0x80,0x1B,0x80
    DB 0x80,0x80,0x80,0x80,0x80,0x11,0x21,0x80
    DB 0x80,0x80,0x1A,0x13,0x01,0x17,0x22,0x3D
    DB 0x80,0x03,0x18,0x04,0x05,0x24,0x23,0x3E
    DB 0x80,0x80,0x16,0x06,0x14,0x12,0x25,0x3F
    DB 0x80,0x0E,0x02,0x08,0x07,0x19,0x26,0x80
    DB 0x80,0x80,0x0D,0x0A,0x15,0x27,0x28,0x80
    DB 0x80,0x2D,0x0B,0x09,0x0F,0x20,0x29,0x80
    DB 0x80,0x2E,0x2F,0x0C,0x2B,0x10,0x1C,0x80
    DB 0x80,0x80,0x2C,0x80,0x1E,0x1D,0x80,0x80
    DB 0x80,0x80,0x80,0x1F,0x80,0x2A,0x80,0x80
    DB 0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80
    DB 0x80,0x41,0x80,0x44,0x47,0x80,0x80,0x80
    DB 0x40,0x4A,0x42,0x45,0x46,0x48,0x30,0x80
    DB 0x3B,0x4D,0x43,0x4C,0x4B,0x49,0x80,0x80
    DB 0x80,0x80,0x80,0x37
endasm
        

noshift_tbl:
asm
    movlw  Low noshift_tbl
    movff  WREG, _ktable
    movlw  High noshift_tbl
    movff  WREG, _ktable + 1
endasm

    Goto keytrans

asm
noshift_tbl
    DB "`","-","=","[","]","0","1","2"
    DB "3","4","5","6","7","8","9",0x5C
    DB ";","'",",",".","/",0x1B,0x7F,"*"
    DB "-","+"
endasm


shift_tbl:
asm
    movlw  Low shift_tbl
    movff  WREG, _ktable
    movlw  High shift_tbl
    movff  WREG, _ktable + 1
endasm

    Goto keytrans

asm
shift_tbl
    DB "~","_","+","{","}",")","!","@"
    DB "#","$","%","^","&","*","(","|"
    DB ":",0x22,"<",">","?",0xA0,0xBF,"*"
    DB "-","+"
endasm


ctrl_tbl:
asm
    movlw  Low ctrl_tbl
    movff  WREG, _ktable
    movlw  High ctrl_tbl
    movff  WREG, _ktable + 1
endasm

keytrans:
    Readcode ktable + (keycode - $1B), ascii
    Return

asm
ctrl_tbl
    DB 0x00,0x1F,0xEA,0x1B,0x1D,0xE0,0xE1,0xE2
    DB 0xE3,0xE4,0xE5,0xE6,0xE7,0xE8,0xE9,0x1C
    DB 0xEB,0xEC,0xED,0xEE,0x1E,0xC0,0xDF,"*"
    DB "-","+"
endasm

You'll notice if you scroll through the table code, that there are sub-tables marked as noshift, shift, and ctrl. These were required for some of the special navigation and Number Pad keys, which are part of the extended keyscan codes added during the 84 to 104 key transition period.

Of course wouldn't you know it, they require special handling since their actual code assignment mimics those of other existing keys (they have an additional $E0 scan code sent in order to distinguish them from standard keys).

Luckily the addition of these very small sub-tables doesn't really impact too greatly on code size requirements. Overall if you compare this table to the one used in Craig Peacock's 68HC705 code you will still see a dramatic reduction in size.

More to come <img src="http://www.picbasic.co.uk/forum/images/icons/icon2.gif" align="absmiddle"> Installment #3: KBmain module (the decoding routines)