home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.os.msdos.programmer:10532 comp.sys.ibm.pc.programmer:572
- Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.programmer
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!att-out!walter!qualcom.qualcomm.com!qualcom!rdippold
- From: rdippold@qualcom.qualcomm.com (Ron Dippold)
- Subject: Re: H-E-L-P!! An interesting UART problem.
- Message-ID: <rdippold.721520794@qualcom>
- Sender: news@qualcomm.com
- Nntp-Posting-Host: qualcom.qualcomm.com
- Organization: Qualcomm, Inc., San Diego, CA
- References: <1992Nov10.094131.9300@iccgcc.decnet.ab.com> <1992Nov11.141104.7451@seas.gwu.edu>
- Date: Wed, 11 Nov 1992 22:26:34 GMT
- Lines: 18
-
- ilan@seas.gwu.edu (Ilan Berkner) writes:
- >The only way to do this would be to either:
-
- >1. Attach an ISR to vector 14h, and _hope_ that all of your client's
- > software will only be using int 14h calls to xmit data. This is
- > like hoping that the moon will turn around in orbit so you can see
- > the other side.
- >2. or put the computer into virtual mode, and write an ISR that traps
- > 386 I/O priviledge exceptions. This technique will only work on
- > 386-class machines, and is incompatible with Windows enhanced mode,
- > 386MAX, QEMM, Desqview, OS/2 2.0, etc.
- >Sorry, but there's no way to trap I/O, and the UART can't do interrupts
- >on transmits, as you found out.
-
- 3. Just do a loop back... that way you're dealing with actual receive
- interrupts.
- --
- You have all the leadership potential of a caboose.
-