************************************************************** IBM Keyboard Interfact Project, by ERic Rudolph, 1991. No Copyright Whatsoever, but I would like credit where it's due. [... lots of stuff about the circuit deleted ...] A little background on the IBM AT keyboard: The keyboard I used for this circuit was a BTC 5339sx. It costs about $40 Lucky Computers, 1-800-348-5825. I have also tested the circuit on a standard PC keyboard, and an HP Vectra AT keyboard. The AT keyboard DIN connector has 5 pins. Pin 3 is called Reset, but it's reserved, so we can't use it. Forget it exists on the AT keyboard. They just charge you money for it. (joke) Open collectors drive the clock and data pins, so when they are not driven low, they float at 5 volts. The keyboard transmits data by bits, each synchonous somehow with the clock line. They keyboard when clocking in or out data, always runs the clock. The controller can drive the clock line, but not with reference to data. When the Keyboard sends data, it first sets the data, then drives clock low, then high, and then changes the data to the next value. The AT uses 11 bits for a transmission, 1 start bit (0), 8 data bits, 1 parity bit-set if the number of 1's in the data bits is even, and a stop bit (1). When the keyboard sends it's last bit, the stop bit, the controller must drive clock line low as a handshake and to tell the keyboard not to send until clock goes high again. Theoretically, the controller could interrupt the sending of the bits, but I consider this unnecessary, and don't bother with it. When the computer needs to send a command to the keyboard, it sets clock line high and the data line low. When the keyboard sees this, it will start clocking pulsed on the data line. Then, the controller must look for the clock line going low, set the data bit, wait for the clock to go high, then wait for the clock to go low again, and then change the bit. Thus, it changes the data in the middle of the clock low pulse. When the keyboard has received it's 10th bit, it will drive the data line low while at the same time clocking out an extra clock low pulse. Then, it expects a handshake of the clock line low from the controller. 0 1 2 | 7 P stop extra Clock:------------\___/---\___/---\___/---\___/---\___/---\___/---\___/end Data:-------\_______00000001111111122222|6677777777PPPPPPPP1111xxxxxxxx_____ Notice there is NO start bit when the controller sends data to the Keyboard. Special Commands the Keyboard can Send to the Controller: ----------------------------------------------------------- 00 Keyboard buffer overflowed AA Selftest passed FA The command sent was received correctly FE The command sent was received poorly. Please resend. Special Commands the Controller can Send to the Keyboard: ----------------------------------------------------------- ED Set the LEDs according to next byte I send bit 0=Scroll lock 1=on bit 1=Num lock bit 2=Caps lock bits 3-7 must be 0 F4 clear the key buffer and start scanning F6 restore default values FE retransmit last character, please FF Reset, you stupid keyboard! Whew! That about raps it up for the AT keybard! Enough said, right? XT keyboards transmit much the same way except they only use 10 bits. Two start bits (both high) and 8 data bits, transmitted in order 0-1-2...-7 The last bit is a make/break bit which is 1 to signify a break. The XT can have no commands sent to it. The way to reset it is to drive the Clock line low for some longish period of time. The keyboard will not send data (it will hold off) if the data line is being held low by an external source (the controller) [... more stuff about his software ...] Any questions? Be glad to answer em! Email address: rudolpe@jacobs.cs.orst.edu Phone # 503-745-7466 (Oregon) ********************************************************* (end of quote) Cheers.... ------------------------------------------------------------------------- mark@garden.equinox.gen.nz A garden is a thing of beauty || tomlinson@elec.canterbury.ac.nz and a job forever. ------------------------------------------------------------------------- From: spcecdt@deeptht.santa-cruz.ca.us (John DuBois) Subject: Re: ibm keyboard port specs wanted Date: 10 Nov 91 02:00:30 GMT Organization: The Armory In article <1991Oct16.181547.26705@mnemosyne.cs.du.edu> aduell@isis.cs.du.edu (Tony Duell) writes: +Anyway, here's what I have gathered from the IBM XT TechRef - I'll look +some more if no other sources are forthcoming +1) the 5 lines are +5V , ground, reset (not uised), clock, data +2) both clock and data are bi-directional, using open-collector buffers to +drive them +3) clock is normally driven by the keyboard. It is clamped low by the CPU +for 20ms to reset the keyboard processor +4) there are 8 data bits. +On reset, the keyboard sends AAh to the CPU. A diagnostic tester sends +something else 65h I think. + +Now for my questions : +a) does the keyboard send clock all the time, or a counted number of +pulses on sending a byte ? +b) what clock rate? +c) what pause between bytes? +d) any start/stop bits ? The only data I have left from hacking at my keyboard when it died a couple of years ago are some timing diagrams recorded from a 'scope (wretched ASCII graphics follow): __ _ _ _ _ _ _ _ | Clock / | / | / | / | / | / | / | (2 more) |_________/ |_____/ |_____/ |_____/ |_____/ |_____/ |_____/ |_____ |<- 36uS->|<-32uS->|12| 20 | | | | | | ___________________________________________________________________________ \ \ / \ / \ / \ / \ / \ / \ Data \ 0 X 1 X 2 X 3 X 4 X 5 X 6 \ \______/_\______/_\______/_\______/_\______/_\______/_\________\_ This is for an XT keyboard. The clock and data lines are both normally high. When a key is pressed, Clock goes low for 36uS. This is followed by 9 clock pulses, each 12.5uS low and 20uS high; on the 10th rising edge the clock stays high until the next sequence. The Data line changes on the rising edge of the clock. There are only 7 data bits (the last two bit times on the Data line are always low). The ~32uS clock period gives a ~31KHz bit rate. At least, this is how I interpret my drawings... John -- John DuBois spcecdt@deeptht.santa-cruz.ca.us KC6QKZ -- Tomi.Engdahl@hut.fi ! LOWERY'S LAW: then@niksula.hut.fi ! "If it jams - force it. If it breaks, ! it needed replacing anyway."