wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) (03/20/90)
I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport card. This is not an option due to project contraints. Has anyone written a serial driver that will handle the above situation? Thanks for your help. ------------------------------------------------------------------------------- William Curtiss 407/984-6383 | - Standard disclamers apply - Harris GISD, Melbourne, FL 32902 | Internet: wcurtiss%x102c@ess.harris.com | <-- New address
md@sco.COM (Michael Davidson) (03/21/90)
wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) writes: >I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, >I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, >I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport >card. This is not an option due to project contraints. Has anyone written a >serial driver that will handle the above situation? The problem (an the reason why we don't support this) is that you have two similar devices sharing the same hardware interrupt line. Now you *can* get away with sharing an interrupt line like this under certain circumstances, but this isn't one of them. Interrupts on AT bus machines are "edge triggered", meaning that the 8259 interrupt controller has to see a false -> true transition on the line to latch the interrupt (sorry, can't remember whether these lines are active low or active high). 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.
usenet@carssdf.UUCP (John Watson) (03/21/90)
In article <3347@trantor.harris-atd.com>, wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) writes: > I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, > I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, > I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport > card. This is not an option due to project contraints. Has anyone written a > serial driver that will handle the above situation? > IT CAN BE DONE!, but I prefer to use int's 33 & 34 by soldering on a couple of wires onto an unused backplane connector and soldering jumper plugs on the other end of the wires, to connect to the board. Then go into /usr/sys/io/sioconf.c in the usual way as per several past articles. Don't forget that your new minor device numbers with be 4 and 12, along with the orriginal 0 and 8. Of course extra bits for modem control apply the same. The driver is already there and IT WORKS. Every rev since 2.2 that I have tried, both 286 & 386. ...!rutgers!carssdf!usenet
mark@promark.UUCP (Mark J. DeFilippis) (03/21/90)
In article <3347@trantor.harris-atd.com>, wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) writes: > I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, > I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, > I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport I saved this last time I saw it around. Hope it helps... How to add comm3 and comm4 under SCO Xenix Coert Vonk October 22, 1989 The basement of the following text was extracted from a usenet message in comp.unix.xenix. It describes how to add additional IBM-Standard COMM PORTS as comm3 and comm4 under SCO Xenix. 1. what do we have? ~~~~~~~~~~~~~~~~~~~~ IBM-Standard COMM PORTS may be characterized as: name base irq address --------------------------- comm1 0x3f8 4 comm2 0x2f8 3 comm3 0x3e8 5 comm4 0x2e8 2 If you think this looks to organized I can set you at ease. At the time IBM released his PC-XT/AT machines, only comm1 and comm2 were defined. Pushed by the demand of the market clone manufactures developed two other sio ports. Due to the lack of concerted attention there exist almost more characteristics for these ports than manufactures. With the release of PS/2 machines IBM set the standard for the comm3 and comm4 ports as represented above. Although all kinds of sio ports may be added, I focus to the standard address and irq of comm3. By the way if you intend to your another irq, you could check if it's is currently in by the /usr/sys/conf/vectorsinuse command (or read the master file yourself, more about this later). 2. edit sioconf.c ~~~~~~~~~~~~~~~~~~ Add new a descriptor to /usr/sys/io/sioconf.c using an ordinary text editor (i.e. vi,lyrix). It should have the format as descripted in /usr/sys/io/sioconf.h : int b_num; /* board number */ int b_type; /* each manufacturer gets a different one */ int b_pcnt; /* port count on the board */ int b_vec; /* interrupt vector */ int b_dev; /* minor dev base */ sd b_addr; /* base address of board */ int b_poll; /* interrupt poll addr */ int b_inc; /* increment (spacing) of io ports on board */ int b_outbits; /* value for OUT1/OUT2 bits in MCR */ Doing so we get: {2,IBM_BOARD, 1,5,4, (sd)0x3e8,0, 0,MCRBIT3}, /*ibm COM3*/ Some remarks on this: -- the next available IBM_BOARD board number is 2 (3 for comm4) -- I use irq5 for the board (irq2 for comm4) -- the minor device base is 4 (could be 12 for comm4) -- the base address is 0x3e8 (0x2e8 for comm4) 3. edited master ~~~~~~~~~~~~~~~~~ The /usr/sys/conf/master file contains information about different devices including interrupt vectors used. Serial (marked sio) devices used originally irqs 3,4,33 and 34. The irq33 and irq34 were originally placed in the table because Xenix got confused by the comm3 or comm4 port, and took it for a 4-port. vec.cnt irqA irqB irqC irqD ------------------------------------------------------------- sio 4 0577 104 sio 0 0 5 1 7 3 4 33 34 pa 2 0133 004 pa 0 0 6 1 2 5 7 0 0 When we correct this recognition problem we get: sio 2 0577 104 sio 0 0 5 1 7 3 4 0 0 pa 2 0133 004 pa 0 0 6 1 2 5 7 0 0 If we want to use irq5 for comm3, we have to steal if from parallel adapter. This brings the vector count for pa down to 1. sio 2 0577 104 sio 0 0 5 1 7 3 4 0 0 pa 1 0133 004 pa 0 0 6 1 2 7 0 0 0 By now it is time to introduce my new comm port. Filling in it's irq vector of 5, increments the sio vector count by one. Yielding in: sio 3 0577 104 sio 0 0 5 1 7 3 4 5 0 pa 1 0133 004 pa 0 0 6 1 2 7 0 0 0 I think now the time has come to make the machine contribute his/her part ... 4. make ~~~~~~~~ I recompiled all modified sources with make (yes, you need development system to do this) and copied the just linked new kernel to the root directory (/xenix.comm3). 5. reboot ~~~~~~~~~~ I rebooted my system and to the boot-prompt I entered xenix.comm3 (name of the new untested kernel). Everything worked fine, comm1, comm2, and comm3 were found. Help save the world! Communicate any problems and suggestions to me, mcsun!hp4nl!neabbs!coertvnk (Coert Vonk). ____ By the way, I am interested in an internship at an American University. Any ideas ..., please e-mail them. ____ / / Uucp address: Mailing address: / ___ __ __ __/ mcsun!hp4nl!neabbs!coertvnk Eikstraat 17 / / / /_/ / / Telephone: 4621 JL Bergen op Zoom /___ /__/ /__ / /__ + 31 1640 42366 The Netherlands -- Mark J. DeFilippis SA @ Department of Mathematics and Computer Science Adelphi University, Garden City, NY 11530 (516) 663-1170 UUCP: philabs!sbcs!bnlux0!adelphi!markd
darcy@druid.uucp (D'Arcy J.M. Cain) (03/21/90)
In article <5275@scolex.sco.COM> md@sco.COM (Michael Davidson) writes: > >wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) writes: > >>I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, >>I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, >>I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport >>card. This is not an option due to project contraints. Has anyone written a >>serial driver that will handle the above situation? > >The problem (an the reason why we don't support this) is that you have >two similar devices sharing the same hardware interrupt line. Now you >*can* get away with sharing an interrupt line like this under certain >circumstances, but this isn't one of them. Interrupts on AT bus machines >are "edge triggered", meaning that the 8259 interrupt controller >has to see a false -> true transition on the line to latch the >interrupt (sorry, can't remember whether these lines are active low >or active high). > >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. Am I missing something? When you have an interupt on a system which has multiple devices sharing a single interupt you check all the devices after disabling interupts. You don't stop after reading the first device. There are all sorts of machines with ganged interupts. Are you saying that they work because they have been lucky so far? -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | (416) 281-6094 |
@adec23.uucp (03/21/90)
md@sco.COM (Michael Davidson) writes: >wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) writes: >>I am trying to install a serial card configured for COM3 and COM4 (INT 3 & 4, >>I/O Addr 3E8 & 2E8) in a machine which already has COM1 and COM2 (INT 3 & 4, >>I/O Addr 3F8 & 2F8). SCO says it can't be done and I should get a multiport >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. Actually you loose ALL interrupts after this, you have to reset the two serial ports before you can get an interupt again. I have successfully managed to work both these ports by judicious polling and a hardware hack at 9600 Baud on a plain 4.77Mhz XT. The other problem is that the interupt is NOT wire-or. The output drivers are three state devices, they drive the line continuously when they are enabled. This means that if one device asserts an interrupt (HI) and the other doesn't (LO) the one that doesn't takes precedence (due to LSTTL driving capability) so NO ONE gets the interrupt. A simple RDL or gate looks after this, but who will support a hack like this? No one in their right mind is the answer. The multiport boards solve this second problem by providing an OR gate on the board to combine the ports interrupt signals BEFORE they get on the buss. Some provide superior interrupt control logic as well. Ciao, -- Mark Salyzyn adec23!mark -- Ciao -- Mark Salyzyn adec23!mark
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (03/22/90)
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
sl@van-bc.UUCP (Stuart Lynne) (03/22/90)
In article <683@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >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. > Something like the following is required to support multiple 8250 type devices on a single interrupt. #define MAXDEV ? int notfinished; int devno; do { notfinished = 0; for (devno = 0; devno<MAXDEV; devno++ ){ if (checkstatus(devno)) { notfinished = 1; dowork(devno); break; } } } while (notfinished); You must be able to complete the for loop without seeing any activity on any 8250 device to guarantee that the interrupt controller get's reset. For small numbers of devices, with a low traffic level it is slightly faster to break from the for loop than to continue once you have found something. Because you are usually just seeing one interrupt from one device. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
root@ozdaltx.UUCP (root) (03/22/90)
For what it is worth.....
I tried for almost two months to get COM3 & COM4 to work. I was able
to get 3 working, but never 4. No matter how much I kluged the
sysio/master/io files. I must have had 14 version of the kernal
floating around. ;-)
To make a long story short, I finially gave up and went with an ARNET
4 port board. BUT, I have since been told that one of the problems
with 3 & 4 is that each requires a single comm board for each slot -
boards with 2 comm ports won't work. I've never followed up on this any
further. Any comments???
Scotty
------
AIDS INFORMATION EXCHANGE BBS (214) 247-2367/247-5609
"Education is the best weapon"
{uunet,smu,ames}!sulaco!ozdaltx!sysop