ingea@IFI.UIO.NO (Inge Arnesen) (09/15/90)
>I think the net would be very interested in hearing more about your COM: >routine. For instance, can it be used with existing win3 comm progs >(in real or enhanced mode)? If not, how about some details of your >terminal program. > > >Ross Porter >ross@cattell.psych.upenn.edu It's not very exiting. It's just a resident TSR that receives characters from the serial line using real mode interrupts. The driver I was refering to in my previous posting is the property of my employer, but several such drivers are available from BBS's and like. The terminal emulator is also property of my emplyer, but the emulator could just as well have been the TERMINAL.EXE program or - worse - the TTY.EXE program supplied with the SDK. The best type to use with Windows are the Int 14h drivers. They install themselves as a common TSR (using 3-5K of base memory - or they can be loaded high with QEMM 5.1) intercepting INT 14H, the entry point for the standard (and quite braindead) IBM BIOS serial port routines. They grab the interrupt vectors for COM1 or 2, initialises the serial port to generate interrupts upon reception of characters and reprograms the interrupt controller to set the COM-interrupts to the highest priority. When a character arrives, the card will generate an interrupt, which will wake the driver up. The driver will fetch the character and put it in an internal buffer and go back to sleep. When an application programs want a character from the driver, it issues an INT 14H call, which the driver receives. The driver then returns the next character waiting in it's internal buffer. This is easy to do from a DOS program or a Windows program running in real mode, since it's just to call the INT 14H directly. From a Windows 3 programm in standard or enhanced mode, you must use the INT 31H standard rutines for real mode calls. Since these calls are pretty expencive in terms of CPU time, don't fetch 1 character at a time, but fetch at least 100, if there are that many available. Since the driver receives characters running in real mode, the CPU, if running in protected mode (Windows 3 standard or enhanced mode), must switch from to real mode before the driver can fetch the character. ================================================================ Windows terminal program fetch request returned char l ^ l - Int 31H I V I Windows Int 31H internal handler I ^ I - Int 14H I V I COM: driver I \________ / ^ I /----------------\ l RECEIVE BUFFER l \----------------/ ^ COM: interrupt handler ^ I Hardware (serial port) This is an attempt to illustrate the how the control flow passes from Windows to the driver and back. It's written on a SUN with bad termcap defininition over a 2400 baud modem line - so that explains the Picasso- like forms :-) ======================================================================= On a 286 (Windows in standard mode) characters will be lost this way, since the switch from protected to real mode takes too long, so forget about this on a 286 in standard mode. In 386 enhanced mode or real mode, this works fine (remember to set COMboosttime=10 in the SYSTEM.INI file - 386 enh. section). If you cannot find such a driver anywhere, I'll post or mail one.... But, such things are easy to find .... at least here in Norway :-) But, if MicroSoft did their work properly (or - there is a way of speeding up those serial routines), this rather messy fix would not be needed! Inge (BoB) { ingea@ifi.uio.no } ========================================================================= == Inge Arnesen, University of Oslo, Norway. == == ==