Why exactly could ISA devices not share IRQs?

It seems to me that if more than one device may raise the same IRQ, then the device #driver⁠s for those devices should all wake up and poll their devices to see which device needs attention.

In theory, this would work, just slower.

And yet, somehow, this is not what happens if two devices on an #ISA bus share the same #IRQ. Instead, the system hangs. Why is that?

#retrocomputing

@argv_minus_one Your question inspired me to dig a little.

There's no guarantee the system will hang. It "might" work randomly, sometimes. But each IRQ line was a separate physical pin in the slot. A card using IRQ X would assume it was the only thing on that wire and might sink any current on that line (no obvious reason not to, no formal test suite, etc.) So only a small amount of current might actually reach the CPU and not trigger the interrupt, or put things in an undefined state.

@argv_minus_one part of the problem is that you can only have one routine setup per interrupt, so the drivers would need to have the logic to check if their device raised the interrupt and if not they would need to call the next interrupt in the chain

I think you could do it, basically you store the old address of the handler before setting it to your address

The trouble is that it requires everyone to play nice and when you are running on a 4 MHz machine you don't want to do extra work

@Wearwolf @argv_minus_one

I agree with Kyle, and add that (if I remember correctly) the interrupt controller can store only one address to the start of each interrupt handler.

Back in the early 1990s I worked for Media Vision, which made pretty good sound cards, though they were resource hogs, especially when it came to interrupts on the ISA bus.

@argv_minus_one Now imagine an Apple II, a simple machine with only one interrupt line (ignoring the NMI). All devices raise the same interrupt. A device driver's job is to hook the interrupt vector on installation, and when it gets called it must quickly figure out if it must act on the interrupt or, if not, call the next interrupt handler, and so on. What fun!

@argv_minus_one "Wake up"? No scheduler involved here, just the one handler the CPU sees that DOS code could directly attach to.

It was perfectly normal to chain eg keyboard interrupt handlers in "Terminate-and-Stay-Resident" programs, but the OS had no overt idea it was going on and there was no guarantee some piece of code wouldn't be an arsehole about it.

Then win9x inherited the whole shitshow as it became an OS in its own right, though it didn't exactly make an effort to support TSRs.

@argv_minus_one

I was under the impression you could do this but it was highly dependent on the type of card and the drivers used. Some types of cards WOULD NOT, while some could if the other card agreed.

Edit:

"In some conditions, two ISA devices could share the same IRQ as long as they were not used simultaneously."

https://en.wikipedia.org/wiki/Interrupt_request

Interrupt request - Wikipedia

@argv_minus_one
Mostly software architecture design. You'd need the shared devices to all have a pollable state register that shows which one _actually_ fired off. Shared IRQ lines could also end up with a situation where a slow handler could end up with a device that gets it's interrupt "eaten" during the handling of another interrupt.

@Yuki

Don't they have to do that anyway, to deal with spurious interrupts?

@argv_minus_one if we recall correctly, spurious interrupts are buffered by the PIC, and always show up as the lowest priortiy (ie, irq 7 or 15). And that doesn't require reaching out to the actual device to confirm, just the pic to see if it's a real irq or spurious