From my notes when I tested Aureal Vortex AU8820B2 and AU8830: it uses asp4dos.com TSR that doesn't require any presence of xEMM386/V86. It load's settings from vortex.ini placed in Windows directory so it probably needs Windows to configure resources. Under DOS there's no wavetable but FM only and it sounds very shitty. It worked better under Win98 where also wavetable can be used by loading soundfont to RAM.

yes bad fm and need an ini made by windows driver. but what is fasinating about this old driver is that can work on any chipset that has pci slot without any ems! my thoughts are if this driver reversed engineered a lot can be found and made a new better sbemu.

I guess that it use some assistance of specific HW in aureal soundchip so it would't help to other soundcards... Yes it would be nice if author of the driver could put this abandonware on github to let see what magic they did...
Also ymf72x/74x dsdma.exe source would be interesting as it implements its own DPMI server but probably the same is now done with HDPMI/VDPMI...

asp4dos.com is just ~35KB, easy to disassemble. I even started, got as far as parsing parameters but couldnt quickly find any magic happening so gave up. Since its not setting any trapping it must be using DDMA.

Cacodemon345 wrote on 2026-04-26, 18:22:

Hi crazii,

Is TinySoundFont planned to be added to SBEMU? I used it in my VSBHDASF project successfully for emulation of MPU-401 output as I do not have any serial ports on any of my PCs. VSBHDA merged my TinySoundFont implementation in my fork and I haven't heard of serious issues otherwise.

(It does use floating-point math, but I presume SBEMU has the ability to handle floating-point save/restore operations correctly.)

Yes, sure. Thanks for your excellent work. I will pick a time to merge your code. It'll also be good if there's anyone who can help me to do that 😁

SBEMU doesn't use float-points in HW interrupts, but it has code to save FP states on software interrupts (driver-reset / configuration changes etc.), because the driver init routine in MPXPlay has FP operations. I think it won't be a problem.

rasz_pl wrote on 2026-04-27, 19:01:

asp4dos.com is just ~35KB, easy to disassemble. I even started, got as far as parsing parameters but couldnt quickly find any magic happening so gave up. Since its not setting any trapping it must be using DDMA.

any finding will be good. by theory about this is if we can use something they use so we can use it. and have sbemu without any ems just like aureal, with sb16 emulation and better fm and compatible with many hda chipsets

Afaik supporting DDMA should allow SBEMU to work with no IO port trapping. But it might not be worth the effort considering how limited chipset DDMA support was, looks like it ended at some early Athlon chipsets https://dosdays.co.uk/topics/pci_sound_cards_in_dos.php https://docs.google.com/spreadsheets/d/1cvhr6 … dit?gid=0#gid=0

im no programmer. i dont know how asp4dos.com is made. but is a fact that is provides sbrpo emulation on evey chipset without ems. the secret behind that compatibility is worth investigating. my humble opinion thats all

f1etch wrote on 2023-06-09, 11:47:

Having issues with Audigy card. As soon as SBEMU loads I get a contant "white noise" sound from the Audigy. Tried with Audigy (SB0090) and Audigy 2 ZS (SB0350) and get same result.

I know this is a pretty ancient post but I was having the same problem with my Audigy 2 ZS, while onboard audio worked fine (enabling it in the bios) but I wanted to run everything through the Audigy and not have to disable onboard AC97 when I wanted to use Windows etc.

I think this more of a problem with Jemmex and the motherboard I'm using, but it might help others. SBEMU and VSBHDA were both buzzing/hissing when started and no other audio would work. In config.sys I have to set:

1DEVICE=JEMMEX.EXE NOE820

No buzzing/hissing anymore.

https://youtu.be/ZAtM3plfUdA

Update:
the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot), 5D (enable/disable OS/E Function Set) is not implemented, those mostly are used by OS (e.g. win3.x/win9x) and maybe implemented in the future along with GEMMIS. I only test 2 games, ALADDIN and LEMMING2. MSCDEX /E also tested. here's a list of programs that uses EMS https://www.vogonswiki.com/index.php/List_of_ … hat_require_EMS. I may find another time to test more.

My Thinkpad T540p only have 64K (+4K used by VDPMI) uma available, with USB support on, and LAN option ROM off. So when EMS is enabled, there is no UMB. I have to add more option to make some UMB for some drivers, e.g. DOSKEY and CTMOUSE.

Changes:

1.
/EMS option, default value=0, valid value [0-8]
/EMS equals /EMS=1, which enables EMS with default amount: 4M, /EMS=0 disables EMS, /EMS=[2-8] set amount in MB. EMS4.0 support up to 32M EMS memory but I don't think it's really needed.

2.
/MV option, default value=b000, valid value [b000-b700]. it is a specialized option for Ixxxx-B7FFF. only works when EMS enabled.
this include the monochrome video buffer. enabled by default. set /MV=0 to disable it. or /MV=b600 to include B600-B7FF. I'm considering a Ixxxx-xxxx option like EMM386, but not very sure.

3.
/EMSX option, default value=0, valid value [0-8]
this is similar to /EMS, and also set page frame to be F000, inspired by QEMM386. I don't know how QEMM does it but its idea is good. you only need either /EMS or /EMSX, not both. this option use the BIOS ROM area as page frame so that it saves the 64K for UMB. this option may have bugs, at least as I tested, it's OK for Aladdin and Lemming2.
In short, /EMSX gives you EMS without losing any of the UMB you had.

4.
Fix Lemmings2 startup freeze, not EMS related, but probably FAT32/DOS/BIOS related.

5.
Disable the "VM timing" feature, as it previously has bug and not working as expected, so it just appears OK but after I fixed that bug, the music becomes slow. disabled and may be used in debug mode.

EDIT: 6.
Fix incorrect DPMI client RM stack pointer that corrupts UMB.

Extra notes: with EMS enabled, a VDS might be needed, but as I tested for Lemmings2, without VDS it uses the page-mapped EMS address directly for DMA (while DMA controller require a physical address), I think without VDS it assumes a physical EMS board, not a emulator like EMM386 - and that works with SBEMU by chance - whether to add VDS remains undetermined.

now with /MV enabled by default, and set /EMSX, I have 96K UMB, which gives a relief.

My next plan is to integrate TSF features, after doing some clean ups. There is no exact date when I'm gonna start it yet.

Just pushed the adaption of SBEMU to VDPMI to a new branch, although the branch may have some commits behind the main branch.
the QEMM and HDPMI dependency, are removed, Virtual PIC is also removed. because VDPMI has its own virtualization. the virtual DMA will be removed in the future.

https://github.com/crazii/SBEMU/tree/vdpmi

crazii wrote on 2026-05-10, 11:40:

Just pushed the adaption of SBEMU to VDPMI to a new branch, although the branch may have some commits behind the main branch.
the QEMM and HDPMI dependency, are removed, Virtual PIC is also removed. because VDPMI has its own virtualization. the virtual DMA will be removed in the future.

https://github.com/crazii/SBEMU/tree/vdpmi

Thanks, crazii.

So am I right in understanding that VDPMI is intended to replace both HDPMI and any EMM solutions? So it will be used instead of Jemm or QEMM too?

Wondering this since you mention both EMS functionality as well as possibly supporting GEMMIS, as well as the fact that VDPMI would still have to support real mode games somehow, which I assume would mean that it would have to function as the V86 monitor as well, right?

But does that mean that it would not be able to coexist with any (other) EMM manager either?

crazii wrote on 2026-05-09, 16:11:

Update:
the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot), 5D (enable/disable OS/E Function Set) is not implemented, those mostly are used by OS (e.g. win3.x/win9x) and maybe implemented in the future along with GEMMIS...

Hi, @crazii,
Does this mean, that this new fork of SBEMU in its future versions could possibly remove its dependency of HimemX memory manager? AFAK @Baron von Riedesel strongly denies the need of GEMMIS API implementation.

digger wrote on 2026-05-11, 09:22:

Thanks, crazii. […]
Show full quote

crazii wrote on 2026-05-10, 11:40:

Just pushed the adaption of SBEMU to VDPMI to a new branch, although the branch may have some commits behind the main branch.
the QEMM and HDPMI dependency, are removed, Virtual PIC is also removed. because VDPMI has its own virtualization. the virtual DMA will be removed in the future.

https://github.com/crazii/SBEMU/tree/vdpmi

Thanks, crazii.

So am I right in understanding that VDPMI is intended to replace both HDPMI and any EMM solutions? So it will be used instead of Jemm or QEMM too?

Wondering this since you mention both EMS functionality as well as possibly supporting GEMMIS, as well as the fact that VDPMI would still have to support real mode games somehow, which I assume would mean that it would have to function as the V86 monitor as well, right?

But does that mean that it would not be able to coexist with any (other) EMM manager either?

Yes, you can check the CONFIG.SYS in the last two SBEMU_VDPMI.zips
it only has HimemX.EXE and VDPMI.EXE loaded, and the former zip doesn't have EMS, the latter has EMS support. you can test if the /EMSX option works.
VDPMI originally (two years ago) needs an EMM but there's problem to provide a possible VXD support without an builtin v86 monitor. the v86 monitor usually is an EMM.
for now, VDPMI doesn't need any EMM. and certainly within an EMM in VDPMI, it is not compatible with any other EMMs.
the external EMM dependency can be added back with complicate codes, but it prevent VDPMI supporting VxD in the future, or even may prevent VDPMI working properly. So the currently path leads to a stable and compatible EMM in VDPMI in the end. it should be, and there is no other way.

aVd wrote on 2026-05-11, 09:48:

Hi, @crazii,
Does this mean, that this new fork of SBEMU in its future versions could possibly remove its dependency of HimemX memory manager? AFAK @Baron von Riedesel strongly denies the need of GEMMIS API implementation.

The explicit dependency of a XMS can be removed from SBEMU, with a virtual_addr_2_physical_addr implemented just now. but an XMM (himem.sys or himemx.exe) is always needed, for any EMS or DPMI.
XMS/XMM can be added into VDPMI, so that VDPMI=Himem.sys/himemx.exe + EMM386/QEMM386/JEMM386 + CWSDPMI/HDPMI, it's like JEMMEX=jemm386+himemx, but with an extra dpmi server. That can be done but currently it's not top priority.
btw, GEMMIS is part of an EMM not XMS.

Got it. And consolidating the DPMI host, v86 monitor and EMM into a single executable or device driver makes a lot of sense here.

However, EMMs also handle additional things like UMBs, Shadow RAM and VDS. With the exception of VCPI, are you planning on implementing all of those common EMM features in VDPMI as well?

Sorry if any of these questions come off as clueless. I wasn't aware of the existence of VDPMI until very recently.

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.

VDPMI was updated recently, with a builtin v86 monitor and UMB support, but without EMS: Re: SBEMU: Sound Blaster emulation on AC97

the latest VDPMI: Re: SBEMU: Sound Blaster emulation on AC97 has EMS.
plans on VDS/XMS/VCPI also explained in the last two posts.

in short:
VCPI won't be supported, unless needed for the support of GEMMIS (win3.x/win9x) in the future. because without VCPI I don't think anything normal can get to protected mode in privilege 0 (ring-0).
VDS not planned to be supported so far, as I tested, games can run with SFX through SBEMU without VDS. but might have to be done if there is a scenario of requirement (other programs/drivers other than tested games).

EMS4.0 has a clear spec so there is no difficulty in implementing it, the spec for VCPI & VDS can also be found in online sources, so I guess it won't be a huge problem, only time to debug & test to make it stable.

crazii wrote on 2026-05-09, 16:11:

Update: the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot) […]
Show full quote

Update:
the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot), 5D (enable/disable OS/E Function Set) is not implemented, those mostly are used by OS (e.g. win3.x/win9x) and maybe implemented in the future along with GEMMIS. I only test 2 games, ALADDIN and LEMMING2. MSCDEX /E also tested. here's a list of programs that uses EMS https://www.vogonswiki.com/index.php/List_of_ … hat_require_EMS. I may find another time to test more.

My Thinkpad T540p only have 64K (+4K used by VDPMI) uma available, with USB support on, and LAN option ROM off. So when EMS is enabled, there is no UMB. I have to add more option to make some UMB for some drivers, e.g. DOSKEY and CTMOUSE.

Changes:

1.
/EMS option, default value=0, valid value [0-8]
/EMS equals /EMS=1, which enables EMS with default amount: 4M, /EMS=0 disables EMS, /EMS=[2-8] set amount in MB. EMS4.0 support up to 32M EMS memory but I don't think it's really needed.

2.
/MV option, default value=b000, valid value [b000-b700]. it is a specialized option for Ixxxx-B7FFF. only works when EMS enabled.
this include the monochrome video buffer. enabled by default. set /MV=0 to disable it. or /MV=b600 to include B600-B7FF. I'm considering a Ixxxx-xxxx option like EMM386, but not very sure.

3.
/EMSX option, default value=0, valid value [0-8]
this is similar to /EMS, and also set page frame to be F000, inspired by QEMM386. I don't know how QEMM does it but its idea is good. you only need either /EMS or /EMSX, not both. this option use the BIOS ROM area as page frame so that it saves the 64K for UMB. this option may have bugs, at least as I tested, it's OK for Aladdin and Lemming2.
In short, /EMSX gives you EMS without losing any of the UMB you had.

4.
Fix Lemmings2 startup freeze, not EMS related, but probably FAT32/DOS/BIOS related.

5.
Disable the "VM timing" feature, as it previously has bug and not working as expected, so it just appears OK but after I fixed that bug, the music becomes slow. disabled and may be used in debug mode.

EDIT: 6.
Fix incorrect DPMI client RM stack pointer that corrupts UMB.

Extra notes: with EMS enabled, a VDS might be needed, but as I tested for Lemmings2, without VDS it uses the page-mapped EMS address directly for DMA (while DMA controller require a physical address), I think without VDS it assumes a physical EMS board, not a emulator like EMM386 - and that works with SBEMU by chance - whether to add VDS remains undetermined.

now with /MV enabled by default, and set /EMSX, I have 96K UMB, which gives a relief.

My next plan is to integrate TSF features, after doing some clean ups. There is no exact date when I'm gonna start it yet.

Just tested this version with SDLPal SDL2 version.

It works on a PM965 laptop. The game runs on a USB flash drive, and the music sounds pretty good. "VDPMI Server Exception: 0e, Error: 0000" This error occurred by chance, not often. Not sure whether it is the issue in SDLPal or VDPMI. Should I upload the screen photo?

On a 845GL computer, the startup process stops when loading VDPMI with the cursor blinks, and I can use the keyboard to perform a reset.

PalMusicFan wrote on 2026-05-13, 07:00:

Just tested this version with SDLPal SDL2 version. […]
Show full quote

crazii wrote on 2026-05-09, 16:11:

Update: the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot) […]
Show full quote

Update:
the EMS 4.0 functions is now added, but the function 5Bh (alternate map register set), 5C (prepare EMS HW for warm boot), 5D (enable/disable OS/E Function Set) is not implemented, those mostly are used by OS (e.g. win3.x/win9x) and maybe implemented in the future along with GEMMIS. I only test 2 games, ALADDIN and LEMMING2. MSCDEX /E also tested. here's a list of programs that uses EMS https://www.vogonswiki.com/index.php/List_of_ … hat_require_EMS. I may find another time to test more.

My Thinkpad T540p only have 64K (+4K used by VDPMI) uma available, with USB support on, and LAN option ROM off. So when EMS is enabled, there is no UMB. I have to add more option to make some UMB for some drivers, e.g. DOSKEY and CTMOUSE.

Changes:

1.
/EMS option, default value=0, valid value [0-8]
/EMS equals /EMS=1, which enables EMS with default amount: 4M, /EMS=0 disables EMS, /EMS=[2-8] set amount in MB. EMS4.0 support up to 32M EMS memory but I don't think it's really needed.

2.
/MV option, default value=b000, valid value [b000-b700]. it is a specialized option for Ixxxx-B7FFF. only works when EMS enabled.
this include the monochrome video buffer. enabled by default. set /MV=0 to disable it. or /MV=b600 to include B600-B7FF. I'm considering a Ixxxx-xxxx option like EMM386, but not very sure.

3.
/EMSX option, default value=0, valid value [0-8]
this is similar to /EMS, and also set page frame to be F000, inspired by QEMM386. I don't know how QEMM does it but its idea is good. you only need either /EMS or /EMSX, not both. this option use the BIOS ROM area as page frame so that it saves the 64K for UMB. this option may have bugs, at least as I tested, it's OK for Aladdin and Lemming2.
In short, /EMSX gives you EMS without losing any of the UMB you had.

4.
Fix Lemmings2 startup freeze, not EMS related, but probably FAT32/DOS/BIOS related.

5.
Disable the "VM timing" feature, as it previously has bug and not working as expected, so it just appears OK but after I fixed that bug, the music becomes slow. disabled and may be used in debug mode.

EDIT: 6.
Fix incorrect DPMI client RM stack pointer that corrupts UMB.

Extra notes: with EMS enabled, a VDS might be needed, but as I tested for Lemmings2, without VDS it uses the page-mapped EMS address directly for DMA (while DMA controller require a physical address), I think without VDS it assumes a physical EMS board, not a emulator like EMM386 - and that works with SBEMU by chance - whether to add VDS remains undetermined.

now with /MV enabled by default, and set /EMSX, I have 96K UMB, which gives a relief.

My next plan is to integrate TSF features, after doing some clean ups. There is no exact date when I'm gonna start it yet.

Just tested this version with SDLPal SDL2 version.

It works on a PM965 laptop. The game runs on a USB flash drive, and the music sounds pretty good. "VDPMI Server Exception: 0e, Error: 0000" This error occurred by chance, not often. Not sure whether it is the issue in SDLPal or VDPMI. Should I upload the screen photo?

On a 845GL computer, the startup process stops when loading VDPMI with the cursor blinks, and I can use the keyboard to perform a reset.

Thanks for the feedback! A photo is helpful here, as a VDPMI Server exception is within VDPMI for sure. Exception e most likely is caused by accessing a NULL pointer.

FYI There are other 2 exception types:
"VDPMI Client16/32 Exception" which may print the client exe nam (in your case, it could be sdlpal.exe)
"VDPMI V86 Exception" usually a problem in real mode.
Both the other 2, might be caused by VDPMI itself, still.

Cacodemon345 wrote on 2026-04-26, 18:22:

Hi crazii,

Is TinySoundFont planned to be added to SBEMU? I used it in my VSBHDASF project successfully for emulation of MPU-401 output as I do not have any serial ports on any of my PCs. VSBHDA merged my TinySoundFont implementation in my fork and I haven't heard of serious issues otherwise.

(It does use floating-point math, but I presume SBEMU has the ability to handle floating-point save/restore operations correctly.)

I just integrated your code with some changes (to the main branch of SBEMU, not the vdpmi branch), the changes are irrelevant to your TSF modification, just some tiny little wrappers.

Two new option added:

/VMPU
Enable Virtual MPU with max voices, default 0 (disabled). set /VMPU, or /VMPU1 (the cmd parse is changed a bit, /VMPU:1 or /VMPU=1 also OK), aka set the value to 1 uses default value 64. otherwise it is clamp to [32,256]
Generally /VMPU is OK to use the VMPU via SF.

/VMSF
Set soundfont file path. if the path is relative, then it is not relative to the CWD, but to the location of SBEMU, this helps group SBEMU and the soundfont file into a single folder.
Default value is sbemusf.sf2. A sf2 file can be renamed and put into the folder where SBEMU locates.

/VMPU and /VMSF currently cannot be changed via cmd line by a second run of SBEMU, it's not handled yet.

Tested with 2 games, and seems OK.

BTW I think the pentium4 float-point code could be switched during runtime (init phase) by detecting CPUID, so that the extra binary for p4 can be removed, but I was in a rush and didn't do that.

Thanks again. 😁