Loading ...
Sorry, an error occurred while loading the content.
 

Re: [SeattleRobotics] Keyboard scan codes

Expand Messages
  • Charles Thurston
    Hello Tom, Check Page 15 in the April 2006 Servo Magazine. I just read the article on doing this. ... -- Best regards, Charles
    Message 1 of 5 , Mar 31, 2006
      Hello Tom,

      Check Page 15 in the April 2006 Servo Magazine. I just read the
      article on doing this.

      Friday, March 31, 2006, 10:08:18 PM, you wrote:

      > Hi all,

      > I'm doing a project where I'm interfacing a PIC to a PC keyboard, as
      > well as emulating a keyboard on a PC's PS/2 port. Right now I just
      > got comms working between the PIC and the keyboard, I think. I'm
      > getting valid data, it's just that the bitstream as well as all the
      > keycodes are completely from all the standards that I've found online.
      > www.beyondlogic.org states that data from the keyboard comes as:

      --
      Best regards,
      Charles mailto:cthurston@...
    • Tom Capon
      Alas, I haven t subscribed yet!
      Message 2 of 5 , Apr 1, 2006
        Alas, I haven't subscribed yet!

        On 3/31/06, Charles Thurston <cthurston@...> wrote:
        > Hello Tom,
        >
        > Check Page 15 in the April 2006 Servo Magazine. I just read the
        > article on doing this.
        >
        > Friday, March 31, 2006, 10:08:18 PM, you wrote:
        >
        > > Hi all,
        >
        > > I'm doing a project where I'm interfacing a PIC to a PC keyboard, as
        > > well as emulating a keyboard on a PC's PS/2 port. Right now I just
        > > got comms working between the PIC and the keyboard, I think. I'm
        > > getting valid data, it's just that the bitstream as well as all the
        > > keycodes are completely from all the standards that I've found online.
        > > www.beyondlogic.org states that data from the keyboard comes as:
        >
        > --
        > Best regards,
        > Charles mailto:cthurston@...
        >
        >
        >
      • PeterBalch
        I asked a similar set of questions on another forum back in 1998. Below (in a fairly random order) is what I was told You probably have all this info already
        Message 3 of 5 , Apr 2, 2006
          I asked a similar set of questions on another forum back in 1998. Below (in
          a fairly random order) is what I was told

          You probably have all this info already but you never know ...

          It's a bit long so it might get chopped. I can send it to you personally if
          it does.

          Peter
          ===================================================

          Hi Everyone

          Does anyone know how the keyboard talks to the PC? I've been asked to
          design a replacement keyboard for a special job.

          So far, from some ancient XT circuit diagrams I reckon that the wires are
          power, ground, chassis ground, clock and data. There may be an extra Reset
          on some keyboards but I'm not sure if it's mandatory. Which are which on an
          XT and PS2 connector?

          Clock and data are open collector so either PC or kbd can send or receive.
          Both are normally high of course.

          When a key is pressed, eleven negative-going pulses are generated on clock.
          Some "data" is generated on data. I think I should read the data on the
          falling edge of clock but I'm not sure.

          And what are the eleven bits? They look like they might be Start=0, 8-data,
          odd-parity, stop=1.

          My old text book says "the keyboard sends a scan-code to the pc when the
          key is pressed and scan-code+128 when the key is released". But what I see
          using an oscilloscope doesn't seem to have the right bit values. They look
          more like 4-bit row and 4-bit col addresses. And key-up is $0F followed by
          the key-value.

          And what does the PC send to query kbd? The BIOS obviously sends something
          because my PC complains if I try to boot without a kbd plugged in.

          Any information will be gratefully receieved.

          Thanks.

          Peter


          ===================================================
          Bob

          I just re-read your message in more detail.

          > Also note that the keyboard always controls the clock line, regardless of
          the data direction.

          How does that work? How does the Keyboard know when to start clocking? Does
          it watch the PC pull the clock line low then take over? Or does the PC
          start by lowering the Data line? The book I found is a bit vague on the
          subject.

          Also, what happens after line contention? They both back off but what then
          - random wait time and try again? Or is there a special code transmitted?

          BTW, how come you know all this stuff? :-)


          Thanks

          Peter

          =======================================================
          Thanks Trevor

          I've just located a 1984 Technical Reference describing the AT keyboard.
          Some of it is a bit
          ambiguous but a few experiments and the web page you suggest might
          disambiguate things.

          It sure is complicated!

          Hopefully the web page will tell me whether the PS/2 keyboard differs.

          Peter
          ===========================================================
          Thanks Bob

          Who'd have thought there was an entire book on keyboards!

          It sure is complicated!

          I have managed to find a 1984 Technical Reference describing the AT
          keyboard. Some of it is a bit ambiguous but a few experiments might
          disambiguate things.

          It's good to know that the PS/2 is the same.

          Peter

          =============================================================
          Hi Brian

          Thank you for the data. It's very useful, where did you find it?

          It's more modern than any information I'd found so far - the best I could
          do was 1984!

          I've connected an old keyboard to my printer port and managed to talk to
          it. Next I'll try eavesdropping on a PC as it boots.

          Thanks

          Peter

          ==================================================================
          Don

          >>I think I have some specs for an AT keyboard out in the garage. IF you
          need them, I'll be happy to lend them to you. (If they really exist).<<

          Thanks.

          I've since found a book with a copy of the AT keyboard h/w design and a
          little about the inteface specification.

          Also I'm in Edinburgh, Scotland so it's probably a long way from your
          garage to here.

          My client is now worrying about the high price I've quoted him so the
          project is on hold. I'd originally been enthisiastic to him about how easy
          it would be - I'd guessed the kbd would use a simple serial interface.

          Why _do_ IBM have to overcomplicate everything?

          Peter




          ===========================================================================
          Bob

          Thanks. I think I now understand enough now to start doing some real
          experiments.

          >> BTW, how come you know all this stuff? :-) <<

          > PC joysticks. ... when they need to send a character, they gate the real
          keyboard offline

          So the real keyboard can repsond to many of the commands.

          I've been asked to put a barcode reader between the PC and the keyboard.
          (Yes, I know such things exist but they cost more than my client wants to
          pay and he's expecting to sell hundreds or, hopefully, thousands.)

          The problem is that he wants it to work whether the keyboard is there or
          not so I'll have to implement _all_ the keyboard commands. My worry is that
          if I get one wrong, the PC will simply say "Keyboard error" and give me no
          further clues.

          When the client saw how many zeroes I put in my cost estimate, he said he'd
          go away and think about it.

          > the 0x0F break you're seeing is probably just because the bits are
          backwards on a 'scope.

          Yes, that was it. I can now connect a kbd to my printer port and decode the
          keystrokes as they arrive.

          Thanks.

          Peter

          ===========================================================================
          ===========
          I have just found a 1984 Technical Reference describing the AT keyboard.
          Some of it is a bit ambiguous but a few experiments
          might disambiguate things.

          It sure is complicated!

          Does anyone know whether the PS/2 keyboard differs?

          Thanks

          Peter



          =========================================================================

          Hi,

          >> Does anyone know how the keyboard talks to the PC? <<

          Try http://www.holtek.com/docum/Computer/6542b.htm, there are data sheets
          explaining the protocol.

          -TrevK

          http://ourworld.compuserve.com/homepages/tkellaway/

          =========================================================================


          Hi Peter,

          Does anyone know how the keyboard talks to the PC? I've been asked to
          design a replacement keyboard for a special job.

          >> So far, from some ancient XT circuit diagrams I reckon that the wires
          are power, ground, chassis ground, clock and data.
          There may be an extra Reset on some keyboards but I'm not sure if it's
          mandatory. Which are which on an XT and PS2
          connector? <<

          That's pretty much it. The reset line should normally be grounded, I don't
          think there are many keyboards that actually respond to
          it. Also, be aware that XT keyboards only worked with XTs. The later AT
          keyboards wired somewhat differently and used
          different scancodes. Connections are:

          Pin AT PS/2
          1 Clock Data
          2. Data N/C
          3. N/C Signal Gnd
          4. Signal Gnd +5VDC
          5. +5VDC Clock
          6. N/C

          Also, the pins are in kind of a wierd arrangement, i.e. they aren't
          numbered in order as you go around the connector. The signals
          for a PS/2 and an AT keyboard are identical, it's just a different
          connector.

          >> Clock and data are open collector so either PC or kbd can send or
          receive. Both are normally high of course. <<

          Yes.

          >> When a key is pressed, eleven negative-going pulses are generated on
          clock. Some "data" is generated on data. I think I
          should read the data on the falling edge of clock but I'm not sure. <<

          Keyboard to PC, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and a
          Stop Bit (High). Data is valid on the falling edge of the
          clock.

          PC to Keyboard, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and
          and Acknowledge bit. Data is valid on the positive clock.
          The Ack bit is actually a tri-state from the PC, the Keyboard sends that so
          the PC knows it got the transfer. Also note that the
          keyboard always controls the clock line, regardless of the data direction.

          For the keyboard to send, both clock and data must be high at the
          beginning. The PC will pull the clock line low if it's busy, and
          will pull the data line low when it wants to send a command to the
          keyboard. Normally, if the PC sends a command (and there
          are several), the keyboard will acknowledge with an 0xfa byte.

          >> And what are the eleven bits? They look like they might be Start=0,
          8-data, odd-parity, stop=1. <<

          Yes.

          >> My old text book says "the keyboard sends a scan-code to the pc when the
          key is pressed and scan-code+128 when the key
          is released". But what I see using an oscilloscope doesn't seem to have the
          right bit values. They look more like 4-bit row and 4-
          bit col addresses. And key-up is $0F followed by the key-value. <<

          That correct, except the keyup code is 0xF0, not 0x0F. Also, there are some
          anomalies with the 'gray' cursor keys that showed
          up on the 101-key boards that through an 0xE0 into the mix. The
          'high-bit-set' code is what it looks like once it gets to the BIOS. I
          can send you a list of the raw keycodes if you like.

          >> And what does the PC send to query kbd? The BIOS obviously sends
          something because my PC complains if I try to boot
          without a kbd plugged in. <<

          The BIOS sends a reset command and expects a particular response, keyboard
          ID or something like that.

          The best book I've found on the subject is "PC Keyboard Design" by Gary J.
          Konzak. Published by Annabooks, ISBN 0-929392-
          12-4.

          Hope this helps!

          - Bob

          =========================================================================


          Bob

          I just re-read your message in more detail.

          > Also note that the keyboard always controls the clock line, regardless of
          the data direction.

          How does that work? How does the Keyboard know when to start clocking? Does
          it watch the PC pull the clock line low then
          take over? Or does the PC start by lowering the Data line?

          ALso, what happens after line contention? They both back off but what then
          - random wait time and try again?

          BTW how come you know all this stuff? :-)


          Thanks

          Peter

          =========================================================================


          8042 - Keyboard Controller (AT,PS/2)

          % 8042 Status Register (port 64h read)

          ³7³6³5³4³3³2³1³0³ 8042 Status Register
          ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ output register (60h) has data for system
          ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ input register (60h/64h) has data for 8042
          ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ system flag (set to 0 after power on reset)
          ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ data in input register is command (1) or data (0)
          ³ ³ ³ ÀÄÄÄÄÄÄÄÄ 1=keyboard enabled, 0=keyboard disabled (via
          switch)
          ³ ³ ÀÄÄÄÄÄÄÄÄÄ 1=transmit timeout (data transmit not complete)
          ³ ÀÄÄÄÄÄÄÄÄÄÄ 1=receive timeout (data transmit not complete)
          ÀÄÄÄÄÄÄÄÄÄÄÄ 1=even parity rec'd, 0=odd parity rec'd (should be
          odd)

          % Port Mode Description

          64h read 8042 status register. Can be read at any time. See
          table above for more information.
          64h write 8042 command register. Writing this port sets Bit 3
          of the status register to 1 and the byte is treated
          as a controller command. Devices attached to the
          8042 should be disabled before issuing commands that
          return data since data in the output register will
          be overwritten.
          60h read 8042 output register (should only be read if Bit 0 of
          status port is set to 1)
          60h write 8042 data register. Data should only be written if
          Bit 1 of the status register is zero (register is
          empty).
          When this port is written Bit 3 of the status register
          is set to zero and the byte is treated as a data. The
          8042 uses this byte if it's expecting data for a
          previous
          command, otherwise the data is written directly to the
          keyboard. See ~KEYBOARD COMMANDS~ for information on
          programming the actual keyboard hardware.


          8042 Commands Related to PC Systems (Port 64h)

          % Command Description

          20 Read 8042 Command Byte: current 8042 command byte is placed
          in port 60h.
          60 Write 8042 Command Byte: next data byte written to port 60h
          is
          placed in 8042 command register. Format:

          ³7³6³5³4³3³2³1³0³ 8042 Command Byte
          ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ 1=enable output register full interrupt
          ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ should be 0
          ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ 1=set status register system, 0=clear
          ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ 1=override keyboard inhibit, 0=allow inhibit
          ³ ³ ³ ÀÄÄÄÄÄÄÄÄ disable keyboard I/O by driving clock line
          low
          ³ ³ ÀÄÄÄÄÄÄÄÄÄ disable auxiliary device, drives clock line
          low
          ³ ÀÄÄÄÄÄÄÄÄÄÄ IBM scancode translation 0=AT, 1=PC/XT
          ÀÄÄÄÄÄÄÄÄÄÄÄ reserved, should be 0

          A4 Password Installed Test: returned data can be read
          from port 60h; FA=password installed, F1=no password
          A5 Load Security: bytes written to port 60h will be read
          until a null (0) is found.
          A6 Enable Security: works only if a password is already loaded
          A7 Disable Auxiliary Interface: sets Bit 5 of command register
          stopping auxiliary I/O by driving the clock line low
          A8 Enable Auxiliary Interface: clears Bit 5 of command register
          A9 Auxiliary Interface Test: clock and data lines are tested;
          results placed at port 60h are listed below:

          00 no error
          01 keyboard clock line is stuck low
          02 keyboard clock line is stuck high
          03 keyboard data line is stuck low
          04 keyboard data line is stuck high

          AA Self Test: diagnostic result placed at port 60h, 55h=OK
          AB Keyboard Interface Test: clock and data lines are tested;
          results placed at port 60h are listed above with command A9
          AC Diagnostic Dump: sends 16 bytes of 8042's RAM, current input
          port state, current output port state and 8042 program status
          word to port 60h in scan-code format.
          AD Disable Keyboard Interface: sets Bit 4 of command register
          stopping keyboard I/O by driving the clock line low
          AE Enable Keyboard Interface: clears Bit 4 of command register
          enabling keyboard interface.
          C0 Read Input Port: data is read from its input port (which is
          inaccessible to the data bus) and written to output register
          at port 60h; output register should be empty before call.

          ³7³6³5³4³3-0³ 8042 Input Port
          ³ ³ ³ ³ ÀÄÄÄÄ undefined
          ³ ³ ³ ÀÄÄÄÄÄ 1=enable 2nd 256K of motherboard RAM,
          0=disable
          ³ ³ ÀÄÄÄÄÄÄ 1=manufacturing jumper not installed,
          0=installed
          ³ ÀÄÄÄÄÄÄÄ 1=primary display is MDA, 0=primary display is
          CGA
          ÀÄÄÄÄÄÄÄÄ 1=keyboard not inhibited, 0=keyboard inhibited

          C1 Poll Input Port Low Bits: Bits 0-3 of port 1 placed in
          status Bits 4-7
          C2 Poll Input Port High Bits: Bits 4-7 of port 1 placed in
          status Bits 4-7
          D0 Read Output Port: data is read from 8042 output port (which
          is
          inaccessible to the data bus) and placed in output register;
          the output register should be empty. (see command D1 below)
          D1 Write Output Port: next byte written to port 60h is placed in
          the 8042 output port (which is inaccessible to the data bus)

          ³7³6³5³4³3³2³1³0³ 8042 Output Port
          ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ system reset line
          ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ gate A20
          ³ ³ ³ ³ ÀÄÁÄÄÄÄÄÄ undefined
          ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄ output buffer full
          ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ input buffer empty
          ³ ÀÄÄÄÄÄÄÄÄÄÄÄ keyboard clock (output)
          ÀÄÄÄÄÄÄÄÄÄÄÄÄ keyboard data (output)

          D2 Write Keyboard Output Register: on PS/2 systems the next data
          byte written to port 60h input register is written to port
          60h
          output register as if initiated by a device; invokes
          interrupt
          if enabled
          D3 Write Auxiliary Output Register: on PS/2 systems the next
          data
          byte written to port 60h input register is written to port
          60h
          output register as if initiated by a device; invokes
          interrupt
          if enabled
          D4 Write Auxiliary Device: on PS/2 systems the next data byte
          written to input register a port at 60h is sent to the
          auxiliary device
          E0 Read Test Inputs: 8042 reads its T0 and T1 inputs; data is
          placed in output register; Bit 0 is T0, Bit 1 is T1:

          ³1³0³ Test Input Port Bits
          ³ ÀÄÄÄÄ keyboard clock
          ÀÄÄÄÄÄ keyboard data

          Fx Pulse Output Port: Bits 0-3 of the 8042 output port can be
          pulsed low for 6 æs; Bits 0-3 of command indicate which
          Bits should be pulsed; 0=pulse, 1=don't pulse; pulsing
          Bit 0 results in CPU reset since it is connected to system
          reset line.

          - PC systems previous to the AT use the 8255 PPI as a keyboard
          controller and use the keyboard's internal 8048.
          - the keyboard's internal controller buffers up to 16 bytes of
          make/break code information. This is common among all PC systems
          and shouldn't be confused with the (32 byte) keyboard buffer
          maintained by the BIOS.
          - see ~KEYBOARD COMMANDS~ for information on programming the
          keyboards internal microprocessor











          Keyboard Commands & Responses

          Commands System Issues to Keyboard (via 8042 port 60h)

          ED Set/Reset Mode Indicators, keyboard responds with ACK then
          waits for a following option byte. When the option byte is
          received the keyboard again ACK's and then sets the LED's
          accordingly. Scanning is resumed if scanning was enabled.
          If another command is received instead of the option byte
          (high bit set on) this command is terminated. Hardware
          defaults to these indicators turned off.

          ³7-3³2³1³0³ Keyboard Status Indicator Option Byte
          ³ ³ ³ ÀÄÄÄ Scroll-Lock indicator (0=off, 1=on)
          ³ ³ ÀÄÄÄÄ Num-Lock indicator (0=off, 1=on)
          ³ ÀÄÄÄÄÄ Caps-Lock indicator (0=off, 1=on)
          ÀÄÄÄÄÄÄÄ reserved (must be zero)

          EE Diagnostic Echo, keyboard echoes the EE byte back to the system
          without an acknowledgement.
          F0 PS/2 Select/Read Alternate Scan Code Sets, instructs keyboard
          to use one of the three make/break scan code sets. Keyboard
          responds by clearing the output buffer/typematic key and then
          transmits an ACK. The system must follow up by sending an
          option byte which will again be ACK'ed by the keyboard:

          00 return byte indicating scan code set in use
          01 select scan code set 1 (used on PC & XT)
          02 select scan code set 2
          03 select scan code set 3

          F2 PS/2 Read Keyboard ID, keyboard responds with an ACK and a two
          byte keyboard ID of 83AB.
          F3 Set Typematic Rate/Delay, keyboard responds with ACK and waits
          for rate/delay byte. Upon receipt of the rate/delay byte the
          keyboard responds with an ACK, then sets the new typematic
          values and scanning continues if scanning was enabled.

          ³7³6³5³4³3³2³1³0³ Typematic Rate/Delay Option Byte
          ³ ³ ³ ÃÄÅÄÅÄÅÄÅÄÄÄÄ typematic rate indicator (see ~INT 16,3~)
          ³ ³ ³ ³ ³ ÀÄÁÄÁÄÄÄ A in period formula (see below)
          ³ ³ ³ ÀÄÁÄÄÄÄÄÄÄÄ B is period formula (see below)
          ³ ÀÄÁÄÄÄÄÄÄÄÄÄÄÄ typematic delay
          ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ always zero

          delay = (rate+1) * 250 (in milliseconds)
          rate = (8+A) * (2**B) * 4.17 (in seconds, ñ 20%)

          Defaults to 10.9 characters per second and a 500ms delay. If a
          command byte (byte with high bit set) is received instead of an
          option byte this command is cancelled.
          F4 Enable Keyboard, cause the keyboard to clear its output buffer
          and last typematic key and then respond with an ACK. The
          keyboard then begins scanning.
          F5 Default w/Disable, resets keyboard to power-on condition by
          clearing the output buffer, resetting typematic rate/delay,
          resetting last typematic key and setting default key types.
          The keyboard responds with an ACK and waits for the next
          instruction.
          F6 Set Default, resets to power-on condition by clearing the
          output
          buffer, resetting typematic rate/delay and last typematic key
          and sets default key types. The keyboard responds with an ACK
          and continues scanning.
          F7 PS/2 Set All Keys to Typematic, keyboard responds by sending an
          ACK, clearing its output buffer and setting the key type to
          Typematic. Scanning continues if scanning was enabled. This
          command may be sent while using any Scan Code Set but only has
          effect when Scan Code Set 3 is in use.
          F8 PS/2 Set All Keys to Make/Break, keyboard responds by sending
          an
          ACK, clearing its output buffer and setting the key type to
          Make/Break. Scanning continues if scanning was enabled. This
          command may be sent while using any Scan Code Set but only has
          effect when Scan Code Set 3 is in use.
          F9 PS/2 Set All Keys to Make, keyboard responds by sending an ACK,
          clearing its output buffer and setting the key type to Make.
          Scanning continues if scanning was enabled. This command may
          be sent while using any Scan Code Set but only has effect when
          Scan Code Set 3 is in use.
          FA PS/2 Set All Keys to Typematic Make/Break, keyboard responds by
          sending an ACK, clearing its output buffer and setting the key
          type to Typematic Make/Break. Scanning continues if scanning
          was enabled. This command may be sent while using any Scan
          Code
          Set but only has effect when Scan Code Set 3 is in use.
          FB PS/2 Set Key Type to Typematic, keyboard responds by sending an
          ACK, clearing its output buffer and then waiting for the key ID
          (make code from Scan Code Set 3). The specified key type is
          then
          set to typematic. This command may be sent while using any
          Scan Code Set but only has effect when Scan Code Set 3 is in
          use.
          FC PS/2 Set Key Type to Make/Break, keyboard responds by sending
          an
          ACK, clearing its output buffer and then waiting for the key ID
          (make code from Scan Code Set 3). The specified key type is
          then
          set to Make/Break. This command may be sent while using any
          Scan
          Code Set but only has effect when Scan Code Set 3 is in use.
          FD PS/2 Set Key Type to Make, keyboard responds by sending an ACK,
          clearing its output buffer and then waiting for the key ID
          (make
          code from Scan Code Set 3). The specified key type is then set
          to Make. This command may be sent while using any Scan Code
          Set
          but only has effect when Scan Code Set 3 is in use.
          FE Resend, should be sent when a transmission error is detected
          from the keyboard
          FF Reset, Keyboard sends ACK and waits for system to receive it
          then begins a program reset and Basic Assurance Test (BAT).
          Keyboard returns a one byte completion code then sets default
          Scan Code Set 2.


          Keyboard Responses to System (via 8042 port 60h)

          00 Key Detection Error or Overrun Error for Scan Code Set 1,
          replaces last key in the keyboard buffer if the buffer is full.
          AA BAT Completion Code, keyboard sends this to indicate the
          keyboard
          test was successful.
          EE Echo Response, response to the Echo command.
          F0 Break Code Prefix in Scan Code Sets 2 and 3.
          FA Acknowledge, keyboard sends this whenever a valid command or
          data byte is received (except on Echo and Resend commands).
          FC BAT Failure Code, keyboard sends this to indicate the keyboard
          test failed and stops scanning until a response or reset is
          sent.
          FE Resend, keyboard request resend of data when data sent to it is
          invalid or arrives with invalid parity.
          FF Key Detection Error or Overrun Error for Scan Code Set 2 or 3,
          replaces last key in the keyboard buffer if the buffer is full.
          id Keyboard ID Response, keyboard sends a two byte ID after
          ACK'ing
          the Read ID command. The byte stream contains 83AB in LSB, MSB
          order. The keyboard then resumes scanning.

          - command F7 through FD are NOP's on the AT and are ACK'ed but not
          acted upon


          =========================================================================
          Hi Paul,

          >> How does that work? How does the Keyboard know when to start clocking?
          Does it watch the PC pull the clock line low then
          take over? Or does the PC start by lowering the Data line? The book I found
          is a bit vague on the subject. <<

          For a PC->Keyboard transfer, the keyboard watches for the PC (actually the
          8042 in the PC) to pull the Data Line low while the
          clock line is high. The PC just waits at that point for the Keyboard to
          start clocking, then sends out the data.

          For a Keyboard->PC transfer, the keyboard just checks that both clock and
          data are high, then starts transmitting. During
          periods when the PC can't respond, it will hold the clock low and that
          stops the keyboard from beginning a transmission.

          >> Also, what happens after line contention? They both back off but what
          then - random wait time and try again? Or is there a
          special code transmitted? <<

          As I mentioned above, the PC holds the clock line low if it can't respond
          to the keyboard for some reason, maybe servicing a
          PS2 mouse or whatever. The Keyboard is supposed to check each time it
          releases the clock line to supply a high clock (up to
          the tenth bit, I think). If the PC has started doing
          something else, it will clamp the clock to ground and the keyboard can see
          that
          it doesn't float high when released. In that case, the keyboard aborts the
          transmission. Also, if either end detects a character
          error or illegal command, it can request a resend. The keyboard does that
          in place of the ACK that it normally sends when it
          receives a command. The PC can do it anytime it gets a garbled character.

          >> BTW, how come you know all this stuff? :-) <<

          I spent about 4 years designing circuits and coding microchips for
          programmable PC joysticks. They connect between the PC
          and the keyboard, when they need to send a character, they gate the real
          keyboard offline and control the clock/data lines
          themselves to generate the characters, then reconnect the keyboard. The
          also downloaded the stick program through the
          keyboard port (there's some real fun<g>). Anyway, I got to know the AT/PS2
          keyboard interface pretty well.

          BTW, it occurred to me that the 0x0F break you're seeing is probably just
          because the bits are backwards on a 'scope. It sends
          things LSB first.

          - Bob

          =========================================================================

          Check the book "the Indispensable PC Hardware Book" by Messmer. ISBN
          0-201-40399-4.

          =========================================================================
          >>Hopefully the web page will tell me whether the PS/2 keyboard differs.

          Winn Rosch's Hardware bible lists the PS/2 connector as:
          Pin Description Direction
          1 Data In
          2 Reserved N/A
          3 Ground N/A
          4 +5v Out
          6 Reserved N/A
          Shield Ground N/A

          |<---Notch
          ^
          5 6
          3 4
          1 2
        • Ed Okerson
          An excellent reference on everything keyboard related: http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html See section 11.3 Keyboard Controller Commands to see
          Message 4 of 5 , Apr 2, 2006
            An excellent reference on everything keyboard related:

            http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

            See section 11.3 Keyboard Controller Commands to see how the PC reads the
            keyboard and tells it to self test, etc.

            Ed Okerson

            > I asked a similar set of questions on another forum back in 1998. Below
            > (in
            > a fairly random order) is what I was told
            >
            > You probably have all this info already but you never know ...
            >
            > It's a bit long so it might get chopped. I can send it to you personally
            > if
            > it does.
            >
            > Peter
            > ===================================================
            >
            > Hi Everyone
            >
            > Does anyone know how the keyboard talks to the PC? I've been asked to
            > design a replacement keyboard for a special job.
            >
            > So far, from some ancient XT circuit diagrams I reckon that the wires are
            > power, ground, chassis ground, clock and data. There may be an extra Reset
            > on some keyboards but I'm not sure if it's mandatory. Which are which on
            > an
            > XT and PS2 connector?
            >
            > Clock and data are open collector so either PC or kbd can send or receive.
            > Both are normally high of course.
            >
            > When a key is pressed, eleven negative-going pulses are generated on
            > clock.
            > Some "data" is generated on data. I think I should read the data on the
            > falling edge of clock but I'm not sure.
            >
            > And what are the eleven bits? They look like they might be Start=0,
            > 8-data,
            > odd-parity, stop=1.
            >
            > My old text book says "the keyboard sends a scan-code to the pc when the
            > key is pressed and scan-code+128 when the key is released". But what I see
            > using an oscilloscope doesn't seem to have the right bit values. They look
            > more like 4-bit row and 4-bit col addresses. And key-up is $0F followed by
            > the key-value.
            >
            > And what does the PC send to query kbd? The BIOS obviously sends something
            > because my PC complains if I try to boot without a kbd plugged in.
            >
            > Any information will be gratefully receieved.
            >
            > Thanks.
            >
            > Peter
            >
            >
            > ===================================================
            > Bob
            >
            > I just re-read your message in more detail.
            >
            >> Also note that the keyboard always controls the clock line, regardless
            >> of
            > the data direction.
            >
            > How does that work? How does the Keyboard know when to start clocking?
            > Does
            > it watch the PC pull the clock line low then take over? Or does the PC
            > start by lowering the Data line? The book I found is a bit vague on the
            > subject.
            >
            > Also, what happens after line contention? They both back off but what then
            > - random wait time and try again? Or is there a special code transmitted?
            >
            > BTW, how come you know all this stuff? :-)
            >
            >
            > Thanks
            >
            > Peter
            >
            > =======================================================
            > Thanks Trevor
            >
            > I've just located a 1984 Technical Reference describing the AT keyboard.
            > Some of it is a bit
            > ambiguous but a few experiments and the web page you suggest might
            > disambiguate things.
            >
            > It sure is complicated!
            >
            > Hopefully the web page will tell me whether the PS/2 keyboard differs.
            >
            > Peter
            > ===========================================================
            > Thanks Bob
            >
            > Who'd have thought there was an entire book on keyboards!
            >
            > It sure is complicated!
            >
            > I have managed to find a 1984 Technical Reference describing the AT
            > keyboard. Some of it is a bit ambiguous but a few experiments might
            > disambiguate things.
            >
            > It's good to know that the PS/2 is the same.
            >
            > Peter
            >
            > =============================================================
            > Hi Brian
            >
            > Thank you for the data. It's very useful, where did you find it?
            >
            > It's more modern than any information I'd found so far - the best I could
            > do was 1984!
            >
            > I've connected an old keyboard to my printer port and managed to talk to
            > it. Next I'll try eavesdropping on a PC as it boots.
            >
            > Thanks
            >
            > Peter
            >
            > ==================================================================
            > Don
            >
            >>>I think I have some specs for an AT keyboard out in the garage. IF you
            > need them, I'll be happy to lend them to you. (If they really exist).<<
            >
            > Thanks.
            >
            > I've since found a book with a copy of the AT keyboard h/w design and a
            > little about the inteface specification.
            >
            > Also I'm in Edinburgh, Scotland so it's probably a long way from your
            > garage to here.
            >
            > My client is now worrying about the high price I've quoted him so the
            > project is on hold. I'd originally been enthisiastic to him about how easy
            > it would be - I'd guessed the kbd would use a simple serial interface.
            >
            > Why _do_ IBM have to overcomplicate everything?
            >
            > Peter
            >
            >
            >
            >
            > ===========================================================================
            > Bob
            >
            > Thanks. I think I now understand enough now to start doing some real
            > experiments.
            >
            >>> BTW, how come you know all this stuff? :-) <<
            >
            >> PC joysticks. ... when they need to send a character, they gate the real
            > keyboard offline
            >
            > So the real keyboard can repsond to many of the commands.
            >
            > I've been asked to put a barcode reader between the PC and the keyboard.
            > (Yes, I know such things exist but they cost more than my client wants to
            > pay and he's expecting to sell hundreds or, hopefully, thousands.)
            >
            > The problem is that he wants it to work whether the keyboard is there or
            > not so I'll have to implement _all_ the keyboard commands. My worry is
            > that
            > if I get one wrong, the PC will simply say "Keyboard error" and give me no
            > further clues.
            >
            > When the client saw how many zeroes I put in my cost estimate, he said
            > he'd
            > go away and think about it.
            >
            >> the 0x0F break you're seeing is probably just because the bits are
            > backwards on a 'scope.
            >
            > Yes, that was it. I can now connect a kbd to my printer port and decode
            > the
            > keystrokes as they arrive.
            >
            > Thanks.
            >
            > Peter
            >
            > ===========================================================================
            > ===========
            > I have just found a 1984 Technical Reference describing the AT keyboard.
            > Some of it is a bit ambiguous but a few experiments
            > might disambiguate things.
            >
            > It sure is complicated!
            >
            > Does anyone know whether the PS/2 keyboard differs?
            >
            > Thanks
            >
            > Peter
            >
            >
            >
            > =========================================================================
            >
            > Hi,
            >
            >>> Does anyone know how the keyboard talks to the PC? <<
            >
            > Try http://www.holtek.com/docum/Computer/6542b.htm, there are data sheets
            > explaining the protocol.
            >
            > -TrevK
            >
            > http://ourworld.compuserve.com/homepages/tkellaway/
            >
            > =========================================================================
            >
            >
            > Hi Peter,
            >
            > Does anyone know how the keyboard talks to the PC? I've been asked to
            > design a replacement keyboard for a special job.
            >
            >>> So far, from some ancient XT circuit diagrams I reckon that the wires
            > are power, ground, chassis ground, clock and data.
            > There may be an extra Reset on some keyboards but I'm not sure if it's
            > mandatory. Which are which on an XT and PS2
            > connector? <<
            >
            > That's pretty much it. The reset line should normally be grounded, I don't
            > think there are many keyboards that actually respond to
            > it. Also, be aware that XT keyboards only worked with XTs. The later AT
            > keyboards wired somewhat differently and used
            > different scancodes. Connections are:
            >
            > Pin AT PS/2
            > 1 Clock Data
            > 2. Data N/C
            > 3. N/C Signal Gnd
            > 4. Signal Gnd +5VDC
            > 5. +5VDC Clock
            > 6. N/C
            >
            > Also, the pins are in kind of a wierd arrangement, i.e. they aren't
            > numbered in order as you go around the connector. The signals
            > for a PS/2 and an AT keyboard are identical, it's just a different
            > connector.
            >
            >>> Clock and data are open collector so either PC or kbd can send or
            > receive. Both are normally high of course. <<
            >
            > Yes.
            >
            >>> When a key is pressed, eleven negative-going pulses are generated on
            > clock. Some "data" is generated on data. I think I
            > should read the data on the falling edge of clock but I'm not sure. <<
            >
            > Keyboard to PC, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and a
            > Stop Bit (High). Data is valid on the falling edge of the
            > clock.
            >
            > PC to Keyboard, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and
            > and Acknowledge bit. Data is valid on the positive clock.
            > The Ack bit is actually a tri-state from the PC, the Keyboard sends that
            > so
            > the PC knows it got the transfer. Also note that the
            > keyboard always controls the clock line, regardless of the data direction.
            >
            > For the keyboard to send, both clock and data must be high at the
            > beginning. The PC will pull the clock line low if it's busy, and
            > will pull the data line low when it wants to send a command to the
            > keyboard. Normally, if the PC sends a command (and there
            > are several), the keyboard will acknowledge with an 0xfa byte.
            >
            >>> And what are the eleven bits? They look like they might be Start=0,
            > 8-data, odd-parity, stop=1. <<
            >
            > Yes.
            >
            >>> My old text book says "the keyboard sends a scan-code to the pc when
            >>> the
            > key is pressed and scan-code+128 when the key
            > is released". But what I see using an oscilloscope doesn't seem to have
            > the
            > right bit values. They look more like 4-bit row and 4-
            > bit col addresses. And key-up is $0F followed by the key-value. <<
            >
            > That correct, except the keyup code is 0xF0, not 0x0F. Also, there are
            > some
            > anomalies with the 'gray' cursor keys that showed
            > up on the 101-key boards that through an 0xE0 into the mix. The
            > 'high-bit-set' code is what it looks like once it gets to the BIOS. I
            > can send you a list of the raw keycodes if you like.
            >
            >>> And what does the PC send to query kbd? The BIOS obviously sends
            > something because my PC complains if I try to boot
            > without a kbd plugged in. <<
            >
            > The BIOS sends a reset command and expects a particular response, keyboard
            > ID or something like that.
            >
            > The best book I've found on the subject is "PC Keyboard Design" by Gary J.
            > Konzak. Published by Annabooks, ISBN 0-929392-
            > 12-4.
            >
            > Hope this helps!
            >
            > - Bob
            >
            > =========================================================================
            >
            >
            > Bob
            >
            > I just re-read your message in more detail.
            >
            >> Also note that the keyboard always controls the clock line, regardless
            >> of
            > the data direction.
            >
            > How does that work? How does the Keyboard know when to start clocking?
            > Does
            > it watch the PC pull the clock line low then
            > take over? Or does the PC start by lowering the Data line?
            >
            > ALso, what happens after line contention? They both back off but what then
            > - random wait time and try again?
            >
            > BTW how come you know all this stuff? :-)
            >
            >
            > Thanks
            >
            > Peter
            >
            > =========================================================================
            >
            >
            > 8042 - Keyboard Controller (AT,PS/2)
            >
            > % 8042 Status Register (port 64h read)
            >
            > ³7³6³5³4³3³2³1³0³ 8042 Status Register
            > ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ output register (60h) has data for system
            > ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ input register (60h/64h) has data for 8042
            > ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ system flag (set to 0 after power on reset)
            > ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ data in input register is command (1) or data
            > (0)
            > ³ ³ ³ ÀÄÄÄÄÄÄÄÄ 1=keyboard enabled, 0=keyboard disabled (via
            > switch)
            > ³ ³ ÀÄÄÄÄÄÄÄÄÄ 1=transmit timeout (data transmit not complete)
            > ³ ÀÄÄÄÄÄÄÄÄÄÄ 1=receive timeout (data transmit not complete)
            > ÀÄÄÄÄÄÄÄÄÄÄÄ 1=even parity rec'd, 0=odd parity rec'd (should be
            > odd)
            >
            > % Port Mode Description
            >
            > 64h read 8042 status register. Can be read at any time. See
            > table above for more information.
            > 64h write 8042 command register. Writing this port sets Bit 3
            > of the status register to 1 and the byte is treated
            > as a controller command. Devices attached to the
            > 8042 should be disabled before issuing commands that
            > return data since data in the output register will
            > be overwritten.
            > 60h read 8042 output register (should only be read if Bit 0 of
            > status port is set to 1)
            > 60h write 8042 data register. Data should only be written if
            > Bit 1 of the status register is zero (register is
            > empty).
            > When this port is written Bit 3 of the status register
            > is set to zero and the byte is treated as a data. The
            > 8042 uses this byte if it's expecting data for a
            > previous
            > command, otherwise the data is written directly to the
            > keyboard. See ~KEYBOARD COMMANDS~ for information on
            > programming the actual keyboard hardware.
            >
            >
            > 8042 Commands Related to PC Systems (Port 64h)
            >
            > % Command Description
            >
            > 20 Read 8042 Command Byte: current 8042 command byte is placed
            > in port 60h.
            > 60 Write 8042 Command Byte: next data byte written to port 60h
            > is
            > placed in 8042 command register. Format:
            >
            > ³7³6³5³4³3³2³1³0³ 8042 Command Byte
            > ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ 1=enable output register full interrupt
            > ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ should be 0
            > ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ 1=set status register system, 0=clear
            > ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ 1=override keyboard inhibit, 0=allow
            > inhibit
            > ³ ³ ³ ÀÄÄÄÄÄÄÄÄ disable keyboard I/O by driving clock line
            > low
            > ³ ³ ÀÄÄÄÄÄÄÄÄÄ disable auxiliary device, drives clock line
            > low
            > ³ ÀÄÄÄÄÄÄÄÄÄÄ IBM scancode translation 0=AT, 1=PC/XT
            > ÀÄÄÄÄÄÄÄÄÄÄÄ reserved, should be 0
            >
            > A4 Password Installed Test: returned data can be read
            > from port 60h; FA=password installed, F1=no password
            > A5 Load Security: bytes written to port 60h will be read
            > until a null (0) is found.
            > A6 Enable Security: works only if a password is already loaded
            > A7 Disable Auxiliary Interface: sets Bit 5 of command register
            > stopping auxiliary I/O by driving the clock line low
            > A8 Enable Auxiliary Interface: clears Bit 5 of command register
            > A9 Auxiliary Interface Test: clock and data lines are tested;
            > results placed at port 60h are listed below:
            >
            > 00 no error
            > 01 keyboard clock line is stuck low
            > 02 keyboard clock line is stuck high
            > 03 keyboard data line is stuck low
            > 04 keyboard data line is stuck high
            >
            > AA Self Test: diagnostic result placed at port 60h, 55h=OK
            > AB Keyboard Interface Test: clock and data lines are tested;
            > results placed at port 60h are listed above with command A9
            > AC Diagnostic Dump: sends 16 bytes of 8042's RAM, current input
            > port state, current output port state and 8042 program
            > status
            > word to port 60h in scan-code format.
            > AD Disable Keyboard Interface: sets Bit 4 of command register
            > stopping keyboard I/O by driving the clock line low
            > AE Enable Keyboard Interface: clears Bit 4 of command register
            > enabling keyboard interface.
            > C0 Read Input Port: data is read from its input port (which is
            > inaccessible to the data bus) and written to output register
            > at port 60h; output register should be empty before call.
            >
            > ³7³6³5³4³3-0³ 8042 Input Port
            > ³ ³ ³ ³ ÀÄÄÄÄ undefined
            > ³ ³ ³ ÀÄÄÄÄÄ 1=enable 2nd 256K of motherboard RAM,
            > 0=disable
            > ³ ³ ÀÄÄÄÄÄÄ 1=manufacturing jumper not installed,
            > 0=installed
            > ³ ÀÄÄÄÄÄÄÄ 1=primary display is MDA, 0=primary display is
            > CGA
            > ÀÄÄÄÄÄÄÄÄ 1=keyboard not inhibited, 0=keyboard inhibited
            >
            > C1 Poll Input Port Low Bits: Bits 0-3 of port 1 placed in
            > status Bits 4-7
            > C2 Poll Input Port High Bits: Bits 4-7 of port 1 placed in
            > status Bits 4-7
            > D0 Read Output Port: data is read from 8042 output port (which
            > is
            > inaccessible to the data bus) and placed in output register;
            > the output register should be empty. (see command D1 below)
            > D1 Write Output Port: next byte written to port 60h is placed
            > in
            > the 8042 output port (which is inaccessible to the data bus)
            >
            > ³7³6³5³4³3³2³1³0³ 8042 Output Port
            > ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ system reset line
            > ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ gate A20
            > ³ ³ ³ ³ ÀÄÁÄÄÄÄÄÄ undefined
            > ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄ output buffer full
            > ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ input buffer empty
            > ³ ÀÄÄÄÄÄÄÄÄÄÄÄ keyboard clock (output)
            > ÀÄÄÄÄÄÄÄÄÄÄÄÄ keyboard data (output)
            >
            > D2 Write Keyboard Output Register: on PS/2 systems the next
            > data
            > byte written to port 60h input register is written to port
            > 60h
            > output register as if initiated by a device; invokes
            > interrupt
            > if enabled
            > D3 Write Auxiliary Output Register: on PS/2 systems the next
            > data
            > byte written to port 60h input register is written to port
            > 60h
            > output register as if initiated by a device; invokes
            > interrupt
            > if enabled
            > D4 Write Auxiliary Device: on PS/2 systems the next data byte
            > written to input register a port at 60h is sent to the
            > auxiliary device
            > E0 Read Test Inputs: 8042 reads its T0 and T1 inputs; data is
            > placed in output register; Bit 0 is T0, Bit 1 is T1:
            >
            > ³1³0³ Test Input Port Bits
            > ³ ÀÄÄÄÄ keyboard clock
            > ÀÄÄÄÄÄ keyboard data
            >
            > Fx Pulse Output Port: Bits 0-3 of the 8042 output port can be
            > pulsed low for 6 æs; Bits 0-3 of command indicate which
            > Bits should be pulsed; 0=pulse, 1=don't pulse; pulsing
            > Bit 0 results in CPU reset since it is connected to system
            > reset line.
            >
            > - PC systems previous to the AT use the 8255 PPI as a keyboard
            > controller and use the keyboard's internal 8048.
            > - the keyboard's internal controller buffers up to 16 bytes of
            > make/break code information. This is common among all PC
            > systems
            > and shouldn't be confused with the (32 byte) keyboard buffer
            > maintained by the BIOS.
            > - see ~KEYBOARD COMMANDS~ for information on programming the
            > keyboards internal microprocessor
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            > Keyboard Commands & Responses
            >
            > Commands System Issues to Keyboard (via 8042 port 60h)
            >
            > ED Set/Reset Mode Indicators, keyboard responds with ACK then
            > waits for a following option byte. When the option byte is
            > received the keyboard again ACK's and then sets the LED's
            > accordingly. Scanning is resumed if scanning was enabled.
            > If another command is received instead of the option byte
            > (high bit set on) this command is terminated. Hardware
            > defaults to these indicators turned off.
            >
            > ³7-3³2³1³0³ Keyboard Status Indicator Option Byte
            > ³ ³ ³ ÀÄÄÄ Scroll-Lock indicator (0=off, 1=on)
            > ³ ³ ÀÄÄÄÄ Num-Lock indicator (0=off, 1=on)
            > ³ ÀÄÄÄÄÄ Caps-Lock indicator (0=off, 1=on)
            > ÀÄÄÄÄÄÄÄ reserved (must be zero)
            >
            > EE Diagnostic Echo, keyboard echoes the EE byte back to the
            > system
            > without an acknowledgement.
            > F0 PS/2 Select/Read Alternate Scan Code Sets, instructs keyboard
            > to use one of the three make/break scan code sets. Keyboard
            > responds by clearing the output buffer/typematic key and then
            > transmits an ACK. The system must follow up by sending an
            > option byte which will again be ACK'ed by the keyboard:
            >
            > 00 return byte indicating scan code set in use
            > 01 select scan code set 1 (used on PC & XT)
            > 02 select scan code set 2
            > 03 select scan code set 3
            >
            > F2 PS/2 Read Keyboard ID, keyboard responds with an ACK and a two
            > byte keyboard ID of 83AB.
            > F3 Set Typematic Rate/Delay, keyboard responds with ACK and waits
            > for rate/delay byte. Upon receipt of the rate/delay byte the
            > keyboard responds with an ACK, then sets the new typematic
            > values and scanning continues if scanning was enabled.
            >
            > ³7³6³5³4³3³2³1³0³ Typematic Rate/Delay Option Byte
            > ³ ³ ³ ÃÄÅÄÅÄÅÄÅÄÄÄÄ typematic rate indicator (see ~INT 16,3~)
            > ³ ³ ³ ³ ³ ÀÄÁÄÁÄÄÄ A in period formula (see below)
            > ³ ³ ³ ÀÄÁÄÄÄÄÄÄÄÄ B is period formula (see below)
            > ³ ÀÄÁÄÄÄÄÄÄÄÄÄÄÄ typematic delay
            > ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ always zero
            >
            > delay = (rate+1) * 250 (in milliseconds)
            > rate = (8+A) * (2**B) * 4.17 (in seconds, ñ 20%)
            >
            > Defaults to 10.9 characters per second and a 500ms delay. If
            > a
            > command byte (byte with high bit set) is received instead of
            > an
            > option byte this command is cancelled.
            > F4 Enable Keyboard, cause the keyboard to clear its output buffer
            > and last typematic key and then respond with an ACK. The
            > keyboard then begins scanning.
            > F5 Default w/Disable, resets keyboard to power-on condition by
            > clearing the output buffer, resetting typematic rate/delay,
            > resetting last typematic key and setting default key types.
            > The keyboard responds with an ACK and waits for the next
            > instruction.
            > F6 Set Default, resets to power-on condition by clearing the
            > output
            > buffer, resetting typematic rate/delay and last typematic key
            > and sets default key types. The keyboard responds with an ACK
            > and continues scanning.
            > F7 PS/2 Set All Keys to Typematic, keyboard responds by sending
            > an
            > ACK, clearing its output buffer and setting the key type to
            > Typematic. Scanning continues if scanning was enabled. This
            > command may be sent while using any Scan Code Set but only has
            > effect when Scan Code Set 3 is in use.
            > F8 PS/2 Set All Keys to Make/Break, keyboard responds by sending
            > an
            > ACK, clearing its output buffer and setting the key type to
            > Make/Break. Scanning continues if scanning was enabled. This
            > command may be sent while using any Scan Code Set but only has
            > effect when Scan Code Set 3 is in use.
            > F9 PS/2 Set All Keys to Make, keyboard responds by sending an
            > ACK,
            > clearing its output buffer and setting the key type to Make.
            > Scanning continues if scanning was enabled. This command may
            > be sent while using any Scan Code Set but only has effect when
            > Scan Code Set 3 is in use.
            > FA PS/2 Set All Keys to Typematic Make/Break, keyboard responds
            > by
            > sending an ACK, clearing its output buffer and setting the key
            > type to Typematic Make/Break. Scanning continues if scanning
            > was enabled. This command may be sent while using any Scan
            > Code
            > Set but only has effect when Scan Code Set 3 is in use.
            > FB PS/2 Set Key Type to Typematic, keyboard responds by sending
            > an
            > ACK, clearing its output buffer and then waiting for the key
            > ID
            > (make code from Scan Code Set 3). The specified key type is
            > then
            > set to typematic. This command may be sent while using any
            > Scan Code Set but only has effect when Scan Code Set 3 is in
            > use.
            > FC PS/2 Set Key Type to Make/Break, keyboard responds by sending
            > an
            > ACK, clearing its output buffer and then waiting for the key
            > ID
            > (make code from Scan Code Set 3). The specified key type is
            > then
            > set to Make/Break. This command may be sent while using any
            > Scan
            > Code Set but only has effect when Scan Code Set 3 is in use.
            > FD PS/2 Set Key Type to Make, keyboard responds by sending an
            > ACK,
            > clearing its output buffer and then waiting for the key ID
            > (make
            > code from Scan Code Set 3). The specified key type is then
            > set
            > to Make. This command may be sent while using any Scan Code
            > Set
            > but only has effect when Scan Code Set 3 is in use.
            > FE Resend, should be sent when a transmission error is detected
            > from the keyboard
            > FF Reset, Keyboard sends ACK and waits for system to receive it
            > then begins a program reset and Basic Assurance Test (BAT).
            > Keyboard returns a one byte completion code then sets default
            > Scan Code Set 2.
            >
            >
            > Keyboard Responses to System (via 8042 port 60h)
            >
            > 00 Key Detection Error or Overrun Error for Scan Code Set 1,
            > replaces last key in the keyboard buffer if the buffer is
            > full.
            > AA BAT Completion Code, keyboard sends this to indicate the
            > keyboard
            > test was successful.
            > EE Echo Response, response to the Echo command.
            > F0 Break Code Prefix in Scan Code Sets 2 and 3.
            > FA Acknowledge, keyboard sends this whenever a valid command or
            > data byte is received (except on Echo and Resend commands).
            > FC BAT Failure Code, keyboard sends this to indicate the keyboard
            > test failed and stops scanning until a response or reset is
            > sent.
            > FE Resend, keyboard request resend of data when data sent to it
            > is
            > invalid or arrives with invalid parity.
            > FF Key Detection Error or Overrun Error for Scan Code Set 2 or 3,
            > replaces last key in the keyboard buffer if the buffer is
            > full.
            > id Keyboard ID Response, keyboard sends a two byte ID after
            > ACK'ing
            > the Read ID command. The byte stream contains 83AB in LSB,
            > MSB
            > order. The keyboard then resumes scanning.
            >
            > - command F7 through FD are NOP's on the AT and are ACK'ed but not
            > acted upon
            >
            >
            > =========================================================================
            > Hi Paul,
            >
            >>> How does that work? How does the Keyboard know when to start clocking?
            > Does it watch the PC pull the clock line low then
            > take over? Or does the PC start by lowering the Data line? The book I
            > found
            > is a bit vague on the subject. <<
            >
            > For a PC->Keyboard transfer, the keyboard watches for the PC (actually the
            > 8042 in the PC) to pull the Data Line low while the
            > clock line is high. The PC just waits at that point for the Keyboard to
            > start clocking, then sends out the data.
            >
            > For a Keyboard->PC transfer, the keyboard just checks that both clock and
            > data are high, then starts transmitting. During
            > periods when the PC can't respond, it will hold the clock low and that
            > stops the keyboard from beginning a transmission.
            >
            >>> Also, what happens after line contention? They both back off but what
            > then - random wait time and try again? Or is there a
            > special code transmitted? <<
            >
            > As I mentioned above, the PC holds the clock line low if it can't respond
            > to the keyboard for some reason, maybe servicing a
            > PS2 mouse or whatever. The Keyboard is supposed to check each time it
            > releases the clock line to supply a high clock (up to
            > the tenth bit, I think). If the PC has started doing
            > something else, it will clamp the clock to ground and the keyboard can see
            > that
            > it doesn't float high when released. In that case, the keyboard aborts the
            > transmission. Also, if either end detects a character
            > error or illegal command, it can request a resend. The keyboard does that
            > in place of the ACK that it normally sends when it
            > receives a command. The PC can do it anytime it gets a garbled character.
            >
            >>> BTW, how come you know all this stuff? :-) <<
            >
            > I spent about 4 years designing circuits and coding microchips for
            > programmable PC joysticks. They connect between the PC
            > and the keyboard, when they need to send a character, they gate the real
            > keyboard offline and control the clock/data lines
            > themselves to generate the characters, then reconnect the keyboard. The
            > also downloaded the stick program through the
            > keyboard port (there's some real fun<g>). Anyway, I got to know the AT/PS2
            > keyboard interface pretty well.
            >
            > BTW, it occurred to me that the 0x0F break you're seeing is probably just
            > because the bits are backwards on a 'scope. It sends
            > things LSB first.
            >
            > - Bob
            >
            > =========================================================================
            >
            > Check the book "the Indispensable PC Hardware Book" by Messmer. ISBN
            > 0-201-40399-4.
            >
            > =========================================================================
            >>>Hopefully the web page will tell me whether the PS/2 keyboard differs.
            >
            > Winn Rosch's Hardware bible lists the PS/2 connector as:
            > Pin Description Direction
            > 1 Data In
            > 2 Reserved N/A
            > 3 Ground N/A
            > 4 +5v Out
            > 6 Reserved N/A
            > Shield Ground N/A
            >
            > |<---Notch
            > ^
            > 5 6
            > 3 4
            > 1 2
            >
            >
            > Visit the SRS Website at http://www.seattlerobotics.org
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.