Path: utzoo!attcan!uunet!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.xenix
Subject: Re: COM3 & COM4 under SCO Xenix ?
Keywords: xenix com serial
Message-ID: <683@sixhub.UUCP>
Date: 21 Mar 90 18:52:26 GMT
References: <3347@trantor.harris-atd.com> <5275@scolex.sco.COM>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Distribution: na
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 30

In article <5275@scolex.sco.COM> md@sco.COM (Michael Davidson) writes:

| Now, consider the situation where COM1 has just interrupted on line
| 3 causing the line to change from the inactive to the active state.
| The interrupt controller sees the transition and latches the interrupt.
| Suppose that COM3 then attempts to interrupt on the same line
| *before* the line has returned to it's inactive state - the line is
| already active so you can't get an inactive -> active transition,
| there is no transition for the interrupt controller to see and
| you lose the interrupt.

  What you say is true, but you can get by it with a little clever
programming which polls the status of both uarts and servicea all
devices which have tbe or rda set. This is how some multiport cards
support use of a single interrupt.

  Certainly the driver would be more complex if the option to support
multiple devices was added, and I can see why SCO would feel this is a
low demand option, since people who need more than two ports frequently
need a lot, but it is possible without loss of data.

  I will add that if you are a real hacker you can run the two 8259
interrupt controllers in different modes, and make the slave controller
level triggered. I take the fifth on why you would do this, but it can
be done if you have a sick mind.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc
"Getting old is bad, but it beats the hell out of the alternative" -anon