Keying On A Standard

Author: Bob Smith
Source: PC Tech Journal, vol 5, no 7, July 1987 (page 134+)

The 101-key enhanced keyboard, declared the standard for IBM's entire line of PCs, introduces a fundamental difference in the hardware and software interface to the system.

Staying power has never been the strongest attribute of IBM‘s keyboards. With the introduction of almost every model in the PC line has come a new version of the “standard" keyboard—that’s three keyboards in five years. Worse, the differences between keyboards have been more than cosmetic, involving some fundamental software incompatibilities; every new keyboard model required that not only users, but also the software be retrained.

At last, IBM seems ready to end the frustration. The company has stated that all of its personal computers and terminals will use one model: the 101-key Enhanced Keyboard, introduced with the IBM RT PC in January 1986. The enhanced keyboard was subsequently made available with the 8-MHz model of the PC/AT, the XT-286, and the PC/XT models manufactured since April 1986. For reasons explained later, this keyboard cannot be retrofitted to systems not designed to support it.

Keyboard standardization received a boost with the introduction of the IBM Personal System/2 (PS/2) line; all models come with the enhanced keyboard. In fact, IBM has strengthened its' commitment to the enhanced keyboard by making it the only model available for the PS/2 machines (For the AT, the older 84-key model is available on special order as a no—cost option)

Photo 1: The 101-key Enhanced Keyboard
The enhanced keyboard has a dedicated cursor keypad and twelve function keys.

The most obvious differences in the enhanced keyboard from previous models are the set of additional dedicated cursor control keys between the original numeric/cursor control keypad and the typewriter section, the line of function keys (12 instead of 10) across the top, and the shift state indicator lights. Photo 1 shows the layout of the enhanced keyboard. Actually, the enhanced keyboard comes in two versions: a 101-key and a 102-key layout. The latter, available only outside of the US, is referred to in IBM documentation as the WT, or World Trade keyboard. It has an additional alphabetical key nestled in the crook of the Enter Key, which is a larger, hook-shaped key on the WT; the backslash is located between the Z and the left shift key (as on the original PC keyboard), To support a variety of national languages, the WT keyboard is available with several different layouts of the alphabetic keys.

According to IBM documentation, the U.S. and WT versions of the enhanced keyboard are identical at the software level. The setup program for the PS/2 models cannot distinguish between them; instead; it asks the user to identify the keyboard by indicating the shape of the Enter key.

System Interface

An overview of the enhanced keyboard interface, and its difference from previous models, can best be presented in terms of the incremental changes introduced to that interface with each keyboard model since the original PC.

Figure 1: PC Processing
The PC introduced the concept of translating keystroke data into character codes and extended key codes. It applied one level of translation.

Figure 1 shows the steps involved in processing keyboard input on a standard PC or AT. Each keystroke sends to the keyboard controller a one-byte scan code, which is a number uniquely identifying the key. The controller places the scan code unchanged in its output buffer, and generates a hardware interrupt that causes the processor to execute an interrupt 09H.

The interrupt service routine (the default interrupt 09H handler is in the ROM BIOS) looks up the scan code in its internal tables and translates it into a two-byte code. In most cases, one of these bytes is the original scan code and, if the key represents an ASCII character, the other is the ASCII code. For non-ASCII characters, the second byte is usually zero.

This two-byte code is placed into the next available location in the circular keyboard buffer, where it waits to be read by an input request from a program. Keyboard read requests are processed by the interrupt 16H handler, which reads the two-byte key codes from the buffer and passes them unmodified to the requesting program.

Figure 2: 84-key Processing
The first AT keyboard added another layer of translation at the level of the keyboard controller. Above that, the data are the same as in the PC.

The 84-key keyboard introduced with the first model of the AT has a different key layout and produces scan codes distinct from those of the original 85-key PC keyboard. The scan-code sets on the two keyboards are different because, for reasons of physical circuit design, it is most efficient to assign scan codes by key location. To maintain compatibility at the software level, IBM introduced a preliminary scan-code translation at the controller level, shown in Figure 2. After translation, the controller's output for a given key is the same as that key‘s output from a PC keyboard controller, thus the interrupt 09H handler and all subsequent software see the same set of key codes as on the original PC.

Figure 3: 101-key Processing
The enhanced keyboard added the capability of switching scan-code sets. Recognizing the new keys requires enhanced support to be present in the keyboard routines of the BIOS.

The 101-key enhanced keyboard introduced yet another key layout. Instead of merely coming up with a new set of scan codes for the new layout, IBM came up with three. By default, the scan-code set made active at boot—up is, for the most part, the same as produced by the 84-key model and is translated by the controller in much the same fashion. Differences arise because the enhanced keyboard produces output for the additional keys not present on the previous models. As shown in Figure 3, these differences are handled by an additional translation step at the other end of the process, within the interrupt 16H handler that passes the two-byte codes out of the keyboard buffer to the requesting program.

The enhanced keyboard adds flexibility at two levels. First, the basic scan codes it produces at the keyboard end of the process are not fixed, but can be chosen from three sets. Second, the output at the other end of the process is filtered through an additional layer of translation. Customized programs can modify either or both ends of the process to modify the transformation of keystrokes into program input.

The differences between the enhanced keyboard and previous models go much deeper than layout and key count. One immediately noticeable difference is that, at boot-up, the enhanced keyboard is put in the NumLock state. This change from past behavior adds to the hardship of transition to the new layout. It is a minor symptom of the many changes made to the keyboard itself and to its interface with the support software, but it can be easily remedied. The following program turns off the NumLock bit in the shift status byte that the BIOS uses when reading keystrokes.


It can be assembled into a .COM file (a debugger is more practical than an assembler) and then invoked from the AUTOEXECBAT file.

BIOS Interface

The enhanced keyboard can be used only with systems that support it with an enhanced interrupt 16H handler in the BIOS. According to IBM documentation, this includes the following models: the AT with the BIOS dated 11/15/86 and later; the XT with the BIOS dated 1/10/86 and later; the XT-286; and all of the PS/2 models The enhanced BIOS routines support 70 new ASCII/scan code pairs as listed in Table 1. Some of these codes are the result of the new keys that are present on the enhanced keyboard (F11, F12, and the additional cursor control keys), while others add support for combinations of keys that were present but not recognized on previous keyboards (for example, Ctrl-up arrow, Ctrl-down arrow, and 5 on the numeric keypad).

Table 1: Handling of New Keys by BIOS Interrupt 16H
For compatibility with programs that cannot handle the enhanced keys, the BIOS translates or discards key codes unless requested through an enhanced function.

In describing the keys on the right-hand side of the various keyboards, the following terminology will be used. Cursor control keys on the original numeric keypad will be named without prefix, such as Home or Del. Other keys around the keypad will be prefixed with “Pad-“, as in Pad-Enter or Pad-asterisk. Finally, the dedicated cursor control keys between the keypad and the typewriter section will be prefixed With X, as in X-up arrow and X-End.

Table 2: BIOS Interrupt 16H Functions
The enhanced interrupt 16H handler recognizes eight functions; the last three deal specifically with the keys unique to the enhanced keyboard.

The functions provided by the enhanced interrupt 16H handler are summarized in Table 2. Two functions are used for reading characters from the keyboard buffer (AH = 00H and AH = 10H) and two are used for determining the presence of characters in the buffer (AH = 01H and AH = 11H). For keys that are common to both the 84-key and 101-key keyboards, each pair of functions operates identically. But their action is different for keys that are present only on the enhanced keyboard. The handling of the new keys by the standard and enhanced functions is listed in Table 1. This information is not formally documented; it was determined by reading the BIOS listings and verifying it with test programs.

When a standard function encounters an enhanced key code, the code is either discarded or, if it duplicates one of the standard keys, is translated to a standard key code. Thus, the codes for pad-Enter and pad-slash are translated to the codes for Enter and slash in the standard set of keys. If, for example, F11 is the only key in the buffer and an AH = 01H call requests buffer status, the response is that no keys are present in the buffer. Unfortunately, that response turns out to be true because, after the call, there are in fact no keys in the buffer - the F11 key gets deleted by the status call. The effect is that programs not written for the enhanced keyboard see nothing different when keys specific to the enhanced keyboard are pressed. That approach is overly conservative because all programs should be written to handle unknown keystrokes. Furthermore, this unconditional deletion of keys can create problems even for programs that use only the enhanced BIOS functions.

When the enhanced functions (AH = 10H and AH : 11H) are used, however, enhanced key codes are never deleted; they are either passed through unchanged or translated as indicated in Table 1. The encoding of the new keys exhibits a structure designed for efficient handling by both the standard and enhanced keyboard reading functions of interrupt 16H. Except for a few special cases, a code in the keyboard buffer represents one of the new keys if its low-order is 00H or F0H, or the high-order byte is greater than 84H. A low-order byte of E0H is assigned to new keys that duplicate the functions of existing keys, such as those on the dedicated cursor control keypad. A low-order byte of F0H is assigned to keys that exist on the 84-key keyboard but are ignored by earlier versions of the BIOS, such as Pad-5 and Ctrl-up arrow, A high-order byte greater than 84H is used for totally new keys, such as F11 and F12.

The translation rules for new keys, when read with functions AH = 0CH and AH = 01H, are as follows:
- If high byte > 84H, discard the entry;
- If low byte = F0H, discard the entry;
- If low byte = E0H, set low byte to 0 and return that entry.

The exceptions are E00DH (Pad-Enter), which is translated to 1C0DH (Enter); E00AH (Ctrl-Pad-Enter), which is translated to 1C0AH (Ctrl-Enter or LF); E02FH (Pad-slash), which is translated to 352FH (slash); and 00E0H (Alt-Pad 224, Greek alpha) and 00F0H (Alt-Pad 240, triple horizontal line), which are returned unchanged.

For functions AH = 10H and AH = 11H, the rules are simpler. If the low-order byte is F0H, it is changed to 00H and returned; all other key codes are returned unchanged. These codes represent keys present on the standard keyboard, but recognized only by the enhanced BIOS functions.

To take advantage of these new ASCII/scan—code pairs, programs must use the extended interrupt 16H BIOS functions, AH = 10H and AH = 11H. Requesting input through DOS will not work because DOS is not sensitive to the enhanced keyboard - it uses the standard low-numbered calls only. Surprisingly, this is true even for version 3.5 (specifically written to support the PS/2 series, which requires the enhanced keyboard). However, using the BIOS instead of DOS calls for keyboard I/O means that the input redirection facilities of DOS are not available.

DOS calls to the keyboard routine cannot always be prevented; the resulting behavior can be quite hard to diagnose. Suppose that a program consistently uses the enhanced interrupt 16H functions so it can accept the extended keystrokes. However, if the user presses any enhanced key while the system is displaying characters on the screen, that keystroke is lost. Where did it go? When running with BREAK ON, DOS checks for Ctrl-Break and Ctrl-C each time it outputs a character to the display. It does so by requesting keyboard status with interrupt 16H function AH = 01H, thus deleting all leading extended keystrokes from the buffer. One solution to this problem is to install a customized interrupt 16H handler that converts all AH = 00H and AH = 01H calls to AH = 10H and AH = 11H respectively. Listing 1 shows such a program. With the customized handler installed, it becomes possible to use DOS calls in programs that need to receive the enhanced keys, thus restoring the input redirection capability.

Listing 1: ENHANKB.ASM

The enhanced interrupt 16H handler also has two functions that return the Shift-key status. Function 2 returns the standard status byte, the same one as this function did in all versions of the BIOS keyboard routine. The enhanced function (AH : 12H) returns two bytes of shift status information. The meaning of the bits in both bytes is shown in Figure 4. Because the enhanced keyboard has two Ctrl and two Alt keys, the extended status information allows programs to distinguish which of the two Alt or Ctrl keys is being pressed. Furthermore, status bits are available to determine if any of the three toggle keys (CapsLock, ScrollLock, and NumLock) is being held down. In the standard shift status byte, the bits for these keys just reflect the current state of the toggle, not the actual position of the key. Note that the position of the fourth key often used as a toggle, Ins, is not reflected in the status bits.

Figure 4: Keyboard Shift Status Bytes
The BIOS maintains an accurate record of the position of certain keys in these two bytes. They are returned in AX from interrupt 16H function AH = 02H.

The interrupt 16H function with AX = 0505H controls the typematic action of the keyboard—that is, the rate at which keystrokes are repeated when a key is held down (see “Rev Up the AT Keyboard,” Kevin M, Crenshaw, Tech Notebook, May 1985, p. 39). This function is fully supported by the BIOS code in all AT models, but it was not documented in the prologue to the interrupt 16H listing in IBM’s Technical Reference Manual. The latest version of the BIOS documentation (which covers the entire IBM PC line, from the original PC through all the PS/2 models) now supplies this documentation. Two parameters are controlled by the interrupt 16H function: the delay before the repeating action begins, and the rate of repetition once it does begin. Both settings must be specified even though only one is to be changed.

The typematic delay (after which typematic action begins) is changed by setting register BH to a value between 00H and 03H (range-checked by the BIOS). The values BH = 00H, 01H, 02H, and 03H correspond to delays of 250 milliseconds (ms), 500 ms, 750 ms, and 1000 ms respectively. The typematic rate is set by the value in BL; it is also range-checked and must be between 00H and 1FH. Setting BL = 00H corresponds to 50 characters per second (cps); BL = 0BH restores the default rate of 10.9 cps; and BL = 1FH slows the keyboard down to 2 cps. Many fine gradations are possible, but the repeating action cannot be turned off.

This function requires AL = 05H. Support to control the typematic rate was introduced in the PCjr BIOS, which defines subfunctions AL = 00H through 04H. The enhanced keyboard’s typematic feature is unlike any of the PCjr’s, so a new subfunction was defined. None of the PCjr subfunctions is supported by the AT BIOS. The typematic feature, while supported in most AT compatibles and 80386-based machines, should be treated carefully. For example, the Phoenix 80386 ROM BIOS (version 3.03 and earlier) decrements AX and then jumps to code that checks for AL = 05H. Consequently, AX = 0306H is required to set the typematic parameters in that BIOS. This bug has been fixed in versions 3.04 and later.

The final enhanced function of the interrupt 16H handler is AH = 05H, the insert key code, which inserts the ASCII/scan-code pair from CX into the keyboard buffer as if it had just been typed at the keyboard (that is, at the end of the first-in, first-out buffer). The BIOS does absolutely no checking of the value. The CH register contains the scan code; CL contains the ASCII character (or extended ASCII code). Carefully follow the translation rules that were outlined above when placing codes into the buffer. For the new keys, codes retrieved from the buffer are not necessarily the same as the codes placed into it; when using functions 00H and 01H, some codes are never retrieved.

Function 05H can be used to seed the keyboard buffer with a program’s input prior to invoking that program, although the default buffer size of 15 keys may be too limiting. This is different from redirecting standard input because, after all the key codes have been read from the buffer, the program waits for further input from the keyboard. With redirection, the program hangs at the end of the input file.

A feature in the BIOS interface can be used to identify the keyboard as either the 84-key or 101-key model. The byte at address 40:96H of the BIOS data area will have bit 4 set to 1, if the enhanced keyboard was detected on bootup, or 0, if otherwise. This feature is documented in the latest BIOS reference manual, so it should be supported by compatibles. It is implemented in Compaq models and in the Phoenix BIOS versions 3.02 and later for 80286- and 80386- based machines.

Testing this bit is the easiest way of determining the keyboard type, but the result reflects the keyboard present when the system was last booted. Because it is possible to switch keyboards without resetting the system, a different keyboard may be present at the time of the test. A method for determining the type of keyboard currently attached is described in a later section.

The Keyboard Controller

Normally, communications between programs and the keyboard takes place by way of the BIOS calls explained above. The BIOS routines perform the actual I/O to the keyboard controller. Occasionally, programs might need to talk directly to the hardware in order to perform functions not supported by the BIOS. One example is in determining the type of keyboard attached.

The keyboard system consists of a Motorola 6805 microprocessor within the keyboard and an Intel 8042 controller on the motherboard. Programs can communicate with either chip. The only information on this subject is scattered over several sections of the Technical Reference Manual; it is cryptic and occasionally misleading. For example, the manual does not distinguish between the keyboard and the controller, using the term keyboard to refer to either or both the 6805 and 8042.

The 8042 keyboard controller on the motherboard directs communications traffic between the system and the keyboard. The controller is implemented identically in all models of the AT, regardless of the keyboard support present in the BIOS. In the PS/2 models, the functions of the 8042 are a superset of those in the AT. This article considers only the AT implementation.

The controller communicates with the keyboard via a serial link that supports either an 11-bit protocol with parity checking or a 9-bit protocol without it. The former is the format used by the AT keyboard, the latter by the original PC keyboard. At boot-up, the keyboard is in the 11-bit mode, which supports either the standard or enhanced AT keyboard. The controller can be switched into 9-bit mode to support the original 83-key PC keyboard.

By default, the 8042 translates the scan codes it receives from the 6805 to those recognized by the BIOS. The translation table is kept in ROM on the 8042 chip and is not accessible to programs; it is published in the Technical Reference Manual. As each scan code is received, the 8042 interrupts the processor. Both the translation and the generation of the interrupt can be disabled by reprogramming the controller.

The system and 8042 communicate with each other via a status register, an input buffer, and an output buffer. The 8042 also has a program-accessible command byte that controls its actions. All are accessed via I/O ports. The Technical Reference Manual also refers to additional components of the 8042: an input port, an output port, and a test, input port. However, they are neither directly accessible as I/O ports nor involved in the keyboard interface. The input port contains the value of switch settings and jumpers on the system board (such as the keyboard-lock and display-adapter switches). The output port (which, despite its name, can be read from as well as written to) is used only during system start-up and shutdown, while the test input port is used only for hardware checkout.

The 8042 status register is a read only port located at I/O address 64H. Its contents may be read at any time; the bit definitions are summarized in Figure 5. Its most important function is to synchronize data flow between the controller and the system.

Figure 5: 8042 Status Register
A program can be used to determine the status of the keyboard controller at any time by reading this byte from an I/O port.

The output buffer (from the 8042 to the system) is a read-only port located at I/O address 60H. From it, the system can read the scan codes received from the 6805 (after translation, if that feature is enabled) and responses to 8042 commands. An instruction to read this port should be executed only when the status register indicates that the output buffer is full; at other times the result is undefined. There is no clear indication as to how long the 8042 might take to respond to a command to fill its output buffer. An 8-MHz AT waits for about 1,200 ms for this condition, using a programmed delay loop. When the system reads the output buffer, bit 0 of the status register (output buffer full) is automatically cleared.

The input buffer (from the system to 8042) is a one-byte write-only port that can be addressed as either I/O port 60H or 64H. Commands to the 8042 are written to port 64H; data for the 8042 and for the 6805 are sent to port 60H. Nothing should be sent to the input buffer unless the status register indicates that it is empty. As with the output buffer, there is no clear indication as to how long a program should wait for the 8042 to read its input buffer, but the BIOS code for an 8-MHz AT uses a programmed delay loop of approximately 200 ms. The OUT instruction to either port address automatically sets bit 1 (input buffer full flag) of the status register. The 8042 resets the bit when it reads the input byte.

Table 3: 8042 Commands
The BIOS and other programs can communicate with the keyboard by sending the commands summarized here to the 8042 controller on the system board.

The commands to the 8042 are listed in Table 3; they are sent to I/O port 64H Commands 60H and D1H require that a subsequent byte of data be sent to I/O address 60H. The commands numbered C0H and higher manipulate the ports containing system initialization and test settings; they are not part of the keyboard interface.

Commands 20H and 60H read and write, respectively, the 8042 command byte. The bit definitions within this byte are shown in Figure 6: The effect of setting or clearing each bit is only vaguely documented in the Technical Reference Manual, and much of it needs to be developed by hands-on testing.

Figure 6: 8042 Command Byte
The value that is sent to the keyboard controller in this byte can fundamentally alter the standard operation of the keyboard.

When turned on, bit 0 causes the 8042 to interrupt the processor on IRQ1 when the controller’s output buffer is full. Turning this bit off effectively disables the keyboard, just as resetting bit 4 does. The quickest way of disabling and enabling the keyboard, however, is by sending commands ADH and AEH to I/O port 64H. These commands directly control bit 4 of the command byte with only one OUT instruction.

Bit 6 of the command byte controls what the Technical Reference Manual calls personal computer compatibility mode, or the translation of scan codes by the controller. When this bit is set to a 1, scan codes are translated from those generated by an AT keyboard to those generated by the same keys on a PC keyboard. The BIOS, even on an AT, recognizes only the PC set of scan codes, and the keyboard generates garbage if the translation is turned off.

The Technical Reference Manual is vague about how bit 5, the personal computer mode bit, differs from bit 6. (It allows the use of the original PC keyboard on an AT.) When the bit is set, the 8042 is placed into a 9-bit serial protocol with no parity checking - the protocol used by the PC keyboard. Because this mode is intended for use with a keyboard that generates the scan codes expected by the BIOS, scan-code translation is turned off.

However, this support of the original PC keyboard is only half-heartedly implemented. At boot-up, the 8042 in the AT is initialized to communicate with an AT-style keyboard; if the older model is connected, the boot process stops on a keyboard error. The screen displays the message “Press F1 to resume," but the system cannot recognize any data from the keyboard, including Ctrl-Alt-Del. The machine must be turned off in order to reboot.

The PC keyboard can be used with the AT by following this sequence: boot up the system with an AT keyboard (either model); run a program to switch the 8042 into PC mode; after the program runs, do not press any key on the AT keyboard or the system will crash; unplug the AT keyboard and plug in a PC keyboard. The system beeps a few times, but then functions properly.

The most surprising aspect of the keyboard controller is its ability to be programmed to ignore the keyboard lock switch on the front panel. If bit 3 of the command byte is turned on, the keyboard is active no matter what the position of the lock.

At boot-up, the BIOS initializes the 8042 command byte to 45H, which enables the following features: scan-code translation, AT—keyboard mode, data transfer to and from the 6805, the keyboard lock, and the generation of interrupts at each keystroke.

The Hardware Interface

The Motorola 6805 microprocessor resides in the keyboard. It scans the data lines from the keys and sends to the 8042 the scan code of each key as it is pressed and released. The microprocessor is present in the standard and enhanced AT keyboards, but the command set incorporated in each is different. The differences can be used by a program to determine which keyboard is attached to the system.

The system and the 6805 communicate with each other via I/O port 60H. Commands from the system to the 6805 are sent via OUT 60H,AL. Because that port is also the input buffer of the 8042 controller, these writes are intercepted by the 8042. The determination of whether the data byte is intended for the 8042 or for the 6805 is made by the state of the command/data bit (bit 3) of the 8042 status register (see Figure 5). The state of this bit is maintained automatically by the 8042 as it receives commands via port 64H. If the previous write to port 64H was a controller command requiring a subsequent data byte, the byte written to port 60H is kept by the 8042; otherwise, the data are passed through to the 6805. The commands from the system to the 6805 are summarized in Table 4. Those marked with an asterisk are supported only by the enhanced keyboard and are treated as no-operations by the 84-key model.

Table 4: Commands from the System to the 6805
At the lowest level accessible with programming, these commands control the operation of the keyboard microprocessor. They are sent via OUT 60H,AL.

The 6805 responds to all transmissions by sending one or more bytes to the output buffer of the 8042. The system can read each of these bytes by executing an IN AL,60H. As with all communication involving the I/O buffers, a program must determine that the input buffer is empty before sending a command to it and that the output buffer is full before reading from it. Generally, the 6805 responds to a command within 20 ms. To the 8042, all data coming from the 6805 (whether scan codes or command responses) are equivalent. If scan-code translation is enabled, any incoming data with a value that matches a scan code are translated by the 8042. Therefore, in order to get correct command responses from the 6805, a program should disable translation for the duration of the communication.

Table 5: Responses from the 6805 to the System
Besides sending the scan codes that corresponds to a user’s keystrokes, the keyboard also sends the responses to system level commands (via OUT 60H,AL).

Responses from the 6805 are summarized in Table 5. Most often, the response is ACK (acknowledge, FAH). For the two-byte commands, the 6805 responds to the initial byte with an ACK, stops scanning for keystrokes, and waits for the second byte (the option byte). To the two invalid commands, the 6805 responds with Resend (FEH); to the Resend command it responds with the previous output. Two commands (Read ID and Select Scan Code Set) produce responses of multiple bytes.

The BIOS uses the Set/reset LED Status command whenever it detects a change in the NumLock, CapsLock, or ScrollLock status. The low-order three bits of the option byte control the status of the ScrollLock, NumLock, and CapsLock indicators (bits 0, 1, and 2 respectively). Setting the bit turns the corresponding indicator light on; clearing it turns the light off. There is no means to read the current state to enable a program to set or clear just one light without affecting the others.

The Set Typematic Delay command is used by the BIOS interrupt 16H function AX = 0305H. The two parameters from registers BH and BL must be combined into one byte by placing the repeat rate value into bits 0 through 4, and by placing the initial delay value into bits 5 and 6. Bit 7 must be zero. The current setting of the typematic parameters cannot be interrogated.

The Echo command can be used to determine whether or not an AT-compatible keyboard is attached to the system. If, in reasonable time, the keyboard responds with Echo (EEH), the AT—style keyboard is determined to be present. Note that this response does not indicate whether or not an enhanced keyboard is present, only that it is AT compatible. In practice, setting the typematic rate and delay should work.

Only the enhanced keyboard supports the Read ID command; this command can be used to distinguish between 84-key and 101-key models. Both keyboards respond to this command with ACK, but the enhanced keyboard then follows this response with two more bytes: ABH and 83H. A program that tests the keyboard type should be written to time out if no further response is received within 500 ms of the initial response. A valid response to this command indicates that the enhanced keyboard is present, and that all of the commands in table 6 are valid.

This is the test used by the boot-up routine when setting the keyboard ID bit in location 40:96H of the BIOS data area. The boot-up routine indicates an enhanced keyboard if the second ID byte is either 83H or 85H. All of the keyboards tested (from IBM, including the PS/2 models and several AT compatibles) returned an ID of 85H.

Another feature present only in the enhanced keyboard is support for three scan-code sets. The Select Scan Code command (followed by an option byte of 1, 2, or 3) activates the scan-code set of that number. An option byte of zero causes the keyboard to respond with the number of the currently active scan-code set. The code sets differ in the values generated for the press and release of each key. (The Technical Reference Manual uses the terms make and break for press and release.)

At boot-up, scan-code set 2 is activated by default. For most keys, it sends a single-byte press code and a two-byte release code consisting of F0H followed by the press code. These codes need to be translated to the ones expected by the BIOS interrupt 09H routine. For example, the B key sends scan code 32H, which, if passed to the BIOS, would be interpreted as M. With code translation enabled, however, the 8042 keyboard controller translates the scan code to 30H (the same as sent by the B key of the PC keyboard), which is properly interpreted by the BIOS. The translation process also converts each two-byte release code to a one-byte code that is the same as the press code with the high bit turned on.

When scan—code set 1 is active, the keyboard produces codes that match the result of translating scan—code set 2. For the keys common to the enhanced and original PC keyboards, this code set produces the same press and release codes as the original keyboard. In effect, this code set moves the translation down a level from the 8042 to the 6805, therefore, scan-code translation at the 8042 level must be disabled.

Scan-code set 3 is similar to the default scan code in that it produces the same scan codes for the majority of the ASCII keys and uses the same press/release coding convention. The scan-code translation on the 8042 should be enabled in order to use scan-code set 3. Some keys, though, are curiously reassigned. For example, with scan-code set 3 activated and translation enabled, CapsLock behaves like the left Ctrl key, the left Ctrl key functions as the left Alt key, NumLock acts like Esc, the right Ctrl-key toggles the CapsLock state, and so on. In fact, if the key caps were appropriately relabeled, the keyboard layout would look very similar to the layout of the 84-key AT keyboard. A few unfortunate omissions must be noted, however. Except for F1, the functions keys generate scan codes unknown to the BIOS; F1 generates the scan code for F12. The extended keys on the dedicated cursor control keypad also generate scan codes that the BIOS cannot handle (so it ignores them). Finally, no key generates the scan code for a backslash, and the NumLock, CapsLock, and ScrollLock states cannot be turned off.

Scan-code set 3 has the rather unusual characteristic of allowing the programming of keys to send scan codes only on press, only on release, or both, and enabling or disabling the typematic repeating action. These characteristics may be set for all keys at once, or for individual keys identified by scan code. The support for this scan set is far from complete, therefore, using its features would first require significant and time consuming programming effort.

Sample Programs

Programmed routines that demonstrate most of the features of the new keyboard are reproduced in Listing 2. Note that this is not a complete program (although it will assemble with Microsoft MASM 4.0) because it lacks a main program. The entire demonstration program, KEYBINFO, is available in both source form and as a .COM file on PCTECHline. This program can be run on any of the three IBM keyboards. It automatically determines the keyboard type and displays appropriate data. On the enhanced AT keyboard, starting KEYBINFO with an argument of 1, 2, or 3 switches the keyboard to the corresponding scan code set.

[My God, that's spread over three pages...]
Listing 2: ATKEY.ASM

KEYBECHO.COM [KB ECHO] displays information about individual keys: scan code, ASCII code, and key name (including any shift states). It is very informative to run KEYBECHO after using KEYBINFO.COM [KB INFO] to change the scan-code set. The source for KEYBECHO is in KEYBECHO.C and KEYBMISC.ASM; the object files from compiling the first and assembling the second are to be linked together. This source code is too large to be reproduced here. To ensure downloading of all the necessary components, all source and executable modules have been archived and placed on PCTECHline in the file named ATKEY.ARC.

The enhanced keyboard has many useful features, but its support at both the BIOS level (scan-code set 3) and the operating system level (discarding extended scan codes) is less than complete. Programming for it is tricky because of incomplete documentation. Because IBM finally seems to have settled on this keyboard model, however, it is worthwhile to search for solutions to some of the problems.

Bob Smith is president of Qualitas, Inc, a software development firm in Bethesda, Maryland. He is a member of the Capital PC User Group, Inc. in Washington, DC.

Content created and/or collected by:
Louis F. Ohland, Peter H. Wendt, David L. Beem, William R. Walsh, Tatsuo Sunagawa, Tomáš Slavotínek, Jim Shorney, Tim N. Clarke, Kevin Bowling, and many others.

Ardent Tool of Capitalism is maintained by Tomáš Slavotínek.
Last update: 08 May 2024 - Changelog | About | Legal & Contact