🚀 go-pugleaf

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.

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.

There are books with sample code for this, and some code posted to
the net on occasion.  But you'll probably have to find out about the
workings of your UART chip and program it in assembler.

Good luck!  I've done this, and it's non-trivial.
Dave
+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ			|
|    Logical -  ...att!pegasus!dmt				|
|    Audible -  (201) 576 2194					|
+---------------------------------------------------------------+

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

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

Not true. I have written 2 application in TurboC 2.0 that talk to COM1 using
Int 14 and they run at 4800 BAUD. I haven't seen any problems with character
loss. Had some problem with applications at 9600, but nothing below that.

This was with ATT PC 6300 BTW, using standard serial ports and ports on
Intel Above board cards.

Jeff

Well, hang on- this is sort of a "yes, no, maybe" question. If you use INT14
to talk to the serial port, the results are going to depend on two major
things: (1) how well the BIOS you're using was written, which you have
no control over, or (2) how fast your CPU is anyway, which you have no
control over.

Basically, if you're going to use INT14, you're giving up interrupt- driven
I/O- ie, you *will* lose characters during disk I/O. If your processor is
fast, you probably won't lose anything in a continuous polling loop, but
that will vary from BIOS to BIOS, machine to machine.

In addition, some BIOSes (BIOSi?) may well be written to provide interrupt-
driven service. But this is NOT a given and the standard IBM BIOS doesn't
do this.

One solution: get ahold of a FOSSIL driver. FOSSILs are device drivers
created for the Fido/ Opus family of BBS software (Fido/ Opus Standard
Serial Interface Layer), and they replace INT 14 with a much more extensive
set of routines. The basic INT 14 calls are still available, but are now
interrupt- driven and much more practical, and there is a very large list
of additional features in the spec. You can find a fossil, most likely,
on any fido or opus board; if you don't see it listed ask the sysop. Some
of the major fossil authors will negotiate very reasonably where including
their work in yours is concerned. I struck such a deal for my own (defunct)
BBS software without any difficulty. Another advantage: they are available
for most nonstandard MSDOS computers as well.

Another solution: use some other set of serial comm routines. I have one,
which I can send you if you like- I put it in public domain, folks, relax
(this is not an ad). It's very stripped- down- it just gets the job done,
with interrupt- driven input.

Good luck!

--
CRANBERRIES! ALBUQUERQUE! This is the start of the end of the beginning of
the middle of the last day of the first part of your life! NEWSPRINT GALORE!
Disclaimer: Datclaimer. Elvis is alive and doing my laundry. Turn down
your air guitar, I can't see the band! I lied, he's dead. Have a #$&$( day.