How Windows 3.11 Supported 19200 bps Serial Ports

This article examines how Microsoft Windows 3.11 achieved reliable serial communication at speeds up to 19,200 bits per second (bps). It covers the underlying architectural mechanisms, including the role of the 16-bit communications driver, 386 Enhanced Mode virtualization, hardware flow control, and the critical integration of the 16550A UART's FIFO buffers to prevent data loss in a cooperative multitasking environment.

The Role of COMM.DRV and SERIAL.386

Windows 3.11 managed serial I/O via a layered driver model consisting of the user-facing communications driver (COMM.DRV) and, in 386 Enhanced Mode, the Virtual Communications Driver (*vcd or SERIAL.386).

COMM.DRV provided the standard Windows Communications API, exposing functions such as OpenComm(), ReadComm(), and WriteComm() to 16-bit applications. To handle 19,200 bps without stalling the operating system, COMM.DRV utilized an internal software ring buffer (typically 1,024 to 4,096 bytes) allocated in memory. When running in 386 Enhanced Mode, the low-level virtual device driver intercepted serial hardware interrupts (IRQ3 and IRQ4) directly, rapidly offloading bytes from the physical COM port hardware into memory before the application layer processed them.

Overcoming the 8250 UART Bottleneck with the 16550A

Older IBM PC hardware relied on the National Semiconductor 8250 or 16450 UART (Universal Asynchronous Receiver-Transmitter). These chips featured only a 1-byte holding register. At 19,200 bps, an incoming byte arrives roughly every 520 microseconds. Because Windows 3.11 relied on cooperative multitasking, a background task or disk access could introduce interrupt latency exceeding that 520-microsecond threshold, resulting in frequent buffer overrun errors.

To sustain 19,200 bps reliably, Windows 3.11 took advantage of the 16550A UART. The 16550A introduced a 16-byte FIFO (First In, First Out) hardware buffer for both receiving and transmitting. The driver configured the UART's interrupt trigger level (commonly set to 4, 8, or 14 bytes). Instead of firing an interrupt for every incoming character, the UART waited until the FIFO filled to the trigger threshold, buying the CPU sufficient time to switch context and service the port before an overrun occurred.

Hardware Flow Control (RTS/CTS)

At 19,200 bps, software flow control (XON/XOFF) was often too slow to prevent overruns because the signal character itself could get stuck behind queued data. Windows 3.11 resolved this by prioritizing hardware handshaking via the RTS (Request to Send) and CTS (Clear to Send) pins:

  • Inbound Throttling: When the receive buffer filled near capacity, the driver dropped the RTS line, signaling the remote modem or terminal to halt transmission immediately.
  • Outbound Throttling: The transmitter checked the CTS line before sending data; if dropped by the receiving end, the Windows driver halted byte transmission until cleared.

Configuration via Control Panel and SYSTEM.INI

Windows 3.11 made 19,200 bps accessible through the native Ports applet in the Control Panel, where users could configure the default baud rate, data bits, parity, stop bits, and flow control. Advanced tuning was handled directly in the SYSTEM.INI file under the [386Enh] section using parameters such as:

  • COMxFIFO=1: Explicitly enabled the 16-byte FIFO support on COM ports (enabled by default for detected 16550A chips).
  • COMxBuffer=: Adjusted the size of the 386 Enhanced Mode software buffer to handle sustained bursts at higher baud rates.