Article 53835 of comp.dcom.modems: Newsgroups: comp.dcom.modems,comp.sys.ibm.pc.hardware.comm,comp.answers,news.answers Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!col.hp.com!fc.hp.com!rjn From: rjn@fc.hp.com (Bob Niland) Subject: MS-Windows COM and Ns16550A UART FAQ Summary: Improving Windows 3.x COM performance and reliability. Sender: news@fc.hp.com (news daemon) Message-ID: Supersedes: Approved: news-answers-request@mit.edu Date: Wed, 16 Feb 1994 21:43:00 GMT Expires: Thu, 17 Mar 1994 00:00:00 GMT Reply-To: rjn@csn.org (Robert J. Niland) Nntp-Posting-Host: hpfcesd.fc.hp.com Organization: Colorado SuperNet, Inc. X-Newsreader: TIN [version 1.2 PL1.4] Followup-To: comp.dcom.modems Keywords: uart 16550 16450 8250 datacomm windows serial modem turbocom Lines: 476 Xref: cs.utk.edu comp.dcom.modems:53835 comp.sys.ibm.pc.hardware.comm:1605 comp.answers:3793 news.answers:18591 Archive-name: windows-com-faq Last-Modified: 17 Feb 1994 15:00:00 GMT FAQ: The 16550A UART & TurboCom drivers Edition: 16 Feb 94 Expires: 17 Mar 94 This article applies to: Intel-based systems running Windows 3.0 and 3.1, to a lesser extent: DOS applications not running under Windows, but NOT to: Windows 2.0 or prior, Windows/NT, OS/2 or PC Unix. One of the unadvertised limitations of most current Windows PCs is that their RS-232C (serial, COM) performance is seriously deficient. Almost everyone who purchases a high-speed modem (V.FC, V.32terbo, V.32bis, V.32, PEP or HST) discovers the problem the first time they try to download a file or accept an incoming FAX (at 9600+) after upgrading the modem. Overrun, "CRC" and retry errors abound, even when the only active application is the datacomm or FAX program. If the transfer completes at all, it may take even longer than with the old 2400bps modem. There are three reasons for the problem: 1. The Universal Asynchronous Receiver/Transmitters (UARTs) used in most PCs are still primitive Ns8250 or 16450 devices with single-byte FIFO (First-In, First-Out) buffers. If the operating system/driver cannot read and flush each character at high interrupt rates, the next incoming character overwrites the FIFO and the previous one is lost. Plain DOS, being a fairly single-minded environment during datacomm, can usually keep up; standard Windows can't, and DOS apps running in standard Windows can't. 2. Windows has more operating system overhead than plain DOS, and interrupts often take longer to service. Overruns are much more likely than under DOS. As soon as you report to your PC/modem vendor that you are losing data, you may be advised that "you need to upgrade to a 16550". However, since there seems to be a conspiracy of ignorance about this issue, you'll often get no useful advice at all. Most of the store-front and mail-order sources I spoke with in attempting to solve my own problem had never heard the term "16550" and many didn't even know what a UART was. 3. Even if your PC has 16550A UARTs (and PS/2's do), or if you can upgrade your mother/COM board or add a new COM board, you may STILL experience errors and overruns because the standard MicroSoft DOS and Windows COM drivers don't take full advantage of the 16550A. Windows 3.1 is improved in this regard over 3.0, but I still recommend a driver upgrade. Applications cannot get around this problem by themselves unless they include a new COMM.DRV. If you have a modem CARD (i.e. an "internal" modem), you may or may not have a problem, as the modem part of the card can be designed to be aware of the state of the UART, and avoid overrunning it; however, I wouldn't want to bet that the card designers were that clever, and would generally insist on a 16550A UART when buying modem card. Some modem cards don't even have conventional UARTs, but if they are to work with standard Windows drivers, they need to simulate one. Use MSD.EXE (below) to see what type of UART the card is/emulates. In any case, if the modem card is pretending to be an 8250 or 16450, even though it may be immune from data loss, system overhead will be higher during I/O. You may not be able to get any useful work done in foreground while a file is being up/downloaded in background. The Hardware Situation. This applies to: Serial/COM ports/cards Internal modems/cards .but NOT.. External modems (What matters is the UART seen at the PC backplane. What's in the modem is generally irrelevant.) A UART is present anywhere that a serial bit stream needs to be converted to a parallel byte stream, and vice versa. An external modem may well have two; one to convert the mark/space stream to bytes (for internal error control, compression, flow control and protocol processing), and another to convert the user-ready bytes to an RS-232C one/zero stream. The computer's COM port will have yet another UART, and this is the most important one. The UARTs on most PC COM ports are based on National Semiconductor Ns8250 or Ns16450 chips (or silicon megacells inside VLSI chips where you can't replace them). You can identify the ostensible UART type on your system by running the MicroSoft diagnostic program: \DOS\MSD.EXE {for DOS 6.0 or later, with or without Windows} \WINDOWS\MSD.EXE {for WIN 3.1 or later, on any DOS} Be sure to run MSD in DOS *before* bringing up Windows. The Windows serial API may prevent MSD from accurately identifying a 16550 if you run it from a Windows DOS prompt. I am also informed that MS-Kermit, rev 3.13 or later, can ID the UART with the "show comm" command. The Ns16550A UART has separate 16-byte transmit and receive FIFOs with configurable trigger levels, and can run reliably at clock rates up to 460,800 bps, although with current modem technology, there's no point in pushing your luck by going over 115,200 bps, and many modems have a max DCE-DTE (modem-computer) rate of 57,600. The 16550 has shorter access cycle times than the 16450 or 8250. The 16550 also has DMA capability, but it is not clear that any PC drivers ever use this. For more technical info, see National Semiconductor Application Note AN-491. So, what UART component hardware do you have? Try to locate the UART on your mother board, multi-function I/O card, COM board or ISA/MCA modem card. If you can't find a socketed component with the numbers "8250" or "16450", your COM ports are probably buried in VLSI, and you won't be able to perform a chip replacement. If you have an actual 8250 or 16450 chip, but it is soldered in, I don't recommend replacing it unless you are an experienced solder-sucker operator. If you can DISABLE your VLSI or soldered-in COM ports (as I chose to do), you can at least add an aftermarket COM board. Disabling the UART may require throwing switches or configuring non-volatile BIOS registers. The 16550A is pin-compatible with the 16450 and 8250A, as long as the old and new parts are supplied in the same IC package. If you have one or more socketed 8250 or 16450 chips, you can buy plug-in Ns16550AFN (40-pin), Ns16550AFV (chip carrier) or PC16C550CN (low power CMOS version) ICs from several suppliers typically for $9 to $15 each. The "N" chip is the normal 40-pin dual-in-line package. Other styles are available, but avoid any Ns16550 chips without a letter suffix (the 16C550C are presumably all OK). The 16550A is compatible with the line-driver support chips used by your 8250 or 16450. Early non-"A" Ns16650 chips have bugs, although National will reportedly exchange those of their own manufacture for free. Clone chips are available from various IC makers other than National. The manual for the TurboCom driver (1.2) stated support for the following (apparently equivalent) chips: National Semiconductor: 16550A, 16551, 16552 (two 16550s in one chip) (PC87312 SuperIO chip has two 16550's inside) Chips&Technology: 82C607 Texas Instruments: t16c550a Silicon Systems: 73M550 VLSI 16C550 TurboCom warns about the pre-"A" Ns16550 and Western Digital 16C550, and says that problems have been reported with early IBM PS/2 55SX and 70 systems (IBM reportedly will upgrade them). If you DON'T have socketed 8250/16450 chips, you'll need to buy an after- market COM or multi-function board. If you have a modem card ("internal modem"), you may not be able to upgrade without replacing the card altogether. In any case, to add a new COM or multi-function card, you'll need to either disable the COM1/2 port(s) you are replacing, or re-assign them to COM3/4 (although watch out for IRQ conflicts without TurboCom). Although cheaper cards are available, in the interest of getting my problem solved quickly I elected buy a Modular Circuit Technology MCT-AIO+ card from: JDR Microdevices 2233 Samaritan Drive San Jose CA 95124 (800) 538-5000 voice US (408) 559-1200 voice other (800) 538-5005 FAX US The MCT-AIO+ (and the "+" is important) sells for $89.95. It is an 8-bit ISA card providing: Port Type Connector Address and IRQ Comments COM DB9M COM 1,2,3 IRQ 2,3,4,5 Ns16550AFN in socket COM ribbon COM 2,3,4 IRQ 2,3,4,5 Ns16550AFN in socket Parallel DB25F LPT1,2,3 IRQ 5,7 Game ribbon The kit includes a ribbon cable and DB25F connector for the secondary COM port, a ribbon cable/connector for the game port, two bulkhead plates for the ribbon-based connectors and a 9F-to-25F adaptor cable. Each port can be individually disabled, and the COM ports have TX, RX, RTS, CTS, DTR, DCD, and DSR jumpers. JDR also sells 16550A UART chips for $11.95, and a Super-I/O multi-function card that adds IDE. Pacific CommWare (below) has a 6-port 16550A card. I have heard from several people about less expensive m-f I/O cards with 16550As: TSD Systems (407) 331-9130 $19.95 for the card, plus $9.95 per 16550. R&S DATA SYSTEMS, INC. 820 East Highway 434 Longwood, FL 32750 PHONE: (407) 331-1424 FAX: (407) 331-8606 2COM/LPT/Game card w/2 16550s for $39 I have no personal experience with any of the firms except JDR. Meanwhile, back at the MCT card from JDR... I only needed two serial ports, and am running out of IRQs on my PC, so I disabled my built-in VLSI-based 8250 ports. However, with the TurboCom driver (below), I could have set the internals as COM3 and 4, using IRQ sharing. The Software Situation Simply upgrading to 16550A UARTs will not completely solve all overrun problems. DOS doesn't provide any support at all for the 16550A. It is up to each serial app to test for UART type and support it as appropriate. You can't even write a generalized boot-time app to enable the FIFO because that can result in events unexpected by typical DOS programs. In Windows, the standard MS serial drivers don't take full advantage of the 16550A. The Windows 3.0 drivers are even less capable, and the Windows 3.1 drivers have the following limitations: - They enable only the receive FIFO, and only at rates above 2400 bps. - They never enable the transmit FIFO, which results in an interrupt rate of 10x during uploads. - They set the trigger level at 14 bytes (too high - it's easy for 2 more bytes to arrive before the driver can read the FIFO). - The Ports menu of the Control Panel only allows speeds up to 19200. With a V.32bis modem, sparse data and text can easily compress 3:1 or more, suggesting that a host DTE connect rate of 57,600 bps would be effective. - Windows provides no workaround for apps that don't provide port speed options above 19200 bps. - The API won't accept rates above "CBR_128000". - The API won't let DOS programs know there is a 16550 there, so I/O from a DOS app will still be based on the interrupt-per-character model. Even if the Win16 API made the 16550 visible, DOS programs that aren't 16550-aware get little benefit from a 16550 port with the standard drivers. - They don't allow IRQ sharing for COM3,4. - A "skipped" COM port (no hard present, or hardware disabled), may prevent any access to higher numbered COM ports that are present. - The BIOS doesn't initialize COM3,4 properly in many systems, and Windows doesn't necessarily clean this up properly when booted.. These problems are reportedly NOT solved in Windows NT (alpha, beta or initial release) nor in DOS 6.0 or 6.2, and may or may not be addressed in any Windows releases after 3.1 (but before "Chicago/4.0"). Rumors suggest they "may" be solved in Chicago. I have heard no rumors about "Cairo". There are rumors that Windows for Workgroups 3.11 has some COM driver enhancements, but 3.11 users I have corresponded with haven't been able to find anything in the README or hardcopy documentation. An excellent generallized replacement comm.drv for Windows is TurboCom/2, from Pacific CommWare, described in several paragraphs below. If you have a 16550A, and you don't upgrade your driver software, at least add the line... COMxFIFO=1 ...in the [386enh] section of \WINDOWS\SYSTEM.INI Replace "x" with "1" thru "4" depending on the affected COM port number. This line enables the FIFO for Windows apps, although with the limitations enumerated earlier. This won't help much for DOS apps running in/under windows, because Windows 3.x still presents them with an 8250 register API. A few Windows applications provide their own drivers. For example, "WFXCOM.DRV" is supplied with Delrina's WinFAX Pro, and is available on a number of BBS/ftp sites and commercial services like CompuServe. It is supposed to be a general COM driver. I have not tried it myself, and given my unpleasant personal experiences with the aforementioed WinFAX, I'm not inclined to. A shareware COMM.DRV is reportedly available from Cherry Hill (609) 983-1414. I have no other information on it. If you are running "FOSSIL" drivers, such as in a "Waffle" BBS, the "BNU" driver reportedly has reasonable 16550A support. However, that only solves the 16550 problem for apps that use the FOSSIL API. Generic Windows and DOS apps still see a virtuallized 8250 interface. Readers report that: FreeBSD-Gamma has 16550A support. Linux-0.99p112 supports the 16550A but has poor interrupt response time. Minix 1.5 has no special 16550A support. SYS5 PC Unixes with the FAS driver have 16550A support (but poor IRQ response). NetBSD 0.9 recognizes 16550s (and apparently supports them). Another reader reports: There are also an alternate set of OS/2 comm drivers available from Ray Gwinn (name SIOxxx.ZIP at ftp-os2.cdrom.com, xxx=version number). These drivers virtualize a 16550 into a 16450 for DOS applications that can't handle 16550's. They are also faster and more efficient than the IBM drivers. The TurboCom Drivers You can get replacement drivers that solve all of the above problems, for all ordinary Windows COM apps, by buying a copy of "TurboCom/2" from: Bio-Engineering Research Pacific CommWare Division 180 Beacon Hill Lane Ashland OR 97520-9701 (800) 856-3818 voice (503) 482-2744 (503) 482-2627 FAX (503) 482-2633 BBS MCImail: 344-5374 CompuServe: 71521,760 Price is $69.95 ($14.95 upgrade from 1.x) for support of up to four COM ports (1-4). TurboComm/2 Plus ($69.95) supports up to 9 COM ports. Both versions are run-time licensed for use on a single machine. Network licenses are available. Bio-Eng is accepts Visa and Mastercard. Egghead and 1-800-Software list TurboCom but as far as I know, they don't stock it. Bio is not a software company per se. They apparently needed reliable hi-speed serial connections for an in-house instrument application, wrote their own driver, discovered a market for it, and revised it to be a general purpose COM driver suite. They upgraded it for Windows 3.1 in 1992. The latest release is 2.0.0, which began shipping in Feb'94. Pacific CommWare now also has a multi-port version (TurboCom/2 Plus, 9 ports, $99.95) and sells a 6-port 16550A card (TCH-62, $139.95, RJ45 at bulkhead, driver software NOT included). The TCH-62 supports high IRQs and IRQ sharing (on IRQ 3 or 5). TurboCom (probably 1.2) is also included (at no extra cost) in "Street Smart", the $59 Windows on-line stock market software from Charles Schwab, Inc. I'm not sure what version, and this copy doesn't include any hardcopy manuals. I didn't re-install it when I bought StreetSmart, so I don't know if there's even a readme.txt provided. Using the full TurboCom product from Bio, I now have my host (DTE) connect rate set to 57,600 bps for most of my datacomm apps, and I am having ZERO problems with downloads. I routinely see transfer rates that exceed 2,000 bps. I am also using 115,200 bps when linking an HP95LX and HP OmniBook425 to my PC, with lossless bi-directional I/O. Uploads to various remote systems are another matter, because many hosts are still using antique UARTs and drivers. Note that 19200 is still the highest rate that the Windows 3.1 Port menu in Control Panel will allow in configuring a COM port's defaults. Many apps also limit your options to 19.2K max. TurboCom gets around this by allowing you to specify, on each port, a factor that will set the real UART rate to a multiple of the rate passed through the Windows APIs and dialog boxes. I also have CTS/RTS hardware flow control enabled, and I suggest that you do the same. You need to enable it separately for: - Windows (Ports dialog in Control Panel), - in the modem (usually via a modem-specific "AT" command), and - in the comm application (if control provided) Also make sure your cable has wires for pins 4 (RTS) and 5 (CTS) on the 25-pin side. Cheapo 3-wire (TXD, RXD, GND) cables won't work. In RTS/CTS hardware flow control, the modem asserts/drops CTS (Clear To Send) when it is ready/not-ready and the computer similarly wiggles RTS (Request To Send). This avoids having to insert reserved flow control characters in the data stream (which you cannot do if the data is non-encoded binary). Even if you only ever transfer 7-bit ASCII data, Xon/Xoff (ASCII DC1/DC3 or hex 0x11/0x13) is not a sufficiently reliable method of flow control. The informal convention (established by DEC) for Xon/Xoff hysteresis is that the sender may transmit another 16 (yes, sixteen) bytes after receipt of the Xoff character from the receiving system or device. The 16 byte FIFO in the 16550 is clearly not big enough to let us rely exclusively on Xon/Xoff. The 16550A doesn't do CTS/RTS all by itself. It provides alerts and status signals to the driver. The 16-byte FIFO, however, provides a margin to prevent the FIFO from overrun while the driver responds and asserts RTS. Even with hardware flow control, a 16550A with TurboCom can still experience overruns in very busy systems, with lots of apps running and serious swapping in progress. If this is your situation, you may need to buy a co-processed COM board, but this may cost you more than a 16550A/TurboCom upgrade. A review of two such boards, and a review of TurboCom, can be found in the February 1993 issue of "Windows Sources" magazine. One of those boards is the $99 Hayes "ESP", which advertises reliable comm up to 230,400 bps. The ESP has been completely revised since that review was published. The other card discussed was the Telcor "T/Port", $159.00. Note - TurboCom apparently can not coexist with the drivers supplied with these cards. I suggest trying a 16550A/TurboCom upgrade first, and experiment with process priorities and time slices if you are a "power user" whose thrashing system still runs into comm problems. Several people have asked: "If I can't afford both a UART and driver upgrade, which individually produces the most benefits?" If you have Windows 3.1, upgrading just the UARTs will solve most of your problems. If you have Windows 3.0, upgrading just the UARTs will generate a much smaller benefit. I would suggest starting with the UARTs, then upgrade to 3.1, then add TurboCom if needed. If you must stay with Windows 3.0, TurboCom 1.2 is still available. What if you can't upgrade the UARTs at all? (Often the case on laptops with no spare PCMCIA slot for a 16550-based modem card). Some new external modems coming on the market connect to the parallel port, and using the interlocked hardware handshake there, avoid the overrun problem. The main disadvantage of a parallel modem is the increasing number of devices that like to share that port (eavesdrop style) with your printer. You may encounter problems using a parallel modem and a LAN adaptor and a security dongle and your printer all on the same port. Other Sources of Information "The Serial Port", by Christian Blum, contains a wealth of technical detail on serial I/O, RS-232C, UARTs, and the programming thereof. For retrieval instructions, send an email message to et11hks4@etcip9.ee.uni-sb.de with the single word "index" or "help" in the subject line. Closing Soapbox Comments The state of RS-232C serial datacomm support is an embarrassment across the computer industry. Because it is the oldest standard I/O interface, the job of designing hardware and writing software often seems to be assigned to the least senior or lowest ranked engineers at computer hardware and software companies. The design of the average serial port is at least ten years behind the state of the art. In my last job, with a major workstation vendor, I lobbied for improved serial ports when they were doing the initial designs of a new system. That family of machines was subsequently introduced with 16550 ports. However, this is the exception. Few computer companies seem to have any champions for decent I/O (The second oldest port - Centronics parallel - only recently became a formal standard and obtained rudimentary bidirectional capabilities). You may as well learn what you can about serial I/O, because this situation shows no sign of improving soon, even though proposed V.fast modems are just a year away, and the interim V.32terbo and V.FC are here today. When V.fast arrives, I expect cries of outrage from Windows users world-wide whose 8250- and 16450-based PCs "sort of" work today with V.32bis, but will fail miserably at V.FC/V.32terbo/V.fast 28Kbps link rates and well-over-56Kbps compressed DCE-DTE rates. Without a hardware-buffered UART (like the 16550) and without software drivers that use that UART to best advantage, a V.FC/V.32terbo/V.fast modem will be a waste of money. Regards, 1001-A East Harmony Road Bob Niland Suite 503 Internet: rjn@csn.org Fort Collins CO 80525 CompuServe: 71044,2124 (303) 223-5209 Copyright 1993, 1994 Robert J. Niland All Rights Reserved Permission is granted to make electronic and hardcopy reproductions of this edition of this article for personal non-commercial use, provided that no material changes are made to the article or this copyright statement. All other copying, storage, reproduction or redistribution of this article, in any form, is prohibited without the express written consent of the author, Robert J. Niland. EOF