Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jarthur!uunet!dev8j.mdcbbs.com!campbell From: campbell@dev8j.mdcbbs.com (Tim Campbell) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: sharing hardware interrupts Message-ID: <1991May29.095441.1@dev8j.mdcbbs.com> Date: 29 May 91 09:54:41 GMT References: <1991May29.014824.16278@ux1.cso.uiuc.edu> Organization: McDonnell Douglas M&E, Cypress CA Lines: 64 Nntp-Posting-Host: ssd31 Nntp-Posting-User: levitch In article <1991May29.014824.16278@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: > I have read that two devices cannot share and concurrent use the same > interrupt (IRQ). I'd like to know if this is really so true and if it > is more a case of just dumb software (which abounds in this world). > > Suppose you have two or more different serial ports in a PC. Surely > there is a register somewhere on there that indicates its status as to > whether or not it has changed state, or has a state that needs to be > dealt with. When any one of the serial ports causes an interrupt (for > the sake of discussion let's say it is #4 and nothing else uses #4) > the software driver will get into control, scan all the known serial > port addresses for states to deal with, and performs the appropriate > action for all of them that need it. > > Given the above software, why could it not be possible to have two or > more devices share the same interrupt. > > I plan to write my own terminal program soon, and I want to make sure > that it is going to be able to handle all reasonable and useful cases. Ok - here's the skinny. When an interrupt occurs in a PC (say #4) the state of the CPU is pushed onto the stack and the machine jumps to the address pointed to by the ISR (interrupt service request) table. This table is the first thing in memory. It's basically a bunch of address (far pointers). IRQ0 would be at address 0000:0000, IRQ1 would be at address 0000:0004, etc. (4 bytes to an interrupt to hold the far pointer). IRQ4 would then be at address 0000:0010 (hex) OR 0001:0000 (however you care to look at it) - this address would then contain the far pointer to the invocation point of the interrupt handler. The machine executes the code found at that address until it encounters an IRET (interrupt return) instruction. It then pops the state of the CPU back off the stack and continues to run as though nothing ever happened. What the machine does while executing the interrupt service is your business. So it is possible to share interrupts. But you mentioned sharing them "concurrently" - which implies to me that you want to use (for example) COM1 and COM3 at the same time. Ok, this is fine if YOU write the low level driver that is to control both of those devices. But say you want to plug a mouse into COM1 and modem into COM3 and the mouse is handled by the traditional MS-Mouse driver MOUSE.COM which is completely oblivious to your interupt sharing scheme. You now have a problem. Yes, I suppose it's *possible* to patch the mouse driver, but probably not especially pleasant -- so the easy way out is to just say it can't be done. So there you have it. Your answer is definitely a qualified "maybe". -Tim P.S. I did set up a fully interrupt driven communications program in Turbo C which supplied the rather convenient option of being able to define a function of type interrupt. This makes the job a LOT easier because the compiler supplies the required IRET as opposed to the plain old RET instruction. I seem to recall hearing that MS C and MS Quick C can now do this as well. Can anyone confirm this? --------------------------------------------------------------------------- In real life: Tim Campbell - Electronic Data Systems Corp. Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA also: tcampbel@einstein.eds.com @ EDS - Troy, MI CompuServe: 71631,654 (alias 71631.654@compuserve.com) P.S. If anyone asks, just remember, you never saw any of this.