"8042" PS/2 Controller
Overview
The PS/2 Controller (often called a "Keyboard controller") is located on the mainboard. In the early days the controller was a single chip (8042). As of today it is part of the Advanced Integrated Peripheral.
The name is misleading because the controller does more than controlling communication with PS/2 devices.
 |
History
The PS/2 controller supersedes an older (uni-directional, single channel) XT controller. The XT controller is only partly compatible (but is 100% obsolete).
 |
To reduce costs, IBM originally used some of the general purpose input/output capabilities of the XT controller to control various unrelated parts of the system. This includes:
- System Reset
- Enable/Disable the A20-Gate
- Controlling the PC Speaker together with the Programmable Interval Timer.
When IBM upgraded to the (bi-directional) PS/2 controller, they intended it to be used to control a keyboard and a mouse, and therefore added support for controlling a second PS/2 channel. Unfortunately, at the time most people were using mice connected to Serial Ports (the PS/2 mouse didn't catch on until later) and several clone manufacturers created PS/2 controllers that only support a single PS/2 channel. Eventually (around the late 80486 and early Pentium time frame) PS/2 mice became more popular, and PS/2 controllers have supported two PS/2 channels since then.
Translation
The original keyboards (using the old XT interface) used "scan code set 1". When the original interface was superseded, IBM wanted to use a newer scan codes, or "scan code set 2". This change would have created compatibility problems for older software that was expecting different scan codes from the keyboard. To avoid the compatibility problem, for the first PS/2 channel, the PS/2 controller supports a translation mode. If translation is enabled the PS/2 controller will translate "scan code set 2" into "scan code set 1".
This translation is enabled by default; and can't be reversed in software. For example, if you receive the byte 0xB5 from the controller, then you can't know if the original data (sent to the controller by the device) was the byte 0xB5; or if it was the two bytes 0xF0, 0x33; or if it was the two bytes 0xF0, 0xB3.
For software to actually use "scan code set 2" (or "scan code set 3"), or to allow different types of PS/2 devices to be used in the first PS/2 port, you need to disable this translation to avoid having the data from the device mangled.
USB Legacy Support
By modern standards you will find many PCs bundled with USB input devices. Some PCs may not even have PS/2 connectors at all. To remain compatible with old software, the mainboard emulates USB Keyboards and Mice as PS/2 devices. This is called USB Legacy Support.
Because the implementation differ by manufacturer and mainboard there are flaws and sometimes even bugs:
- Some emulation layers also handle the communication with the real PS/2 connectors regardless of any connected USB device. So maybe not all capabilities of the PS/2 connectors and devices can be used. For example extended mouse modes needed to use the scroll wheel won't work or the keyboard only works on the first PS/2 connector and the mouse only on the second connector.
- The SMM BIOS that's providing the PS/2 USB Legacy Support may not support extended memory techniques or Long Mode and may cause system crashes.
This USB Legacy Support should be disabled by the OS as soon as the OS initialises the USB Controller, and this should be done before the OS attempts to initialise the real PS/2 controller. Otherwise the OS would only be initialising the emulated PS/2 controller and there's a large risk of problems caused by deficiencies in the firmware's emulation.
PS/2 Controller Commands
The PS/2 Controller accepts some commands and performs them. These commands should not be confused with bytes sent to a PS/2 device (e.g. keyboard, mouse).
To send a command to the controller, write the command byte to IO port 0x64. If there is a "next byte" (the command is 2 bytes) then the next byte needs to be written to IO Port 0x60. If there is a response byte, then the response byte needs to be read from IO Port 0x60.
| Command Byte | Meaning | Response Byte |
|---|---|---|
| 0x20 | Read "byte 0" from internal RAM | Controller Configuration Byte (see below) |
| 0x21 to 0x3F | Read "byte N" from internal RAM (where 'N' is the command byte & 0x1F) | Unknown (only the first byte of internal RAM has a standard purpose) |
| 0x60 | Write next byte to "byte 0" of internal RAM (Controller Configuration Byte, see below) | None |
| 0x61 to 0x7F | Write next byte to "byte N" of internal RAM (where 'N' is the command byte & 0x1F) | None |
| 0xA7 | Disable second PS/2 port (only if 2 PS/2 ports supported) | None |
| 0xA8 | Enable second PS/2 port (only if 2 PS/2 ports supported) | None |
| 0xA9 | Test second PS/2 port (only if 2 PS/2 ports supported) | 0x00 test passed
0x01 clock line stuck low 0x02 clock line stuck high 0x03 data line stuck low 0x04 data line stuck high |
| 0xAA | Test PS/2 Controller | 0x55 test passed
0xFC test failed |
| 0xAB | Test first PS/2 port | 0x00 test passed
0x01 clock line stuck low 0x02 clock line stuck high 0x03 data line stuck low 0x04 data line stuck high |
| 0xAC | Diagnostic dump (real all bytes of internal RAM) | Unknown |
| 0xAD | Disable first PS/2 port | None |
| 0xAE | Enable first PS/2 port | None |
| 0xC0 | Read controller input port | Unknown (none of these bits have a standard/defined purpose) |
| 0xC1 | Copy bits 0 to 3 of input port to status bits 4 to 7 | None |
| 0xC2 | Copy bits 4 to 6 of input port to status bits 4 to 7 | None |
| 0xD0 | Read Controller Output Port | Controller Output Port (see below) |
| 0xD1 | Write next byte to Controller Output Port (see below)
Note: Check if output buffer is empty first |
None |
| 0xD2 | Write next byte to first PS/2 port output buffer (only if 2 PS/2 ports supported)
(makes it look like the byte written was received from the first PS/2 port) |
None |
| 0xD3 | Write next byte to second PS/2 port output buffer (only if 2 PS/2 ports supported)
(makes it look like the byte written was received from the second PS/2 port) |
None |
| 0xD4 | Write next byte to second PS/2 port input buffer (only if 2 PS/2 ports supported)
(sends next byte to the second PS/2 port) |
None |
| 0xF0 | Pulse output line low for 6 ms. Bits 0 to 3 are used as a mask (0 = pulse line, 1 = don't pulse line) and correspond to 4 different output lines.
Note: Bit 0 corresponds to the "reset" line. The other output lines don't have a standard/defined purpose. |
None |
PS/2 Controller Configuration Byte
Commands 0x20 and 0x60 let you read and write the PS/2 Controller Configuration Byte. This configuration byte has the following format:
| Bit | Meaning |
|---|---|
| 0 | First PS/2 port interrupt (1 = enabled, 0 = disabled) |
| 1 | Second PS/2 port interrupt (1 = enabled, 0 = disabled, only if 2 PS/2 ports supported) |
| 2 | Unknown |
| 3 | Should be zero |
| 4 | First PS/2 port clock (1 = disabled, 0 = enabled) |
| 5 | Second PS/2 port clock (1 = disabled, 0 = enabled, only if 2 PS/2 ports supported) |
| 6 | First PS/2 port translation (1 = enabled, 0 = disabled) |
| 7 | Must be zero |
PS/2 Controller Output Port
Commands 0xD0 and 0xD1 let you read and write the PS/2 Controller Output Port. This output port has the following format:
| Bit | Meaning |
|---|---|
| 0 | System reset (output)
WARNING always set to '1'. You need to pulse the reset line (e.g. using command 0xFE), and setting this bit to '0' can lock the computer up ("reset forever"). |
| 1 | A20 gate (output) |
| 2 | Second PS/2 port clock (output, only if 2 PS/2 ports supported) |
| 3 | Second PS/2 port data (output, only if 2 PS/2 ports supported) |
| 4 | Output buffer full with byte from first PS/2 port (connected to IRQ1) |
| 5 | Output buffer full with byte from second PS/2 port (connected to IRQ12, only if 2 PS/2 ports supported) |
| 6 | First PS/2 port clock (output) |
| 7 | First PS/2 port data (output) |
Initialising the PS/2 Controller
TODO Note: this is Controller initialisation and NOT Device initialisation
Detecting PS/2 Devices
TODO
Hot Plug PS/2 Devices
WARNING: PS/2 was never intentionally designed to support hot-plug. Usually it is fine as most PS/2 controllers have reasonably robust IO lines, however some PS/2 controllers (mostly those in old chipsets) may potentially be damaged.
Despite the warning, most OSs (Windows, Linux, etc) do support hot-plug PS/2. It is also relied on by old "mechanical switch" KVMs (which allow the same PS/2 devices to be shared by multiple computers by effectively disconnecting the device from one computer and connecting it to the next).
When a PS/2 device is removed the PS/2 controller won't know. To work around this, when no data has been received from the device for some length of time (e.g. 2 seconds), an OS can periodically test for the presence of the device by sending an "echo" command to the device and checking for a reply. If the device doesn't respond, then assume the device has been unplugged.
When a PS/2 device is first powered up (e.g. when it is plugged in to a PS/2 port), the device should perform its Basic Assurance Test and then attempt to send a "BAT completion code". This means that software (e.g. an OS) can automatically detect when a PS/2 device has been inserted. Note: If a device is removed and then another device (or the same device) is plugged in quickly enough, the software may not have had time to detect the removal.
When software detects that a device was plugged in it can determine the type of device (see above). If the device was the same type as before software can re-configure it so that the device is in the same state as it was before removal. This means that (for example) someone using an old "mechanical switch" KVMs doesn't lose state (things like keyboard LEDs, typematic rate, etc) when switching between computers. If the device is not the same as before or there was no previously connected device, then software may need to start a new device driver (and terminate the old device driver, if any).
Sending Bytes To Device/s
TODO
Recieving Bytes From Device/s
TODO
CPU Reset
To trigger a CPU Reset (No matter what state the CPU currently has) you have to write the value 0xFE to the Output port.
;Wait for a empty Input Buffer
wait1:
in al, 0x64
test al, 00000010b
jne wait1
;Send 0xFE to the keyboard controller.
mov al, 0xFE
out 0x64, al