The PC uses a 16C450 (or compatible) UART (at least those PCs which are lucky enough to have a serial port at all). It DOES have a means to transmit and/or receive the 9-th bit, even if it is called differently, but there ARE several caveats - which are more the result of PC-approach (remember, PC is NOT a CONTROLLER but a COMPUTER) than defficiencies of the UART itself. What the 16C450 does not have is the mode when all bytes with 9th bit unset are ignored, but that's all.

The 16C450 can handle an optional parity of any given polarity (plus the standard even/odd); called MARK and SPACE as per standard RS232-terminology. There are two cases: transmission and reception.

Before transmitting a byte, the appropriate parity can/should be set. This is exactly the same as with the '51 UART except the name of this bit - before you transmit a byte in 9-bit mode, you need to set the 9th bit "manually" in both cases.

Reception is slightly different. In 16C450, the "trick" is to set the parity in one way (say, SPACE); then the 9th bit in received bytes is distinguished as parity error. Again, this is only a name for a status bit - renaming it "received 9th bit" will make it the same as in '51.

Caveat#1: As the parity setting in 16C450 is common for both transmitter and receiver, this scheme might result in erratically evaulated 9th bit when simultaneously transmitting and receiving. However, only in very rare cases the 9th bit mode is used in a manner requiring fullduplex communication - the most common case is a RS-485 (or similar multidrop) bus, which is naturally halfduplex.

Caveat#2: 16C450 is almost never used. Most of the UARTs are 16C550 compatible, which have FIFOs. The parity flag is applied to the currently transmitted byte, so if you fill the FIFO and then change the parity, the changed parity will be applied to bytes transmitted from FIFO (this is maybe a flaw but nobody assumes you will change parity on-the-fly). The remedy is easy: the FIFO in 16C550 can be disabled, resulting in 16C450-compatibility.

Caveat#3 (the most serious): UARTs - as any other hardware - in modern OS are hidden behind a software "abstraction" layer (call it driver, API, VxD, or anything). This software usually disables any real-time access to hardware (which in itself is a very serious problem), and often also simply disables access to needed resources of the hardware (such as the parity bit or parity error - they are not needed for "normal" applications). This is a price for modularity (i.e. you can replace the hardware by other type of hardware, even a combination of hardware and software - see virtual serial ports).
That's why "special drivers" have to be used.


There might be terminal emulator programs which can handle the 9th bit, but I know of none too comfortable. Terminal by Bray can change transmitted parity to MARK and SPACE when needed, but it simply ignores the parity errors in reception.

Jan Waclawek