From MSDOS and ISA to Multicore CPUs and Windows

MSDOS

• In The early 1980s when the IBM PC was first introduced IBM and other companies quickly made RS232 serial communications addon boards available to allow the connection of the PC to external devices.
• The PC was generally running the MS DOS operating system and programs were coded so that the program talked directly to whatever hardware resources they needed. Standard Serial ports were always expected to be at fixed i/o addresses and wired to certain interrupts.
• COM1: ADDRESS=03F8 hex IRQ=04
• COM2: ADDRESS=02F8 hex IRQ=03
• MSDOS could only run one application program at a time and an unwritten assumptions of all these programs was that they had exclusive use of and immediate unrestricted access to all PC system resources

ISA Cards

• ISA Cards 1981-1997
• Serial Port Resources are set by the user using DIP switches and jumpers
• ISA no plug and play- the add in card had no mechanism for automatically informing the PC system what resources it needed.
• The PC had no mechanism for allocating resources to add in cards, everything was down to the user knowing exactly what was in the PC and being able to personally ensure that one device in the PC does not clash with any other.

Windows 3.1

• With the tremendous success of Windows 3.1 in early 1990s programmers started to become familiar with writing code so that application programs talked to system Device Drivers that presented a standard API to the outside world. This Windows Device Driver then managed the actual communications to the serial ports hardware.
• Windows 3.1 was a system that implemented cooperative multitasking and so was capable of running multiple well behaved application programs at the same time provided they accessed the system resources strictly via the system Device Drivers through the Microsoft provided Application Programming Interfaces- Device Driver APIs
• It was necessary for the user to tell Windows what hardware resources serial port add in cards needed by entering data using the System in Control Panel.
• Though the Device Drivers in principle allowed serial ports at any otherwise unused i/o address and interrupt in practice COM1: and COM2: used exactly the same values assumed by MSDOS programs. This greatly eased the transition from MSDOS to Windows serial applications

ISA To PCI Transition

• ISA to PCI Change
• In the late 1990s the slots on new PC motherboards underwent a gradual change from being ISA only through a mix of ISA and PCI to being completely PCI slots.
• PCI cards were configured electronically as the PC booted up. The card requests resources from the PC which responds by allocating it i/o address and interrupt. Typically the resources allocated do not correspond to those traditionally used by ISA cards.
• Old MSDOS applications running in a DOS window inside Windows broke mainly because they expected to talk to serial ports at particular i/o addresses and interrupts.
• Huge effort was invested by the industry and customers in migrating their code to work with PCI based PCs. However issues to do with the unwritten assumptions of these programs that they had exclusive use of and immediate unrestricted access to all PC system resources remained hidden in the program code.

Serial Port Improvement

• The burden of implementing the Windows OS on the CPU where the application programs only actually run during small time slices meant that the PC could no longer do real time control of the serial port. To overcome this extra features were added to the serial port chip- the UART- to lower the burden on the PC the first one being 16 byte transmit & receive FIFO buffers. The data sent and received by Windows to the serial port is no longer a character at a time but is now transferred in FIFO size packets. This trend continues to this day with the following features being implemented in stateof the art UARTs.
  • FIFO size grows from 16 to 32 to 64 to 128 and 256 bytes
  • Automatic flow control RTS/CTS or DTR/DSR implemented in hardware
  • XON/XOFF flow control in hardware
  • RS485 Half Duplex Autogating
  • DMA transfers of data to and from the serial port.
  • Baud rates higher than 115,200 and non standard baud rates
• Today the way an application communicates to a serial port has become completely uncoupled from the underlying hardware that actually implements the serial interface. Instead the Application talks to the Windows API in a standard manner, the serial port hardware manufacturer provides a device driver that interfaces to Windows OS and repackages the transactions in a manner that is compatible with the actual serial implementation

Validation of Platform

• As in the days of DOS, it has proved that there are often many hidden assumptions in code of Windows application programs about the underlying hardware implementation and performance. This results in programs ‘breaking’ when being moved from one version of Windows to another or with different firmware versions or due to changes to the external network system.
• Timeouts in programs that allow an application to recover gracefully when the communications system fail often cause errors to be incorrectly reported when the serial port hardware is changed to one with longer inherent latency.
• These issues may be exacerbated by the use of multi core CPUs in the PC since the context change time from one core to another adds its own latency.
• To mitigate against these issues system suppliers often go through along costly period of validating a given solution, characterising its operational performance in a large number of defined test cases.
• Sometimes this merely results in a making a particular system work because of tweaking of parameters to match the quirks of the various devices involved, preventing platform evolution over time.

---

This is part 1 in a 3 part series.

Part 2: 

Latency and Response Times

Part 3:

The Software Challenge

Download the full presentation below: