From e47a3aa300eac638317013eb9426a579fbecc229 Mon Sep 17 00:00:00 2001 From: root Date: Sun, 7 Jun 2015 01:52:49 +0100 Subject: more documentation --- .../ps2keyboard/index.html | 2393 ++++++++++++++++++++ .../ps2protocol/fpdin1.JPG | Bin 0 -> 5591 bytes .../ps2protocol/fpindin.JPG | Bin 0 -> 5683 bytes .../ps2protocol/index.html | 537 +++++ .../ps2protocol/ps2.JPG | Bin 0 -> 13162 bytes .../ps2protocol/qscope.JPG | Bin 0 -> 27058 bytes .../ps2protocol/sdl.jpg | Bin 0 -> 2394 bytes .../ps2protocol/sdl1.jpg | Bin 0 -> 2394 bytes .../ps2protocol/spindin.JPG | Bin 0 -> 6343 bytes .../ps2protocol/spindin1.JPG | Bin 0 -> 6246 bytes .../ps2protocol/waveform1.jpg | Bin 0 -> 11046 bytes .../ps2protocol/waveform2.jpg | Bin 0 -> 12777 bytes .../ps2protocol/waveform3.jpg | Bin 0 -> 21331 bytes 13 files changed, 2930 insertions(+) create mode 100644 docs/www.computer-engineering.org/ps2keyboard/index.html create mode 100644 docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/fpindin.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/index.html create mode 100644 docs/www.computer-engineering.org/ps2protocol/ps2.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/qscope.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/sdl.jpg create mode 100644 docs/www.computer-engineering.org/ps2protocol/sdl1.jpg create mode 100644 docs/www.computer-engineering.org/ps2protocol/spindin.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/spindin1.JPG create mode 100644 docs/www.computer-engineering.org/ps2protocol/waveform1.jpg create mode 100644 docs/www.computer-engineering.org/ps2protocol/waveform2.jpg create mode 100644 docs/www.computer-engineering.org/ps2protocol/waveform3.jpg diff --git a/docs/www.computer-engineering.org/ps2keyboard/index.html b/docs/www.computer-engineering.org/ps2keyboard/index.html new file mode 100644 index 0000000..72d0b4e --- /dev/null +++ b/docs/www.computer-engineering.org/ps2keyboard/index.html @@ -0,0 +1,2393 @@ + + + + + + + + + + + The PS/2 Keyboard Interface + + + + + + The PS/2 +Keyboard Interface
+ + +
+ +
+
+
+ Source: http://www.Computer-Engineering.org
+ Author: Adam Chapweske
+ Last Updated: 04/01/03
+ +
+ Legal Information:
+
+ All information within this article is provided "as is" and without +any express or implied warranties, including, without limitation, the implied + warranties of merchantibility and fitness for a particular purpose.  
+
+ This article is protected under copyright law.  This document may + be copied only if the source, author, date, and legal information is included.
+
+ + Abstract:
+
+ This article tries to cover every aspect of AT and PS/2 keyboards.  + It includes information on the low-level signals and protocol, scan codes, + the command set, initialization, compatibility issues, and other miscellaneous + information.  Since it's closely related, I've also included information + on the PC keyboard controller.  All code samples involving the keyboard + encoder are written in assembly for Microchip's + PIC microcontrollers.  All code samples related to the keyboard +controller are written in x86 assembly
+ + +

A History Lesson:

+ +

The most popular keyboards in use today include:

+ + + IBM introduced a new keyboard with each of its major desktop computer + models.  The original IBM PC, and later the IBM XT, used what we +call the "XT keyboard."  These are obsolete and differ significantly +from modern keyboards; the XT keyboard is not covered in this article.  + Next came the IBM AT system and later the IBM PS/2.  They introduced + the keyboards we use today, and are the topic of this article.  AT + keyboards and PS/2 keyboards were very similar devices, but the PS/2 device + used a smaller connector and supported a few additional features.  + +Nonetheless, it remained backward compatible with AT systems and few of +the additional features ever caught on (since software also wanted to +remain backward compatible.)  Below is a summary of IBM's three major +keyboards. +

IBM PC/XT Keyboard (1981):

+ + + IBM AT Keyboard (1984) - Not backward compatible with XT systems(1). + + + IBM PS/2 Keyboard (1987) - Compatible with AT systems, not compatible + with XT systems(1). + + + The PS/2 keyboard was originally an extension of the AT device.  + It supported a few additional host-to-keyboard commands and featured +a smaller connector.  These were the only differences between the +two devices.  However, computer hardware has never been about standards + as much as compatibility.  For this reason, any keyboard you buy +today will be compatible with PS/2 and AT systems, but it may not +fully support all the features of the original devices. + + +

Today, "AT keyboard" and "PS/2 keyboard" refers only to their connector + size.  Which settings/commands any given keyboard does or does not + support is anyone's guess.  For example, the keyboard I'm using right + now has a PS/2-style connector but only fully supports seven commands, partially + supports two, and merely "acknowledges" the rest.  In contrast, my + "Test" keyboard has an AT-style connector but supports every feature/command + of the original PS/2 device (plus a few extra.)  It's important you + treat modern keyboards as compatible, not standard.  If your design +a keyboard-related device that relies on non-general features, it may work +on some systems, but not on others...

+ +

Modern PS/2 (AT) compatible keyboards

+ + +
+ Footnote 1) XT keyboards use a completely different protocol + than that used by AT and PS/2 systems, making it incompatible with the + newer PCs.  However, there was a transition period where some keyboard + controllers supported both XT and AT (PS/2) keyboards (through a switch, +jumper, or auto-sense.)  Also, some keyboards were made to work on +both types of systems (again, through the use of a switch or auto-sensing.)  +If you've owned such a PC or keyboard, don't let it fool you--XT keyboards +are NOT compatible with modern computers. + +

General Description:

+ + +

Keyboards consist of a large matrix of keys, all of which are monitored + by an on-board processor (called the "keyboard encoder".)  The specific + processor(1) varies + from keyboard-to-keyboard but they all basically do the same thing:  + Monitor which key(s) are being pressed/released and send the appropriate + data to the host.  This processor takes care of all the debouncing +and buffers any data in its 16-byte buffer, if needed.  Your motherboard + contains a "keyboard controller"(2) that is in charge of decoding + all of the data received from the keyboard and informing your software of + what's going on.  All communication between the host and the keyboard + uses an IBM protocol. 
+ +
+ Footnote 1)  Originally, IBM used the Intel 8048 microcontroller + as its keyboard encoder.  There are now a wide variety of keyboard + encoder chips available from many different manufacturers.

+ Footnote 2) Originally, + IBM used the Intel 8042 microcontroller as its keyboard controller.  + This has since been replaces with compatible devices integrated in motherboards' + chipsets. The keyboard controller is covered later in this article. + +

Electrical Interface / Protocol:

+ + +

The AT and PS/2 keyboards use the same protocol as the PS/2 mouse.  + Click here for detailed information on + this protocol.

+ +

Scan Codes:

+ +

Your keyboard's processor spends most of its time "scanning", or monitoring, + the matrix of keys.  If it finds that any key is being pressed, released, + or held down, the keyboard will send a packet of information known as a +"scan code" to your computer.  There are two different types of scan +codes: "make codes" and "break codes".  A make code is sent when +a key is pressed or held down.  A break code is sent when a key is +released.  Every key is assigned its own unique make code and break +code so the host can determine exactly what happened to which key by looking + at a single scan code.  The set of make and break codes for every key + comprises a "scan code set".  There are three standard scan code sets, + named one, two, and three.  All modern keyboards default to set two.(1)

+ + +

So how do you figure out what the scan codes are for each key?  + Unfortunately, there's no simple formula for calculating this.  If + you want to know what the make code or break code is for a specific key, + you'll have to look it up in a table.  I've composed tables for all +make codes and break codes in all three scan code sets:

+ + +
+ + Footnote 1) Originally, the AT keyboard only supported set + two, and the PS/2 keyboard would default to set two but supported all three.  + Most modern keyboards behave like the PS/2 device, but I have come across + a few that didn't support set one, set three, or both.  Also, if +you've ever done any low-level PC programming, you've probably notice +the keyboard controller supplies set ONE scan codes by default.  This +is because the keyboard controller converts all incomming scan codes to +set one (this stems from retaining compatibility with software written for +XT systems.)  However, it's still set two scan codes being sent down +the keyboard's serial line.  + +

Make Codes, Break Codes, and Typematic Repeat:

+ +

Whenever a key is pressed, that key's make code is sent to the computer.  + Keep in mind that a make code only represents a key on a keyboard--it + does not represent the character printed on that key.  This means + that there is no defined relationship between a make code and an ASCII code.  + + It's up to the host  to translate scan codes to characters or commands. +

+ +

Although most set two make codes are only one-byte wide, there are a + handfull of "extended keys" whose make codes are two or four bytes wide.  + These make codes can be identified by the fact that their first byte is + E0h. 

+ +

Just as a make code is sent to the computer whenever a key is pressed, + a break code is sent whenever a key is released.  In addition to +every key having its own unique make code, they all have their own unique +break code(1).  Fortunately, + however, you won't always have to use lookup tables to figure out a key's + break code--certain relationships do exist between make codes and break + codes.  Most set two break codes are two bytes long where the first + byte is F0h and the second byte is the make code for that key.  Break + codes for extended keys are usually three bytes long where the first two +bytes are E0h, F0h, and the last byte is the last byte of that key's make +code.  As an example, I have listed below a the set two make codes and +break codes for a few keys: 

+ + +
+
+ +
  + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + +
Key
+ 		+ + +
(Set 2)
+ + Make Code
+ 		+ + +
(Set 2)
+ Break Code
+
+ + +
"A"
+ 		+ + +
1C
+ 		+ + +
F0,1C
+
+ + +
"5"
+ 		+ + +
2E
+ 		+ + +
F0,2E
+ +
+ + +
"F10"
+ 		+ + +
09
+ 		+ + +
F0,09
+
+ + +
Right Arrow
+ 		+ + +
E0, 74
+ + 		+ + +
E0, F0, 74
+
+ + +
Right "Ctrl"
+ 		+ + +
E0, 14
+ 		+ + +
E0, F0, 14
+
+ +
+
+ Example:  What sequence of make codes and break codes should + be sent to your computer for the character "G" to appear in a word processor?  + Since this is an upper-case letter, the sequence of events that need to + take place are: press the "Shift" key, press the "G" key, release the "G" + key, release the "Shift" key.  The scan codes associated with these + events are the following:  make code for the "Shift" key (12h), make + code for the "G" key (34h), break code for the "G" key(F0h,34h), break code + for the "Shift" key (F0h,12h).  Therefore, the data sent to your computer + would be: 12h, 34h, F0h, 34h, F0h, 12h.
+ + If you press a key, its make code is sent to the computer.  +When you press and hold down a key, that key becomes typematic, +which means the keyboard will keep sending that key's make code until the +key is released or another key is pressed.  To verify this, open a text +editor and hold down the "A" key.  When you first press the key, the +character "a" immediately appears on your screen.  After a short delay, +another "a" will appear followed by a whole stream of "a"s until you release +the "A" key.  There are two important parameters here:  the typematic + delay, which is the short delay between the first and second "a", +and the typematic rate, which is how many characters per second +will appear on your screen after the typematic delay.  The typematic +delay can range from 0.25 seconds to 1.00 second and the typematic rate +can range from 2.0 cps (characters per second) to 30.0 cps.  You may +change the typematic rate and delay using the "Set Typematic Rate/Delay" +(0xF3) command. + +

Typematic data is not buffered within the keyboard.  In the case + where more than one key is held down, only the last key pressed becomes + typematic.  Typematic repeat then stops when that key is released, + even though other keys may be held down.

+ +


+ Footnote 1) Actually, the "Pause/Break" key does not have + a break code in scan code sets one and two.  When this key is pressed, + its make code is sent; when it's released, it doesn't send anything.  So + how do you tell when this key has been released?  You can't.

+ + +

Reset:

+ +

At power-on or software reset (see the "Reset" command) the keyboard + performs a diagnostic self-test referred to as BAT (Basic Assurance Test) + and loads the following default values: 

+ + + +

When entering BAT, the keyboard enables its three LED indicators, and + turns them off when BAT has completed.  At this time, a BAT completion + code of either 0xAA (BAT successful) or 0xFC (Error) is sent to the host. +   This BAT completion code must be sent 500~750 milliseconds after +power-on.

+ + +

Many of the keyboards I've tested ignore their CLOCK and DATA lines until +after the BAT completion code has been sent.  Therefore, an +"Inhibit" condition (CLOCK line low) may not prevent the keyboard from + sending its BAT completion code.

+ +

Command Set:

+ +

A few notes regarding commands the host can issue to the keyboard:
+

+ + + + Below are all the commands the host may send to the keyboard:
+ + + + + +
The next six commands can be issued when the keyboard is in any +mode, but it only effects the behavior of the keyboard when in "mode 3" +(ie, set to scan code set 3.)
+
+ + + +
+ + + + + + + + + + + + + + + +
MSb
+
+ +
+
+
+
+ 		LSb
+
+ +
+ + + + + + + + + + + + + + + + +
Always 0Always 0Always 0Always 0Always 0Caps LockNum LockScroll Lock
+
+ +
+
+ +
+ +
    + + +
      +
    • "Scroll Lock" - Scroll Lock LED off(0)/on(1)
      • +
    • "Num Lock" - Num Lock LED off(0)/on(1)
      • +
    • "Caps Lock" - Caps Lock LED off(0)/on(1)
      • + +
    + +
+ +
+
+
+ *Originally available in PS/2 keyboards only. + +

Emulation:

+ + + The i8042 Keyboard Controller: + +

Up to this point in the article, all information has been presented +from a hardware point-of-view.  However, if you're writing low-level + keyboard-related software for the host PC, you won't be communicating +directly with the keyboard.  Instead, a keyboard controller provides +an interface between the keyboard and the peripheral bus.  This controller +takes care of all the signal-level and protocol details, as well as providing + some conversion, interpretation, and handling of scan codes and commands.  +

+ +

An Intel 8042/compatible microcontroller is used as the PC's keyboard + controller.  In modern computers, this microcontroller is hidden within + the motherboard's chipset, which integrates many controllers in a single + package.  Nonetheless, this device is still there, and the keyboard + controller is still commonly referred to as "the 8042".

+ + +

Depending on the motherboard, the keyboard controller may operate in + one of two modes: "AT-compatible" mode, or "PS/2-compatible" mode.  + The latter is used if a PS/2 mouse is supported by the motherboard.  + If this is the case, the 8042 acts as the keyboard controller and the +mouse controller.  The keyboard controller auto-detects which mode +it is to use according to how it's wired to the keyboard port.

+ +

The 8042 contains the following registers:

+ + + The first three registers (input, output, status) are directly accessible + via ports 0x60 and 0x64.  The last register (control) is read using + the "Read Command Byte" command, and written using the "Write Command Byte" + command.  The following table shows how the peripheral ports are +used to interface the 8042:
+ +   +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
Port
+ 		+ +
Read / 
+ + Write
+ 		+ +
Function
+
0x60ReadRead Input Buffer
0x60WriteWrite Output Buffer
0x64ReadRead Status Register
0x64WriteSend Command
+
+ + +

Writing to port 0x64 doesn't write to any specific register, but sends + a command for the 8042 to interpret.  If the command accepts a parameter, + this parameter is sent to port 0x60.  Likewise, any results returned + by the command may be read from port 0x60.

+ +

When describing the 8042, I may occasionally refer to its physical I/O + pins.  These pins are defined below:

+ +

AT-compatible mode

+ +
+ + + + + + + + + + +
Port 1 (Input Port): + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0P10
+ Undefined
+ + .
1P11
+ Undefined
+ + .
2P12
+ Undefined
+ + .
3P13
+ Undefined
+ + .
4P14External RAM
+ 1: Enable external RAM
+ + 0: Disable external RAM
5P15Manufacturing Setting
+ 1: Setting enabled
+ + 0: Setting disabled
6P16Display Type Switch
+ 1: Color display
+ + 0: Monochrome
7P17Keyboard Inhibit Switch
+ 1: Keyboard enabled
+ + 0: Keyboard inhibited
+
+ 		Port 2 (Output Port): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0P20System Reset
+ 1: Normal
+ 0: Reset computer
1P21
+ Gate A20
+ .
2P22
+ Undefined
+ .
3P23
+ Undefined
+ .
4P24
+ Input Buffer Full
+ .
5P25
+ Output Buffer Empty
+ .
6P26Keyboard Clock
+ 1: Pull Clock low
+ 0: High-Z
7P27Keyboard Data:
+ 1: Pull Data low
+ 0: High-Z
+ + 		Port 3 (Test Port): + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0T0Keyboard Clock 
+ (Input)
+ + .
1T1Keyboard Data
+ (Input)
+ + .
2--
+ Undefined
+ + .
3--
+ Undefined
+ + .
4--
+ Undefined
+ + .
5--
+ Undefined
+ + .
6--
+ Undefined
+ + .
7--
+ Undefined
+ + .
+
+
+ +
+ +

PS/2-compatible mode

+ +
+ + + + + + + + + + +
Port 1 (Input Port): + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0P10Keyboard Data
+ (Input)
+ .
1P11Mouse Data
+ (Input)
+ .
2P12
+ Undefined
+ .
3P13
+ Undefined
+ .
4P14External RAM
+ 1: Enable external RAM
+ 0: Disable external RAM
5P15Manufacturing Setting
+ 1: Setting enabled
+ 0: Setting disabled
6P16Display Type Switch
+ 1: Color display
+ 0: Monochrome
7P17Keyboard Inhibit Switch
+ 1: Keyboard enabled
+ 0: Keyboard disabled
+
+ 		Port 2 (Output Port): + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0P20System Reset
+ 1: Normal
+ 0: Reset computer
1P21
+ Gate A20
+ .
2P22Mouse Data:
+ 1: Pull Data low
+ 0: High-Z
3P23Mouse Clock:
+ 1: Pull Clock low
+ 0: High-Z
4P24Keyboard IBF interrupt:
+ 1: Assert IRQ 1
+ 0: De-assert IRQ 1
5P25Mouse IBF interrupt:
+ 1: Assert IRQ 12
+ 0: De-assert IRQ 12
6P26Keyboard Clock:
+ 1: Pull Clock low
+ 0: High-Z
7P27Keyboard Data:
+ 1: Pull Data low
+ 0: High-Z
+
+ 		Port 3 (Test Port): + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PinNameFunction
0T0Keyboard Clock
+ (Input)
+ .
1T1Mouse Clock
+ (Input)
+ .
2--
+ Undefined
+ .
3--
+ Undefined
+ .
4--
+ Undefined
+ .
5--
+ Undefined
+ .
6--
+ Undefined
+ .
7--
+ Undefined
+ .
+
+
+
+ + +

(Note: Reading keyboard controller datasheets can be confusing--it will + refer to the "input buffer" as the "output buffer" and vice versa.  + This makes sense from the point-of-view of someone writing firmware for + the controller, but for somebody used to interfacing the controller, this + can cause problems.  Throughout this document, I only refer to the +"input buffer" as the one containing input from the keyboard, and the "output + buffer" as the one that contains output to be sent to the keyboard.) +

+ +

Status Register:

+ +

The 8042's status flags are read from port 0x64.  They contain +error information, status information, and indicate whether or not data +is present in the input and output buffers.  The flags are defined as + follows:
+ +  

+ +
+ + + + + + + + + + + + + + + + + + +

+ 		+ +
+ + + + + + + + + + + + + + + + + + +
MSb
+
+
+ +
+
+
+ 		+ + +
LSb
+ +
+
+
AT-compatible mode: + +
+ + + + + + + + + + + + + + + + + +
+ + +
PERR
+ 		+ + +
RxTO
+ + 		+ + +
TxTO
+ 		+ + +
INH
+ 		+ + +
A2
+ + 		+ + +
SYS
+ 		+ + +
IBF
+ 		+ + +
OBF
+ +
+
+
PS/2-compatible mode:  + +
+ + + + + + + + + + + + + + + + + +
+ + +
PERR
+ 		+ + +
TO
+ + 		+ + +
MOBF
+ 		+ + +
INH
+ 		+ + +
A2
+ + 		+ + +
SYS
+ 		+ + +
IBF
+ 		+ + +
OBF
+ +
+
+
+
+ + + + [EG: On my PC, the normal value of the 8042's "Status" register +is 14h = 00010100b.  This indicates keyboard communication is not +inhibited, and the 8042 has already completed its self-test ("BAT").  +The "Status" register is accessed by reading from port 64h ("IN AL, 64h")] + +

Reading keyboard input:

+ + +

When the 8042 recieves a valid scan code from the keyboard, it is converted + to its set 1 equivalent.  The converted scan code is then placed in + the input buffer, the IBF (Input Buffer Full) flag is set, and IRQ 1 is asserted.  + Furthermore, when any byte is received from the keyboard, the 8042 inhibits + further reception (by pulling the "Clock" line low), so no other scan codes + will be received until the input buffer is emptied.

+ +

If enabled, IRQ 1 will activate the keyboard driver, pointed to by interrupt + vector 0x09.  The driver reads the scan code from port 0x60, which causes + the 8042 to de-assert IRQ 1 and reset the IBF flag.  The scan code +is then processed by the driver, which responds to special key combinations +and updates an area of the system RAM reserved for keyboard input.

+ +

If you don't want to patch into interrupt 0x09, you may poll the keyboard + controller for input.  This is accomplished by disabling the 8042's + IBF Interrupt and polling the IBF flag.  This flag is set (1) when + data is available in the input buffer, and is cleared (0) when data is read + from the input buffer.  Reading the input buffer is accomplished + by reading from port 0x60, and the IBF flag is at port 0x64, bit 1.  + The following assembly code illustrates this:

+ + +

kbRead:
+ WaitLoop:    in     +al, 64h     ; Read Status byte
+              + and    al, 10b     ; Test IBF flag +(Status<1>)
+ +              + jz     WaitLoop    ; Wait for IBF = + 1
+              + in     al, 60h     ; Read input + buffer

+ + +

Writing to keyboard:

+ +

When you write to the 8042's output buffer (via port 0x60), the controller + sets the OBF ("Output Buffer Full") flag and processes the data.  The + 8042 will send this data to the keyboard and wait for a response.  +If the keyboard does not accept or generate a response within a given amount + of time, the appropriate timeout flag will be set (see Status register + definition for more info.)  If an incorrect parity bit is read, the + 8042 will send the "Resend" (0xFE) command to the keyboard.  If the + keyboard continues to send erroneous bytes, the "Parity Error" flag is set + in the Status register.  If no errors occur, the response byte is +placed in the input buffer, the IBF ("Input Buffer Full") flag is set, and +IRQ 1 is activated, signaling the keyboard driver.

+ + +

The following assembly code shows how to write to the output buffer.  + (Remember, after you write to the output buffer, you should use int 9h + or poll port 64h to get the keyboard's response.)

+ +

kbWrite:
+ WaitLoop:    in     +al, 64h     ; Read Status byte
+ +              + and    al, 01b     ; Test OBF flag +(Status<0>)
+              + jnz    WaitLoop    ; Wait for OBF = 0 +
+ +              + out    60h, cl     ; Write data to +output buffer

+ +

Keyboard Controller Commands:

+ +

Commands are sent to the keyboard controller by writing to port 0x64.  + Command parameters are written to port 0x60 after teh command is sent.  + Results are returned on port 0x60.  Always test the OBF ("Output Buffer + Full") flag before writing commands or parameters to the 8042.

+ + + + + +
+ + + + + + + + + + + + + + + + +

+ 		+ +
+ + + + + + + + + + + + + + + + + + + + +
MSb
+
+
+
+
+
+ 		+ + +
LSb
+
+
+
AT-compatible mode: + +
+ + + + + + + + + + + + + + + + + + +
+ + +
--
+ 		+ + +
XLAT
+ 		+ + +
PC
+ + 		+ + +
_EN
+ 		+ + +
OVR
+ 		+ + +
SYS
+ + 		+ + +
--
+ 		+ + +
INT
+
+ +
+
PS/2-compatible mode:  + +
+ + + + + + + + + + + + + + + + + + +
+ + +
--
+ 		+ + +
XLAT
+ 		+ + +
_EN2
+ + 		+ + +
_EN
+ 		+ + +
--
+ 		+ + +
SYS
+ + 		+ + +
INT2
+ 		+ + +
INT
+
+ +
+
+
+ + + + + +


+ Modern Keyboard Controllers:

+ + +

So far, I've only discussed the 8042 keyboard controller.  Although + modern keyboard controllers remain compatible with the original device, compatibility + is their only requirement (and their goal.)

+ +

My motherboard's keyboard controller is a great example of this.  + I connected a microcontroller+LCD in parallel to my keyboard to see what + data is sent by the keyboard controller.  At power-up, the keyboard + controller sent the "Set LED state" command to turn off all LEDs, then reads + the keyboard's ID.  When I tried writing data to the output buffer, + I found the keyboard controller only forwards the "Set LED state" command + and "Set Typematic Rate/Delay" command.  It does not allow any other + commands to be sent to the keyboard.  However, it does emulate the +keyboard's response by placing "acknowledge" (0xFA) in the input buffer +when appropriate (or 0xEE in response to the "Echo" command.)  Furthermore, +if the keyboard sends it an erroneous byte, the keyboard controller takes +care of error handling (sends the "Retry" command; if byte still erroneous; +sends error code to keyboard and places error code in input buffer.)

+ + +

Once again, keep in mind chipset designers are more interested in compatibility + than standardization. 

+ +

Initialization:

+ +

The following is the communication between my computer and keyboard +when it boots-up.  I beleive the first three commands were initiated + by the keyboad controller, the next command (which enables Num lock LED) + was sent by the BIOS, then the rest of the commands were sent my the OS + (Win98SE).  Remember, these results are specific to my computer, but + it should give you a general idea as to what happens at startup.

+ +
Keyboard: AA  Self-test passed                + ;Keyboard controller init
+ + Host:     ED  Set/Reset Status + Indicators 
+ Keyboard: FA  Acknowledge
+ Host:     00  Turn off all LEDs +
+ + Keyboard: FA  Acknowledge
+ Host:     F2  Read ID
+ Keyboard: FA  Acknowledge
+ + Keyboard: AB  First byte of ID
+ Host:     ED  Set/Reset Status + Indicators     ;BIOS init
+ Keyboard: FA  Acknowledge
+ + Host:     02  Turn on Num Lock + LED
+ Keyboard: FA  Acknowledge
+ Host:     F3  Set Typematic +Rate/Delay        ;Windows init + +
+ Keyboard: FA  Acknowledge
+ Host:     20  500 ms / 30.0 +reports/sec
+ Keyboard: FA  Acknowledge
+ + Host:     F4  Enable
+ Keyboard: FA  Acknowledge
+ Host:     F3  Set Typematic +Rate/delay
+ + Keyboard: FA  Acknowledge
+ Host:     00  250 ms / 30.0 +reports/sec
+ Keyboard: FA  Acknowledge
+ +
+
+ + + diff --git a/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG b/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG new file mode 100644 index 0000000..378895b Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG b/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG new file mode 100644 index 0000000..2ef568f Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/index.html b/docs/www.computer-engineering.org/ps2protocol/index.html new file mode 100644 index 0000000..8adffd9 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/index.html @@ -0,0 +1,537 @@ + + + + + + + + + + + + + + + The PS/2 Mouse/Keyboard Protocol + + + + + The PS/2 +Mouse/Keyboard Protocol
+ +
+ +
+
+
+ Source: http://www.Computer-Engineering.org
+ Author: Adam Chapweske
+ + Last Updated: 05/09/03
+
+
+ Legal Information:
+
+ All information within this article is provided "as is" and without +any express or implied warranties, including, without limitation, the implied + warranties of merchantibility and fitness for a particular purpose.  
+
+ + This article is protected under copyright law.  This document may + be copied only if the source, author, date, and legal information is included.
+
+ Abstract: +

This document descibes the interface used by the PS/2 mouse, PS/2 keyboard, + and AT keyboard.  I'll cover the physical and electrical interface, + as well as the protocol.  If you need higher-level information, such + as commands, data packet formats, or other information specific to the keyboard + or mouse, I have written separate documents for the two devices: +

+ +
The PS/2 (AT) Keyboard Interface + +
+ The PS/2 Mouse Interface
+ The Physical Interface:
+ +

The physical PS/2 port is one of two styles of connectors:  The + 5-pin DIN or the 6-pin mini-DIN.  Both connectors are completely +(electrically) similar; the only practical difference between the two is + the arrangement of pins.  This means the two types of connectors can + easily be changed with simple hard-wired adaptors.  These cost about + $6 each or you can make your own by matching the pins on any two connectors.  + The DIN standard was created by the German Standardization Organization + (Deutsches Institut fuer Norm) .  Their website is at http://www.din.de (this site is +in German, but most of their pages are also available in English.) + +

+ +

PC keyboards use either a 6-pin mini-DIN or a 5-pin DIN connector.  + If your keyboard has a 6-pin mini-DIN and your computer has a 5-pin DIN + (or visa versa), the two can be made compatible with the adaptors described + above.  Keyboards with the 6-pin mini-DIN are often referred to as + "PS/2" keyboards, while those with the 5-pin DIN are called "AT" devices + ("XT" keyboards also used the 5-pin DIN, but they are quite old and haven't + been made for many years.)  All modern keyboards built for the PC +are either PS/2, AT, or USB.  This document does not apply +to USB devices, which use a completely different interface.

+ +

Mice come in a number of shapes and sizes (and interfaces.)  The + most popular type is probably the PS/2 mouse, with USB mice gaining popularity.  + Just a few years ago, serial mice were also quite popular, but the computer + industry is abandoning them in support of USB and PS/2 devices.  This + document applies only to PS/2 mice.  If you want to interface a serial + or USB mouse, there's plenty of information available elsewhere on + the web.
+ +
+ The cable connecting the keyboard/mouse to the computer is usually +about six feet long and consists of four to six 26 AWG wires surrounded +by a thin layer of mylar foil sheilding.  If you need a longer cable, +you can buy PS/2 extenstion cables from most consumer electronics stores. + You should not connect multiple extension cables together.  If +you need a 30-foot keyboard cable, buy a 30-foot keyboard cable.  Do +not simply connect five 6-foot cables together.  Doing so could result +in poor communication between the keyboard/mouse and the host.
+

+ +

As a side note, there is one other type of connector you may run into + on keyboards. While most keyboard cables are hard-wired to the keyboard, + there are some whose cable is not permanently attached and come as a separate + component.  These cables have a DIN connector on one end (the end + that connects to the computer) and a SDL (Sheilded Data Link) connector +on the keyboard end.  SDL was created by a company called "AMP."  + + This connector is somewhat similar to a telephone connector in that it +has wires and springs rather than pins, and a clip holds it in place.  +If you need more information on this connector, you might be able to find +it on AMP's website at http://www.connect.amp.com.  Don't confuse the SDL +connector with the USB connector--they probably both look similar in my +diagram below, but they are actually very different.  Keep in mind +that the SDL connector has springs and moving parts, while the USB connector +does not.

+ +

The pinouts for each connector are shown below:
+   + + + + + + + + + + + + + +
+ +
Male
+ +
+ (Plug)
+ 		+ +
Female 
+ +
+ (Socket)
+ 		5-pin DIN (AT/XT): 
+ + 1 - Clock
+ 2 - Data
+ 3 - Not Implemented
+ 4 - Ground
+ 5 - Vcc (+5V)
+
+   + + + + + + + + + + +
+ +
Male
+ + +
+ (Plug)
+ 		+ +
Female
+ +
+ (Socket)
+ + 		6-pin Mini-DIN (PS/2):
+ 1 - Data
+ 2 - Not Implemented
+ 3 - Ground
+ 4 - Vcc (+5V)
+ + 5 - Clock
+ 6 - Not Implemented
+
+   + + + + + + + + + + + + +
+ +
+
+ 		+ +
+
+ 		6-pin SDL:
+ + A - Not Implemented
+ B - Data
+ C - Ground
+ D - Clock
+ E - Vcc (+5V)
+ F - Not Implemented
+

+ +

+ +


+ The Electrical Interface:
+

+ + +

Note:  Throughout this document, I will use the more general term + "host" to refer to the computer--or whatever the keyboard/mouse is connected + to-- and the term "device" will refer to the keyboard/mouse.

+ + +

Vcc/Ground provide power to the keyboard/mouse.  The keyboard or + mouse should not draw more than 275 mA from the host and care must be taken + to avoid transient surges.  Such surges can be caused by "hot-plugging" + a keyboard/mouse (ie, connect/disconnect the device while the computer's + power is on.)  Older motherboards had a surface-mounted fuse protecting + the keyboard and mouse ports.  When this fuse blew, the motherboard + was useless to the consumer, and non-fixable to the average technician. + Most newer motherboards use auto-reset "Poly" fuses that go a long +way to remedy this problem.  However, this is not a standard and +there's still plenty of older motherboards in use.  Therefore, I +recommend against hot-plugging a PS/2 mouse or keyboard.
+

+ + +
+

Summary: Power Specifications
+ Vcc = +4.5V to +5.5V.  
+ Max Current = 275 mA.
+

+
+ +

The Data and Clock lines are both open-collector with pullup resistors + to Vcc.  An "open-collector" interface has two possible state: low, + or high impedance.  In the "low" state, a transistor pulls the line + to ground level.  In the "high impedance" state, the interface acts + as an open circuit and doesn't drive the line low or high. Furthermore, +a "pullup" resistor is connected between the bus and Vcc so the bus is pulled + high if none of the devices on the bus are actively pulling it low.  The + exact value of this resistor isn't too important (1~10 kOhms); larger resistances + result in less power consumption and smaller resistances result in a faster + rise time.  A general open-collector interface is shown below:
+ +

+ +
+

Figure 1: General open-collector interface.  Data + and Clock are read on the microcontroller's pins A and B, respectively. + Both lines are normally held at +5V, but can be pulled to ground by + asserting logic "1" on C and D.  As a result, Data equals D, inverted, + and Clock equals C, inverted.
+

+
+ +
+

+
+ +

+
+ +


+ Note: When looking through examples on this website, you'll notice +I use a few tricks when implementing an open-collector interface with +PIC microcontrollers.  I use the same pin for both input and output, +and I enable the PIC's internal pullup resistors rather than using external + resistors.  A line is pulled to ground by setting the corresponding + pin to output, and writing a "zero" to that port.  The line is set +to the "high impedance" state by setting the pin to input.  Taking +into account the PIC's built-in protection diodes and sufficient current +sinking, I think this is a valid configuration.  Let me know if your +experiences have proved otherwise.
+
+ Communication: General Description
+ +

+ +

The PS/2 mouse and keyboard implement a bidirectional synchronous serial + protocol.  The bus is "idle" when both lines are high (open-collector). +  This is the only state where the keyboard/mouse is allowed begin + transmitting data.  The host has ultimate control over the bus and + may inhibit communication at any time by pulling the Clock line low.  
+

+ +

The device always generates the clock signal.  If the host wants +to send data, it must first inhibit communication from the device by pulling + Clock low.  The host then pulls Data low and releases Clock.  This + is the "Request-to-Send" state and signals the device to start generating + clock pulses.
+ +

+ +
+

Summary: Bus States
+ Data = high, Clock = high:  Idle state.
+ Data = high, Clock = low:  Communication Inhibited.
+ Data = low, Clock = high:  Host Request-to-Send

+ +
+   All data is transmitted one byte at a time and each byte is +sent in a frame consisting of 11-12 bits.  These bits are: + + + + +

The parity bit is set if there is an even number of 1's in the data bits + and reset (0) if there is an odd number of 1's in the data bits.  + The number of 1's in the data bits plus the parity bit always add up to +an odd number (odd parity.)  This is used for error detection.  The + keyboard/mouse must check this bit and if incorrect it should respond + as if it had received an invalid command.
+

+ +

Data sent from the device to the host is read on the falling edge +of the clock signal; data sent from the host to the device is read on the + rising edge.  The clock frequency must be in the +range 10 - 16.7 kHz.  This means clock must be high for 30 - 50 microseconds +and low for 30 - 50 microseconds..  If you're designing a keyboard, +mouse, or host emulator, you should modify/sample the Data line in the +middle of each cell.  I.e.  15 - 25 microseconds after the appropriate +clock transition.  Again, the keyboard/mouse always generates the clock +signal, but the host always has ultimate control over communication. +

+ + +

+ Timing is absolutely crucial.  Every time quantity I give +in this article must be followed exactly.
+
+ Communication: Device-to-Host
+ +

The Data and Clock lines are both open collector.  A resistor is +connected between each line and +5V, so the idle state of the bus is high. + When the keyboard or mouse wants to send information, it first checks +the Clock line to make sure it's at a high logic level.  If it's not, + the host is inhibiting communication and the device must buffer any to-be-sent + data until the host releases Clock.  The Clock line must be continuously + high for at least 50 microseconds before the device can begin to transmit + its data. 

+ + +

As I mentioned in the previous section, the keyboard and mouse use a +serial protocol with 11-bit frames.  These bits are:

+ + + The keyboard/mouse writes a bit on the Data line when Clock + is high, and it is read by the host when Clock is low.  Figures 2 +and 3 illustrate this.
+ + +

Figure 2:  Device-to-host communication.  + The Data line changes state when Clock is high and that data is valid + when Clock is low.
+

+ +
+
+ +

+ + +

Figure 3:  Scan code for the "Q" key (15h) being +sent from a keyboard to the computer.  Channel A is the Clock signal; +channel B is the Data signal.

+ +
--- +
+
+ +

The clock frequency is 10-16.7 kHz.  The time from the rising + edge of a clock pulse to a Data transition must be at least 5 microseconds.  + The time from a data transition to the falling edge of a clock pulse +must be at least 5 microseconds and no greater than 25 microseconds.  + +
+

+ +

The host may inhibit communication at any time by pulling the Clock + line low for at least 100 microseconds.  If a transmission is inhibited + before the 11th clock pulse, the device must abort the current transmission + and prepare to retransmit the current "chunk" of data when host releases + Clock.  A "chunk" of data could be a make code, break code, device + ID, mouse movement packet, etc.  For example, if a keyboard is interrupted + while sending the second byte of a two-byte break code, it will need to + retransmit both bytes of that break code, not just the one that was interrupted.
+

+ +

If the host pulls clock low before the first high-to-low clock transition, + or after the falling edge of the last clock pulse, the keyboard/mouse +does not need to retransmit any data.  However, if new data is created +that needs to be transmitted, it will have to be buffered until the host +releases Clock.  Keyboards have a 16-byte buffer for this purpose. + If more than 16 bytes worth of keystrokes occur, further keystrokes +will be ignored until there's room in the buffer.  Mice only store +the most current movement packet for transmission.

+ + + +

Host-to-Device Communication:
+

+ +

The packet is sent a little differently in host-to-device communication... +

+ +

First of all, the PS/2 device always generates the clock signal.  + If the host wants to send data, it must first put the Clock and Data +lines in a "Request-to-send" state as follows:

+ + + The device should check for this state at intervals not to exceed + 10 milliseconds.  When the device detects this state, it will begin + generating Clock signals and clock in eight data bits and one stop bit.  + The host changes the Data line only when the Clock line is low, +and data is read by the device when Clock is high.  This is opposite +of what occours in device-to-host communication. + +

After the stop bit is received, the device will acknowledge the received + byte by bringing the Data line low and generating one last clock pulse.  + If the host does not release the Data line after the 11th clock pulse, the + device will continue to generate clock pulses until the the Data line is +released (the device will then generate an error.)

+ + +

The host may abort transmission at time before the 11th clock pulse + (acknowledge bit) by holding Clock low for at least 100 microseconds. +

+ +

To make this process a little easier to understand, here's the steps + the host must follow to send data to a PS/2 device:

+ +
1)   Bring the Clock line low for at least 100 microseconds. +
+ 2)   Bring the Data line low.
+ 3)   Release the Clock line.
+ + 4)   Wait for the device to bring the Clock line low. +
+ 5)   Set/reset the Data line to send the first data bit +
+ 6)   Wait for the device to bring Clock high.
+ 7)   Wait for the device to bring Clock low.
+ + 8)   Repeat steps 5-7 for the other seven data bits and + the parity bit
+ 9)   Release the Data line.
+ 10) Wait for the device to bring Data low.
+ 11) Wait for the device to bring Clock  low.
+ + 12) Wait for the device to release Data and Clock
+ +


+ Figure 3 shows this graphically and +Figure 4 separates the timing to show which signals are generated by the +host, and which are generated by the PS/2 device.  Notice the change +in timing for the "ack" bit--the data transition occours when the Clock + line is high (rather than when it is low as is the case for the other +11 bits.)

+ +

Figure 3:  Host-to-Device Communication. +
+ + +

+ +

Figure 4:  Detailed host-to-device communication. +
+ +
+  

+ + +

Referring to Figure 4, there's two time quantities the host looks for. +  (a) is the time it takes the device to begin generating clock pulses + after the host initially takes the Clock line low, which must be no greater + than 15 ms. (b) is the time it takes for the  packet to be sent, which + must be no greater than 2ms.  If either of these time limits is not +met, the host should generate an error.  Immediately after the "ack" +is received, the host may bring the Clock line low to inhibit communication + while it processes data.  If the command sent by the host requires +a response, that response must be received no later than 20 ms after the +host releases the Clock line.  If this does not happen, the host generates + an error.

+ +
+
+
+ + diff --git a/docs/www.computer-engineering.org/ps2protocol/ps2.JPG b/docs/www.computer-engineering.org/ps2protocol/ps2.JPG new file mode 100644 index 0000000..067edaf Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/ps2.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/qscope.JPG b/docs/www.computer-engineering.org/ps2protocol/qscope.JPG new file mode 100644 index 0000000..aa62a11 Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/qscope.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/sdl.jpg b/docs/www.computer-engineering.org/ps2protocol/sdl.jpg new file mode 100644 index 0000000..9e2f926 Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/sdl.jpg differ diff --git a/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg b/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg new file mode 100644 index 0000000..df7ceab Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg differ diff --git a/docs/www.computer-engineering.org/ps2protocol/spindin.JPG b/docs/www.computer-engineering.org/ps2protocol/spindin.JPG new file mode 100644 index 0000000..e60cb72 Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/spindin.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG b/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG new file mode 100644 index 0000000..a0ec642 Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG differ diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg new file mode 100644 index 0000000..cda9a5c Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg differ diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg new file mode 100644 index 0000000..f234c1e Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg differ diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg new file mode 100644 index 0000000..560ac50 Binary files /dev/null and b/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg differ -- cgit v1.2.3