Copyright (c) 1994 Trace R&D Center
University of Wisconsin
2107 Engineering Centers Bldg.
1550 Engineering Dr.
Madison, WI 53706
Reproduction With Permission Only
Please send any comments regarding this proposal to:
Standards Project Manager
Trace Research and Development Center, University of Wisconsin
2107 Engineering Centers Bldg., 1550 Engineering Dr., Madison, WI 53719
There are a number alternate input or AAC devices capable of emulating the standard computer input devices. However, computers as they are currently designed cannot understand the output from an AAC device without some kind of communication translation taking place. This communication translation is usually accomplished by the emulating interface. The emulating interface can be a hardware device (e.g., Trace Transparent Access Module) or special software running on a computer (e.g., "SerialKeys" feature of AccessDOS) that converts the characters and commands transmitted over the serial cable from the alternate input device into keystroke and mouse actions understood by the receiving computer. In either case, a hardware interface (e.g. a serial port) is necessary to supply or support the connection from the alternate input device to the emulating interface. The hardware interface (e.g., a serial port) can be physically located on an external hardware device attached to the computer or be part of the computer itself.
As you read or refer to this GIDEI Proposal, you will need to distinguish between what the GIDEI Proposal is defining (e.g., the connection and data communication protocol) and what other pieces are necessary to allow alternative input or AAC devices to function as computer input devices (e.g., keyboards, mice, etc.).
For a quick reference, several of the GIDEI commands which comprise the "data communication protocol" are listed in the section titled "GIDEI Commands At A Glance." Information concerning the GIDEI "connection protocol" requirements are covered later in this document in the section titled "Hardware Connection."
In addition, Appendix A has added information on an industry wide effort that promises to make PC installation and use easier for all computer users. Collectively known as the External COM device "Plug- and-Play" draft specification, it is an attempt to simplify the installation, device identification, and initial communication for devices attaching on the "serial" port, which may have a far reaching effort towards "ease-of-use" for AAC devices accessing a computer via GIDEI.
Keep in mind that the General Input Device Emulating Interface (GIDEI) Proposal defines a connection and data communication protocol only, between the alternate input devices and other emulating interfaces which emulate standard computer input devices, not to any software or hardware designed to do translation.
A person who is unable to access a computer is at a great disadvantage in today's society. Many schools and jobs require the use of computers daily. The person who is physically unable to use a computer keyboard or mouse can not participate in certain activities on an equal level with others.
Technology has evolved to the point where electronic aids are available for many people with physical disabilities to assist them in doing many of the same things that others are doing on standard computer systems. For example, several aids can perform word processing features. Yet there still exists the need to access the same computers and software that are used by others. In schools and in the workplace, an individual is often required to use the same software programs that others are using.
Fortunately, many special electronic aids used by people with disabilities can be used as alternate input devices for standard computers. Any device which is capable of connecting to a computer as described in this GIDEI Proposal and also capable of transmitting ASCII information arranged to conform with the GIDEI data communication protocol, should be capable of acting as a alternate input device.
The following figures should help you to better understand the terminologies GIDEI, alternate input device, and emulating interface. Each figure contains a picture of a computer, showing the connection for the standard keyboard and mouse input devices. Each figure also contains a picture of a alternative input device (e.g., AAC) device that is also connected in some fashion to the computer. It is this AAC device-to- computer connection that is the critical component you need to understand, when determining if you need-to- follow the GIDEI Proposal for connection and data communication purposes between your AAC device and the computer.
The detailed discussions which follow are designed to assist you in better understanding the proper application of the GIDEI Proposal, with or without the figures as a reference.
Figure 1
The example in Figure 1 shows an AAC device connected directly to the computer using a serial cable. The serial cable from the AAC device connects directly to the computer serial or "com" port, which is usually located at the rear of the computer. The user in Figure 1 wishes to make selections on their AAC device, transmit the information across the serial cable to the computer, and expects the computer to understand that the information represents keyboard or mouse actions. In Figure 1, the "connection" protocol as defined in the GIDEI Proposal includes the serial cable, its internal wiring or "pin-out" arrangement, and the amount, speed, and characteristics of the information the user sends from their AAC device to the computer. The "data communication" protocol as defined in the GIDEI Proposal concerns the contents of the information or "data packets" themselves, that the user either creates or which may be pre-stored on their AAC device.
You might expect that once the user sets up their AAC device to conform to both the connection and data communication protocol as defined in the GIDEI Proposal, that their AAC device would be able to communicate with and control the computer. Unfortunately, without one additional missing piece, the computer will not be able to understand what the AAC device is transmitting.
Computers are very powerful tools. However from a user input standpoint, most computers only understand the user when given input or instructions from the keyboard or the mouse. By design, keyboards and mice each use their own language to communicate with the computer. Therefore, once the AAC device is connected to the computer as shown in Figure 1 (e.g., either directly through the use of a serial cable or indirectly via some kind of wireless link), something must act as a "go-between" to translate the AAC device language into the keyboard or mouse language understood by the computer. Since the information transmitted from the AAC device is well defined by the GIDEI Proposal data communication protocol, a good portion of the translation work is already completed. In Figure 1, the missing "go-between" piece is the software that functions as the "emulating interface" on the computer receiving the alternate input device information. Emulating interface software would do the translation of the information sent from the AAC device into keyboard and mouse language understood by the computer. The emulation interface software is the missing "go- between" piece that allows the AAC device which is connected directly to the computer com port to "emulate" these standard input devices. The "SerialKeys" feature provided as part of the AccessDOS software package is an example of "emulating interface" software.
Figure 2
The AAC to computer connections shown in Figure 2 are very similar to the example shown in Figure 1, except the serial cable coming from the AAC device is now connected to a "black box" outside the computer rather than directly to the computer. (Again, please note that the serial cable could also be a wireless serial link). The black box has cables coming "from" the keyboard and mouse, and cables "exiting" the black box which connect to the computer at the same place the keyboard and mouse cables would have been plugged into the computer, had the black box not been used. The black box also has a connection for the serial cable used to connect to the AAC device. Again the "connection" protocol as defined in the GIDEI Proposal includes the serial cable, its internal wiring or "pin- out" arrangement, and the amount, speed, and characteristics of the information the user sends from their AAC device to the black box. The "data communication" protocol as defined in the GIDEI Proposal concerns the contents of the information or "data packets" themselves, that the user either creates or which may be prestored on their AAC device.
In this example, information is sent from the AAC device to the black box. Therefore, the black box needs to perform the necessary translation of the AAC device information prior to sending it to the computer through the keyboard and mouse cables. The black box becomes the missing "go-between" piece in this example. Since the black box is connected between the standard input devices and the computer, it understands the language used by the keyboard and mouse when talking with the computer, and is therefore capable of allowing the AAC device to again "emulate" the standard input devices. In this case, we would refer to the black box as an "emulating interface device," since it is actually a piece of hardware which a user could take from computer-to-computer, as their needs might dictate. The Trace Transparent Access Module (T-TAM) is one example of an "emulating interface device."
Figure 3
Figure 3 shows one more example connection. However, the example in Figure 3 shows how a non-GIDEI alternate input device might connect to a computer. The AAC device in Figure 3 is connected directly to the computer using a keyboard cable. Since there is no serial cable or wireless serial link involved, this example does not use the GIDEI Proposal.
The AAC device in Figure 3 does not use any kind of GIDEI connection, because this AAC device already has a keyboard emulation interface built into it which understands the keyboard language of the computer it is connected to. In this example, we would say that the AAC device is acting as both the "alternative input device" and the "emulating interface device." Some individuals may also call an AAC device with "direct keyboard connection" capability a "keyboard emulating interface," since the AAC device connects directly to a keyboard cable and "emulates" or looks like another keyboard to the computer. This terminology can be confusing however, since it does not distinguish between a device which is capable of connecting directly to the keyboard port or a device which emulates the keyboard using an external emulator. Perhaps a preferred term for this type of device would be to describe it as an alternative input device with built-in keyboard emulation. However, as stated above, this combination is still another example of keyboard emulation.
As technology advances, we expect more and more AAC devices to be designed capable of connecting directly to the computer as substitute or additional keyboards, mice, etc. These devices would not need to use the GIDEI connection and data communication protocol. However, until all alternative input devices are so equipped, the GIDEI Proposal provides a consistent method for users to connect with and operate a computer.
The reasons behind the effort to standardize the GIDEI is based on several important and practical concerns:
Many people need access to two or more different types of computers. If the only way they can obtain that access is through a GIDEI connection, it would be beneficial to the user if the GIDEI worked the same (at the user level) for all computers, keyboards and pointing devices. There is little enthusiasm on the part of users, clinicians and developers to have to deal with multiple GIDEI formats and protocols.
For schools and clinics it is important that a emulating interface on a computer be compatible with a variety of alternate input devices so that different people can access or share the computer. For public computer systems, such as computer based card catalogues in public libraries, it is important that the computer be accessible to everyone. Having a single GIDEI connection and data communication protocol that all alternate input devices can implement will provide that access in the most advantageous solution.
The GIDEI Proposal defines the connection and data communication protocol between alternate input devices and an emulating interface. The alternate input device, using this protocol, transmits information to the computer. The emulating interface then processes that information to determine which keystrokes to type or what mouse actions to perform on the computer. If it is a hardware emulating interface device, it may need to mimic the electrical signals that the normal keyboard and mouse exhibit. If it is a software emulating interface, it will place the keystroke and mouse information into locations within the computer or its operating system, where application programs will think it came from a user typing on the keyboard or from a user operating the mouse.
Some confusion arises when software or hardware developers state that they have a "general input device emulating interface," either in software or hardware. What they are referring to usually, is the fact that their interface can handle "general" input, thus it isn't limited to translating alternative input device information into only keyboard or only mouse languages. While reading this document, the General Input Device Emulating Interface (GIDEI) refers only to the connection and data communication protocol, not to any software or hardware designed to do translation.
The GIDEI connection protocol is designed to allow both wired and wireless links for GIDEI communication. Specifications have been made to allow for some degree of flexibility while taking into account the limitations of most current alternate input devices. Basic operation of the GIDEI is possible with virtually any alternate input device with a serial port and advanced options are included for alternate input devices that have additional capabilities.
The GIDEI Proposal defines two modes of operation as part of the data communication protocol for sending keystroke and mouse information: Character Mode and Escape Sequence Mode. In Character Mode, the emulating interface would understand to convert ASCII characters received from the alternate input device directly into whatever keystrokes are necessary to produce those same characters on the computer. The Escape Sequence Mode is designed to provide a way for a person using an alternate input device to type keys that have no ASCII equivalent (e.g., Home, PageUp, etc) as well as to allow the user to "hold" two or more keys down at the same time, as is required by many computers (e.g., Ctrl-Alt-Del). Escape Sequence Mode also allows the user to specify mouse actions such as clicking, double clicking and moving. Finally, Escape Sequence Mode is used to change certain operational features the GIDEI Proposal supports.
The GIDEI Proposal was developed with thought given to both hardware and software emulation interface implementations. Features such as key repeat and adjustable typing rate were deliberately removed from this proposal to take into account the fact that some emulating interface implementations could not guarantee access to a timing mechanism. Memory requirements were also considered when Commands and Key Names were established as part of the GIDEI data communication protocol. While the length of some of the Key Names could be shortened, this would have made it much more difficult for users to understand. Since many of the alternate input devices today require the user to program these escape sequence strings in "squares" or "selections" on their alternate input device, user readability was given greater priority than device memory requirements.
Previous versions of the GIDEI were concerned with maintaining a degree of compatibility with previous versions of the Keyboard Emulating Interface (KEI v1.0) standards. However, to provide better support for the newer and more powerful communication aids, GIDEI2 no longer guarantees such "backward" compatibility.
Keyboard Commands
Typing Specific Keys: each key is designated by a name. To type the key, use the Key Name in an escape sequence. An escape sequence is simply the ESCAPE character (ASCII 27, represented as "<esc>" below), followed by a sequence of other ASCII characters, and ending with the PERIOD character (ASCII 46,"."). (Note: Some Many AAC devices can generate an ESCAPE character using a combination of the control key plus a left bracket (e.g., control+[), which may appear on the AAC device display as "^[" or as a blank character. Others have the ESCAPE character programmed on a keyboard layout page.)
Other Key Actions: to perform other actions, use escape sequences of the general form:
Valid keyboard commands are:
<esc> , combine , ctrl , alt , del .
<esc> , hold , shift .
<esc> , lock , ctrl .
<esc> , rel .
Button identifier now refers to a mouse button action, such as pressing mouse button #1, rather than a location, such as pressing the "left" mouse button. This distinction is being made because many operating systems now allow the user to reprogram the buttons on the mouse to perform any desired action. Therefore, users are encouraged to follow the new button identifiers, rather than previous GIDEI conventions which defined a "left" or "right" mouse button. If the button identifier is not included, typically the "default" button is activated with the mouse command.
Valid mouse commands are:
<esc> , click .
- or -
<esc> , click , but1 .
<esc> , dblclick .
<esc> , moulock , but1 .
<esc> , mourel .
<esc> , anchor .
(The next single lowercase letter "a" through "z" following an "anchor" command becomes the "name" of the current mouse cursor screen position, thus allowing 26 separate mouse cursor locations to be "anchored" or saved.)
<esc> , move , 1 X direction , 1 Y direction .
<esc> , mougo , downleft , 5 .
A) It moves the mouse cursor to a specified absolute screen location when both an X and Y position is indicated.
<esc> , goto , X position , Y position .
B) It moves the mouse cursor to a specified screen location, based upon that location having been preassigned using the "anchor" command (see above).
<esc> , goto .
(The next single lowercase letter "a" through "z" following this "goto" command is the "name" of the mouse cursor screen position "anchor" the user wishes to return to.)
<esc> , moustop .
<esc> , moureset .
<esc> , baudrate , XXXXX .
When the AAC user is communicating with the emulating interface at a known rate, the baudrate command can be used to change to another rate, should the user wish to do so.
ASCII: ASCII is an acronym which stands for the American Standard Code for Information Interchange. What this means to the computer user is that usually numeric values represent characters inside the computer. For example, the ASCII code for the uppercase "A" is "65." Table 1 provides a listing of ASCII characters and their corresponding numeric or decimal code.
Emulating Interface: A "system" that accepts information from an alternate input device and transforms it into keystrokes or other input information in the computer.
Escape Character: The single character used to indicate the beginning of a GIDEI Escape Sequence. It is ASCII 27. In this document the escape character is designated by "<esc>."
Escape Sequence: A character string that starts with an escape character (ASCII 27) and ends with a period character (ASCII 46). Escape Sequences are used to send special commands and keystrokes.
Hardware emulating interface: Usually an "external" device that attaches to the computer and provides connection "ports" for AAC devices while simultaneously interacting with the computer in such a way that the computer is unaware that any external device is attached.
Key Name: The ASCII string of characters assigned by the GIDEI Proposal to designate each key on the normal keyboard.
Neutral Keyboard: The state of the keyboard when all "toggling" keys are in their "untoggled" position.
Secondary Key Function: One or more actions produced by a key when it is typed in combination with other keys. Secondary Key Functions are normally activated by holding down, for example, a [Shift] key, an [Alt] key, an [Option] key, a [Ctrl] key, etc., along with the key.
Software emulating interface: Software which is implemented as a co-process within the target computer. Typically, it is a program resident in the computer which uses the computer's serial port to communicate with the alternate input device. It is activated when the serial port receives characters. Once activated, it interprets the keystroke and mouse information and makes these keystrokes available to the operating system in that computer.
Special Keys: Keys that do not produce ASCII characters. An example is the "right arrow" key.
Transparent Interface: An interface that is invisible to or undetectable by the computer system and the software running on it. A emulating interface whose implementation is not distinguishable from the way the normal keyboard works. In other words, it is a interface that operates with a computer and the software running on it exactly the same way as the normal keyboard would operate. Ideally, all interfaces should be transparent to insure access to the same programs that can be operated from the normal keyboard or mouse.
XOFF Character: The character sent by the GIDEI to the alternate input device to tell it to stop transmission. The XOFF character is ASCII 19 (control-S).
XON Character: The character sent by the GIDEI to the alternate input device to tell it to resume transmission. The XON character is a ASCII 17 (control-Q).
The hardware interface is the component of the system which the user's AAC device "directly connects to." It handles the physical connection, signal interfacing, communications protocol and data buffering.
The GIDEI Proposal data connection protocol uses the RS-232C communication link for transferring information from an external AAC device to the hardware interface. The hardware interface itself might be under the control of emulating interface "software" running on a computer or a separate external "black box" connected to the computer.
See also Appendix A, regarding "Plug-and-Play."
The serial connection is based on EIA Standard RS-232-C: Interface Between Data Terminal Equipment and Data Communication Equipment Employing Serial Binary Data Interchange, August 1969, Electronic Industries Association, Washington, D. C. 20006.
Of the 25 lines defined, four are used for the GIDEI Proposal.
The hardware interface plays the role of the DCE (data communication equipment). The alternate input device or "external device" would connect to the hardware interface with a serial cable or wireless serial link, as discussed earlier in Figures 1 and 2. The hardware interface is usually the computer running emulating interface software or a black box connected to the computer.
Pin Assignments (for the AAC, or DTE, device)
(assuming the AAC device has a 25 pin D connector)
The user may change the baud rate via an escape sequence command sent to the hardware interface. Valid baud rates are 300, 1200, 2400, 4800, 9600, and 19200.
The descriptions below pertain to both devices during normal operation after transmission has been establish. There are some changes that must be noted when the devices are initially connected, or when a baud rate change takes place. These two cases are explained in separate sections later in this document.
With hardware handshaking, the hardware interface controls the signal on the Clear To Send line. It asserts this line when it can receive data and lowers it when it is not ready to receive more data.
The external AAC device, if using this handshaking method, must check the status of this line before each character is transmitted. It may only send data if the line is asserted.
Software handshaking is a system where the hardware interface, using ASCII characters, transmits its status information to the external AAC device on the Received Data line. The hardware interface sends an XON character (ASCII 17) to signal that it is ready to receive data and sends an XOFF character (ASCII 19) to signal that it is not ready.
The external AAC device, if using this handshaking method, must check its receive buffer before each transmission to determine if an XOFF has been sent. If so, it must wait until an XON is sent before sending any more data.
Hardware Interface Handshaking
To suspend the transmission of characters by the external device, the hardware interface puts the CTS line into the OFF state (logic 1, -3 to -15 volts) and sends one (1) XOFF character at the current baud rate to the external device over the Received Data line.
If the hardware interface lowers the CTS line and sends an XOFF while a character is being transmitted by the external device, transmission will continue until the current character has finished being transmitted.
It may turn out that the external AAC device, due to the buffering capabilities of its serial hardware, may not be able to stop the transmission of characters immediately. In this case, one or more characters might still be sent after the hardware interface has signaled it to stop. To accommodate this, the hardware interface will be required to be able to receive four (4) more characters after the initial XOFF has been sent to the external device. In addition, after each of these "extra" characters is received, the hardware interface will send another XOFF back to the external device.
Once the external device has received the XOFF character or has detected the lowering of the CTS line, it must wait for an XON or an asserted CTS before any additional data is sent to the hardware interface.
There are a few exceptions to this requirement. See later.
If the external device is using the XON/XOFF handshaking method, it is recommended that the external device periodically interrogate the status of the hardware interface while it is waiting for an XON. (See next section)
There is no timing specification given to define what "periodically" means. The intention is that the external device checks at reasonable intervals. Not so often that the hardware interface spends all its time handling the serial transmission and therefore can't get anything else accomplished, but often enough to avoid an unreasonable delay for the user.
To do this, the external device is allowed to send a NULL character (ASCII 0) at the current baud rate to the hardware interface. If the hardware interface is ready to receive keystroke data it will receive this character and then send an XON back to the external device. While the hardware interface must monitor the character data for this character, it is still passed on to its input buffer just like any other character.
If the hardware interface is not ready to receive keystroke data, it will send nothing back.
No character is sent back in this case (instead of sending an XOFF) to guard against potential problems. First, if the external device missed the original XON (which is why it is interrogating), chances are that it could miss an XOFF when the hardware interface is interrogated. In that case the external device is hung up waiting for the XOFF response. Secondly, the hardware interface may have sent the original XOFF because it was too busy to handle any more serial data for a while. If this is the case, the NULL character would not be received or interpreted by the hardware interface so it couldn't possibly send the additional XOFF.
So no matter what the reason is that the hardware interface is busy, the end result, as seen by the external device, is that the hardware interface did not send back an XON. The external device should try again later.
This interrogation method is useful (and recommended) for external devices using the software handshaking system to insure that transmission does not hang up because an XON character was missed.
If the hardware interface receives three (3) consecutive characters with a framing error, it will:
2. Change to 300 baud (if not at this rate already)
3. Raise the CTS line and send out an XON at 300 baud after the above steps are completed in order.
Besides the benefit of setting the hardware interface to a known state, this requirement will also help to insure the quality of the transmission by not allowing baud rates which produce repeated erroneous characters.
The hardware interface may have been left at a different baud rate by the previous user or it may be in the middle of an escape sequence. Even if it was just installed, noise on the lines when the external device is connected could possibly put the hardware interface into an escape sequence. (This probably pertains more to wireless link serial systems.)
To begin the initial connection, the external device must be configured to a default state also.
External Device Configuration
If software handshaking is being used, the external device should assume that the hardware interface is ready to receive characters. The hardware interface is assumed to be installed and ready. Certainly, this should be the case if it has been idle for a short amount of time or just installed/powered up.
Until the hardware interface has changed to 300 baud, the external device should ignore any characters received from the hardware interface.
The hardware interface may be sending information back to the external device but you have no way of knowing the baud rate at which it is transmitting until it is initialized.
Once the external device is set up, it sends three NULL characters (ASCII 0) at 300 baud to the hardware interface. This causes one of two things to happen:
Sending NULL characters at 300 baud is the recommended way to insure that three framing errors are caused.
In addition, using the NULL character will avoid the possibility of one type of error that can occur if the hardware interface is at a higher baud rate. What can happen is that the hardware interface could mistakenly assemble a character (or characters) if the data bits are not all logic 0 because of the unsynchronized bit transmissions.
If the hardware interface was already at 300 baud, the NULL characters do nothing other than cause XONs to be sent back to the external device because of the Status Inquiry. These XONs are ignored by the external device. While the NULL characters are passed on to its input buffer, it is unlikely that it would cause any problems for any connected modules.
Regardless of what baud rate the hardware interface was in, it is now at 300 baud and the external device has established communication with the hardware interface.
To complete the initialization, the external device then sends an Escape Sequence Command to the hardware interface to cause it to reset to Character Mode.
The Escape Sequence Command that must then be sent is an Escape character followed by a period:
(See section on Escape Sequence Mode for information about Escape Sequences.)
After receiving this command, the hardware interface will be configured in its default state, or ready to receive ASCII characters (See next section on "Character Mode" transmission.).
Two methods are suggested:
Handshaking After Changing Baud Rate By Command
The hardware interface will then perform its baud change to the specified baud rate. After changing the baud rate, it will clear out any characters it may have received since the baud rate change began. When completed, it will signal the external device that it is ready by raising the CTS line and sending an XON character at the new baud rate.
Since the external device might not change baud rate as fast as the hardware interface, it might not properly receive the XON character. Because of this, it should employ the Status Inquiry method, if it is using XON/XOFF handshaking.
Table 1 shows all the ASCII characters from 0 through 127. Characters which exist above 127 (e.g., ASCII 128 through ASCII 255), sometimes referred to as "Extended ASCII," may differ due to the computer or receiving device's operating system.
If your alternate input device is capable of sending the ASCII value for the character you need, most hardware interfaces will understand how to generate the character or key for your request. If some of the keys on a particular keyboard have single character labels which are ASCII characters in the Extended ASCII 128 to ASCII 255 range, GIDEI2 supports transmission of these characters and hopefully the hardware interface will understand how to "create" the character or keyboard "keys" via emulation on the receiving computer. For example, if you require an "e" with a circumflex accent "^" on a computer in the United States, GIDEI2 supports transmission of the Extended ASCII character "234"(ISO 8859-1 Standard) direct from the alternate input device to the hardware interface. (Note: remember the hardware interface may be either an external "black box" device connected to the receiving computer or emulation interface software running directly on the receiving computer.)
Two ASCII characters are reserved by the GIDEI for special use. They are the NULL character (ASCII 0), and the ESCAPE character (ASCII 27). See the Escape Sequence Mode section to find how to type these characters.
Based on the GIDEI Proposal, an emulating interface will leave Character Mode and enter Escape Sequence Mode upon receiving an Escape character. (see the next section for information on Escape Sequence Mode) Based on the GIDEI Proposal, after start up, after an escape sequence, and after an error in an escape sequence, the emulating interface will return to Character mode.
Example: if an ASCII d is sent, the interface will type a d on the computer. If an ASCII G is sent, the interface will type a shift key and a g to produce a capital G on the computer.
The actual keystrokes that the interface will type to get the character is dependent on the keyboard that the interface is emulating. The intention of the GIDEI is to allow the external AAC device to send characters that the hardware interface then translates into the appropriate key presses or mouse actions.
Table 1: ASCII Characters With Their Corresponding Decimal Code
| Character | Code | Character | Code | Character | Code |
| NULL | 0 | + | 43 | W | 87 |
| SOH (ctrl-A) | 1 | , | 44 | X | 88 |
| STX (ctrl-B) | 2 | - | 45 | Y | 89 |
| ETX (ctrl-C) | 3 | . | 46 | Z | 90 |
| EOT (ctrl-D) | 4 | / | 47 | [ | 91 |
| ENQ (ctrl-E) | 5 | 0 | 48 | \ | 92 |
| ACK (ctrl-F) | 6 | 1 | 49 | ] | 93 |
| BEL (ctrl-G) | 7 | 2 | 50 | ^ | 94 |
| BS (ctrl-H) | 8 | 3 | 51 | _ | 95 |
| HT (ctrl-I) | 9 | 4 | 52 | ` | 96 |
| LF (ctrl-J) | 10 | 5 | 53 | a | 97 |
| VT (ctrl-K) | 11 | 6 | 54 | b | 98 |
| FF (ctrl-L) | 12 | 7 | 55 | c | 99 |
| CR (ctrl-M) | 13 | 8 | 56 | d | 100 |
| SO (ctrl-N) | 14 | 9 | 57 | e | 101 |
| SI (ctrl-O) | 15 | : | 58 | f | 102 |
| DLE (ctrl-P) | 16 | ; | 59 | g | 103 |
| DC1 (ctrl-Q) | 17 | < | 60 | h | 104 |
| DC2 (ctrl-R) | 18 | = | 61 | i | 105 |
| DC3 (ctrl-S) | 19 | > | 62 | j | 106 |
| DC4 (ctrl-T) | 20 | ? | 63 | k | 107 |
| NAK (ctrl-U) | 21 | @ | 64 | l | 108 |
| SYN (ctrl-V) | 22 | A | 65 | m | 109 |
| ETB (ctrl-W) | 23 | B | 66 | n | 110 |
| CAN (ctrl-X) | 24 | C | 67 | o | 111 |
| EM (ctrl-Y) | 25 | D | 68 | p | 112 |
| SUB (ctrl-Z) | 26 | E | 69 | q | 113 |
| ESC | 27 | F | 70 | r | 114 |
| FS (ctrl-\) | 28 | G | 71 | s | 115 |
| GS (ctrl-]) | 29 | H | 72 | t | 116 |
| RS (ctrl-^) | 30 | I | 73 | u | 117 |
| US (ctrl-_) | 31 | J | 74 | v | 118 |
| SPACE | 32 | K | 75 | w | 119 |
| ! | 33 | L | 76 | x | 120 |
| " | 34 | M | 77 | y | 121 |
| # | 35 | N | 78 | z | 122 |
| $ | 36 | O | 79 | { | 123 |
| % | 37 | P | 80 | | | 124 |
| & | 38 | Q | 81 | } | 125 |
| ' | 39 | R | 82 | ~ | 126 |
| ( | 40 | S | 83 | DEL | 127 |
| ) | 41 | T | 84 | ||
| * | 42 | U | 85 | ||
| V | 86 |
Character, Code
NULL 0
SOH (ctrl-A) 1
STX (ctrl-B) 2
ETX (ctrl-C) 3
EOT (ctrl-D) 4
ENQ (ctrl-E) 5
ACK (ctrl-F) 6
BEL (ctrl-G) 7
BS (ctrl-H) 8
HT (ctrl-I) 9
LF (ctrl-J) 10
VT (ctrl-K) 11
FF (ctrl-L) 12
CR (ctrl-M) 13
SO (ctrl-N) 14
SI (ctrl-O) 15
DLE (ctrl-P) 16
DC1 (ctrl-Q) 17
DC2 (ctrl-R) 18
DC3 (ctrl-S) 19
DC4 (ctrl-T) 20
NAK (ctrl-U) 21
SYN (ctrl-V) 22
ETB (ctrl-W) 23
CAN (ctrl-X) 24
EM (ctrl-Y) 25
SUB (ctrl-Z) 26
ESC 27
FS (ctrl-\) 28
GS (ctrl-]) 29
RS (ctrl-^) 30
US (ctrl-_) 31
SPACE 32
! 33
" 34
# 35
$ 36
% 37
& 38
' 39
( 40
) 41
* 42
+ 43
, 44
- 45
. 46
/ 47
0 48
1 49
2 50
3 51
4 52
5 53
6 54
7 55
8 56
9 57
: 58
; 59
< 60
= 61
> 62
? 63
@ 64
A 65
B 66
C 67
D 68
E 69
F 70
G 71
H 72
I 73
J 74
K 75
L 76
M 77
N 78
O 79
P 80
Q 81
R 82
S 83
T 84
U 85
V 86
W 87
X 88
Y 89
Z 90
[ 91
\ 92
] 93
^ 94
_ 95
` 96
a 97
b 98
c 99
d 100
e 101
f 102
g 103
h 104
i 105
j 106
k 107
l 108
m 109
n 110
o 111
p 112
q 113
r 114
s 115
t 116
u 117
v 118
w 119
x 120
y 121
z 122
{ 123
| 124
} 125
~ 126
DEL 127
For purposes of this document, an "escape" character (ASCII or decimal 27) will be represented by "<esc>." Therefore an escape sequence would look like:
To make Key Names easier to remember, many Key Names consist of the same characters as the label used for that key on the keyboard. For example, the Key Name for the "backspace" key is either "backspace" or "bspace." The shorter Key Name allows the user to conserve memory when programming that key selection on their alternate input devices, especially if they have a device with several possible selections. Many of the longer Key Names also have shorter equivalents for this purpose. However, longer Key Names are usually available for users who find it easier to learn and remember Key Names in this fashion.
The Escape Sequence Mode has several purposes besides just sending Key Names. Listed below are brief descriptions and examples of Escape Sequence Mode uses. For more explanation on Escape Sequence Mode commands, refer to the next sections.
Keys such as the [Right Arrow] key that have no corresponding ASCII character equivalent are typed using the Escape Sequence Mode. To send the Right Arrow key using Escape Sequence Mode, you must first determine (e.g., look in the Key Names Aliases section) that the Key Name for the Right Arrow key is simply "right." Then you would construct the following Escape Sequence to emulate a press and release of the Right Arrow key.
To Type Key Combinations
A key combination is where two or more keys are pressed down together (e.g all the keys are pressed before any of the keys are released). The Escape Sequence Mode is used to allow an alternate input device to type key combinations of from two to five keys. For example, suppose you run a program that requires you to press the shift, control, and F1 keys to perform a particular operation quite frequently. One option might be to use the Escape Sequence Mode "combine" command to perform this multiple key operation. The "combine" command instructs the emulating interface to press the keys in the order in which they are received, and then release them in reverse order. Therefore, the following example instructs the emulating interface to press the shift, control, and F1 keys, and then to release the F1, control, and shift keys. Note, whenever a GIDEI command is used (e.g., "combine" in this example), the comma "," character must be used immediately after the "escape" character and again immediately after the GIDEI command. Refer to the sections later in this document on keyboard escape sequences. mouse escape sequences, and miscellaneous escape sequences for more examples of GIDEI commands used in an escape sequence.
To Type Any ASCII Character
Another purpose of the Escape Sequence Mode is to allow alternate input devices that are unable to produce some ASCII characters, another method to type those that can be generated on the Normal Keyboard of the connected computer system. For example, some "lower-end" or inexpensive alternate input devices may have the ability to transmit characters only, not numbers. Using Escape Sequence Mode, a user with this device could type the number "9" using the following escape sequence.
To Operate the Mouse
Besides the keyboard uses described above, the Escape Sequence Mode allows complete control of standard mouse activity, such as moving relative and absolute distances, clicking and double clicking, activating mouse buttons, and dragging. For example, to move the mouse cursor to the right and down on some computer systems, you might create the following escape sequence.
To Change the Baud Rate
Using the Escape Sequence Mode the user can change the baud rate from the default value of 300 baud. This is an example of one of the miscellaneous GIDEI commands that are available. The baud or "baudrate" has to do with how fast information is communicated across the serial link. The higher the "baudrate," typically the faster the response.
Clearing Syntax Errors
The Escape Sequence Mode is used to clear errors resulting from improper use of syntax.
Characters Allowed in GIDEI Escape Sequences
For example, if the user wished to get the "A with circumflex" or "1" character, which is ASCII character 177 on some DOS systems, their alternate input device must be capable of transmitting Extended ASCII or decimal "177." If their device is unable to generate ASCII characters above 127, they must then use an escape sequence after determining the proper Key Name for the "A with circumflex" character in the Key Name Aliases table (see GIDEI Key Name Aliases at the end of this document). Note the following examples.
[one-half symbol]
--or--
The following is an example of a character NOT allowed in GIDEI Escape Sequence Mode:
<esc> ce'nt .
Please note that while the GIDEI2 Proposal supports transmission of the Extended ASCII characters between ASCII 128 through ASCII 255 in Character Mode, it is still up to the hardware interface (either the "black box" connected to the computer or the emulation interface software) to create the proper character or keystroke at the receiving computer.
All characters in escape sequences are converted to lower case by most hardware or software interfaces prior to processing.
Space characters (decimal 32) anywhere in the escape sequences are ignored by most hardware or software interfaces.
Escape sequences use one of two possible syntaxes, which may not be evident to most users but is described here for GIDEI Proposal completeness. Escape sequences can either include the appropriate GIDEI Command name in the escape sequence or they can "imply" a particular command is being used. The following two examples are both escape sequences involved with the keyboard, however only one requires the use of a GIDEI command name
Only one GIDEI Command Name can be included in an escape sequence to distinguish what action the hardware interface is to perform. Parameters are also included where appropriate and are separated with a comma character (ASCII or decimal "44").
Note the hold GIDEI command name, preceded by a comma.
Also note that two keys are "typed," the "shift" key and the "a" key.
Without a GIDEI Command Name, or the "implied" method
The Implied method is typically used to type single keys. The command name is NOT specified in the escape sequence (e.g., it is implied).
Note you DO NOT need the GIDEI "hold" command or comma "," separator (ASCII or decimal "44") to press a single key (e.g., Key Name).
The hardware interface tests each field in a GIDEI Escape Sequence to determine if it has invalid character strings.
A field consists of the characters in an escape sequence between the delimiting characters escape, comma, and period.
Invalid Fields
Invalid fields are fields with characters that do not conform to any of the formats (e.g., GIDEI command names or Key Name aliases) defined for escape sequences. Please review the previous section titled "Characters Allowed in GIDEI Escape Sequences." When the emulating interface determines that a field contains an unrecognized character string, it may provide some form of user feedback (e.g., audible sound) and it then switches to Character Mode and types the remaining characters in the invalid field followed by any other characters received.
Invalid Commands or Unsupported Features
Invalid commands or parts of commands which are unsupported via GIDEI should provide the user with some form of feedback (e.g. audible and visual, if possible), and then the emulating interface should switch to Character Mode and type the remaining characters in the invalid field followed by any other characters received if possible. It is possible that some kind of reset may also be necessary, such as an escape sequence reset as described in the next section, or possibly needing to re-establish serial communications (e.g. see prior section on Hardware Connection).
Resetting the Escape Sequence Mode
If the hardware interface is in Escape Sequence Mode and receives another escape character before getting the period character (e.g., ASCII or decimal "46") which terminates an escape sequence, then all the characters before this escape character are discarded. After discarding previous characters, the hardware interface remains in Escape Sequence Mode ready to start assembling a new escape sequence.
Command and Parameter Designations
Each GIDEI command, Key Name, or mouse action is assigned a character or string of characters which specify it. This basically gives each GIDEI command, Key Name, or mouse action a "name" used to refer or identify it. Sometimes this is also called an "alias," since many of the keys on the keyboard have more than one "name." For example, the "return" key is also called the "enter" key on some keyboards. In the list of GIDEI Key Name Aliases at the end of this document, the "return" Key Name also has the names or "aliases" of "ret" and "enter."
Delimiting Characters within Escape Sequences
The Escape Key
The [Esc] key on the computer system must be designated by the characters of the Key Name, esc or escape.
The Period Key
The [.] key on the computer system must be designated by the Key Name, period.
The Space Key
The [space] key on the computer is designated by the Key Name, space.
The Comma Key
The [comma] key on the computer is designated by the Key Name, comma.
Format
Additional Information
Format
Example
Additional Information
While this command is supposed to be used for a minimum of two keys, it is not an error if only one Key Name is presented in the escape sequence.
Some key combinations may be impossible to type simultaneously due to the nature of a given keyboard or computer. The hardware interface will only be required to simulate keystrokes that are possible on the normal keyboard.
The function of this command differs from the combine command in that it allows the user to program generic hold keys on the alternate input device rather than programming all the possible combinations with the combine command. Once the generic key is programmed, it would only take two selections to type any two key control or shift combination.
Format
Examples
<esc> , hold , control .
<esc> , hold , control . c
Additional Information
Only Key Names are allowed after the hold command in this escape sequence. Please see the section on Key Name Aliases for a list of the valid key names for a given keyboard and computer.
Some key combinations may be impossible to type simultaneously due to the nature of a given keyboard or computer. The hardware interface will only be required to simulate keystrokes that are possible on the normal keyboard.
If the Hold sequence is sent by mistake, you may clear it with the rel command. (See rel later in this section.)
Example:
If I wanted to type a capital g key I could send or program into one selection:
<esc> , hold , shift. g
--or--
The <esc> , hold , shift. sequence would be programmed into one selection on the alternate input device so it would only take one selection for the shift and a second for the g, or any other letter you wished to "capitalize."
If I wanted to type a control c , I could send or program into one selection:
<esc> , hold , ctrl. c
--or--
Again, once the control escape sequence is programmed into one selection, any other control key combination would take only two selections on the AAC device.
Format
Example
<esc> , lock , kp8 .
Additional Information
If the lock sequence is sent by mistake, you may clear it with the rel command. (See rel command)
Only Key Names are allowed in this escape sequence. Please see the section on Key Name Aliases for a list of the valid Key Names for a given keyboard and computer.
Some key combinations may be impossible to type simultaneously due to the nature of a given keyboard or computer. The hardware interface will only be required to simulate keystrokes that are possible on the normal keyboard.
Format
<esc> , rel , Key Name 1, Key Name 2, Key Name 3, Key Name 4, Key Name 5.
Additional Information
Format
Example
The implied press used to type the "escape" key is shown.
<esc> pageup .
The implied press is used to type the "page up" key is shown.
Additional Information
Format
Additional Information
Formats
Examples
<esc> , goto . h
Additional Information
Format
Allowable mouse cursor directions "up", "down", "left", and "right" which define the horizontal and vertical directions, while "upleft", "upright", "downleft", and "downright" would define the four diagonal directions.
Allowable speeds are a given with a number from 1 through 10, with faster mouse cursor speeds being associated with larger numbers (e.g., 1 is the slowest speed, and 10 would be the fastest speed).
Example
Additional Information
Format
Additional Information
Many operating systems define the left-most mouse button as mouse button identifier #1, and the remaining mouse buttons are identified from left-to-right in ascending order as the default. However, these same operating systems also allow the user to reassign mouse button actions, such that the "left" or mouse identifier #1 may not physically be located on the left-most side of the mouse puck or track ball. Therefore, mouse button identifier now refers to a mouse button action, such as pressing mouse button #1, rather than a location, such as pressing the "left" mouse button.
Therefore, users are encouraged to follow the new button identifiers, rather than previous GIDEI conventions which defined a "left" or "right" mouse button.
Format
<esc> , moulock , ???? .
<esc> , moulock , X .
<esc> , moulock , X , X , X , X , X .
where X is:
Additional Information
Format
<esc> , mourel , ???? .
<esc> , mourel , X .
<esc> , mourel , X , X , X , X , X .
where X is ;
Additional Information
Format
<esc> , click , ???? .
<esc> , click , X .
where X is ;
Additional Information
Format
<esc> , dblclick , ???? .
<esc> , dblclick , X .
where X is:
Additional Information
The X and Y values given with the mouse goto command may also be written with a "+" sign as part of the number.
Format
Example
--or--
<esc> , goto , +25 , +25 .
B. The mouse goto command will also cause the mouse cursor to move to the specified anchor location when the location coordinate is specified as the next "single" lowercase letter "a" through "z."
Format
Example
Additional Information
Format
Example
Additional Information
A
aacute
acircumflex
acute
adieresis
ae
again
agrave
alphanumeric
alt
altgr
amp
ampersand
aogonek
apostrophe
apple
aring
ast
asterisk
at
B
backslash
backspace
bbar
break
bslash
bspace
C
cacute
cancel
capslk
capslock
ccaron
ccedilla
cedilla
circumflex
clear
cmd
colon
comma
command
compose
control
conversion
copy
ctrl
cut
D
dblquote
del
delete
dieresis
divide
dn
dollar
down
E
eacute
ecaron
ecircumflex
edieresis
egrave
eight
end
enter
equal
esc
escape
eth
exclaim
exclaimdown
execute
F
f1
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f2
f20
f21
f22
f23
f24
f3
f4
f5
f6
f7
f8
f9
find
five
four
front
fullsize
G
graphical
grave
H
help
hiragana
home
hyphen
I
iacute
icaron
icircumflex
idieresis
igrave
ins
insert
K
kana
kanji
kanjidict
kp*
kp+
kp-
kp/
kp0
kp1
kp2
kp3
kp4
kp5
kp6
kp7
kp8
kp9
kp=
kpcomma
kpdel
kpdivide
kpdn
kpdown
kpdp
kpend
kpenter
kpequal
kphome
kphyphen
kpins
kpinsert
kpleft
kpmidl
kpminus
kpperiod
kppgdn
kppgup
kpplus
kpright
kpslash
kpstar
kptimes
kpup
L
lalt
lbrace
lbracket
lcmd
lcommand
lcompose
lcontrol
lctrl
left
linefeed
llthan
lock
lopenapple
loption
lparen
lquote
lshift
lthan
lwithslash
M
menu
meta
micro
minus
mordinal
multiply
N
ncaron
next
nine
noconversion
ntilde
number
numlk
numlock
O
oacute
ocircumflex
odieresis
oe
ogonek
ograve
ohungarumlaut
one
onehalf
onequarter
ooblique
open
openapple
option
otilde
P
pagedown
pageup
paste
pause
period
pf1
pf2
pf3
pf4
pgdn
pgup
plus
pound
prev
print
printscreen
props
prtscr
Q
question
questiondown
R
ralt
rbrace
rbracket
rcaron
rcmd
rcommand
rcompose
rcontrol
rctrl
remove
reset
ret
return
right
ring
rolldown
rollup
romanize
ropenapple
roption
rparen
rshift
S
sacute
scaron
scroll
scrolllock
section
select
semicolon
seven
sharps
shift
shiftleft
shiftright
six
slash
small
space
stop
superone
superthree
supertwo
sysreq
T
tab
tcaron
three
tilde
triangle
two
U
uacute
ucircumflex
udieresis
ugrave
uhungarumlaut
underscore
undo
up
uring
V
vbar
W
wordreg
wordrem
Y
yacute
ydieresis
yen
Z
zcaron
zdotaccent
zero
Plug and Play is both a design philosophy and a set of PC architecture specifications. The ultimate goal of Plug and Play is to design intelligence into the PC itself, to handle installation and configuration tasks without user intervention. A Plug and Play system has a number of characteristics. First, any installation is a simple, fail-safe operation. For devices the installation is automatic: plug the device in, turn on the system, and it works. With a Plug and Play system, the user can insert and remove devices, or connect-to or disconnect-from a docking station or network, without restarting the system or fiddling with configuration parameters. The system determines the optimal configuration, and applications automatically adjust to take full advantage of the new configuration. Users do not need to modify expansion card jumper settings, or even modify operating system configuration files. The benefits to both users and computer industry members will be substantial, as PC ease-of-use will be enhanced while support costs will be substantially lowered.
The Plug and Play COM specification, a component of the overall Plug and Play Architecture, presents a mechanism to provide automatic configuration capability to peripheral devices that connect to a PC using Asynchronous Serial Data Interchange on standard serial ports, commonly known as COM ports. This enables full Plug and Play for the PC system, including external serial peripherals, referred to here as COM Devices.
The essential elements of Plug and Play COM are:
Identify the device
Locate a driver for the device
Detect detachment of serial devices
Full compatibility between existing COM hardware and software and the new hardware and software which support Plug and Play
The full Plug and Play COM specification defines mechanisms that each Plug and Play COM device must implement to support identification, which in turn supports automatic configuration of the entire PC system without end-user intervention.
The solution of the COM device identification problem addresses major concerns of end-users, system integrators, and operating system vendors. It also presents an excellent business opportunity for providing measurable value and differentiation in the short term, by reducing the user difficulties and associated technical support costs.
There are two ways that serial device manufacturers can implement this specification. For simple hardware based devices (e.g., serial mice) the hardware (e.g., ASICs) will need revision. For intelligent serial devices (e.g., modems and printers) these changes can be implemented by controller code firmware changes. However, care has to be taken in the controller code to avoid false-positive (erroneous) detection of the COM Enumerator (confusing the application software with unexpected PnP ID) or failure to detect the COM Enumerator.
There is now a forum on the Compuserve Information Service to address Plug and Play in Personal Computers. Please refer to this forum for all your Plug and Play support needs. This forum is the official mechanism for support, information and discussion, as well as receiving current versions of Specifications. Type "GO PLUGPLAY" to access this forum. To obtain a Compuserve account (if you don't already have one) please call 1- 800-848-8199.
For further details on the Plug and Play architecture and implementation details, see the following documents, some may be available on the CompuServe Plug and Play forum:
Plug and Play ISA Specification, Microsoft 1993
Plug and Play BIOS Specification, Microsoft 1993
Plug and Play PCMCIA Specification, Microsoft 1993
CCITT V.24, List of definitions for interchange circuits between data terminal equipment and data circuit terminating equipment.
EIA/TIA-232-E Interface between data terminal equipment and data communication equipment employing serial binary data interchange on unbalanced circuits.
EIA/TIA-574 9-position Non-synchronous Interface Between Data Terminal Equipment and Data Circuit- terminating Equipment Employing Serial Binary Data Interchange
EIA/TIA-578 Asynchronous Facsimile DCE Control Standard-Service Class 1
TIA/EIA-592 Asynchronous Facsimile DCE Control Standard-Service Class 2
TIA/EIA-602 Serial Asynchronous Automatic Dialing and Control
PCCA XSTD-101 Data Transmission Systems and Equipment- Network Independent Dialing, Control and Data Transfer for Asynchronous DCE
This document is hosted on the Trace R&D Center Web site. Please visit our home page for the latest information about Designing a More Usable World - for All.