Grex Micros Conference

View Responses

Grex Micros Item 15: Wanted: C routines to talk to COM3/COM4
Entered by steve on Tue Oct 15 21:12:30 UTC 1991:

   Does anyone know of some C routines to talk to the serial
port in C?  I have a need to talk to COM3 & COM4.
   If something like Dr. Dobbs has a low cost version of this
I'd love to hear.  Freebies would of course be the best.
   I assume that the "real" libraries like Greenleafs C library
have this functionality, right?  If you've had expereince with
one of these libraries, I'd like to hear about it.
   Thanks.

9 responses total.

#1 of 9 by bad on Tue Oct 15 22:09:58 1991:

Hee hee. COM3 and COM4? I'm glad I'm not in your shoes!

#2 of 9 by mju on Tue Oct 15 23:34:22 1991:

You might want to think about forgetting a direct approach, and use the
FOSSIL API instead.  FOSSIL is a standardized communications port
"interface layer" (which is what the IL in FOSSIL stands for) that
uses extensions to the INT 0x14 calls.  The user loads a FOSSIL device
driver which hooks INT 0x14 and responds to the FOSSIL calls; the
application, in turn, utilizes the FOSSIL for all serial I/O.  Using
the FOSSIL API, in addition to much reducing the programming effort
necessary for supporting serial I/O under MS-DOS, allows greater
portability -- FOSSIL programs can be used on any MS-DOS-compatible
machine for which a FOSSIL driver is available, instead of just those
with IBM-compatible serial I/O chipsets.  In addition, using the FOSSIL
API encourages you to modularize your code to the extent where porting
it to a different OS would only consist of replacing your serial I/O
library with something that implimented similar features in an OS-dependant
manner.  [FOSSIL calls are sufficiently high-level to allow this --
typical FOSSIL calls are "raise/lower DTR", "read character (blocking)",
"write character (nonblocking)", and so forth.]  Details of the FOSSIL
API, as well as FOSSIL API libraries for C, Pascal, etc. can be found
on many Fidonet BBSes (where, by no small coincidence, most of the BBS
software uses the FOSSIL calls); I also might be able to dig up some
from my old MS-DOS days.

(FOSSIL, incidentally, is an acronym for "Fido/Opus/SeaDog Standard
Interface Layer"; Fido, Opus, and SeaDog are names of some of the
first programs to use the FOSSIL interface.  Extensions to the FOSSIL
standard for console I/O have been made, but have not seen the wide
use that FOSSIL serial I/O functions have -- perhaps due to the
relatively short length of time that the "video FOSSIL" standard
has been in existance.  Some common FOSSIL drivers for IBM-hardware-compatible
machines are "BNU" (not to be confused with the Unix UUCP variant of
the same name), "X00", and "Opus!Comm".)

(And, to finally answer how this is relevant to your question -- X00,
for one, supports up to 16 communications ports.  BNU has similar
"limitations".  By using the FOSSIL API, you completely absolve yourself
from any responsibility on how the low-level code is implimented.
This is much, much easier than re-re-re-...-inventing the interrupt-
driven serial I/O driver, which IBM failed to provide in the BIOS
serial I/O routines.)

#3 of 9 by steve on Wed Oct 16 03:03:25 1991:

   Interesting.  Where does one obtain FOSSIL?

   Any other ideas out there?

#4 of 9 by mju on Wed Oct 16 03:41:49 1991:

You can get a FOSSIL driver from a lot of BBSes.  Most FOSSIL drivers
also come with a copy of the FOSSIL API spec, which includes
specifications for how to call the various FOSSIL functions at an
assembly-language level -- i.e., interrupt number and arguments to
place in the appropriate registers.  I might have a FOSSIL C library
hanging around in one of my many disk boxes, or you might be able to
find it on a local BBS.

#5 of 9 by bad on Wed Oct 16 05:32:47 1991:

See? I try to enter a useless, pessimistic response, and some young
upstart immediately jumps in and hands out useful information.
Sigh.
This curmudgeonly stuff is frustrating.

#6 of 9 by mdw on Fri Oct 18 00:20:25 1991:

I think I have an extremely crude program around somewhere
that does interrupt driven I/O, with COM1/COM2, and is
otherwise *very* primitive.  It could probably be extended
to work with COM3/COM4 without too much trouble.

#7 of 9 by roach on Sat Oct 26 03:57:03 1991:

You may also want to try the LiteComm C libraries.  These have the
advantage of not requiring drivers to be loaded at boot time.  FOSSIL
requires a "device = ..." line in config.sys in order to operate.  These
consume somewhat precious RAM.  Unless you need FOSSIL every time you
run, it's not worth it.

LiteComm provides a link library and header files, uses stream-I/O
similar calls to load and use the drivers (lopen(), lwrite(), lgetc(),
lputc(), et cetera).  It supports COM1, 2, 3, and 4.

I downloaded the shareware versions of both FOSSIL and LiteComm from
CompuServe a while ago.  I'd be will to upload them here, if you're
interested.

#8 of 9 by steve on Sun Oct 27 00:14:15 1991:

   Thanks for the pointer!!!

   I grabbed this off a system a long time ago, and promptly stuffed
it onto a disk.  Just found said disk, and it seems as if they are just
what I was looking for.  thankyou thankyou thankyou...

   (Know of any bugs in LiteComm?)

#9 of 9 by steve on Fri Nov 1 22:48:55 1991:

   Well, it seems my version of LiteComm is hopelessly out of date.  I
have version 3, and the latest version is 6.  Is there anyone out there
who can point me twords a BBS that has version 5 or 6?  Please?  I kinda
need it this next week at work...

Response not possible - You must register and login before posting.