DOS/16M FAQ: Interrupt Handling
[Previous Section] *
[Index of FAQ] *
[Next Section]
-
I have a protected mode handler installed as a TSR and signaled
via protected mode int 7C. To determine elapsed time, the handler calls
the Microsoft library function clock(), signals int 7C, calls clock()
again, and checks the difference. I'm finding that erratic values are
returned. Do you have any suggestions as to what might be causing
this?
-
If one protected mode program installs a bi-modal communications
handler and a second protected mode program is active when a
communications interrupt is signaled, will there be any kind of
conflict?
-
Why won't the Microsoft _bios_disk() function work with
DOS/16M?
-
Why is it that when called from an interrupt handler, pointers
(32-bit offsets) passed as parameters to an assembly language routine
reference incorrect segment register (this works if pointers are global
rather than automatic), but when called from non-interrupt code, the same
routine behaves correctly?
-
I'm writing a bi-modal communications handler and I want the
real mode handler to access data in high memory. Is there any way I can
switch from real to protected mode in a DPMI environment to access data in
high memory?
1.
I have a protected mode handler installed as a TSR and signaled
via protected mode int 7C. To determine elapsed time, the handler calls
the Microsoft library function clock(), signals int 7C, calls clock()
again, and checks the difference. I'm finding that erratic values are
returned. Do you have any suggestions as to what might be causing
this?
Interrupt masking during real mode <-> protected mode
transitions could easily account for variation in results. You may get
more consistant results if you assign a protected mode pointer to the BIOS
data tick count and use that directly for interval calculation.
2.
If one protected mode program installs a bi-modal communications
handler and a second protected mode program is active when a
communications interrupt is signaled, will there be any kind of
conflict?
No.
3.
Why won't the Microsoft _bios_disk() function work with
DOS/16M?
We don't provide register translation for INT 13h, so
protected-mode addresses aren't translated to real-mode, and
extended-memory data structures just aren't accessible. You will need to
provide your own wrapper and translation.
We suggest using d16SignalRMInterrupt() to actually signal the
interrupt.
4.
Why is it that when called from an interrupt handler, pointers
(32-bit offsets) passed as parameters to an assembly language routine
reference incorrect segment register (this works if pointers are global
rather than automatic), but when called from non-interrupt code, the same
routine behaves correctly?
The routine uses implicit segment registers; it assumes
DS=SS. This assumption fails in ISR case. There are a couple of things
you can do: be certain that pointers passed to this routine are always
global or automatic, coding the called routine appropriately, with segment
overrides if needed; pass 48-bit pointers, including the correct selector
value; or simplest of all, pass no pointers, just return the desired
16-bit value.
5.
I'm writing a bi-modal communications handler and I want the
real mode handler to access data in high memory. Is there any way I can
switch from real to protected mode in a DPMI environment to access data in
high memory?
Use a real-mode callback function(INT 31h func 303h). It's
worth doing it this way, instead of through a pass-up communications
handler, because the data-copying function won't be used every time an
interrupt occurs.
|