Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!csource!david
From: david@csource.OZ.AU (david nugent)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: talking to com port with C
Summary: Int 14 standards
Message-ID: <14@csource.OZ.AU>
Date: 7 Jun 90 12:33:04 GMT
References: <2913@hsv3.UUCP> <4811@pegasus.ATT.COM>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 55

dmt@pegasus.ATT.COM (Dave Tutelman) writes:

> In article <2913@hsv3.UUCP> sv@hsv3.UUCP (Steve Verity) writes:
> >
> >Hi, I need a C routine to talk to a com port.  I am tring to use INT
> >14......
> >Steve Verity   sv@v7fs1                ...Maxed on MIDI
> 
> Wow, Int 14 and MIDI -- WHAT A CONCEPT !!!
> 
> Steve,
> Int 14 was written in such a way as to be useless at much above 300 baud.
> Even a simple program to read from the line and write to the screen
> will lose characters at 1200 if you use Int 14.


Yes, this is true if you use the standard BIOS communications support.

Sad, but true, it sucks.  ;-)


> At anything above this point, you need to write your own low-level
> interrupt-driven handler for the COM port.  If you're really doing
> a MIDI program, the 31 Kb/sec rate demands even tighter coding than
> the average terminal emulator.

Now, there IS an easier way.

From Fidonet, we have the "FOSSIL" concept developed.  This means interrupt
driven communications supporting speeds of up to 38400 baud (faster if
you use unsupported features of specific drivers) still using that same
INT 14H layer.  It is backwardly compatible with the standard INT 14H
calls, and adds a number of other calls, including block read/write for
even higher potential throughput.

A FOSSIL driver loads either as a TSR or device driver.  In any case,
it simply takes over INT 14H and remains dormant until activated by
an application.  It can be switched "off" and "on" at will.

I'm seeing more and more software under DOS utilising this layer.
Quite a few UUCP engines utilise FOSSIL quite successfully and 
achieving the high throughputs formerly available only under a Unix.

Yep, this still keeps INT 14H alive and kicking - even if IBM/MicroSoft
had little to do with it's development.  ;-)  Using one of these freely
available drivers is a whole lot easier than reinventing the wheel and
having to unecessarily relearn things thought disappointment things
which I know for certain are not written in any text that I've come
across.

david

-- 
  Unique Computing Pty Ltd, Melbourne, Aust.
  david@csource.oz.au  3:632/348@fidonet  28:4100/1@signet