Adding here:
I have an old mid 2000s era Toshiba with 2GB RAM, and AC'97 / ICH audio.
SBEMU finds it fine, and it seems working but I have run into some strange issues. I am unsure if it is related to strangeness of this machine or not:
This machine has a very strange memory map setup, and appears to be intended to live with winXP installed, not old realmode OSes like DOS or Win9X. The adapter rom region has the video bios and pals at C000-CFFF, with a few small 4k holes in this space. D000-DFFF is unambiguously free, but Clean-Booted system with no memory managers running, has MSD showing RAM mapped in here. Same with the E000-EFFF range.
That isn't too strange, except that MSD shows RAM mapped in there. EMM386 complains about RAM or Option Roms mapped into that space. MSD reports RAM, so that is not surprising.
At first, I thought maybe the system was just blanket turning on caching for the entire option rom space with no option to turn it off-- its a weaksauce phoenix bios, so I can see that being the case. So, I used himem.sys with /shadowram:off to try and turn it off. No dice. STILL maps RAM there. No idea why.
I interrogated it with UMBCHK from UMBPCI, because I was having severe stability issues, lockups, hangs, and other anomalous stuff when including that whole range for UMBs. DOS does not identify option ROMs in the region but the system is clearly using it for something important. UMBCHK identifies that the pages between E400 and EFFF are locked, and not available. After excluding this region, the lockups have ended, so I presume I have things "Configured Correctly" for QEMM97 now.
EG--
DEVICE=C:\QEMM\QEMM386.sys RAM X=B000-BFFF X=C000-CFFF I=D000-E3FF X=E400-FFFF FRAME=D000
which keeps it out of the monochrome screen buffer area (So things like infocom games play fine), and keeps it out of the small 4k holes in the C000 area, (and for some reason, out of some small 4k holes in the F000 area.), keeps UMBs neat and tidy, and out of "Whatever is trying to live at E400 that is so damn important."
Windows 98se is able to successfully boot, as long as the SBEMU driver is NOT loaded. It crashes early in the loading process if it is. The system is otherwise stable, and fully functioning like a champ, as long as the SBEMU driver is NOT loaded.
Which brings me to the problem--
games that use DPMI protected mode memory, like Doom, Doom 2, and Heretic, crash SPECTACULARLY as soon as digitized sound effects get played, when SBEMU is running. Fake OPL synthesis works just fine though-- Disable digitized sound effects, and it starts up and runs like a champ, just no sound effects.
I am unsure as to what causes this. Other games, like Wolfenstein 3d, or Warcraft II, work just fine.
I have tried various iterations on options for HDPMI32i, including keeping the LSB in low memory, and having all DPMI clients in separate memory spaces. LSB in low memory has no effect, and while "DPMI client in separate space" (-a flag) prevents crashing, it also prevents SBEMU from even producing sound with those games.
I have reproduced the same issue with JEMM386 and JEMMEX, both with win98se's fake "Dos 7", and with FreeDos. It happens regardless of the DOS running, or which of the memory managers is doing the job.
Strangely, Duke3D works just fine. Everything just works great. FM audio AND Fake OPL3.
Any suggestions?
edit--
Maybe try using the CWSDPMI.exe from duke3d to the affected games? Might be an issue with that extender not playing well with others?