🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.programmer
Article #746

Re: talking to a com port with C

#746
From: david nugent
Date: Fri, 15 Jun 1990 16:44
90 lines
4090 bytes
In <26067@cc.usu.edu> JRD@cc.usu.edu (Joe Doupnik) writes:


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

There's a lot of misconception about 16550's of all types, but in general
it is true that the BIOS runs it in 16450 mode - ie. without the FIFO's,
but only because that's the default power-on state of these chips.  If
you're not interrupt driving these chips, then you can easily enable the
FIFO's and have the BIOS use them immediately.  You'll still get severe
receiver overruns at high speeds (9600+ baud), but a LOT less.  At least
it should make non-interrupt driven comms via INT 14H at 1200-2400 baud
possible.

The other misconception about them is that while you can change the
trigger levels on them to 1, 4, 8 or 14 bytes, you ALWAYS have a 
16-byte buffer both ways once the FIFO's are enabled.  It's just that
a receiver interrupt gets generated when the receiver FIFO gets occupied
up to that many bytes.

You'll also find that the majority of PC, AT and AT386 BIOS sets will
not even recognise a 16550 series UART.  The result is that several
popular programs no longer seem to work, since the BIOS data area is
not "patched" by POST to include the port addresses, and the hardware
bits returned by INT 11H don't reflect their presence - there are
various fixes available, but someone not knowing that or having not
having access to those fixes can be completely frustrated by the fact
that his favourite communications programs now longer function....

Here's a little code to turn the FIFO's on, to really get the most
from the system's BIOS.  As to how hard you can then drive the BIOS,
I can't give any specific figures, since it's too dependent on your
own system's speed and what other interrupt driven devices are in use
(such as network cards etc.).

This may be entered using DOS's DEBUG, and in this case switches on
FIFO's for COM1 (I specifically use the port's base address here so
that you can easily replace 3f8 with whatever base address you need
to use, such as 2f8 for COM2):

	C>DEBUG
	-a
	xxxx:0100	mov	DX,3f8
	xxxx:0103	add	DX,2
	xxxx:0106	mov	AL,01
	xxxx:0108	out	DX,AL
	xxxx:0109	int	20
	xxxx:010B
	-rcx
	:b
	-nfifo.com
	-w
	Writing 000B bytes
	-q
	C>

BTW, there's no harm done at all by running this with an 8250, 16450
or similar UART present.  It just doesn't have any effect, since the
register you're writing to in that case is 'write-only' on those
chips.

To enable the various trigger levels (and as I implied above, there's
no real advantage in using more than 1 byte unless you start using an
interrupt driven driver, since you ALWAYS get full 16-byte buffers no
matter how many bytes the trigger is set to), you can substitute the
following values into the "mov AL,xx" statement above:

	1 byte		=	01
	4 bytes		=	41
	8 bytes		=	81
	14 bytes	=	C1

To disable the FIFO's, just substitute that same value for 0.

A better solution is, of course, to use an interrupt driven INT 14H
replacement, but if that's not available, the above certainly should
help.

david

-- 
         * Unique Computing Pty Ltd, Melbourne, Australia. *
       david@csource.oz.au  3:632/348@fidonet  28:4100/1@signet
Technical Details
Message-ID: <23@csource.OZ.AU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!munnari.oz.au!csource!david
References: <26067@cc.usu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!munnari.oz.au!csource!david
From: david@csource.OZ.AU (david nugent)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: talking to a com port with C
Message-ID: <23@csource.OZ.AU>
Date: 15 Jun 90 16:44:11 GMT
References: <26067@cc.usu.edu>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 90