Mail Archives: djgpp/1994/04/07/06:31:11
Here are two additional problems I found while debugging sb from
sblaster.zip:
- real mode callbacks don't work at all: rmcb_common saves ds in
cs:ds_tmpds but restores it from ds_ds, it should be transferred from
ds_tmpds to ds_ds after setting ds to DGROUP. (I've patched a version of
go32.exe to restore ds from cs:ds_tmpds which should work as long
as rmcb is not called recursively, which I don't think is the case)
- go32_dpmi_chain_pm_vector() (correct? can't memorize all those long
names...) is used in sb.c to activate the protected mode interrupt
sb_intr. If an interrupt occurs, this routine is called followed by
the original default interrupt handler (ivec -> interrupt_common ->
real mode -> int instruction in real mode -> rmcb -> rmcb_common ->
sb_intr) and sb_intr is called twice. I therefore have commented away
the go32_dpmi_chain... call so that every SB interrupt goes through
the real mode callback. This seems to work fine from both protected
and real mode (BTW an easy method to put the CPU into real mode while
a 32 bit program is running is to press the pause key). But there is
still a problem: I now get quite often an Unsupported Int 0D and the
register dump displays totally wrong register values, for example
selectors with values larger than 0x1000. This looks to me like a
hard to find bug, maybe caused by interrupts enabled where they
shouldn't or by an incorrectly restored segment register.
- Another, only partially related problem is that the set_controller()
function called by go32 to shift the interrupt vectors resets the
interrupt mask to 0, enabling all hardware interrupts. This caused the
strange behavior of inportb(0x21) reported earlier. On the other hand
it's better to leave it that way, as there is currently no way to
change the interrupt mask register from protected mode permanently:
it is restored to its previous value the next time go32 switches back
to real mode and would prevent any further servicing of the Soundblaster
interrupt.
Intermediate conclusion: interrupt level programming with go32 seems
still to be an adventureous challenge :-)
Stefan.
--
stefan AT lis DOT e-technik DOT tu-muenchen DOT de
- Raw text -