The word has spread around most user groups that a NS16550AFN is the quick fix for any number of modem problems. Fact or folklore? What is a 16550? What does it cost to implement? Is it worth it? This article will answer those questions, debunk a few myths, and tell you how to make the swap.
The needs of the colony are relayed in messages called interrupts. So called because they interrupt the normal operation of the CPU to service the request of a colony member. For each interrupt, bookmarks must be placed in the program under execution. After servicing the interrupt, the CPU returns to the bookmarks and resumes execution. The whole interrupt process is inefficient and can drastically affect overall performance if repeated interrupts are used.
On the serial side, it receives and transmits bits of data to and from the modem using a serial bus. The serial bus operates at a much slower data rate and only has one data path as compared to the parallel bus's eight or sixteen data paths. The serial bus's maximum data exchange rate is at least 500 times slower than the parallel bus.
The advantages of the 16550 are its 16-byte FIFO (First-In-First-Out) buffers for both the transmit and receive data paths and its ability to operate at higher baud rates. Unlike systems with large FlFOs, the principle function of the UART is not data storage. These FIFOs act like elastic links that can stretch, if needed, to smooth data flow. With FlFOs, the timing of serial data transfer becomes less critical. Relaxed timing requirements, together with a higher baud rate, allow a higher rate of data flow.
OK! You fixed the refrigerator! The above paragraph has been paraphrased from a collection of UART articles. The paragraph illustrates the problem caused by myths abounding around UARTs and the 16550 in particular. While these statements are essentially true, they miss the point and detract from a understanding of the real problem. Reducing the interrupt service time is like fixing the refrigerator when you live at the north pole.
The FIFO buffers are extremely small allowing, on average, only five bytes of (one byte at a time) data transfer per interrupt service routine. This could save about 800 CPU ticks, about 32 microseconds (using a 25 MHz CPU clock). 32 microseconds could make coexistence with multitasking easier but it is otherwise a very small change. The big savings occurs in preventing overrun errors. A single overrun error can take many seconds to recover. Overrun errors can cause modems to down shift to slower speeds or even worse, abort the transfer.
Not quite! UARTs are single function pieces of hardware that perform one particular function of data formatting. UARTs are dumb chips. They do not calculate or control anything. They do not off-load any burden from the CPU in the sense of cooperative processing. UARTs simply relay and format data... Garbage in, Garbage out... Serial interfaces that do cooperative processing and block data transfers are available. Expect to pay upwards of a thousand dollars for such an interface.
The maximum serial data exchange rate is governed by the slowest element in the serial data path. For any modem-to-modem transfer, there is a minimum of four major elements in the serial data path: The near-end UART and modem, and the far-end modem and UART.
The bottleneck always has been the modems. Even though modern modems are forty-eight times faster than the modems first used on the PC, the modem will remain the bottleneck until replaced by ISDN or other faster technologies. If the modem is the bottleneck, why the concern with the UART? Two reasons:
1) Because the modems are the bottleneck, every effort should be made to maximize their throughput. Modems should never be kept waiting on a CPU.
2) A constant stream of high frequency interrupts will bring a CPU to its knees. Modems become, in effect, the controlling elements. This removes control from the program or operating system. The problem becomes how to interface the CPU to the modem in such a way as to never make the modem wait, while maintaining program control.
Virtually every aspect of the Advanced Technology (IBM PC) machines is vastly improved except for the serial port, the interface point between CPU and modem. Improving the serial port really requires hacking up the BIOS or using special device drivers. Neither solution is very elegant or cheap and must be very carefully implemented to maintain compatibility. In other words, it must be done at the manufacturing and design levels.
Obviously, buying one of the new super serial cards is the best solution in terms of performance. However, it may be possible to get equivalent performance from a field upgrade of your existing serial card by replacing the UART within the serial card. Obviously replacing the chip is cheaper too. Finding out if you can upgrade your existing serial card to a NS16550AFN UART will require a little detective work. If you are not the technical type, you may want to invite your favorite techno-weeny over for dinner. (I like steak.)
Before you invest in a dinner, determine if your system really needs a new UART with this simple Q & A test. If you answer Yes to two or more of the following questions, you need a NS16550AFN. (Note: Once again, if you have an internal modem, you should NOT upgrade your UART.)
Do you need a UART upgrade test:
The above criteria are based upon a few generalizations:
1) The more powerful your machine, the less likely
you need an upgrade. A fast CPU is one way of
overcoming inefficiencies.
2) The more power-hungry your applications,
the more likely you need to upgrade.
If you elect to replace the entire card, make sure you can return it if your system does not recognize the NS16550AFN. Some cards sold as 16550s are intended for UNIX systems and are not compliant with MSDOS systems. Whether you buy a new card or upgrade your old one, you will still need to upgrade your software after completing hardware installation. (See Software Upgrades, later in this article.)
If you elect to upgrade an existing card, find your UART and make sure the board is upgradable before buying the chip. It's always a good idea to take the card with you to buy the chip.
The newer short card frequently uses a square chip, approximately 1.5 by 1.5 inches. The square multi-I/O chips may look alike but they vary greatly. There is actually a square version of the NS16550AFN but more likely your chip is a variant of a SMC (Surface Mount) design. The SMC or VLSI chips need further determination obtained by running software tests on your computer.
The older card is usually physically longer and will have one or two UARTs. (Intel "Above Board Pluses" fall into this category but are not upgradable.) Frequently only the second UART is in a socket. (Also, second UARTs may be permanently assigned to COM2.) Socketed chips are (much) more easily upgraded.
Most UARTs are a distinctive 0.6 inch wide by 2.1 inches long and have 40 pins. Unless you are very good with a soldering iron, the UART must be in a socket, so take a look at the sockets on the board first. (If you are upgrading an empty UART socket and there are two small empty 14-pin sockets, you will need to purchase and install MC1488 and MC1489 chips as well.)
The most common UART chips are the 8250A, the 16450A and the NS16550AFN. (There may be a letter inserted in the type number i.e. 16C450A.) The 8250 is the original, the 16450 the second generation, and the 16550 the third generation. Second generation chips may be appropriate for some users. 16550 chips sell in the $12 to $14 range. 16450 chips sell for about half that. (See Software Upgrades for more information on the 16450.)
For instance, one program called 16550.EXE (found in the archive file 16550U.ZIP) correctly found the 16550 while also identifying COM3 and COM4 as running 16550s, even when these ports were not installed. It also failed to find a 16450 COM port.
Another program, IS16550.COM (found in archive file IS16550.ZIP) correctly found all COM ports and correctly identified 16550s. It also attempted to test the ports and all ports failed even though there was no apparent problem with the card.
I recommend the program UARTID.EXE found in the archive CHKURCOM.ZIP. It correctly identifies the COM ports, the UART type and all UART settings. This is a very simple program that can be extremely valuable for checking setup and status. For those readers that want a slightly more functional test program, try MODEM DOCTOR (MDR.EXE) found in MODEMD52.ZIP. The MODEM DOCTOR has nice color menus and works correctly for all tests but is somewhat crippled in its shareware version.
1) It allows the modem's FIFO (not to be confused with the UART FIFO) to fill up with data. This is necessary to maintain maximum throughput.
2) It permits the data rate to float. A floating data rate permits the modem to fully utilize all the new advances such as data compression, synchronous data transfer and advanced modulation techniques to the maximum extent possible.
3) The effectiveness of the UART FIFO is multiplied by the locked DTE baud rate. The more effective the FIFO, the more easily a multitasking operating system interfaces to the serial port.
Many are confused by locked DTE modem operation. Part of the confusion stems from the words data rate and baud rate. The words are often misused by interchanging. Baud rate is an ancient term dating back to Samuel Morse that has been somewhat redefined to meet modern requirements. It's related to frequency.
IEEE defines baud as "a unit of signaling speed equal to the number of discrete conditions or signal events per second". The problem is the word events. Some events contain data and some events don't. Worse, some events contain two or more data pieces per event. No wonder everyone is confused. Since the object is to transfer data, it is much more meaningful to refer to data rate. Data rate is measured by counting the number of pieces of data per second. Simple? No!
Ideally, data rate is measured in bytes per
second. The trouble is, data communication
does not always deal with conventional bytes.
Data communications are more likely to deal in bits.
The bits comprise frames. Frames may contain
5, 7, 8, 9, 11, 256, or more bits per frame!
Even worse, frames may change dynamically
making measuring data rate like writing on Jello.
In spite the difficulty of measuring exact data rates, approximate data rates are easily determined. Here are a few simple rules to sort out data and baud rates:
1) When dealing with setting up hardware, refer to baud rate. That is, use hardware to set baud rate.
2) When dealing with data communications use the data rate. Tune software to maximize data rate.
Rule Of Thumb: Data rate (in characters per second) is (very) approximately equal to the baud rate divided by ten.
The labels used here are from the communications program TELlX, but all programs will have similar function labels. PROCOMM labels are almost identical.
In TELIX, deleting the configuration file (TELIX.CFM) will initiate an automatic reinstallation process. (There is a reinstallation program for PROCOMM called PCINSTAL.EXE, dated 06/24/92 (INSTPC.ZIP) that can be used for reinstallation. Use the "I", "Install a new modem or direct connection" command option.) Programs like TELIX can also be reinstalled from within the program by using the "ALT O" command to access the configuration menu.
Start software modification by setting the "Terminal Baud Rate" to 57,600, "Shell: 16550 Buffer On" to "ON" (if using a 16550 or to "OFF' if using a 16450) and "Auto Baud Detect" to "OFF".
Next, check the modem program dialing directories ("ALT D"). Most directories store the baud rate associated with each dialing entry. Reset all entries to the locked DTE baud rate. The modem will take over the function of selecting the correct baud rate for each connection. Failing to reset all entries to the DTE rate will lose the benefit of updating the UART.
Here are several drivers found on local BBSs: COMM56.DRV, 09/28/92 (COMM56.ZIP) (Third party) or COMM.DRV,10/01/92 (COMMDRV.ZIP) (Microsoft). For OS/2 users the third party drivers, SIO.SYS or VSIO.SYS, 05/14/93 (SIO102.ZIP) are highly recommended. If the driver names are identical, you may copy the replacement driver over the older driver. Otherwise you will need to edit SYSTEM.INI to reflect the new name. E.G., "comm.drv=comm.drv" is replaced by "COMM.DRV=COMM56.DRV"
Here are a few other settings to look at:
device=*combuff (delete this line in your WIN.INI)
device=chcomb.386
[386Enh]
COM1FlFO=true
COM1Buffer=10000
COMBoostTime=4 (normally 2)
COMlrqSharing=true
The same tests were repeated after the UART switch. The maximum transfer rate was upped to 1595 CPS - not that big of a change for a modem that was already running a locked DTE at 57Kb.
The big change was in the number of other applications that could be run simultaneously. Three windows were opened under DesqView running applications that were known to abort data transfers - no effect on data transfers. Then four more windows were opened running lighter applications. Still no effect.
The effect was similar under WINDOWS,
except other WINDOWS applications suffered
a noticeable slowdown limiting the
maximum number of applications.
Not bad for the cost of a $14 part.
Page 6 had an ad for the Pacific Exchange BBS
For some time now much has been said regarding the many benefits of using the National Semiconductor 16550AFN Universal Asynchronous Receiver Transmitter (UART) for serial communications. With this I/O (Input Output) chip installed in your serial card, together with a high speed modem, you can achieve maximum serial port to modem (DTE to DCE) throughput with more reliable data transmissions.
The reason for this is because the 16550AFN can buffer (store) up to 16 incoming bytes, whereas other UARTs can only buffer 1 or 4 bytes. This allows the CPU to service other tasks while incoming bytes are stored safely. This is possible due to the larger buffer of the 16550AFN and enhanced software interfaces.
This article assumes that the reader is somewhat familiar with serial communications hardware and software. The article will explain how the 16550AFN works from a technical standpoint, and what benefits may result from its use. Also explained is a simple and inexpensive (free) way to detect what type of serial input/output UART chip is currently installed.
Once signaled, then CPU will fetch the byte via a software Interrupt Service Routine (ISR). However, just because the CPU has been signaled, it does not mean that it will be able to fetch the waiting byte before the modem overwrites it with another incoming byte.
The 8250 UART only has a 1-byte buffer, and therefore only 1 byte at a time can be "buffered." Also, the modem does not care whether the CPU has fetched the previous byte from the serial port or not, it just fills the buffer whenever it wants to. This can create a problem known in technical terms as a character overrun.
When an overrun occurs, it disturbs the data stream, which in turn causes software stream errors such as CRC and checksum errors. This, of course, is not good. However, if the serial port could temporarily buffer these bytes until the CPU had a chance to service the port, overruns could possibly be prevented or at least reduced. This is where the 16550AFN UART comes in.
To best illustrate the functions of the 16550AFN chip, let me paint a quick scenario. Assume an interrupt-driven serial port is attached to a modem that is online and connected a remote BBS. The computer is in the process of downloading a file using Zmodem, while running under Microsoft Windows 3.0 in "enhanced" mode. Keep in mind that Windows is a non-preemptive multitasking environment. This means that while Windows can manage multiple tasks at once, it must wait for an application to "give up" the CPU for other tasks. (Unlike OS/2's preemptive multitasking, which manages time allotment for all tasks.)
If a background application takes too much time, other tasks that need servicing are held up. In the case of the serial port, overruns can occur. For example, let's assume a background Windows application had to write a large amount of data to the hard disk. Due to the heavy load on the CPU during disk writes, it could cause interference with ongoing serial communications.
Why? Because the disk writing application did not free up enough CPU time to attend to incoming bytes. If the CPU is busy with other tasks, it cannot service other application needs. If another byte comes in, it overwrites the previous byte, causing an overrun.
The 16550AFN helps resolve this series of events by buffering incoming bytes. This chip automatically senses if a byte, or bytes, have not been retrieved by the CPU in time, and it will buffer the bytes, up to 16, until the CPU is freed from other tasks.
Now let's take a deeper look into how the 16550AFN functions, and how it really benefits the user on a software/hardware level. Let's assume a scenario in which the CPU did get tied up with another task, and the 16550AFN did its job and buffered 4 bytes. This means that the CPU, once freed, must now retrieve 4 pending bytes. Once the CPU has time to service the port, it retrieves the first byte, and is "notified" there are more bytes waiting. However, the CPU does not have to be interrupted to be notified of more pending bytes.
What the 16550AFN does is keep the Enable Received Data Available Interrupt (ERBFI) trigger bit high until the CPU can clear out all remaining bytes of data. If the ISR is programmed correctly, it should enable interrupts on entry (so higher priority interrupts can occur), and should not exit the routine until the ERBFI bit is low. This bit-polling and byte retrieval continues until the buffer is free of all buffered bytes, then the ISR can be exited.
By entering the ISR once, and retrieving several bytes at a time and then exiting, the number of times the CPU has to enter the ISR is greatly reduced. Less system interrupts are generated, thus requiring less CPU demand. When CPU demands are lowered, the likelihood of errors is diminished. This is why the 16550AFN chip shines.
The 16550AFN chip offers other benefits, such as higher port speeds (up to 256 kbps using an 8-MHz crystal and specialized circuitry), DMA (Direct Memory Addressing) support, and interrupt prioritization. However, those aspects are beyond the scope here.
Now that we know how the 16550AFN UART functions,
and what benefits it provides, let's find out
if we have one installed in our system.
FIFO.EXE is a utility program that detects
which type of UART I/O chip is in an IBM PC
compatible computer. FIFO.EXE is inside the
archive IFIFO10.ZIP, which includes the
full Turbo C source code listing,
documentation and the FIFO.EXE program.
It is a free download on the Berryessa Central BBS.
(That BBS is long gone.)
The FIFO.EXE program will tell us what
kind of UART I/O chip is installed:
Since the original PC/XT/AT design has only 2 serial ports, the FIFO.EXE program will only search for COM1 and COM2. According to DOSREF by Dave Williams, there is a "semi" standard for detecting the I/O addresses of COM3 and COM4. If you need to search other I/O addresses, just hard-code the variable "iobase" to your particular port address.
FIFO.EXE looks at two memory areas for COM1 and COM2 I/O port addresses. The word at absolute address [0040:0000] and [0040:0002] contain the I/O addresses for each COM port, respectively. If you want, add code to search the addresses [0040:0004] and [0040:0006] for COM3 and COM4, respectively.
Page 10 had an ad for the Mustang Software
(www.mustang.com)