Path: 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 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