📄 the ps-2 keyboard interface.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0048)http://www.computer-engineering.org/ps2keyboard/ -->
<HTML><HEAD><TITLE>The PS/2 Keyboard Interface</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2180" name=GENERATOR>
<META content="Adam Chapweske" name=Author><!--This file created 10:20 PM 3/29/01 by Claris Home Page version 3.0-->
<META content="Adam Chapweske" name=author></HEAD>
<BODY vLink=#3333ff aLink=#3333ff link=#3333ff bgColor=#ffffff><SMALL><B><FONT
face=Arial,Helvetica><FONT size=+3><SMALL>The PS/2 Keyboard
Interface</SMALL></FONT></FONT></B></SMALL><BR>
<CENTER></CENTER>
<CENTER>
<HR align=left width=400 noShade SIZE=1>
</CENTER><BR><FONT face=Arial,Helvetica>Source: <A
href="http://www.computer-engineering.org/">http://www.computer-engineering.org/</A></FONT><BR><FONT
face=Arial,Helvetica>Author: Adam Chapweske<BR>Last Updated:
04/01/03<BR><BR></FONT><B>Legal Information:</B><BR><BR>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. <BR><BR>This article is protected under
copyright law. This document may be copied only if the source, author,
date, and legal information is included.<BR><BR><B>Abstract:</B><BR><BR>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 <A href="http://www.microchip.com/">Microchip's</A> PIC
microcontrollers. All code samples related to the keyboard controller are
written in x86 assembly<BR>
<P><B>A History Lesson:</B> </P>
<P>The most popular keyboards in use today include: </P>
<UL>
<LI>USB keyboard - Latest keyboard supported by all new computers (Macintosh
and IBM/compatible). These are relatively complicated to interface and
are not covered in this article.
<LI>IBM/Compatible keyboards - Also known as "AT keyboards" or "PS/2
keyboards", all modern PCs support this device. They're the easiest to
interface, and are the subject of this article.
<LI>ADB keyboards - Connect to the Apple Desktop Bus of older Macintosh
systems. These are not covered in this article </LI></UL>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.
<P>IBM PC/XT Keyboard (1981): </P>
<UL>
<LI>83 keys
<LI>5-pin DIN connector
<LI>Simple uni-directional serial protocol
<LI>Uses what we now refer to as scan code set 1
<LI>No host-to-keyboard commands </LI></UL>IBM AT Keyboard (1984) - Not backward
compatible with XT systems<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#A%20History%20Lesson%20FN">(1)</A></TT>.
<UL>
<LI>84 -101 keys
<LI>5-pin DIN connector
<LI>Bi-directional serial protocol
<LI>Uses what we now refer to as scan code set 2
<LI>Eight host-to-keyboard commands </LI></UL>IBM PS/2 Keyboard (1987) -
Compatible with AT systems, not compatible with XT systems<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#A%20History%20Lesson%20FN">(1)</A></TT>.
<UL>
<LI>84 - 101 keys
<LI>6-pin mini-DIN connector
<LI>Bi-direction serial protocol
<LI>Offers optional scan code set 3
<LI>17 host-to-keyboard commands </LI></UL>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 <I>compatible</I> with PS/2 and AT systems, but
it may not fully support all the features of the original devices.
<P>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... </P>
<P>Modern PS/2 (AT) compatible keyboards </P>
<UL>
<LI>Any number of keys (usually 101 or 104)
<LI>5-pin or 6-pin connector; adaptor usually included
<LI>Bi-directional serial protocol
<LI>Only scan code set 2 guaranteed.
<LI>Acknowledges all commands; may not act on all of them. </LI></UL><A
name="A History Lesson FN"></A><BR><I>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.</I>
<P><B>General Description:</B> </P>
<P>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<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#General%20Description%20FN">(1)</A></TT>
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"<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#General%20Description%20FN">(2)</A></TT>
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. <BR><A
name="General Description FN"></A><BR><I>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.</I> </P><I>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.</I>
<P><B>Electrical Interface / Protocol:</B> </P>
<P>The AT and PS/2 keyboards use the same protocol as the PS/2 mouse.
Click <A href="http://www.computer-engineering.org/ps2protocol">here</A> for
detailed information on this protocol. </P>
<P><B>Scan Codes:</B> </P>
<P>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"<I> </I>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.<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#Scancodes%20FN">(1)</A></TT>
</P>
<P>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: </P>
<UL>
<LI><A
href="http://www.computer-engineering.org/ps2keyboard/scancodes1.html">Scan
Code Set 1</A> - Original XT scan code set; supported by some modern keyboards
<LI><A
href="http://www.computer-engineering.org/ps2keyboard/scancodes2.html">Scan
Code Set 2</A> - Default scan code set for all modern keyboards
<LI><A
href="http://www.computer-engineering.org/ps2keyboard/scancodes3.html">Scan
Code Set 3</A> - Optional PS/2 scan code set--rarely used </LI></UL><A
name="Scancodes FN"></A><BR><I>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. </I>
<P><B>Make Codes, Break Codes, and Typematic Repeat:</B> </P>
<P>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 <U>key</U> 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. </P>
<P>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. </P>
<P>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<TT><A
href="http://www.computer-engineering.org/ps2keyboard/#MakeBreakTypematic%20FN">(1)</A></TT>.
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: </P>
<BLOCKQUOTE>
<BLOCKQUOTE>
<BLOCKQUOTE>
<TABLE cols=3 width=300 border=1>
<TBODY>
<TR>
<TD>
<CENTER>Key</CENTER></TD>
<TD>
<CENTER>(Set 2) <BR>Make Code</CENTER></TD>
<TD>
<CENTER>(Set 2) <BR>Break Code</CENTER></TD></TR>
<TR>
<TD>
<CENTER>"A"</CENTER></TD>
<TD>
<CENTER>1C</CENTER></TD>
<TD>
<CENTER>F0,1C</CENTER></TD></TR>
<TR>
<TD>
<CENTER>"5"</CENTER></TD>
<TD>
<CENTER>2E</CENTER></TD>
<TD>
<CENTER>F0,2E</CENTER></TD></TR>
<TR>
<TD>
<CENTER>"F10"</CENTER></TD>
<TD>
<CENTER>09</CENTER></TD>
<TD>
<CENTER>F0,09</CENTER></TD></TR>
<TR>
<TD>
<CENTER>Right Arrow</CENTER></TD>
<TD>
<CENTER>E0, 74</CENTER></TD>
<TD>
<CENTER>E0, F0, 74</CENTER></TD></TR>
<TR>
<TD>
<CENTER>Right "Ctrl"</CENTER></TD>
<TD>
<CENTER>E0, 14</CENTER></TD>
<TD>
<CENTER>E0, F0,
14</CENTER></TD></TR></TBODY></TABLE></BLOCKQUOTE></BLOCKQUOTE>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.</BLOCKQUOTE>If you press a key, its make code is sent to the
computer. When you press and hold down a key, that key becomes
<I>typematic</I>, 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
<I>typematic delay</I>, which is the short delay between the first and second
"a", and the <I>typematic rate</I>, 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.
<P>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. </P>
<P><A name="MakeBreakTypematic FN"></A><BR><I>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.</I> </P>
<P><B>Reset:</B> </P>
<P>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: </P>
<UL>
<LI>Typematic delay 500 ms.
<LI>Typematic rate 10.9 cps.
<LI>Scan code set 2.
<LI>Set all keys typematic/make/break. </LI></UL>
<P>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. </P>
<P>Many of the keyboards I've tested ignore their CLOCK and DATA lines until
<I>after</I> 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. </P>
<P><B>Command Set:</B> </P>
<P>A few notes regarding commands the host can issue to the keyboard:<BR></P>
<UL>
<LI>The keyboard clears its output buffer when it recieves any command.
<LI>If the keyboard receives an invalid command or argument, it must respond
with "resend" (0xFE).
<LI>The keyboard must not send any scancodes while processing a command.
<LI>If the keyboard is waiting for an argument byte and it instead receives a
command, it should discard the previous command and process this new one.
</LI></UL>Below are all the commands the host may send to the keyboard:<BR>
<UL>
<LI>0xFF (Reset) - Keyboard responds with "ack" (0xFA), then enters "Reset"
mode. (See "Reset" section.)
<LI>0xFE (Resend) - Keyboard responds by resending the last-sent byte.
The exception to this is if the last-sent byte was "resend" (0xFE).
If this is the case, the keyboard resends the last non-0xFE byte.
This command is used by the host to indicate an error in reception.
</LI></UL>
<BLOCKQUOTE>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.) <BR></BLOCKQUOTE>
<UL>
<LI>*0xFD (Set Key Type Make) - Disable break codes and typematic repeat for
specified keys. Keyboard responds with "ack" (0xFA), then disables
scanning (if enabled) and reads a list of keys from the host. These keys
are specified by their set 3 make codes. Keyboard responds to each make
code with "ack". Host terminates this list by sending an invalid set 3
make code (eg, a valid command.) The keyboard then re-enables scanning
(if previously disabled).
<LI>*0xFC (Set Key Type Make/Break) - Similar to previous command, except this
one only disables typematic repeat.
<LI>*0xFB (Set Key Type Typematic) - Similar to previous two, except this one
only disables break codes.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -