Hi,

I picked up the VDPMI code in the Lunar New Year, and it's been 2 years so I forgot much about the details, I have to add more comments on the code I written before. after some debug and tests, I found it is extremely difficult to achieve "virtualization" without a v86 monitor; for protected mode games it's OK, but for real mode games, the IVT hooks can be overridden by a real mode program easily. I so spend a couple of months to add a v86 monitor. the changes are so huge that I have to debug it again. now I tested again on my Thinkpad T540p and it works as before, probably with less bugs. But the UMB code is preliminary and may have problems.

The next of my plan will be add EMS for the v86 monitor, and then a VXD sound card driver for win9x to learn the VXD stuff. after that it will be add vmm api to support VXD for vpdmi.
VPCI won't be supported obviously there is DPMI.
VDS for now is not planned, as VDS is mainly for multitasking & page mapped env, and VPDMI provide only 1:1 identity page mapping, and no multi-tasks.
XMS could be considered, but now it's not the priority.

Here are the changes and attached zip.

changes on SBEMU:
adapted to VDPMI, use IOPL=3
fix random crash on Tyrian exit

VDPMI:
v86 monitor, loaded as driver from config.sys, enable virtual interrupts (VIF+VIP+PVI). it can be executed from command line, see /? for more details.
fix keyboard/mouse driver problem, but there still may be bugs when a usb-mouse is used.
xms2 interception to limit XMS size, HimemX may have its own option, but this can work for Himem.sys
xms move memory function: compatibility workaround for HimemX (SWDA / Xuanyuan Jian Waizhuan: Feng Zhi Wu / 軒轅劍外傳 楓之舞. Himem.sys/JEMMEX is fine with the game)
fix LH/DEVICEHIGH crash when booting from USB. (seen on my laptop, its a bug of the BIOS's USB legacy support/emulation, crash on EMM386 and JEMMEX)
fix Legend (Z.COM / Jinyong Qunxiazhuan / 金庸群俠傳) freeze on USB disk. (same reason above, it will freeze when the game folder is on usbdisk, won't freeze if boot from usb but game folder is on HDD, and, it freeze without any EMM/DPMI)
fix startup-time random crash (divide 0 error) for monkey island (its a bug of monkey island, only exposed on fast CPUs, and on a SB init path, probably produce-able on a P4 cpu with SB compatible PCI cards. hard fixed in v86 monitor)
fix SB detection for Space Quest V (tricky fix through v86 monitor)
fix incorrect SoundFX (noise), for PAL / The Legend of Sword and Fairy / 仙劍奇俠傳, and probably another game which I forgot its tittle.
add compatibility to FastDoom.
a new "VM timing" is added, to exclude the ring 0 time consumed, so that the debug logs won't cause a infinite irq0 deadloop. it is experimental only and may cause games to slowdown or speedup (it's fixed on my laptop, but I doubt its compatibility)

VDPMI will be open-sourced when it reaches a more stable phase.
I'm not sure to start anew a VXD (e.g. from ALSA) or to modify the existing code of SBEMU. it will be a breaking change so currently I'm considering a new port, and keeps the old as it is.

crazii wrote on 2026-04-22, 13:54:

Hi, […]
Show full quote

Hi,

I picked up the VDPMI code in the Lunar New Year, and it's been 2 years so I forgot much about the details, I have to add more comments on the code I written before. after some debug and tests, I found it is extremely difficult to achieve "virtualization" without a v86 monitor; for protected mode games it's OK, but for real mode games, the IVT hooks can be overridden by a real mode program easily. I so spend a couple of months to add a v86 monitor. the changes are so huge that I have to debug it again. now I tested again on my Thinkpad T540p and it works as before, probably with less bugs. But the UMB code is preliminary and may have problems.

The next of my plan will be add EMS for the v86 monitor, and then a VXD sound card driver for win9x to learn the VXD stuff. after that it will be add vmm api to support VXD for vpdmi.
VPCI won't be supported obviously there is DPMI.
VDS for now is not planned, as VDS is mainly for multitasking & page mapped env, and VPDMI provide only 1:1 identity page mapping, and no multi-tasks.
XMS could be considered, but now it's not the priority.

Here are the changes and attached zip.

changes on SBEMU:
adapted to VDPMI, use IOPL=3
fix random crash on Tyrian exit

VDPMI:
v86 monitor, loaded as driver from config.sys, enable virtual interrupts (VIF+VIP+PVI). it can be executed from command line, see /? for more details.
fix keyboard/mouse driver problem, but there still may be bugs when a usb-mouse is used.
xms2 interception to limit XMS size, HimemX may have its own option, but this can work for Himem.sys
xms move memory function: compatibility workaround for HimemX (SWDA / Xuanyuan Jian Waizhuan: Feng Zhi Wu / 軒轅劍外傳 楓之舞. Himem.sys/JEMMEX is fine with the game)
fix LH/DEVICEHIGH crash when booting from USB. (seen on my laptop, its a bug of the BIOS's USB legacy support/emulation, crash on EMM386 and JEMMEX)
fix Legend (Z.COM / Jinyong Qunxiazhuan / 金庸群俠傳) freeze on USB disk. (same reason above, it will freeze when the game folder is on usbdisk, won't freeze if boot from usb but game folder is on HDD, and, it freeze without any EMM/DPMI)
fix startup-time random crash (divide 0 error) for monkey island (its a bug of monkey island, only exposed on fast CPUs, and on a SB init path, probably produce-able on a P4 cpu with SB compatible PCI cards. hard fixed in v86 monitor)
fix SB detection for Space Quest V (tricky fix through v86 monitor)
fix incorrect SoundFX (noise), for PAL / The Legend of Sword and Fairy / 仙劍奇俠傳, and probably another game which I forgot its tittle.
add compatibility to FastDoom.
a new "VM timing" is added, to exclude the ring 0 time consumed, so that the debug logs won't cause a infinite irq0 deadloop. it is experimental only and may cause games to slowdown or speedup (it's fixed on my laptop, but I doubt its compatibility)

VDPMI will be open-sourced when it reaches a more stable phase.
I'm not sure to start anew a VXD (e.g. from ALSA) or to modify the existing code of SBEMU. it will be a breaking change so currently I'm considering a new port, and keeps the old as it is.

Hi,
Intel Haswell system (Z97 chipset): vdpmid.exe freezes without any messages.
Intel Ivy Bridge system (Thinkpad T430) is the same: vdpmid.exe freezes without any messages.
Both systems work with older versions of SBEMU.

BTW, in your package the example CONFIG.SYS file references VDPMI.EXE (DEVICE=VDPMI.EXE) while the proper name is VDPMID.EXE.

Falcosoft wrote on 2026-04-22, 15:02:

Hi, Intel Haswell system (Z97 chipset): vdpmid.exe freezes without any messages. Intel Ivy Bridge system (Thinkpad T430) is the […]
Show full quote

Hi,
Intel Haswell system (Z97 chipset): vdpmid.exe freezes without any messages.
Intel Ivy Bridge system (Thinkpad T430) is the same: vdpmid.exe freezes without any messages.
Both systems work with older versions of SBEMU.

BTW, in your package the example CONFIG.SYS file references VDPMI.EXE (DEVICE=VDPMI.EXE) while the proper name is VDPMID.EXE.

the "vpdmid.exe" was a debug exe 2 years ago, I updated the zip file, sorry for the inconvenience.

Hi, crazii! It's good to have you back.

It's been a while. Thanks for your continued work on this! 😃

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

digger wrote on 2026-04-22, 17:41:

Hi, crazii! It's good to have you back.

It's been a while. Thanks for your continued work on this! 😃

Hi digger, Long time no see!
I remember that you recommend ALSA or OSS for the sound driver, what's your opinion now?

truemaster wrote on 2026-04-23, 15:53:

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

There is no need to reverse engineer it. The code is on github, just not yet released to the public. Besides, VDPMI does not contain any sound card related code, you may consider it as a prototype, combination of "HDPMI+JEMM/EMM386", nothing more.

Did the previously released SBEMU work for your aureal vortex pci ? If SBEMU+VDPMI works now, I think it should work then. The SBEMU I provided here has no sound card driver related changes at all.

if it does not work for you HDA chipset, I guess there could be bugs on the original SBEMU. If VSBHDA works, then I need help by someone who can collect the changes of VSBHDA and create a pull request for SBEMU.

I have been working on a HD Audio driver for Windows 98 but it is WDM not VxD, only supports HD Audio and not any of the other MPXPlay drivers, and only has sound blaster emulation through Microsoft's SBEMUL driver (8 bit digital sound and General MIDI, no OPL).

There is a very preliminary VxD driver for HD Audio on GitHub here that you could use for an example for porting MPXPlay (though it only works on QEMU and the author never clarified the license terms), and besides that there are a few sample files in the Windows 95 DDK.

VxD drivers don't get any OS level support for Sound Blaster or OPL emulation so if you want to provide that, you need to make a port trapping driver using VxD services. There is assembly source code in the download for Alpha 2 of VDMSound for Windows 98 and you could disassemble the VxD provided with Alpha 3 which seems to be the same thing but with more error handling added.

It may not be possible to trap the ports used for the high DMA channels in the 9x DOS box, which is why most software emulation is limited to Sound Blaster Pro.

truemaster wrote on 2026-04-23, 15:53:

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

The Vortex's DOS compatibility depends on hardware on the card to do the I/O port trapping, hardware which is simply not there for HD Audio.

crazii wrote on 2026-04-23, 20:51:

Hi digger, Long time no see!
I remember that you recommend ALSA or OSS for the sound driver, what's your opinion now?

ALSA is likely more actively maintained by a larger group of developers, and will probably support a lot more sound devices, by the virtue of being part of the Linux kernel.

OSS on the other hand is licensed under a number of open source licenses, including 2-clause BSD, which might offer people more freedom in terms of licensing when implementing it in their projects.

OSS might also have a leg up in portability, since it supports multiple operating systems (BSD, Solaris and in the past also Linux). But ALSA drivers might prove not to be that much harder to port in practice.

Since SBEMU is already licensed under GPLv2, my advice would be to go for ALSA.

To give you an idea of the extensive level of maintenance and support of the ALSA drivers in the Linux kernel: the upcoming Linux 7.1 kernel will include an ALSA driver improvement for the AMD InterWave chip that is found in the Utrasound PnP card that came out in 1995. 😅

onethirdxcubed wrote on 2026-04-23, 21:26:

I have been working on a HD Audio driver for Windows 98 but it is WDM not VxD, only supports HD Audio and not any of the other M […]
Show full quote

I have been working on a HD Audio driver for Windows 98 but it is WDM not VxD, only supports HD Audio and not any of the other MPXPlay drivers, and only has sound blaster emulation through Microsoft's SBEMUL driver (8 bit digital sound and General MIDI, no OPL).

There is a very preliminary VxD driver for HD Audio on GitHub here that you could use for an example for porting MPXPlay (though it only works on QEMU and the author never clarified the license terms), and besides that there are a few sample files in the Windows 95 DDK.

VxD drivers don't get any OS level support for Sound Blaster or OPL emulation so if you want to provide that, you need to make a port trapping driver using VxD services. There is assembly source code in the download for Alpha 2 of VDMSound for Windows 98 and you could disassemble the VxD provided with Alpha 3 which seems to be the same thing but with more error handling added.

It may not be possible to trap the ports used for the high DMA channels in the 9x DOS box, which is why most software emulation is limited to Sound Blaster Pro.

truemaster wrote on 2026-04-23, 15:53:

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

The Vortex's DOS compatibility depends on hardware on the card to do the I/O port trapping, hardware which is simply not there for HD Audio.

Thanks for your good guidance. I found your github project sometime ago, and indeed I thought about a WDM, but that may limit its use only on win9x.
I was thinking about a VXD that works on win9x with dsound support, and at the same time, with a possible simple emulation layer of the VMM/VxD API in VDPMI, the same VXD can also work in DOS. It will force to increase the VXD's stability by expanding its use, but at the same time, that idea seems extremely difficult, which is left to test out.

There are also some VXD samples that uses C wrappers, in the book "Writing Windows Virtual Device Drivers", (some online sources available, e.g. https://heha.fwh.is/vxd/vxd_fra.htm). Hopefully it will help me to do it in C code.

Currently VDPMI provides the virtualization of the PIC, the DMA virtualization is still in SBEMU, which should be removed and changed to the VxD API.

digger wrote on 2026-04-23, 22:43:

ALSA is likely more actively maintained by a larger group of developers, and will probably support a lot more sound devices, by […]
Show full quote

crazii wrote on 2026-04-23, 20:51:

Hi digger, Long time no see!
I remember that you recommend ALSA or OSS for the sound driver, what's your opinion now?

ALSA is likely more actively maintained by a larger group of developers, and will probably support a lot more sound devices, by the virtue of being part of the Linux kernel.

OSS on the other hand is licensed under a number of open source licenses, including 2-clause BSD, which might offer people more freedom in terms of licensing when implementing it in their projects.

OSS might also have a leg up in portability, since it supports multiple operating systems (BSD, Solaris and in the past also Linux). But ALSA drivers might prove not to be that much harder to port in practice.

Since SBEMU is already licensed under GPLv2, my advice would be to go for ALSA.

To give you an idea of the extensive level of maintenance and support of the ALSA drivers in the Linux kernel: the upcoming Linux 7.1 kernel will include an ALSA driver improvement for the AMD InterWave chip that is found in the Utrasound PnP card that came out in 1995. 😅

Thanks! That is pretty sound advice.
I will take a close look to ALSA when I finishes the EMS code.

crazii wrote on 2026-04-23, 20:59:

There is no need to reverse engineer it. The code is on github, just not yet released to the public. Besides, VDPMI does not con […]
Show full quote

truemaster wrote on 2026-04-23, 15:53:

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

There is no need to reverse engineer it. The code is on github, just not yet released to the public. Besides, VDPMI does not contain any sound card related code, you may consider it as a prototype, combination of "HDPMI+JEMM/EMM386", nothing more.

Did the previously released SBEMU work for your aureal vortex pci ? If SBEMU+VDPMI works now, I think it should work then. The SBEMU I provided here has no sound card driver related changes at all.

if it does not work for you HDA chipset, I guess there could be bugs on the original SBEMU. If VSBHDA works, then I need help by someone who can collect the changes of VSBHDA and create a pull request for SBEMU.

no im speeking for the aureal dos driver made by aureal back in 2000. this driver works even on new chipsets without any ems or jemm real mode and protected mode support. (unlike creative sblive dos drivers whitch is up to ich5 and needed ems anyways) and the reason i said to reverse enginner it is to see if the sbemu dos driver can achive same treatment

truemaster wrote on 2026-04-24, 04:38:

aureal dos driver made by aureal back in 2000. this driver works even on new chipsets without any ems or jemm real mode and protected mode support.

Unlikely. Afaik Aureal patented ISA DMA emulation using pretty much same methods sbemu is using and requires emm386.

truemaster wrote on 2026-04-24, 04:38:

crazii wrote on 2026-04-23, 20:59:

There is no need to reverse engineer it. The code is on github, just not yet released to the public. Besides, VDPMI does not con […]
Show full quote

truemaster wrote on 2026-04-23, 15:53:

guys aureal vortex pci card has dos audio even on chipset like z97. without any ems or jemm! can this driver reversed engineered and hopefully can be used for hda chipsets?

There is no need to reverse engineer it. The code is on github, just not yet released to the public. Besides, VDPMI does not contain any sound card related code, you may consider it as a prototype, combination of "HDPMI+JEMM/EMM386", nothing more.

Did the previously released SBEMU work for your aureal vortex pci ? If SBEMU+VDPMI works now, I think it should work then. The SBEMU I provided here has no sound card driver related changes at all.

if it does not work for you HDA chipset, I guess there could be bugs on the original SBEMU. If VSBHDA works, then I need help by someone who can collect the changes of VSBHDA and create a pull request for SBEMU.

no im speeking for the aureal dos driver made by aureal back in 2000. this driver works even on new chipsets without any ems or jemm real mode and protected mode support. (unlike creative sblive dos drivers whitch is up to ich5 and needed ems anyways) and the reason i said to reverse enginner it is to see if the sbemu dos driver can achive same treatment

OK, it hardware emulated like onethirdxcubed said. A PCI device can declare IO ports it uses in the IO space, its part of the bus protocol. In this case, 220h is included besides its "normal" pci ports. the card process SB cmd indrectly. The TSR driver is simple, I believe it translate the PCI interrupt or maybe NMI to the SB irq, and other simple tasks. There're other chips probably doing the same, e.g. the SB emulation of VIA VT82C686B.

rasz_pl wrote on 2026-04-24, 05:19:

truemaster wrote on 2026-04-24, 04:38:

aureal dos driver made by aureal back in 2000. this driver works even on new chipsets without any ems or jemm real mode and protected mode support.

Unlikely. Afaik Aureal patented ISA DMA emulation using pretty much same methods sbemu is using and requires emm386.

Aureal DOS driver does NOT require Emm386. Even when the driver is loaded the CPU stays in real mode.
BTW, Aureal DOS driver's OPL emulation is worse than SBEMU's OPL emulation. It emulates only OPL2 and sounds worse in most cases.
And only SB Pro is emulated, SB16 is not.

rasz_pl wrote on 2026-04-24, 05:19:

truemaster wrote on 2026-04-24, 04:38:

aureal dos driver made by aureal back in 2000. this driver works even on new chipsets without any ems or jemm real mode and protected mode support.

Unlikely. Afaik Aureal patented ISA DMA emulation using pretty much same methods sbemu is using and requires emm386.

It's probably similar to Distributed DMA (DDMA) that I see it here at vogons for many times, but I don't know what it is. There is also TDDMA, and maybe more, which I don't know the details either.
All PCI cards use the similar tech, e.g. the ESS Solo-1, C-Media CMI8738, or the YMF PCI cards. the SETUPDS.EXE of the YMF 7x4 PCI driver, has two option: DDMA and PCPCI/SB-Link. PCPCI/SB-Link as we know is a hardware connector on some motherboard and soundcard. It's been said that the SB-Link has a better compatibility. I have a Tualatin board with a SB-Link and it's working good with a YMF724, and another laptop with YMF754 which has good compatibility with PCPCI enabled too.

EDIT: did some search and google AI told me that there is a DSDMA tech which requires EMM386 (still sourced from vogons), but whether it uses VDS (virtual DMA service of emm386) or port-trapping is unknown. because EMM386 doesn't allow trap low IO ports like DMA controller, either there is a backdoor or DSDMA doesn't trap dma ioports.

Wait Aureal, I was thinking Ensoniq. Yes Aureal is most likely DDMA. I think it was Ensoniq with "magic" patented dma emulation. I seem to remember soemthing about firing NMI by the card when it thinks dma should be arriving and TSR reading DMA programmed address? but arent DMA Page Registers write only?
This IBM patent also describes just reading back address from DMA like its nothing https://patents.google.com/patent/US5784595A/en
"The method includes determining the location in the host memory for data to be transferred from the host memory to the accessory card or from the accessory card to the host memory by reading the memory address contents of the DMA controller; reading data from the host memory at the address specified in the DMA controller and writing it to the accessory card or reading data from the accessory card and writing it to the host memory at the address specified by the DMA controller"
it describes it like its nothing
"Read the DMA controller's current address register;
Read the system's page register (this indicates which 64K page of PC memory the DMA controller is pointing to);
Construct the physical address (page=segment, current address=offset);
Read the DMA controller's current word count register;
RETURN with the DMA physical address and the DMA count register;"

if this is possible no virtualization would ever be needed, just a TSR hooked to a timer interrupt

yes aureal emulates only sbpro like all non creative isa sb emulated pci cards. ensoniq was sbpro only till creative bought them out and create an sb16 emulation on ensoniq chips. fm is bad on aureal like you said. but its worth the effort to find out how this tsr driver is made out because of the compatibility on newer chipsets like z97. then ofcource it will need corections to the sound part like better fm and sb16 emulation.