EXCOM version 2 notes



A. Release Contents

   These notes assume that the reader is familiar with "excom" as presented
in June DDJ.  The release of excom consist of three files, the others are
excom.asm and exmode.c.  The new versions of excom.asm and exmode.c are not
compatible with the versions printed in DDJ, the extended initialization
call has been changed and is not upward compatible.


B. Change Summary

   Excom now supports interrupt driven output buffering, output XON-XOFF,
and self repair after running some badly behaved applications.  Exmode has
been enhanced to support new excom features.  A few bugs were fixed.


C. Transmitter

   When a transmit request is made, the character is put into a buffer and
control is returned to the caller without waiting for the character to
actually be sent.  The caller is only made to wait when the buffer is full.
Some points of interrest follow:


   1. Status

      The status returned from the initialization, transmit, and status
   calls (int 14h with ah = 0, 1, and 3) is a lie.  If there is room in the
   transmit buffer, the status indicates that the transmit holding register
   is empty.  This status would most likely be used by an application to
   decide if a transmit will return immediately or delay the application.
   For this case the status lie really tells the application what it wants
   to know, that another character can be handled without delay.  For
   performance reasons, the receive call (ah = 2), doesn't include this lie,
   hope no applications use status returned from receive to decide to
   transmit.


   2. RTS

      The bios asserts RTS just before the first character is transmitted
   and then leaves it on.  Excom asserts RTS upon initialization.


   3. XON-XOFF transmit

      Excom will transmit XON and XOFF as flow control characters without
   regard for transmit control signals or the transmitter being X'ed off.


   4. Transmitter disable

      Excom will accept characters into the output buffer even if current
   conditions prohibit sending the characters.  This will cause problems for
   applications that send a character and wait for a timeout to determine
   that the transmitter is disabled.


D. Self Repair

   Excom will re-initialize the UARTS and the UART interrupt vectors under
two circumstances, when excom is waiting for a receive character and if when
starting up the the transmitter, the UART interrupt vectors are found to be
corrupted.  The goal here was to solve some specific problems that I was
having without hurting performance too much.  My problem was that I was
running a shell through a com port, switch back to the console, run
CrossTalk through the same port, return to my shell to the com port, re-boot
because CrossTalk had changed the UART vectors.  This feature may not ever
help you, but it's cheap and doesn't seem to do any harm.  The choice of
when to do the reinitialization was based on a balance between performance
and picking a few spots where is would be likely to help.  If the bad
program changes the vector for int14h, excom will never be called and thus
can't fix anything.


E. Relocation to Top of RAM

   The article promises that this version will relocate to the top of RAM.
I lied, looking at several resident programs that did not relocate and
reconsidering the facts convinced me that it was more trouble than it was
worth.  To avoid memory problems, have excom installed with your
"autoexec.bat" if you want it all the time or if you only want it with
certain programs, load excom, run the program, remove excom.


F. Other Thoughts

   Here are a few little things that popped into my head while working on
this code that may be of help.


   1. UART speed

      I have seen code for the 8250 UART that delays a little between
   accesses to the UART.  I have never had a problem with my code even
   though there are a few places where I beat on the UART a bit.  If excom
   doesn't work on your machine, try some nop's to space the tight groups of
   UART accesses.


   2. Wasted space

      There is probably some clever way to use the program header for data
   space.  I never worried about it and so that 256 bytes of header just
   sits there doing nothing.


   3. Exact status

      If an application looks for an exact match of status instead of just
   checking the specific bits of interrest, excom will probably not work
   correctly.  See above and the article for discussions about status
   differences.


   4. Bulk I/O

      Given the nature of buffered I/O, it would be desirable to have calls
   to excom to move 'n' characters.  In fact DOS could be modified to use
   these calls when sending or receiving blocks of data.  Oh well, I can't
   do everything.


G. Support

   Feel free to write to me, via DDJ, with any bugs, questions, etc.  I will
be glad to fix any bugs and will consider enhancement requests.