Hello Sean et. al. Boy, you've really grasped the "can of worms", the mucky innards of the IBM PC. Leaving aside all the reasons WHY it's so bad and concentrating on what you can do with the pieces: 1) IRQ7 is implemented in the (primary, supposedly) printer port using a tri-state buffer which as it should, defaults to tri-state. DOS never made use of the printer IRQ, though many clever uses have been made of it for OTHER sorts of parallel port hardware. Even WIN95 doesn't appear to use it (it allocates scheduler "slots" to it as a separate program) so you MAY consider IRQ7 fair game. I personally use it for my sound card as it is the LOWEST IRQ priority of all, and use IRQ5 for my net card for a similar reason. You may recall IRQ6 is allocated to the FDC. 2) The serial ports are supposed to have tri-state drivers too, allowing you to share IRQ4 between COM1 (mouse) and and COM3, and IRQ3 between COM2 (secondary modem) and COM4, as long as you are using only one of each pair at a time and turn each off when not using it. This has been totally garbaged as i) No "official" serial BIOS was written as IBM knew serial comms weren't necessary for a PC, so everyone wrote their own as a "lowest common denominator". ii) Manufacturers, particularly of clones, realised users didn't need more than two COM ports in a PC (if that), so deleted the IRQ tri-state drivers which the users didn't need or miss. iii) "Extra" COM port cards now use IRQ10 (primary modem/ FAX) and IRQ11, that is; they are pseudo-16-bit cards in EISA format. There is a subtle hint here for designers such as Sean; these cards use ONLY the IRQ lines on the EISA extension part, nothing else; they are actually 8-bit cards. ISA (short) COM and modem cards are, in case you have not discovered it by now, USELESS! Unless you are a hardware hacker like myself and wire-wrap a jumper between the IRQ select of the modem card and the suitable "extended" IRQ line of say, the net card. There are two groups of PC users; those who consider the innards of their PC inviolate, and those who make it do what they want. I would ASSUME this forum to be largely if not exclusively the latter? 3) It is quite easy to share IRQs, if you can write the code to do it, difficult now with WIN95 at least in respect to the COM ports since the drivers are "set in stone". Assuming your cards lack the tri-state driver, simply cut a track and put a series resistor (470ohm) in the IRQ line on the dominant card, and a diode (cathode towards the bus) in each secondary card. Voila! A diode-OR gate. 4) The nature of the 8259 Programmable Interrupt Controller. You need the datasheets to understand how it works, so get them (and even then it's a bit of a mystery), but in short, each input trips an edge- sensitive bit in the eight-bit Interrupt Request Register (IRR). Edge- sensitive means that i) if the IRQ line is only pulsed, the IRR remembers but ii) If you omit to clear the IRQ line in the peripheral card, you will never generate another interrupt! An 8-bit Interrupt Mask Register (IMR) next masks the IRR bits as they are conveyed to the priority logic and In-Service Register (ISR). The message here is that i) if an IRR bit is already set and you then "un-mask" (enable) it, it will generate an immediate interrupt and ii) if you mask it IN the interrupt service routine and fail to clear the interrupt in the PIC (no, actually the Programmable Interrupt Controller in this context), you have "locked out" all interrupts of lower priority. Indeed, the single salient feature of the 8259 PIC is that you MUST tell it when you have serviced the interrupt AND clear the interrupt source as well (and in that order!). 5) Code. IRQ drivers do the following: A) Install: i) Enable the tri-state buffer on the card. IRQ source on card is of course disabled at this point. ii) Mask off interrupts in CPU while servicing the 8259 PIC. iii) Read old mask bit from IMR and save it. iv) Read the old ISR (Interrupt Service Routine) vector (INT $21;$35) and save it for restoration. v) Install new ISR vector using INT $21;$25 vi) Set (enable) mask bit in IMR. vii) Re-enable interrupts in CPU. viii) Enable IRQ source on card. B) Service: i) Disable IRQ source on card. (Clears IRQ line) iia) {Re-entrancy} clear (mask) bit in IMR iib) {Re-entrancy} Enable interrupts iiia) {Sharing} if not(interrupt_condition_flag) jump to old ISR vector. iiib) While(interrupt_condition_flag) service_interrupts (and of course clear interrupt flags) iv) issue EOI command to 8259 PIC. v) {Re-entrancy} set (enable) bit in IMR vi) Enable IRQ source on card. Only NOW allows further IRQ. vii) RTI C) Remove: i) Disable IRQ source on card. No further interrupts should be generated by it now. ii) Mask off interrupts in CPU while servicing the 8259 PIC. iii) Restore old (saved) mask bit to IMR. iv) Re-install the old ISR (Interrupt Service Routine) vector (INT $21;$25). v) Disable the tri-state buffer on the card. Wait awhile. vi) Re-enable interrupts in CPU. Herbert Graf wrote: > >>IRQs, if OTOH you change you're card to the 16 bit size it should > >> work, in fact I don't think you even have to do data transfers with > >> 16 bit, I believe it will still allow you to do 8 bit transfers if > >> that is what you want. It will. You have to assert a signal on the "extension" to use 16-bit transfers, but you can use the IRQ lines anytime. > > But this ought to work (sort-of) because it is possible to have two > >com ports (1 and 3 or 2 and 4) on the same IRQ but on different > > cards, right? I know they won't work well > Well yes, the problem is they fight with each other if their > outputs aren't tri-stated, for example one card might be hollding a > low and another might be wanting to initiate an IRQ, the high fights > with the low and three things can happen, ... > Usually everything works fine, but I don't know what the > recommendation is, whether to leave it tristated or not, for safety > sake on any bus, I would recommend tristating when not in use, it just > solves many problems. As I say regarding the COM ports, you don't have an option as the "clone" manufacturers have long since departed from one of the few sensible aspects of the IBM standard. > I just though about this, I also have one free, IRQ 7, not the best > IRQ to use, probably why it is free in almost every machine I use! :) Why not the best? If it's free, it MUST be the best! (See top!) And Harold M Hallikainen wrote: > Also, I believe there are a couple things in the ISA design that > keep us from sharing interrupts. Yes, practically everything about it. But then the PC designers knew we'd never NEED more interrupts! > Second, I believe the interrupt controller is edge triggered instead > of level triggered (though it MIGHT be possible to change this through > programming the interrupt controller). Nope! You can read the IRR itself, but as it is edge-triggered and reset when the interrupt is serviced, it doesn't tell you the actual status of the interrupt lines. YOU CAN'T WIN! > Before the ISA bus, I did stuff with the MC6802. It was VERY > easy to share interrupts on that! It was active low and level > triggered. It was designed for systems with lots of interrupts. Its Interrupt controller is designed for systems with lots of interrupts. The 8080 (yes, I said 8080, the 8088 is merely a variant) wasn't. > I did one ISA bus design that used open source drivers to pull > the IRQ line up, and a current mirror to pull the line low. These > cards could be paralleled on the same IRQ line without contention. I > never got to fully test how the edge level trigger problem would be > fixed. Professional multi-I/O cards for the PC use a register to indicate and prioritise which device is requesting service on the single interrupt. The IRQ service routine as in my template above performs a while loop to service all outstanding requests. It first disables the IRQ line to allow the IRR to be reset when the EOI command is asserted, then re- enables the IRQ line so that if another interrupt occurs between the while loop and the RTI, it is treated as a fresh IRQ. The limitation is that co-operative IRQ code is essential to completely cover all possibilities with edge-triggering. No such code was included in the PC. Level-triggering as used in Motorola systems permits much simpler and more reliable code. That's life! Cheers, Paul B.