Mail Archives: djgpp/2014/07/11/09:00:12
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
On 07/11/2014 01:50 PM, Johann Klammer wrote:
> On 07/11/2014 10:38 AM, Mateusz Viste wrote:
>> Hi,
>>
>> Thank you all for your kind replies.
>>
>> The "weird interrupt happening during I/O" sounded sexy enough that I
>> had to test it out immediately - I replaced all my inportb() and
>> outportb() calls with a function that first call disable(), then do the
>> in/out operation, and then call enable() if interrupts were enabled
>> before. Unfortunately this doesn't changed my problem - my PC still
>> reboots wildly on random i/o operations on the 0x330 port.
>>
>> Some context: I am trying to play a few notes on my Sound Blaster 64
>> (ISA) card using its embedded MPU401 synth controller. It works pretty
>> well when compiled in realmode with Turbo C 2.0.1, but then I am having
>> a bit of hard time with memory management (64K limit et all), so I
>> thought I'd recompile it under DJGPP. And then I experienced those wild
>> reboots I was writing before. Interestingly enough, the protected mode
>> version works fine on DOSBox.
>>
>> Of course I am aware that such 'bug report' is good for nothing - I was
>> just wondering whether there is some top secret information about doing
>> I/O calls from protected mode that I ignored, but I understand now that
>> there is nothing specific to do in protected mode (or at least nothing
>> much else than in real mode), so I will try to put together some
>> minimalistic test program to reproduce the problem on the smallest
>> possible example, and then I'll see where it leads me (might get back to
>> you then).
>>
>> Again, thanks for all your prompt replies!
>>
>> cheers,
>> Mateusz
>>
>>
> If the interrupt flag gets set, it stays set until after the interrupts
> get re-enabled, at which point the interrupt will run and crash your
> system, unless there's a handler there and not just garbage, or a
> default, probably installed by the dos extender/C run-time, which
> probably restarts your system. So, just disable/enable will not solve
> your problem.
> With dos extenders the interrupt is typically forwarded to a PM handler
> (if installed), You should try that (install a handler) and write a byte
> to the text segment, to see if anything is happening..
> There's probably a dos_setvect() or something...
> There is probably a control bit somewhere on your MPU port range to
> disable interrupt generation from that specific source. You can try
> that, too.
>
- Raw text -