🚀 go-pugleaf

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.

For starters, the MS Bus Mouse can use several different IRQ levels; by
no means is it fixed at IRQ2 (I know, I have one, and it's set at IRQ5).
As for sharing interrupts, your assertion that the PC will not share
them is just plain false. As long as there is a reliable way to
interrogate the hardware to see if it generated an interrupt, the only
thing stopping interrupts from being shared are LAZY or INCOMPETENT
PROGRAMMERS. A simple example:

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.

Now, if the drivers are properly written, at installation time they will
take the current vector for INT 0x0c and save it someplace, then change
INT 0x0c's vector to point to their interrupt service routine. Let's
suppose an interrupt is generated by the mouse. The processor gets an
INT 0x0c and jumps to the vector for that interrupt, which points to the
serial port driver (which was loaded last). The serial port driver
checks the serial port's interrupt identification register, the contents
of which indicate that the serial port has not generated the interrupt.
The driver then jumps to the address that was in the INT 0x0c vector
slot before it installed itself, passing control to the handler for the
A/D board.

The A/D board's driver checks the A/D board's interrupt identification
register, and discovers that the A/D board did not generate the
interrupt. The handler then jumps to the address that was in the INT
0x0c vector slot when IT was installed, passing the buck to the mouse
driver.

The mouse driver checks the InPort card's interrupt identification
register, and finds out that indeed the mouse did generate the
interrupt. It handles the interrupt, and then returns control to the
system via an IRET instruction.

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.