Hi..
 > Now, as I see it, if you want to capture a software interrupt which is
 > generated by a hardware interrupt and write your own handler, before
 > installing
 > your code you should change the output control word for PIC 1 or PIC 2,
 > depending on whether the IRQ you're servicing is 0-7 or 8-15.  Is this
 > correct?
So, basicly you're writing your own hardware interrupt handler.
Here's how it works. When the PIC receives an interrupt, it checks it's IER 
to see if the interupt is enabled or not. If not, the interrupt is *INGORED*. 
Now, with the keyboard (IRQ 1) the IER is always enabled, because the 
keyboard is a standard part of the PC hardware - the BIOS initializes it. 
Same for the standard parts of any PC - IRQ6 for floppy, IRQ 14 for IDE HDD 
(on an AT+), etc etc.
With a sound card, the BIOS does not initialise it, so you need to turn on 
the appropriate bit in the IER yourself. This in turn leads to a catch-22 
situation: how to find the correct interrupt when the card cannot yet 
generate one? Creative's answer was to use the set blaster= environment 
variable. You read that, then enable the correct IER bit. If set blaster= is 
wrong, your code will fail. Most auto-detect routines work this way:
save original IER's
Install your own interrupt handler for all 16 interrupts
turn on *ALL* IER's
make the s/c generate an interrupt (ie play 1 byte by DMA)
See which of the 16 interrupts was triggered (ignore the 'standard' ones - 
irq 0,1,2,6,8,14 etc in case the user was messing about)
restore original IER's + enable the one you detected.
Other routines only enable the IRQ's the card is capable of generating - 
5,7,10, etc, however I dislike this method as it breaks future compatability, 
especially with MCA and PCI sound cards.
 > had to do this.  Also, I've noticed in some SoundBlaster code I found on
 > Creative's Web site that in their ISR, if the IRQ was greater than 8,
 > they
 > signalled an EOI by outputting 20h to PIC 2 and also did the usual 20h
 > to PIC 1
 > Is this necessary?  Here's some pseudocode of what they did:
Yes. It's because of the way the hardware is built - PIC2 is slaved to PIC1, 
so both need the EOI command transmitted. Basicly, just do it... without it, 
the first PIC won't be able to process any more interrupts, because it's 
still awaiting bieng told the first one is finished.
    Craig
--- FMail/386 1.20+
---------------