RayeR wrote on Today, 12:00:

Did you write vdpmi from scratch? Maybe could start with cwsdpmi that is mostly in TurboC with some assembly parts. I understand you, for me it's also not easy to read huge asm projects even well documented one, better with C...

Yes. USBDDOS has a minimal "local-builtin DPMI" (extender-like) code and I re-used some of it, adding memory & LDT APIs. compiled by Openwatcom, assembly codes are coupled with watcom register calling convention. it has taken shape and there's no going back to other compiler options. besides TurboC generate less efficient codes although it compiles fast.

The VDPMI core is in pure 32 bit flat model, much more easy and efficient like normal win32/linux programming, with tiny amount of assembly for mode switches and interrupt/exception entries, its optimized memory layout needs the features of the powerful linker - wlink. TurboC on the other hand is a 16bit compiler, despite the fact that it can use 32 bit registers.

the core is linked in dos4gnz mode, but it is not a dos4g(w) program, instead it is a 32bit LX image stubbed with a custom 16bit loader, not using the dos4gw loader.
since the loader can load LE/LX images and the windows VxDs are in LE format, the loader can load VxDs with some fixes & improvements.

crazii wrote on 2026-06-04, 06:46:

UPDATE: […]
Show full quote

UPDATE:

VDPMI:
1.fix ctmouse freeze on installation on some PC, cause by keyboard driver bug
2.bugfix on interception xms2 memory size
3.add CTRL+ALT+DEL handling. previously there is no handling and there is random exception, the reset is probably triggered by triple fault. now vdpmi will switch to real mode instead of v86, and return to BIOS keyboard handler so that it does a normal warmboot.
4.add 64k io cache for loader, mode switches reduced to 1/16 during loading compared with no io cache
5.fix duke3d stutter. obvious in its setup.exe. caused by a bug that pending IRQs (here it is the virtual sb irq, 5 or 7) not immediately handled on STI (or equivalent).
There will still be a stutter on the first time for setup.exe, it is caused by PVI and setup uses "pushf" "cli" "popf" and "popf" doesn't restore VIF in PVI mode (unlike in v86 mode). so there is a dead lock. the deadlock is detected and forced a VIF=1 with a timeout. vdpmi will disable PVI dynamically on frequent deadlocks. before PVI is turned off, the VIF=0 will prevent sb irq 5/7 to be handled, so dma buffer not updated by program, and sbemu plays the same content in DMA buffer until VIF=1 (stuttering). may be a PVI switch will be added so that the stutter can be gone for good.
EDIT: 6. hard fix/hotpatch for the Jungle book "divide by 0" error, probably cause by timing. unlike the hard fix for monkey island, which is clear with its disassembly, the reason of crash for jungle is still unknown, the code path is complicated so this is a temporary fix, until the real reason is found.

SBEMU:
1.bugfix on FIXTC, enable FIXTC by default. improves playback stability. it may cause slightly incorrect pitch, notably in LIONKING (intro music etc.).
2.revert resample code to 1.0beta3, the beta3 code has better buffer size alignment (e.g. 11111 Hz to 22050 Hz, size will double so that it fit the sound buffer better)
3.imrpove VIA / ICH sound playback, SFX artifacts removed for Doom, now the playback is much more stable. this works with change (2), but not necessarily depends on change (1).
4.bugfix on OPL active check.
EDIT: the OPL volume amplification (x2) is removed, but not merged to main branch yet.

I believe the SFX stability is much better now, at least, it is no worse than the beta3 build. those SBEMU changes also merge from vdpmi branch to the main branch, with a 1.0beta6rc2 release (information updated in OP in this thread).

Special thanks to Yacko83 who helps with the tests with patience and keen perception.

The attachment SBEMU_VDPMI_03.zip is no longer available

Did some tests with this VDPMI version. It's on my X99 system using actual CT2950 behind dISAppointment so I'm not using SBEMU in this context.
1. /EMSX works and doesn't crash my system. MEM reports having about 4096KB of EMS and I have access to much more UMB than usual. I don't have tools to comprehensively validate EMS functionality, however.
2. /MV option doesn't work and hangs the system with it. /I=B000-B7FF has no effect so I think VDPMI's /I is not meant for the monochrome region (which is /MV's responsibility).
3. Most real mode games work without issues. Protected mode games (e.g. those with DOS4GW extenders) are hit-or-miss. Astrofire/Terrafire (DOS4GW) would crash outright with a VDPMI exception.
4. Not sure if it's related to the CTRL-ALT-DEL handler, but I do notice that I need to do CTRL-ALT-DEL twice to perform a warmboot. The first CTRL-ALT-DEL would make the command prompt hang, unable to type anything, and a second CTRL-ALT-DEL warm reboots the system. This is at least observed on MS-DOS 7.10 (Win98SE) kernel.
5. Duke3D does work without crashing, though I do notice some kind of stutter in-game, while the demo is playing. I only tested Duke3D briefly, and I'm not sure if the stutter is caused by VDPMI or other hardware issues (e.g. video card's VESA quirks).

My tests are done on both MS-DOS 7.10 (Win98SE) and FreeDOS kernels. I can try booting some other DOS kernels with the help of lDebug but I haven't set it up at the moment.
The UMB amount reported by MEM kind of differs between MS-DOS and FreeDOS with VDPMI.
- With MS-DOS it shows about 94KB of UMB available, with kernel itself taking 29KB of conventional and no UMB.
- With FreeDOS it shows about 192KB of UMB available, with kernel itself taking ~106KB of it. That extra amount of UMB reported and marked as taken by the kernel is likely a mistake, as the kernel actually takes about 11KB UMB when using JEMMEX/JEMM386, with which the actual amount of available UMB is correctly reported. This issue is mostly cosmetic as the actually usable UMB area is the same.

Issues with protected mode games are not important for the time being, as from my experience, the safest way would be to launch them from an environment without any EMM or UMBPCI. Xeon E5 family architectures can't work with UMBPCI unfortunately (while Xeon E3 of those generations can).

LSS10999 wrote on Today, 15:09:

Did some tests with this VDPMI version. It's on my X99 system using actual CT2950 behind dISAppointment so I'm not using SBEMU i […]
Show full quote

crazii wrote on 2026-06-04, 06:46:

UPDATE: […]
Show full quote

UPDATE:

VDPMI:
1.fix ctmouse freeze on installation on some PC, cause by keyboard driver bug
2.bugfix on interception xms2 memory size
3.add CTRL+ALT+DEL handling. previously there is no handling and there is random exception, the reset is probably triggered by triple fault. now vdpmi will switch to real mode instead of v86, and return to BIOS keyboard handler so that it does a normal warmboot.
4.add 64k io cache for loader, mode switches reduced to 1/16 during loading compared with no io cache
5.fix duke3d stutter. obvious in its setup.exe. caused by a bug that pending IRQs (here it is the virtual sb irq, 5 or 7) not immediately handled on STI (or equivalent).
There will still be a stutter on the first time for setup.exe, it is caused by PVI and setup uses "pushf" "cli" "popf" and "popf" doesn't restore VIF in PVI mode (unlike in v86 mode). so there is a dead lock. the deadlock is detected and forced a VIF=1 with a timeout. vdpmi will disable PVI dynamically on frequent deadlocks. before PVI is turned off, the VIF=0 will prevent sb irq 5/7 to be handled, so dma buffer not updated by program, and sbemu plays the same content in DMA buffer until VIF=1 (stuttering). may be a PVI switch will be added so that the stutter can be gone for good.
EDIT: 6. hard fix/hotpatch for the Jungle book "divide by 0" error, probably cause by timing. unlike the hard fix for monkey island, which is clear with its disassembly, the reason of crash for jungle is still unknown, the code path is complicated so this is a temporary fix, until the real reason is found.

SBEMU:
1.bugfix on FIXTC, enable FIXTC by default. improves playback stability. it may cause slightly incorrect pitch, notably in LIONKING (intro music etc.).
2.revert resample code to 1.0beta3, the beta3 code has better buffer size alignment (e.g. 11111 Hz to 22050 Hz, size will double so that it fit the sound buffer better)
3.imrpove VIA / ICH sound playback, SFX artifacts removed for Doom, now the playback is much more stable. this works with change (2), but not necessarily depends on change (1).
4.bugfix on OPL active check.
EDIT: the OPL volume amplification (x2) is removed, but not merged to main branch yet.

I believe the SFX stability is much better now, at least, it is no worse than the beta3 build. those SBEMU changes also merge from vdpmi branch to the main branch, with a 1.0beta6rc2 release (information updated in OP in this thread).

Special thanks to Yacko83 who helps with the tests with patience and keen perception.

The attachment SBEMU_VDPMI_03.zip is no longer available

Did some tests with this VDPMI version. It's on my X99 system using actual CT2950 behind dISAppointment so I'm not using SBEMU in this context.
1. /EMSX works and doesn't crash my system. MEM reports having about 4096KB of EMS and I have access to much more UMB than usual. I don't have tools to comprehensively validate EMS functionality, however.
2. /MV option doesn't work and hangs the system with it. /I=B000-B7FF has no effect so I think VDPMI's /I is not meant for the monochrome region (which is /MV's responsibility).
3. Most real mode games work without issues. Protected mode games (e.g. those with DOS4GW extenders) are hit-or-miss. Astrofire/Terrafire (DOS4GW) would crash outright with a VDPMI exception.
4. Not sure if it's related to the CTRL-ALT-DEL handler, but I do notice that I need to do CTRL-ALT-DEL twice to perform a warmboot. The first CTRL-ALT-DEL would make the command prompt hang, unable to type anything, and a second CTRL-ALT-DEL warm reboots the system. This is at least observed on MS-DOS 7.10 (Win98SE) kernel.
5. Duke3D does work without crashing, though I do notice some kind of stutter in-game, while the demo is playing. I only tested Duke3D briefly, and I'm not sure if the stutter is caused by VDPMI or other hardware issues (e.g. video card's VESA quirks).

My tests are done on both MS-DOS 7.10 (Win98SE) and FreeDOS kernels. I can try booting some other DOS kernels with the help of lDebug but I haven't set it up at the moment.
The UMB amount reported by MEM kind of differs between MS-DOS and FreeDOS with VDPMI.
- With MS-DOS it shows about 94KB of UMB available, with kernel itself taking 29KB of conventional and no UMB.
- With FreeDOS it shows about 192KB of UMB available, with kernel itself taking ~106KB of it. That extra amount of UMB reported and marked as taken by the kernel is likely a mistake, as the kernel actually takes about 11KB UMB when using JEMMEX/JEMM386, with which the actual amount of available UMB is correctly reported. This issue is mostly cosmetic as the actually usable UMB area is the same.

Issues with protected mode games are not important for the time being, as from my experience, the safest way would be to launch them from an environment without any EMM or UMBPCI. Xeon E5 family architectures can't work with UMBPCI unfortunately (while Xeon E3 of those generations can).

Thanks for the feedback!

Yes /EMSX will give you 64K more UMB than /EMS, like the amount of UMB without EMS support. /EMSX or /EMS is not actually effective unless you run a program that uses EMS, e.g. Aladdin.
I will do more test with /MV and /I /X options, and Ctr+alt+del. the /I option should work with address above A000, so /I=b000-b7fff should equivalent to /MV. I guess there're bugs. /MV is just an easy switch and added early than /I support.
I haven't tested on FreeDOS yet. would do that when it's more stable on MSDOS. Currently I tested it on three machines with MSDOS6.22 and 7.1 (Win98SE boot disk without the win98 system installed), the problems you encountered doesn't not exist on those machines, there should be unhandled corner cases for different BIOSes.
the duke3d stutter is probably caused by VDPMI, and another switch /PVI is added, it will help that with /PVI=0

BTW DPMI may help DOS4GW on Athlon CPUs. As I tested with my HP T5720 thin client with a embedded Athlon (GeodeNX), without DPMI/EMM, duke3d just crashes with some corrupted game messages.
the Athlon CPU (or the same Thoroughbred core) has a known TLB bug for 4M page tables.

LSS10999 wrote on Today, 15:09:

2. /MV option doesn't work and hangs the system with it. /I=B000-B7FF has no effect so I think VDPMI's /I is not meant for the monochrome region (which is /MV's responsibility).

I found a bug if "/MV" is used. I've been refactor the command line parser recently and if "/MV" is used, the starting address is 1 (/MV=1) instead of b000 which will cause a freeze. 🤣. the value should be clamped to b000-b700, I do it like 'clamp(x,min,max)' without assignment, but it should be 'x=clamp(x, min, max)' 🤣.

by default /MV is set to b000 (enabled), so if you don't specify /MV, it should be turned on by default. I will do more test and check the code.
EDIT: I checked that /I=b000-b7ff works and you may want to check mem.exe /d/p, initially some LH drivers and COMMAND.COM will be shown at address 0B000.