sv@hsv3.UUCP (Steve Verity) (06/02/90)
Hi, I need a C routine to talk to a com port. I am tring to use INT 14, but I am unsure about handshaking. Do I need to query the status port before sending characters? What bits do I need to worry about? Thanks for any help. Email if you want and I will summerize. -- ...........>..........>........>......>...>...>..>..>..>..>.>.>.>>>>>>>>+ . Steve Verity sv@v7fs1 + + ...Maxed on MIDI + . Video-7 / Headland Technology + ...ames!vsi1!v7fs1!sv + .. +
dmt@pegasus.ATT.COM (Dave Tutelman) (06/03/90)
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 | +---------------------------------------------------------------+
david@csource.OZ.AU (david nugent) (06/07/90)
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
JXS118@psuvm.psu.edu (Jeff Siegel, Op from Atherton Hall) (06/10/90)
>> >> 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
boutell@freezer.it.udel.edu (Tom Boutell) (06/10/90)
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.
jkl@Neon.Stanford.EDU (John Kallen) (06/11/90)
In article <90160.190621JXS118@psuvm.psu.edu> JXS118@psuvm.psu.edu (Jeff Siegel, Op from Atherton Hall) writes: >>> >>> 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 That's because you are running a fast machine. On the good ol'e original PC's and XT's, when the clock runs at 4.77 MHz, you can just barely do serial communication at 1200 baud. In general, it is in general not a good idea to write code that makes assumptions on the underlying hardware being fast enough for your application. I'm sure that one could write a Int14 poller that runs 9600 baud on a '486, but you won't be able to use that on an XT (there are a *lot* of those out there.) An interrupt service routine on IRQ 4 and IRQ 3 works on *any* machine regardless of system speed, and it can handle high baudrates, too. (38.4 kBaud, anyone, anyone? :-) _______________________________________________________________________________ | | | | |\ | | /|\ | John Kallen Computer: kom-pyu'-ter (n) a | |\ \|/ \| * |/ | |/| | | PoBox 11215 device for generating errors | |\ /|\ |\ * |\ | | | | Stanford CA 94309 speedily and unpredictably. _|_|___|___|____|_\|___|__|__|_jkl@neon.stanford.edu___________________________