Mail Archives: djgpp/2014/07/11/14:46:13
You are totally right, I was naively assuming that setvect() takes the
actual IRQ number as an argument, and not some black magic vector... :)
Altough your rule "add 0x08 to the IRQ #" seems to be a little imperfect
(but I might be wrong of course). I found in some unreliable source that
it's true only for IRQs 1-8. For IRQ 8-16 the vector is jumping a little
faster. Specifically I found a little helper to locate the vector for a
given IRQ:
const int irq_to_vect[] = { 8, 9, 10, 11, 12, 13, 14, 15,
112, 113, 114, 115, 116, 117, 118, 119};
I will test this stuff asap.
BTW, I unexpectedly found an interesting text on wikipedia, at
http://en.wikipedia.org/wiki/Intel_8259 :
"IRQ2/9 is the traditional interrupt line for an MPU-401 MIDI port, but
this conflicts with the ACPI system control interrupt (SCI is hardwired
to IRQ9 on Intel chipsets); this means ISA MPU-401 cards with a
hardwired IRQ 2/9, and MPU-401 device drivers with a hardcoded IRQ 2/9,
cannot be used in interrupt-driven mode on a system with ACPI enabled."
And NOW my seemingly random reboots suddenly make a lot of sense! :) But
I am unable to explain why running under real mode would mask reboots,
as the ACPI vs MPU401 conflict shall be present both in real and
protected modes... So many roads.
Mateusz
On 07/11/2014 03:35 PM, Johann Klammer wrote:
> On 07/11/2014 02:48 PM, Mateusz Viste wrote:
>> I have to admit I had no occasion yet to play with interrupts in DOS
>> (other that from a user point of view). What you write sounds very
>> convincing. And I have read in some MPU401 documentation that it is
>> likely to emit INT 9 at some occasions.
>>
>> For a test, I tried to handle the INT 9 with a "do nothing" function in
>> Turbo C, and now when my program ends, I have no keyboard anymore (ie. I
>> can press keys, but no reaction happens at all). :) Haven't tried to
>> catch the interrupt in protected mode yet, as it looks somewhat complex
>> (according to the DJGPP docs) - way more convoluted than doing it in
>> real mode at least.
>>
>> In any case, thanks for the hint! I will try to play with interrupts
>> this weekend and see what happens.
>>
>> cheers,
>> Mateusz
>>
>>
> Interrupt 9 is not necessarily interrupt 9 in dos_setvect.. I believe
> there was an offset involved...
>
> That's me setting a handler for the parport interrupt:
>
> _dos_setvect( pp->intr+0x08, ex_isr );
> (using Openwatcom, though.. there may be differences)
>
> seems there's 0x08 to be added...
>
> Interrupt vector 0x09 is the keyboard interrupt(IRQ 1) in DOS. You
> hooked it and forgot to restore it to previous value....
>
>
- Raw text -