home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10595 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  2.5 KB
  1. Xref: sparky comp.os.msdos.programmer:10595 comp.sys.ibm.pc.programmer:582
  2. Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.programmer
  3. Path: sparky!uunet!utcsri!skule.ecf!roscoe
  4. From: roscoe@ecf.toronto.edu (ROSCOE JAMES ANDREW)
  5. Subject: Re: H-E-L-P!!  An interesting UART problem.
  6. Message-ID: <BxnxAA.Ft0@ecf.toronto.edu>
  7. Organization: University of Toronto, Engineering Computing Facility
  8. References: <1992Nov10.094131.9300@iccgcc.decnet.ab.com>
  9. Date: Fri, 13 Nov 1992 16:18:09 GMT
  10. Lines: 44
  11.  
  12. In article <1992Nov10.094131.9300@iccgcc.decnet.ab.com> gardner@iccgcc.decnet.ab.com writes:
  13.  
  14. >I'm writing a TSR that needs to redirect any bytes that 
  15. >are written to COM2 for transmission to another "bucket."
  16. >
  17. >A vendor's program is running and writing bytes to COM2
  18. >for transmission.  I want to have my TSR kicked whenever
  19. >the vendor's program sends a byte to COM2 for transmission
  20. >BUT I want to grab that byte and do some other work on 
  21. >it...  In fact, there will not be any external device
  22. >ever attached to COM2, so the byte won't actually ever
  23. >be transmitted  and no external handshaking is going to
  24. >occur.
  25.  
  26.  So what you want to do is log everything that goes to com2.  Judging from the
  27. other followups to your article, I get the feeling there's no way to tell when
  28. the UART has actually had a character sent to it.
  29.  
  30. >What I have written are two isr's: One that is attached
  31. >to the COM2 hardware interrupt vector (0xb) and another 
  32. >that is attached to the secondary clock software interrupt 
  33. >vector (0x1c).  The isr attached to COM2 is responsible 
  34. >for grabbing the byte from COM2 and saving it in a queue.
  35. >The timer isr is responsible for taking a byte from the 
  36. >queue and sending someplace else...
  37.  
  38.  The vendor program will very likely not call your handler after its own,
  39. since it would be almost against the rules of UART programming.  You could
  40. probably then change the interrupt handler back to your own (or to the original
  41. DOS handler, if there even is one).  The handler which the vendor program
  42. installed, then, could be called as a subroutine by your own timer tick handler
  43. so that you would have full control over what it things the "UART" (virtual,
  44. in this case) is telling it.  You still might not be able to read the character
  45. being transmitted out of the port, but it's worth trying.
  46.  
  47.  You should have full control over everything at this point, and the only
  48. real problem I can think of would be the possibility of not being able to read
  49. the character from the comm port after it's been written.  Best of luck to you!
  50. See ya.
  51.  
  52. -- 
  53.  
  54.    James
  55.     - roscoe@ecf.toronto.edu
  56.