Windows 98 Serial Port Baud Rates for Modems

In Microsoft Windows 98, managing serial port baud rates for external modems relied on a 32-bit communications architecture that decoupled the computer-to-modem interface speed from the physical telephone line transmission speed. Through the coordination of the VCOMM driver subsystem, hardware UART controllers, and the Unimodem driver, the operating system enabled high-speed data buffering, hardware flow control, and dynamic port configurations that maximized dial-up throughput while preventing data loss.

The Communications Architecture: VCOMM and SERIAL.VXD

Windows 98 handled serial communications through a layered 32-bit Protected Mode driver architecture centered on VCOMM.VXD. Rather than allowing software applications to write directly to serial hardware registers, Windows 98 routed all communication requests through VCOMM.

VCOMM served as the intermediary between communications APIs (such as Win32 Communications functions like SetCommState) and the port driver, SERIAL.VXD. When an application or dialer initiated a connection, VCOMM translated the software's requested baud rate into instructions for SERIAL.VXD, which directly programmed the serial port's Universal Asynchronous Receiver-Transmitter (UART) chip.

Decoupling DTE and DCE Rates

A fundamental mechanism in Windows 98 was the distinction between Data Terminal Equipment (DTE) speed and Data Communication Equipment (DCE) speed:

  • DTE Rate: The communication speed between the computer’s RS-232 serial port (COM port) and the external modem.
  • DCE Rate: The actual modulation speed negotiated over the analog telephone wire between the local modem and the remote provider (e.g., 28.8 Kbps, 33.6 Kbps, or 56 Kbps).

To take advantage of hardware-level data compression protocols such as V.42bis and MNP 5, the DTE speed needed to be significantly faster than the DCE speed. Windows 98 allowed users and modem configuration files to set the serial port to fixed, elevated baud rates—most commonly 57,600 bps or 115,200 bps. The external modem held this high-speed connection with the PC constant, buffering data internally and transmitting it over the telephone line at whatever DCE rate the line conditions permitted.

The Role of Unimodem and INF Files

Windows 98 utilized the Universal Modem Driver (Unimodem) architecture. Modems were installed using device-specific .INF files that defined the hardware's supported command sets and maximum allowable DTE rates.

During setup or manual configuration in the "Modems" applet within the Control Panel, users selected a "Maximum Speed" setting. When dialing out, Unimodem issued standard Hayes AT commands to initialize the modem and lock the serial interface at that designated rate, preventing the modem from falling back to lower serial port speeds when slower connection negotiations occurred on the line.

UART Utilization and FIFO Buffering

High serial baud rates placed heavy demands on the system CPU. To maintain stability at rates up to 115,200 bps, Windows 98 heavily relied on 16550A UART chips (or compatible successors) featuring 16-byte First-In, First-Out (FIFO) hardware buffers.

Within the Advanced Port Settings in Device Manager, Windows 98 provided slider controls for the UART FIFO buffers:

  • Receive Buffer: Determined how many bytes arrived in the UART buffer before triggering an interrupt to the CPU.
  • Transmit Buffer: Regulated how much outbound data could be loaded into the UART at once.

By tuning these buffers, Windows 98 balanced interrupt latency against processing overhead, ensuring the serial interface could sustain high baud rates without suffering buffer overflow errors.

Hardware Flow Control (RTS/CTS)

Because the serial port operated at a higher speed than the physical phone line, flow control was critical to avoid dropped packets. Windows 98 mandated Hardware Flow Control (RTS/CTS—Request to Send / Clear to Send) for high-speed modem configurations.

When the external modem's internal buffers filled up due to a slow DCE connection or line re-negotiation, it dropped the CTS voltage signal, prompting SERIAL.VXD to halt serial transmission instantly. Once buffer space cleared, the signal was restored, allowing reliable operation at elevated baud rates without manual software intervention.