Thanks very much for integrating my TinySoundFont changes!

crazii wrote on 2026-05-11, 15:24:

I posted a early testing version of VDPMI in 2024, here: Re: SBEMU: Sound Blaster emulation on AC97
this one needs an external EMM, support 16bit dpmi client, like tyrian and jazz jackrabbit. but is buggy.

Hi. I tested "sbemu-1.1apha1-rc1.zip" under Windows 98 in MS-DOS mode, with the standard original HIMEM.SYS + EMM386.EXE (+ BURNMEM.SYS before them, to limit the total amount of available memory), and ran SBEMU after exiting WINDOWS as follows:

SET BLASTER=A240 I7 D3 H5 T6
VDPMI.EXE /MAXMEM=16 /V1=0 /I16TO32=1 /VM=1 /PVI=0 /UMB=1
SBEMU /SC2

Everything started up correctly and appeared in green in all lines, with a characteristic click in the speakers:

I ran SETMAIN.EXE (the Duke3D audio configurator) and the sound + music appeared after the appropriate configuration (SB16 + ADLIB). In the Duke3D game itself, the sound and music work properly after this.

After the game, you can unload VDPMI.EXE from memory using the "/u" parameter, but how can you unload SBEMU itself from memory?

Overall, I like idea of optional compatibility with EMM386, especially since it eliminates unnecessary hardware restarts.

Thanks.

A quick update: I am trying to finish the /VMPU and /VMSF re-setting from a second run of SBEMU.

This is involves disk IO in a TSR in (the technically the right way ) or pre-load it and pass it to the TSR (hacking and poor maintenance). not very easy & straightforward. It may not be worth the effort, but I feel compelled to finish it. it may help for some testing purpose, e.g. switch between different soundfonts to compare the results.

DoZator wrote on Today, 09:42:

After the game, you can unload VDPMI.EXE from memory using the "/u" parameter, but how can you unload SBEMU itself from memory?

On unloading, VDPMI will free all extended memory for DPMI clients, including SBEMU, so theoretically you don't need to unload SBEMU, except that there might be some little remnants of conventional/UMB memory used by SBEMU not freed, which needs a simple protocol to perform cleanups for it, this part will be done in the future.

DoZator wrote on Today, 09:42:

Overall, I like idea of optional compatibility with EMM386, especially since it eliminates unnecessary hardware restarts.

Yes I like that idea too. But unfortunately it won't work properly for VDPMI. I guess you need restart to switch to Windows, right? there is another long way: to support GEMMIS so that Windows can run with VDPMI. this is planned but not the priority for the time being. I think it's a matter of time, please stayed tuned 😁.

crazii wrote on Today, 10:14:

I guess you need restart to switch to Windows, right?

Yes, this is true when SBEMU is loaded into regular memory. And if you load it into the upper memory (LH SBEMU /SC2), then the return to WINDOWS is correct, you just need to unload VDPMI.EXE /U, but SBEMU remains loaded in the upper memory, and you can see it in the DOS window of WINDOWS using mem /c /p, and it only takes up 640 bytes 😁