Mail Archives: djgpp/2014/07/11/08:00:23
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 -