Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!hellgate.utah.edu!cc.utah.edu!cc.usu.edu!jrd
From: JRD@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: talking to a com port with C
Message-ID: <26067@cc.usu.edu>
Date: 12 Jun 90 04:35:04 GMT
Lines: 33


	One major factor, not yet mentioned, about using the Bios serial
port interrupt (14h) for communications is the loss of characters occurring
whenever the screen scrolls one or more lines. The fault lies in the video
bios routines for keeping taking a long time. But then a manual, fast,
assembler procedure to do the same thing also takes a long time. Deep down
then the access rate into video memory is at fault. Thus, expect to lose
two or three characters after a LF which scrolls the screen, on a 4.77MHz
PC and a very swift 33MHz 386 box. (Hint, the video does not run at the
cpu speed.) Without that scrolling part one can easily poll the Bios
for 9600 baud operation on AT's and above.
	As was mentioned a few messages ago on the network, disk activity
also produces major comms outages.
	Here is an assistance but not a total cure. Replace the typical
8250 (and equivalent on AT's and above) with a National Semiconductor
16550A UART chip (please, note that A!). This chip is essentially plug
replaceable. The benefits acrue if the comms program can put the chip
into receiver-FIFO mode so it can buffer up to 16 characters before being
accessed. The Bios runs the chip without the FIFO. And a plain 16550 is
no help at all because it has bugs in the FIFO mode.
	I put one of these chips in my 8MHz AT and with MS-DOS Kermit
the loss of characters at very high baud rates (38,400 and up) from disk
activity dropped way way down. Kermit puts the chip into FIFO mode and
uses interrupt driven i/o, naturally. Other comms programs are beginning to
do the same.
	Finally, one might reasonably ask if the serial port Bios pathway
is intrinsically too slow and thus ought to be abandoned at first glance.
Surprizingly, the answer is no! I run Kermit over serveral packages which
communicate with Kermit via that selfsame Int 14, one character at a time,
have to poll the darned thing, pathway. A typical throughput on a 20MHz 386
is over 15,000 baud (including overhead for Kermit packet work). An interrupt
on a PC is basically a very slow instruction. Even so this path can go fast.
	Joe D.