Mail Archives: djgpp/2014/07/11/09:40:07
--047d7b86e4f277114204fdeb1345
Content-Type: text/plain; charset=UTF-8
There's lots of docs for catching ints [1][2][3][4]. It is more complex
than real mode but so it goes.
[1] http://www.delorie.com/djgpp/v2faq/faq18_9.html
[2] http://www.ee.nmt.edu/~rison/ee352_spr00/supp/000128/timer_int.html
[3] http://www.delorie.com/djgpp/doc/ug/interrupts/hwirqs.html
[4] http://geezer.osdevbrasil.net/osd/intr/dos-32.c
On Fri, Jul 11, 2014 at 5:48 AM, Mateusz Viste <mateusz DOT viste AT delorie DOT com>
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
>
>
>
>
>
> 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.
>>
>>
>
--047d7b86e4f277114204fdeb1345
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There's lots of docs for catching ints [1][2][3][4]. =
=C2=A0It is more complex than real mode but so it goes.<div><br></div><div>=
[1]=C2=A0<a href=3D"http://www.delorie.com/djgpp/v2faq/faq18_9.html">http:/=
/www.delorie.com/djgpp/v2faq/faq18_9.html</a></div>
<div>[2]=C2=A0<a href=3D"http://www.ee.nmt.edu/~rison/ee352_spr00/supp/0001=
28/timer_int.html">http://www.ee.nmt.edu/~rison/ee352_spr00/supp/000128/tim=
er_int.html</a></div><div>[3]=C2=A0<a href=3D"http://www.delorie.com/djgpp/=
doc/ug/interrupts/hwirqs.html">http://www.delorie.com/djgpp/doc/ug/interrup=
ts/hwirqs.html</a></div>
<div>[4]=C2=A0<a href=3D"http://geezer.osdevbrasil.net/osd/intr/dos-32.c">h=
ttp://geezer.osdevbrasil.net/osd/intr/dos-32.c</a></div></div><div class=3D=
"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Jul 11, 2014 at 5:=
48 AM, Mateusz Viste <span dir=3D"ltr"><<a href=3D"mailto:mateusz.viste@=
delorie.com" target=3D"_blank">mateusz DOT viste AT delorie DOT com</a>></span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
In any case, thanks for the hint! I will try to play with interrupts this w=
eekend and see what happens.<br>
<br>
cheers,<br>
Mateusz<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
On 07/11/2014 01:50 PM, Johann Klammer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 07/11/2014 10:38 AM, Mateusz Viste wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Thank you all for your kind replies.<br>
<br>
The "weird interrupt happening during I/O" sounded sexy enough th=
at I<br>
had to test it out immediately - I replaced all my inportb() and<br>
outportb() calls with a function that first call disable(), then do the<br>
in/out operation, and then call enable() if interrupts were enabled<br>
before. Unfortunately this doesn't changed my problem - my PC still<br>
reboots wildly on random i/o operations on the 0x330 port.<br>
<br>
Some context: I am trying to play a few notes on my Sound Blaster 64<br>
(ISA) card using its embedded MPU401 synth controller. It works pretty<br>
well when compiled in realmode with Turbo C 2.0.1, but then I am having<br>
a bit of hard time with memory management (64K limit et all), so I<br>
thought I'd recompile it under DJGPP. And then I experienced those wild=
<br>
reboots I was writing before. Interestingly enough, the protected mode<br>
version works fine on DOSBox.<br>
<br>
Of course I am aware that such 'bug report' is good for nothing - I=
was<br>
just wondering whether there is some top secret information about doing<br>
I/O calls from protected mode that I ignored, but I understand now that<br>
there is nothing specific to do in protected mode (or at least nothing<br>
much else than in real mode), so I will try to put together some<br>
minimalistic test program to reproduce the problem on the smallest<br>
possible example, and then I'll see where it leads me (might get back t=
o<br>
you then).<br>
<br>
Again, thanks for all your prompt replies!<br>
<br>
cheers,<br>
Mateusz<br>
<br>
<br>
</blockquote>
If the interrupt flag gets set, it stays set until after the interrupts<br>
get re-enabled, at which point the interrupt will run and crash your<br>
system, unless there's a handler there and not just garbage, or a<br>
default, probably installed by the dos extender/C run-time, which<br>
probably restarts your system. So, just disable/enable will not solve<br>
your problem.<br>
With dos extenders the interrupt is typically forwarded to a PM handler<br>
(if installed), You should try that (install a handler) and write a byte<br=
>
to the text segment, to see if anything is happening..<br>
There's probably a dos_setvect() or something...<br>
There is probably a control bit somewhere on your MPU port range to<br>
disable interrupt generation from that specific source. You can try<br>
that, too.<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
--047d7b86e4f277114204fdeb1345--
- Raw text -