Monster Media 1993 #2/Image.iso/internet/mswincom.zip/MSWINCOM.TXT

Text File | 1993-07-31 | 19KB | 398 lines

Path: nlbbs!pagesat!decwrl!elroy.jpl.nasa.gov!swrinde!cs.utexas.ed
!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!ub!csn!teal.csn.org!rjn
From: [e-mail] (Robert J. Niland)
Newsgroups: comp.dcom.modems,comp.answers,news.answers
Subject: MS-Windows COM and Ns16550A UART FAQ
Summary: Improving Windows 3.x COM performance and reliability.
Keywords: uart 16550 16450 8250 datacomm windows serial modem turbocom
Message-ID: <[e-mail]>
Date: Thu, 29 Jul 1993 21:43:00 GMT
Expires: Mon, 16 Aug 1993 00:00:00 GMT
Sender: [e-mail] (news)
Reply-To: [e-mail] (Robert J. Niland)
Followup-To: comp.dcom.modems
Organization: Colorado SuperNet, Inc.
Lines: 377
Approved: [e-mail]
Supersedes: <none>
Nntp-Posting-Host: teal.csn.org
X-Newsreader: TIN [version 1.2 PL1]

Archive-name: windows-com-faq
Last-Modified: Mon Jul 27 15:49:50 MDT 1993


FAQ: The 16550A UART & TurboCom drivers                 Edition: 27 Jul 93
                                                        Expires: 27 Sep 93
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.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 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; 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 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 like ProComm+/Win (which is what I use) cannot
   get around this problem by themselves.

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 the modem card is, or is pretending to be.  In any case, if it 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.


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, with or without Windows}
 \WINDOWS\MSD.EXE  {for WIN 3.1 on DOS 5.0}
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.

The Ns16550 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.

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 states 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
[phone] voice US
[phone] voice other
[phone] 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 a Super-I/O multi-function card that adds IDE.

I have heard from several people about less expensive m-f I/O cards
with 16550As:

TSD Systems
[phone]
$19.95 for the card, plus $9.95 per 16550.

Greenfield Trading and Distributors
[phone] (voice), [phone](FAX).
Their card is $33 w/one 16550, $45 w/2, and they sell 16550AFNs for $13.

R&S DATA SYSTEMS, INC.
820 East Highway 434
Longwood, FL  32750
PHONE: [phone]
FAX: [phone]
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.  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, and even
   if it did, 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.
 - 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, and may or may not be addressed in any
Windows releases after 3.1 (but before 4.0). Rumors suggest they "may" be
solved in Windows "4.0".

A few applications provide their own drivers.  For example, "WFXCOMM.DRV"
is now available for Delrina's WinFAX Pro (although I have no data on how
to obtain it, or whether or not it is a full-featured generic COM driver,
nor how it compares to TurboCom).

If you are running "FOSSIL" drivers, such as in a "Waffle" BBS, the "BNU"
driver reportedly has reasonable 16550A support. Since I am about to
install the UUCP parts of Waffle on my system, I expect to have more
information shortly.

I would also be interested in gathering data on the state of 16550A driver
support in OS/2 and the various PC Unix systems.


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", current
version 1.2, from:

Bio-Engineering Research
Pacific CommWare Division
180 Beacon Hill Lane
Ashland  OR   97520-9701
[phone] voice
[phone] FAX
[phone] BBS
MCImail:    344-5374
CompuServe: 71521,760

Price was around $50 as I recall.  Bio-Eng is not set up to accept credit
cards, so I had to send a check.  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 recently upgraded it for Windows 3.1.  It is run-time licensed.

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 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 will 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. 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.


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.  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.FAST's
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.FAST modem will be a waste of
money.

Regards,                                          1001-A East Harmony Road
Bob Niland                                        Suite 503
Internet:  [e-mail]                            Fort Collins CO 80525
CompuServe: 71044,2124                            [phone]

                     Copyright 1993 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