Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!bronze!copper!nengle
From: nengle@copper.ucs.indiana.edu (nathan engle)
Newsgroups: comp.os.msdos.programmer
Subject: Re: defeating time-out on com ports?
Message-ID: <1991Apr9.160945.22325@bronze.ucs.indiana.edu>
Date: 9 Apr 91 16:09:45 GMT
References: <3603@naucse.cse.nau.edu>
Sender: news@bronze.ucs.indiana.edu (USENET News System)
Organization: Indiana University, Bloomington
Lines: 65

In article <3603@naucse.cse.nau.edu> rrw@naucse.cse.nau.edu (Robert Wier) writes:
[some stuff about EGAs deleted]
> Now, working on the same project I've run into a snag using the 
> COM port.  We have a situation where we don't know when the 
> data will appear - it can be anywhere from 100 ms to 11 seconds
> after the previous carriage return.
>
> The problem we are having (my students are currently using 
> Quick-C) is that when you go out to read a character and there
> isn't one there yet, the port seems to "time out" in 1.5 seconds
> or so.  I can't find any way to defeat this, although I certainly
> see why in most circumstances it would be useful.

The BIOS serial port routines use polling to monitor the state of the
UART. Unfortunately, this method is inadequate for baud rates of greater
than 300 baud or so unless you take full control of the PC (even disable
timer and keyboard interrupts) and use assembly to drive the UART at max
speed. I'm sure that this is the trick used by 115K baud transfer
programs like laplink - I think that 9600 baud is about the fastest an
original PC could accept using interrupt driven serial I/O.

Interrupt driven I/O is really the answer to your problem. You can set
things up so that the UART will yank an interrupt line whenever a
character arrives. An interrupt character drops each character into the
buffer, and rather than monitoring the UART, you just have to watch the
buffer.

There are a couple of libraries available for serial I/O that you can
buy, or if you like I can post a sample program (simple terminal
emulator) that uses interrupt driven I/O, and is written entirely in C
including the interrupt handlers. Depending on what you're trying to get
the students to learn, it might be educational to dig through my TERM
code. One other thing I would recommend if they go that route is that
you should get a copy of the 8250 data sheet which can be found in the
National Semiconductor Communications/UARTS/LAN databook.
 
> I know it CAN be done, because Kermit does it.  The big K just
> sits waiting patiently for something to arrive and display it on
> the screen.

The big K waits for the 8250 to generate RxData interrupts.

> Does anyone know how to do this?  Does it require going directly
> to the UART and bypassing the built in routines?  Or is there 
> something actualy in the hardware in the nature of a switch
> which has to be reset?

There are actually a couple ways to approach this problem. Some people
like me have written programs that take direct control of the serial
port since the BIOS services are so inadequate. A lot of pretty famous
communications programs do the same thing. 
  However there are also those people who want to try to repair IBM's
bogus serial BIOS routines. Basically, it's possible to write a TSR
routine (typically referred to as a FOSSIL driver - don't ask what it
stands for) that replaces the Int 14h handler with routines that do
interrupt driven I/O. Therefore, whatever program is using the brain-
damaged Int 14h interface to get to the serial port will work about a
thousand times better than the original Int 14h routines would allow.
  Myself, I prefer method #1 since I like getting more direct control of
the hardware. Also, you end up with a self-contained program that doesn't
require some other thing to be loaded before it will run.
 
Nathan Engle             Software Evangelist
Indiana University       Dept of Psychology
nengle@copper.ucs.indiana.edu