On Fri, Jul 11, 2014 at 5:= 48 AM, Mateusz Viste <mateusz DOT viste AT delorie DOT com> wro= te:

I have to admit I had no occasion yet to pla= y with interrupts in DOS (other that from a user point of view). What you w= rite sounds very convincing. And I have read in some MPU401 documentation t= hat it is likely to emit INT 9 at some occasions.

For a test, I tried to handle the INT 9 with a "do nothing" funct= ion in Turbo C, and now when my program ends, I have no keyboard anymore (i= e. 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 m= ode at least.

In any case, thanks for the hint! I will try to play with interrupts this w= eekend 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 th= at 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 t= o
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.