ISA interrupt sharing
Arbitrary ISA boards cannot share interrupt lines safely (though several ISA devices integrated onto a single board can).
There are several reasons for this. First of all, the interrupt line may be driven at all times by some other board, causing the first board's interrupt request to vanish; extra hardware would be required on both cards to prevent this.
ISA devices employ edge triggered interrupts, so the interrupt may be missed because it is pulsed after that interrupt was already asserted by another board and latched by the PIC.
The card may lock up (stall) if its interrupt status register is read when no interrupt is pending, causing the host to hang. One requirement of a shared-interrupt device driver is that it has to check interrupt status on all cards assigned to that interrupt.
It is also possible to have spurious interrupts (like a parallel port interrupt caused by external event while no parallel port driver is loaded, or a fluctuation at power up); if something else is on that IRQ line, its interrupt handler will get called. The other interrupt handler will not know how to clear the asserted interrupt in the device, leading to an interrupt storm and lockup.
If you design ISA devices that account for all of the above scenarios, you may be able to get away with sharing interrupts between them (but not with an arbitrary ISA card!)
Under DOS, there is another caveat. If you have several device drivers sharing a software or hardware interrupt, the most recently installed interrupt handler will “chain” to the old handlers. If a device driver takes over a hardware IRQ vector, the other driver probably issued a PIC EOI at the end of its IRQ handling routine. If you then issue a PIC EOI at the end of your routine after calling the other driver, the result will be that an interrupt could be lost. So you would have to be quite careful to ensure that you issue EOI if and only if your board was the one responsible for the interrupt.
Some things you might not know about PCI
A PCI bus only has 4 possible interrupt lines: INTA-D. These are connected to PIC lines (or mapped by the I/O-APIC) and set to level-trigger mode in the ELCR (Edge/Level Control Register) by the system firmware. If you have more than 4 interrupt-driven PCI devices attached to a PCI bus (most systems only have one PCI bus and an AGP bus), at least two of those devices will be sharing a PCI interrupt line. This implies that they share the same CPU interrupt vector.
While PCI devices are required by the specification to have level triggered interrupts so that interrupt sharing is possible, PCI devices are NOT required to support sharing that interrupt line in any sane fashion. So when that CPU interrupt vector is called, it usually will call several interrupt handlers (one for each device on the shared IRQ), and the interrupt handler will attempt to determine whether its card was the one that generated the interrupt. Frequently, there are bugs in logic that result in lockups or unexpected behavior. For example, some cards will lock up if their interrupt reason register is read while an interrupt is not pending. Others will automatically clear the interrupt flag and continue operation when the status register is read during the scan, leading to problems if you needed to service interrupts in a particular order. Better yet, hardware bugs may cause a device to appear to its driver to be the source of an interrupt when in fact it was not, causing lost interrupts from the other device it shares the IRQ with.
ISA DMA
The FreeBSD developer's handbook has a good overview of ISA DMA and the 8237 DMA controller: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/dma.html
Plug and Play (ISA)
Plug and Play is now a general PC industry term used to describe any hardware which should require no software installation or hardware configuration on the part of the user. ISA Plug and Play has a very specific meaning, however. The Plug and Play scheme consists of two special ports (0x279 and 0xA79) and a set of Plug and Play registers, implemented by system logic. 0x279 is ADDRESS and 0xA79 is WRITE_DATA. ADDRESS is the 8-bit address of an internal Plug and Play register, and WRITE_DATA is the value to be written.
Note: port 0x279 appears to conflict with the tertiary ISA parallel port; however, Plug & Play writes to this register, while parallel port driver software should only read from it.
The PnP card powers on in sleep mode; it only snoops the bus for writes to 0x279 and 0xA79. When software wants to configure a card, it disables interrupts, writes two zeroes, and then the 32-byte industry Plug and Play key (6A,B5,DA,ED,F6,FB,7D,BE,DF,6F,37,lB,0D,86,C3,61,B0,58,2C,16,8B,45,A2,D1,E8,74,3A,9D,CE,E7,73,39) to port 0x279. (This should be done twice, so that in case a previous key write failed to complete, the internal state machine in the card will be reset). Afterwards, a series of commands referred to as the isolation protocol attempts to isolate a particular PnP card for configuration by repeatedly relocating the PnP READ_DATA port and verifying the checksum of what is read from READ_DATA. If the checksum matches, the card is assigned a unique “Card Select Number” based on its serial number among other things, and the CSN is then used to configure the card. The process is repeated to isolate other PnP cards and configure them.
Most PnP cards also have a separate vendor-defined key that can be sent to place them into software configuration mode outside of the PnP scheme.
Because of the vendor key scheme, and due to the fact that most manufacturers of add-in boards do not bother to store a unique serial number in the board's EEPROM, it is rarely possible to have more than one identical ISA PnP card installed in the same system.
The PnP configuration can be performed by the BIOS, the operating system, or an operating system PnP driver (such as Intel's ICU for DOS).
If the PnP configuration is performed by the BIOS, the hardware resource configuration of the PnP device, as well as a list of all configurations it can support, is exported to the operating system via the 16-bit PnP BIOS interface. The operating system can use the configuration as-is, or it can change the configuration to any of several pre-set configurations provided by the card's PnP EEPROM. If the operating system changes the configuration via the PnP BIOS interface, the configuration will be stored in the ESCD, which is stored in non-volatile memory somewhere. When the system is reset, the BIOS will afterwards use the ESCD values to configure the card. Therefore, changes made to PnP cards in one operating system will persist to another operating system on the same computer via the PnP BIOS and ESCD.
Many systems will leave PnP cards unconfigured. In this case, the PnP BIOS is irrelevant and will show zero PnP cards. This is misleading, because there may very well be PnP cards in the system, but simply that the BIOS did not configure them! In this case, it is necessary for the operating system or driver software such as ICU, isapnptools, or the isapnp driver to use port 0x279 and 0xA79 to find and configure PnP devices.
This is the same case when 'PnP Operating System' or a similar function in the BIOS is set to 'Yes'. This simply means that the BIOS will not configure PnP cards, export cards through the PnPBIOS interface, or make use of the ESCD – thus leaving the configuration of the PnP cards wholly up to the operating system or drivers.