🚀 go-pugleaf

In article <Bsrt1x.GE4@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
>
>In article <gate.e146oB1w165w@toz.buffalo.ny.us> cyberman@toz.buffalo.ny.us (Cyberman) writes:
>>
>>I also remember the PC WILL not share interupts.  Serial devices
>>can if they are on the same board, however if they are on
>>SEPERATE boards then you are in trouble.  IRQ 2 was specifically
>>set for the vertical retrace.  MS did it again you might say by
>>using it for thier blasted mouse.
>
>I take issue with these statements.
>
>
>Let's say I have a serial port (COM1:), an A/D board, and a bus mouse,
>all set to generate hardware interrupts on IRQ4. Let's say for the sake
>of argument that you installed the mouse driver first, then the A/D
>board's driver, and finally the serial port driver.
>

If you are talking about microchannel machines,you are correct.  However, 
if you are talking about "normal" XT and ISA bus PC's, you have no understanding
of the bus, and should stop spreading lies.  Since you said "PC," and 
not "PS/2", I'll assume you meant the later.

THERE IS A HARDWARE PROBLEM THAT PREVENTS THE SHARING OF INTERRUPTS.

Let's say for the sake of argument you have your mouse driver, pulling 
IRQ4 LOW  because no interrupt is pending, your A/D board pulling 
IRQ4 LOW because no interrupt is pending, and your serial port board 
gets an interrupt.

Either it will pulse the IRQ4 line high,  or hold IRQ4 high until you clear 
the interrupt condition (UART that uses a level active IRQ pin).  In
any case, IRQ4 is held low, effectively tied to ground, by two drivers, 
and the PIC WILL NOT see the interrupt condition because the line is still a 
logic low.

You might want to check your facts before spreading misinformation.  With such 
a long winded example on how the PC allegedly handles interrupts,  
people might actually believe you.

Anyone who doesn't believe the facts can try it themselves.  Find two
serial ports, on the same IRQ line, enable interrupts at the UART 
IER and with the appropriate user bit in the MCR.  See if you register
any interrupts where both don't interrupt at the same time - on
most hardware you won't get anything. 
 
You can hang a scope off the bus if you want, and you'll see what's 
happening.

>Now, if the drivers are properly written, at installation time they will

BS.  The software is broken, but the hardware is broken too.

>Voila! Shared interrupts. All it takes is a little intelligent design on
>the part of the programmer. The REAL problem is that apparently few
>programmers go the "extra mile" and design ISRs that a) interrogate the
>hardware to see if which device generated the interrupt, and b) chain to
>prior handlers if their device was not responsible. But don't think for
>a minute that because it's not commonly done that it CANNOT be done at
>all.

Then why don't you do it, without hardware modifications, and prove me wrong?  
I'd love to have my Unix serial driver talking to three serial ports at 
once, two on the same IRQ, it'd let me use the modem, terminal, and mouse
all at the same time....

Incidentally, IBM fixed this design flaw when they did the microchannel bus - 
a little late.  Microchannel uses level active interrupts, active low, 
sort of like the mem16 line on the ISA bus.  This means that interrupt requests
are OR'd in hardware.

Getting shared IRQ's on PC's requires hardware modifications.  Either you have 
to cut some traces, and route the lines through a 7432 OR gate, or you can
do some unreliable garbage by running the drivers through some resistors.

Some companies sell multi-port serial boards that do just this - ie run the 
IRQ lines through an OR gate.

Some hardware is flakey, but if it's working right you won't 
get shared interrupts on an XT/AT bus machine, no matter what 
you do to the software.
-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel.