home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / ddjmag / ddj8706.arc / EXCOM.TXT < prev    next >
Encoding:
Text File  |  1987-08-05  |  5.0 KB  |  133 lines
  1.                            EXCOM version 2 notes
  2.  
  3.  
  4.  
  5. A. Release Contents
  6.  
  7.    These notes assume that the reader is familiar with "excom" as presented
  8. in June DDJ.  The release of excom consist of three files, the others are
  9. excom.asm and exmode.c.  The new versions of excom.asm and exmode.c are not
  10. compatible with the versions printed in DDJ, the extended initialization
  11. call has been changed and is not upward compatible.
  12.  
  13.  
  14. B. Change Summary
  15.  
  16.    Excom now supports interrupt driven output buffering, output XON-XOFF,
  17. and self repair after running some badly behaved applications.  Exmode has
  18. been enhanced to support new excom features.  A few bugs were fixed.
  19.  
  20.  
  21. C. Transmitter
  22.  
  23.    When a transmit request is made, the character is put into a buffer and
  24. control is returned to the caller without waiting for the character to
  25. actually be sent.  The caller is only made to wait when the buffer is full.
  26. Some points of interrest follow:
  27.  
  28.  
  29.    1. Status
  30.  
  31.       The status returned from the initialization, transmit, and status
  32.    calls (int 14h with ah = 0, 1, and 3) is a lie.  If there is room in the
  33.    transmit buffer, the status indicates that the transmit holding register
  34.    is empty.  This status would most likely be used by an application to
  35.    decide if a transmit will return immediately or delay the application.
  36.    For this case the status lie really tells the application what it wants
  37.    to know, that another character can be handled without delay.  For
  38.    performance reasons, the receive call (ah = 2), doesn't include this lie,
  39.    hope no applications use status returned from receive to decide to
  40.    transmit.
  41.  
  42.  
  43.    2. RTS
  44.  
  45.       The bios asserts RTS just before the first character is transmitted
  46.    and then leaves it on.  Excom asserts RTS upon initialization.
  47.  
  48.  
  49.    3. XON-XOFF transmit
  50.  
  51.       Excom will transmit XON and XOFF as flow control characters without
  52.    regard for transmit control signals or the transmitter being X'ed off.
  53.  
  54.  
  55.    4. Transmitter disable
  56.  
  57.       Excom will accept characters into the output buffer even if current
  58.    conditions prohibit sending the characters.  This will cause problems for
  59.    applications that send a character and wait for a timeout to determine
  60.    that the transmitter is disabled.
  61.  
  62.  
  63. D. Self Repair
  64.  
  65.    Excom will re-initialize the UARTS and the UART interrupt vectors under
  66. two circumstances, when excom is waiting for a receive character and if when
  67. starting up the the transmitter, the UART interrupt vectors are found to be
  68. corrupted.  The goal here was to solve some specific problems that I was
  69. having without hurting performance too much.  My problem was that I was
  70. running a shell through a com port, switch back to the console, run
  71. CrossTalk through the same port, return to my shell to the com port, re-boot
  72. because CrossTalk had changed the UART vectors.  This feature may not ever
  73. help you, but it's cheap and doesn't seem to do any harm.  The choice of
  74. when to do the reinitialization was based on a balance between performance
  75. and picking a few spots where is would be likely to help.  If the bad
  76. program changes the vector for int14h, excom will never be called and thus
  77. can't fix anything.
  78.  
  79.  
  80. E. Relocation to Top of RAM
  81.  
  82.    The article promises that this version will relocate to the top of RAM.
  83. I lied, looking at several resident programs that did not relocate and
  84. reconsidering the facts convinced me that it was more trouble than it was
  85. worth.  To avoid memory problems, have excom installed with your
  86. "autoexec.bat" if you want it all the time or if you only want it with
  87. certain programs, load excom, run the program, remove excom.
  88.  
  89.  
  90. F. Other Thoughts
  91.  
  92.    Here are a few little things that popped into my head while working on
  93. this code that may be of help.
  94.  
  95.  
  96.    1. UART speed
  97.  
  98.       I have seen code for the 8250 UART that delays a little between
  99.    accesses to the UART.  I have never had a problem with my code even
  100.    though there are a few places where I beat on the UART a bit.  If excom
  101.    doesn't work on your machine, try some nop's to space the tight groups of
  102.    UART accesses.
  103.  
  104.  
  105.    2. Wasted space
  106.  
  107.       There is probably some clever way to use the program header for data
  108.    space.  I never worried about it and so that 256 bytes of header just
  109.    sits there doing nothing.
  110.  
  111.  
  112.    3. Exact status
  113.  
  114.       If an application looks for an exact match of status instead of just
  115.    checking the specific bits of interrest, excom will probably not work
  116.    correctly.  See above and the article for discussions about status
  117.    differences.
  118.  
  119.  
  120.    4. Bulk I/O
  121.  
  122.       Given the nature of buffered I/O, it would be desirable to have calls
  123.    to excom to move 'n' characters.  In fact DOS could be modified to use
  124.    these calls when sending or receiving blocks of data.  Oh well, I can't
  125.    do everything.
  126.  
  127.  
  128. G. Support
  129.  
  130.    Feel free to write to me, via DDJ, with any bugs, questions, etc.  I will
  131. be glad to fix any bugs and will consider enhancement requests.
  132.  
  133.