PDA

View Full Version : IBM Model F XT Keyboard information



Maelgrum
June 30th, 2016, 12:27 PM
Greetings !

During my investigation of IBM Model F XT Keyboard firmware, i found some information about this keyboard i like to share.
This is keyboard matrix layout:
https://docs.google.com/spreadsheets/d/14_eJTc2P8WIMPJu6X0hwUtcfG5SCmYgQCp8mYbGjNXg/edit?usp=sharing
On Sheet2 is more 'visual' presentation of keyboard matrix and make scancodes for keys.

With this information + schematics + firmware you can make new keyboard :)

Notes:
1. Interesting what there is scancode 0x76 but no physical key, associated with it. May be it was used for testing or diagnostic purposes, or ROM checksum correction, or simple mistyping - dont know ...
2. All others non existent keys give scancode 0x00. Usually you cannot register keypress with this row+column combination on matrix, so it can be only error situation - some liquid on keyboard film, for example.
3. XT keyboard protocol is bidirectional ))) Keyboard can accept command from host (PC). But it is only 1 command - reset :)

This is interesting to anyone ? :)

Maelgrum
July 1st, 2016, 06:24 AM
Some notes about XT Keyboard protocol:
1. CLOCK and DATA lines can be PULLED DOWN by 7407 driver on keyboard or host (pc) side, or can be RELEASED and pulled up by resistors on both sides. Pull up resistor values for clock is 2k ohm on kbd side, and 4.7k on host side. For data values is 1k on kbd side and 4.7k on host side.
2. Keyboard to Host packet is 10 bit: 2 start bits and 8 data bits. First start bit is 0, second start bit is 1. Data send LSB first:
0 1 D0 D1 D2 D3 D4 D5 D6 D7
3. Host latches data bits on CLOCK HIGH to LOW transition (trailing egde)
4. On host side reciever is 9 bit register, so fist start bit (with value 0) goes through register and simply ignored
5. Second start bit (with value 1) used to arm IRQ1 trigger
6. IDLE state is: CLOCK released by kbd (and host) and pulled up (to +5V), DATA is pulled low by kbd.
IDLE state KBD HOST Logic level
CLOCK release release HIGH
DATA pull low release LOW
This is normal state of lines for keyboard, and in this state kbd can send packets to host.
7. All protocol timings is based on duration of machine cycle. Based on reference schematics, typical oscillator frequency for KBD processor is 5.102535 MHz, so duration of machine cycle is 2940 ns = 2.94 us. Measured on real kbd, machine cycle is 2.858 us. I can guess what +- 0.5 us duration spread is quite possible, due to component tolerances e.t.c, so machine cycle can be from 2.5 to 3.5 us. For simplicity lets assume machine cycle duration 3 us (its very near of ideal and measured values).
8. Correct visual presentation of protocol is here:
http://www.kbdbabel.org/signaling/
all other sources of information about XT keyboard protocol was misleading or simply wrong.
9. Keyboard to Host packet is 368 cycles (1104 us) total, from first HIGH to LOW CLOCK edge to last LOW to HIGH CLOCK edge. CLOCK during data bits tranmission is driven 11 cycles (33 us) low and 25 cycles (75 us) high, for total of 36 cycles (108 us).
10. Data (during data bits tranmission) is set 9 cycles (27 us) after CLOCK HIGH to LOW edge, and 2 cycles (6 us) before CLOCK LOW to HIGH edge.

Maelgrum
July 1st, 2016, 07:42 AM
Host can do 2 things:
1. Host can send command to kbd. Only one command defined - RESET, but anyway - protocol is bidirectional.
Host requests to send command by pulling CLOCK LOW (by writing 0 to PB6 bit of 8255A). (.. to be continued ...)
2. Host can show BUSY state to kbd by pulling DATA LOW. Host automatically enters BUSY state after recieving packet from kbd. After reading scancode byte from PA0-PA7 of 8255A, host ISR routine (IRQ1) clears this state by setting PB7 bit to 1 and then setting back to 0 for normal operation.
Kbd detects BUSY state by following: Then kbd has more scancodes to send, it runs as usual its send routine, then pulls CLOCK LOW - so host recieves first start bit (with 0 value). Then kbd releases DATA line - in normal course of action, then protocol in IDLE state, data line goes high. But in BUSY state host actively pulls data line low, so after kbd releases data line, it is not going high. This is indication to kbd of BUSY state. Kbd releases CLOCK and pulls down DATA and enters keyboard scan routine. Then, after some time, it tries to send again and again. Retry period is something like 2580 cycles (7740 us) - 3001 cycles (9003 us).

Maelgrum
July 1st, 2016, 08:11 AM
About key repetition rate:
If key pressed and not released, following happens:

<scancode> .. delay 211716 cycles ( 635 ms) .. <same scancode> .. delay 34368 cycles ( 103 ms) .. <same scancode> .. delay 34368 cycles ( 103 ms) .. <same scancode> .. delay 34368 cycles ( 103 ms) ............................

If multiple keys are pressed, intersymbol delay varies - 4679, 5381, 1089 cycles for example.
16 symbols was transmitted in 48625 cycles (145.8 ms), so rate is approx. 9.1 ms per symbol.

Maelgrum
July 7th, 2016, 06:08 AM
Deatailed XT Keyboard protocol timings:
On this page http://wavedrom.com/editor.html
insert following script:
** Note - remove spaces between dots in following script, i.e. "... ..." is bad, "......" correct

{ "signal" : [
{ "name": "Clock", "wave": "1.0..........................................1.... ....................0..........1.................. ......0..........1........................0....... ...1........................0..........1.......... ..............0..........1........................ 0..........1........................0..........1.. ......................0..........1................ ........0...........1." },
{ "name": "Data", "wave": "0...1............................................. .............................3.................... ...............4.................................. .3...................................4............ .......................3.......................... .........4...................................3.... ...............................4.................. .............0........", data: 'D0 D1 D2 D3 D4 D5 D6 D7'}
],
head:{
text:'XT Keyboard Protocol',
tick:-2,
},
foot:{
text:'* all timings in machine cycles, 1 machine cycle is ~3 microseconds'
}
}

per
July 7th, 2016, 07:05 AM
I did some work with the XT keyboard interface years ago. I used it to interface with a NES controller.

The interface itself is pretty forgiving when it comes to timing, and as long as you just make sure about the start-bits, data-bit order and holding each bit long enough (a few microseconds should be enough), things should be OK. You will also have to respond properly to the host pulling the lines low during startup, though. Cirquits in the host itself sync the reading of a bit with the system clock, so the IRQ will trigger properly no matter when the final bit is clocked in.

Maelgrum
July 7th, 2016, 08:13 AM
Its just fun project. 8048 emulator + ibm keyboard schematics + firmware, and many hours of testing and debugging )))
But now i can execute original code, and see what happening inside, its very interesting.

Information above can be used for repairing old keyboard (keyboard matrix above), or for making PS/2 or USB to XT keyboard translator.