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

Re: [SeattleRobotics] Keyboard scan codes

Expand Messages
  • Tom Capon
    Alas, I haven t subscribed yet!
    Message 1 of 5 , Apr 1 6:09 AM
    View Source
    • 0 Attachment
      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 2 of 5 , Apr 2 4:32 AM
      View Source
      • 0 Attachment
        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 3 of 5 , Apr 2 7:08 AM
        View Source
        • 0 Attachment
          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.