New update:

SBEMU changes:
1.stereo swap added. It was discussed long time ago, but I was reluctant to add this, because in a way it is a historical problem of the legacy SB cards.
2.FIXTC changed to threshold, default 1000 (Hz), if the difference between fixed sample rate (22050/11025) and samplereate by game is larger than 1000, game setting will be used. this fixes the lionking pitch/speed problem.

VDPMI changes:
1. /PVI is added. by default is ENABLED. try disabling it (/PVI=0) to remove some stuttering
2.bugfix on /MV (freeze if /MV=1 is set)
3.add int67h ax=FFA5h, get EMM386 entry point function. Now terrafire works.
4.v86 driver entrance bugfix, not fully done yet.
5.Ctrl+Alt+Del: fix jumping to realmode: IF not turned of
6.replace watcom c runtime lib (16 bit loader only). the 32bit core does not link with 32bit c runtime. only the loader links with c runtime. technically the GPL and OWPL are not compatible. to get a fully GPL compatible binary to release "legally", a custom implementation of a small portion of c runtime/startup code is used to fully remove the ow library dependency.

updated bugfix:

crazii wrote on 2026-06-11, 06:48:

What's your disk's FS, FAT16 or FAT32? I think there could be bugs.

I tried both FAT16 on small flashdisk under MSDOS 6.22 and FAT32 on 4GB under MSDOS7. When I run chkdsk on such drive it reported lot of lost clusters. When I use the same flashdisk on older PC with Panasonic USB ASPI driver it works fine, scandisk reports no errors. BTW does your driver properly handling the partition table on flashdisk or it expects just start with FS bootsector (big floppy mode, no partititon)?

crazii wrote on 2026-06-11, 07:12:

New update: […]
Show full quote

New update:

SBEMU changes:
1.stereo swap added. It was discussed long time ago, but I was reluctant to add this, because in a way it is a historical problem of the legacy SB cards.
2.FIXTC changed to threshold, default 1000 (Hz), if the difference between fixed sample rate (22050/11025) and samplereate by game is larger than 1000, game setting will be used. this fixes the lionking pitch/speed problem.

VDPMI changes:
1. /PVI is added. by default is ENABLED. try disabling it (/PVI=0) to remove some stuttering
2.bugfix on /MV (freeze if /MV=1 is set)
3.add int67h ax=FFA5h, get EMM386 entry point function. Now terrafire works.
4.v86 driver entrance bugfix, not fully done yet.
5.Ctrl+Alt+Del: fix jumping to realmode: IF not turned of
6.replace watcom c runtime lib (16 bit loader only). the 32bit core does not link with 32bit c runtime. only the loader links with c runtime. technically the GPL and OWPL are not compatible. to get a fully GPL compatible binary to release "legally", a custom implementation of a small portion of c runtime/startup code is used to fully remove the ow library dependency.

The attachment SBEMU_VDPMI_05.zip is no longer available

Tested this VDPMI version and noticed these things:
- CTMOUSE cannot load, citing unable to find my PS/2 mouse with this VDPMI version. I do not recall seeing this issue with previous version.
- CTRL-ALT-DEL problem still persists. No difference with previous version.
- /MV is not enabled by default. It seems /MV=B000 does not work, but /MV will.
- When /MV is not enabled, FreeDOS MEM does not report that 100KB "system code" block as used UMB. When /MV is enabled, the 100KB "system code" block will show up in FreeDOS MEM.
- When using /I=B000-B7FF instead of /MV, it still only covers to B6FF, per (FreeDOS) MEM /D/P, with the rest being marked as "system code" until D000.
- Pretty much all DOS4GW apps (not just AstroFire/TerraFire) crash with a VDPMI Server exception. AstroFire/TerraFire SETUP works without issues, though.

I wonder if some of those regressions were caused by removing the Watcom C library...

Here's what I got regarding the VDPMI Server exception crash.

1VDPMI Server Exception: 0d, Error: d3ac
2EAX:00004800 EBX:00000040 ECX:0000f0ac EDX:00000000 ESI:000007d8 EDI:0000146c
3ESP:000014f8 DS:0020 ES:0020 GS:0000 FS:0008 CR2:00000000 VISR=0000
4SS:ESP:0020:0000ed64 CS:EIP:0010:0050cf73 EFLAGS:00010002 VM=0 IF=0 VIF=0 VIP=0
5DS: base: 008ff000 limit: 00524fff ES: base: 008ff000 limit: 00524fff
6SS: base: 008ff000 limit: 00524fff CS: base: 008ff000 limit: 00524fff
7CS:EIP(0002:00001f73): cf 00 00 00 00 00 00 00 00 00 00 00 00 50 8b 44
8SS:ESP: 00000104 0000d3af 00000000 00004b4e *00001168* 0000008f 00000097 00000000
900000000 0000146c 000007d8 000014f8
10Exiting with error: 800dd3ac

NOTE: I marked a value with * on both sides (since bold doesn't work inside "code" blocks). This particular value differs across different DOS4GW programs, while the rest of the error message (including values) is identical.

RayeR wrote on 2026-06-11, 13:55:

crazii wrote on 2026-06-11, 06:48:

What's your disk's FS, FAT16 or FAT32? I think there could be bugs.

I tried both FAT16 on small flashdisk under MSDOS 6.22 and FAT32 on 4GB under MSDOS7. When I run chkdsk on such drive it reported lot of lost clusters. When I use the same flashdisk on older PC with Panasonic USB ASPI driver it works fine, scandisk reports no errors. BTW does your driver properly handling the partition table on flashdisk or it expects just start with FS bootsector (big floppy mode, no partititon)?

The driver is a DOS block device that maps partitions into dos drives. so the mounted drive has no partition table. only partition boot sector. I never runs scandisk on it - I didn't know if it supports that. but for sure it does not support fdisk. because there is no BIOS emulation, it's only at dos level.

LSS10999 wrote on 2026-06-11, 16:15:

- CTMOUSE cannot load, citing unable to find my PS/2 mouse with this VDPMI version. I do not recall seeing this issue with previ […]
Show full quote

- CTMOUSE cannot load, citing unable to find my PS/2 mouse with this VDPMI version. I do not recall seeing this issue with previous version.
- CTRL-ALT-DEL problem still persists. No difference with previous version.

I wonder if some of those regressions were caused by removing the Watcom C library...

Here's what I got regarding the VDPMI Server exception crash.

Copy code to clipboard

1VDPMI Server Exception: 0d, Error: d3ac
2EAX:00004800 EBX:00000040 ECX:0000f0ac EDX:00000000 ESI:000007d8 EDI:0000146c
3ESP:000014f8 DS:0020 ES:0020 GS:0000 FS:0008 CR2:00000000 VISR=0000
4SS:ESP:0020:0000ed64 CS:EIP:0010:0050cf73 EFLAGS:00010002 VM=0 IF=0 VIF=0 VIP=0
5DS: base: 008ff000 limit: 00524fff ES: base: 008ff000 limit: 00524fff
6SS: base: 008ff000 limit: 00524fff CS: base: 008ff000 limit: 00524fff
7CS:EIP(0002:00001f73): cf 00 00 00 00 00 00 00 00 00 00 00 00 50 8b 44
8SS:ESP: 00000104 0000d3af 00000000 00004b4e *00001168* 0000008f 00000097 00000000
900000000 0000146c 000007d8 000014f8
10Exiting with error: 800dd3ac

NOTE: I marked a value with * on both sides (since bold doesn't work inside "code" blocks). This particular value differs across different DOS4GW programs, while the rest of the error message (including values) is identical.

There is severe bug on the Ctrl+Alt+Del fix. I will update the zip soon.

LSS10999 wrote on 2026-06-11, 16:15:

- /MV is not enabled by default. It seems /MV=B000 does not work, but /MV will.

The /MV problem will be fixed. it is indeed caused by the new c runtime lib replacement, strtoul implmentation. Sorry for the inconvenience, 🤣

LSS10999 wrote on 2026-06-11, 16:15:

- When using /I=B000-B7FF instead of /MV, it still only covers to B6FF, per (FreeDOS) MEM /D/P, with the rest being marked as "system code" until D000.

VDPMI itself will use 4K UMB, located on the smallest UMB block, in the highest address of that block. As I tested, it could be the b700-b7ff in that case. it is allocated before handling all UMBs to DOS.
For FreeDOS currently it is not tested yet, please wait a while after some improvement on SBEMU is done.

The bugfix build is updated in the SBEMU_VDPMI_05.zip.

crazii wrote on 2026-06-12, 02:04:

There is severe bug on the Ctrl+Alt+Del fix. I will update the zip soon. […]
Show full quote

LSS10999 wrote on 2026-06-11, 16:15:

- CTMOUSE cannot load, citing unable to find my PS/2 mouse with this VDPMI version. I do not recall seeing this issue with previ […]
Show full quote

- CTMOUSE cannot load, citing unable to find my PS/2 mouse with this VDPMI version. I do not recall seeing this issue with previous version.
- CTRL-ALT-DEL problem still persists. No difference with previous version.

I wonder if some of those regressions were caused by removing the Watcom C library...

Here's what I got regarding the VDPMI Server exception crash.

Copy code to clipboard

1VDPMI Server Exception: 0d, Error: d3ac
2EAX:00004800 EBX:00000040 ECX:0000f0ac EDX:00000000 ESI:000007d8 EDI:0000146c
3ESP:000014f8 DS:0020 ES:0020 GS:0000 FS:0008 CR2:00000000 VISR=0000
4SS:ESP:0020:0000ed64 CS:EIP:0010:0050cf73 EFLAGS:00010002 VM=0 IF=0 VIF=0 VIP=0
5DS: base: 008ff000 limit: 00524fff ES: base: 008ff000 limit: 00524fff
6SS: base: 008ff000 limit: 00524fff CS: base: 008ff000 limit: 00524fff
7CS:EIP(0002:00001f73): cf 00 00 00 00 00 00 00 00 00 00 00 00 50 8b 44
8SS:ESP: 00000104 0000d3af 00000000 00004b4e *00001168* 0000008f 00000097 00000000
900000000 0000146c 000007d8 000014f8
10Exiting with error: 800dd3ac

NOTE: I marked a value with * on both sides (since bold doesn't work inside "code" blocks). This particular value differs across different DOS4GW programs, while the rest of the error message (including values) is identical.

There is severe bug on the Ctrl+Alt+Del fix. I will update the zip soon.

LSS10999 wrote on 2026-06-11, 16:15:

- /MV is not enabled by default. It seems /MV=B000 does not work, but /MV will.

The /MV problem will be fixed. it is indeed caused by the new c runtime lib replacement, strtoul implmentation. Sorry for the inconvenience, 🤣

LSS10999 wrote on 2026-06-11, 16:15:

- When using /I=B000-B7FF instead of /MV, it still only covers to B6FF, per (FreeDOS) MEM /D/P, with the rest being marked as "system code" until D000.

VDPMI itself will use 4K UMB, located on the smallest UMB block, in the highest address of that block. As I tested, it could be the b700-b7ff in that case. it is allocated before handling all UMBs to DOS.
For FreeDOS currently it is not tested yet, please wait a while after some improvement on SBEMU is done.

The bugfix build is updated in the SBEMU_VDPMI_05.zip.

Did a quick test of the updated build:
- CTMOUSE now loads.
- CTRL-ALT-DEL still not fixed.
- StarGunner (freeware version) crashes with a VM86 exception 06, error 0000.

Looks like sound is broken in most protected mode games (music is fine). I'm using a real CT2950, not SBEMU.
- No sound with AstroFire/TerraFire. SETUP complains about bad DMA setting.

EDIT: The next two issues will manifest if AstroFire/TerraFire or other similar games have been run before. Will post the details on a new reply.
- DUKE3D fails with error on sound init.
- Sound only plays briefly (like about 0.5s) in Terminal Velocity.

All those games work correctly when using JEMMEX/JEMM386.

On the other hand, no difference in behavior observed in real mode games like WOLF3D-based ones at the moment.
Sound works in DIGPAK SDK also but MIDI playback seems to stutter a bit with and without /PVI=0.

Tests were done on FreeDOS at the moment. In most cases VDPMI behaves the same in both FreeDOS and MS-DOS.
The 100KB used "system code" UMB block can be seen on MS-DOS as well, if using FreeDOS' MEM instead of the one from MS-DOS.

LSS10999 wrote on 2026-06-12, 05:08:

- StarGunner (freeware version) crashes with a VM86 exception 06, error 0000. […]
Show full quote

- StarGunner (freeware version) crashes with a VM86 exception 06, error 0000.

Looks like sound is broken in most protected mode games (music is fine). I'm using a real CT2950, not SBEMU.
- No sound with AstroFire/TerraFire. SETUP complains about bad DMA setting.
- DUKE3D fails with error on sound init. However, it seems to run fine with /PVI=0 though I'm not sure if this option really works.
- Sound only plays briefly (like about 0.5s) in Terminal Velocity.

I haven't tested it without SBEMU, if without it, then all other services could be needed. e.g. the VDS (virtual DMA service), which is not implemented yet.

I will do more test on those games. and add new services when it is more stable.

BTW PVI has no effect on real mode games, I think it is another problem with wolf3d.

crazii wrote on 2026-06-12, 05:40:

BTW PVI has no effect on real mode games, I think it is another problem with wolf3d.

Wolf3D-based games are fine. No issues.

The MIDI stutter (playback being a bit slow) was observed in DIGPAK SDK's MENU sample program.

To be precise, the MIDI portion is called MIDPAK, and the MENU sample program can be used to test both DIGPAK and MIDPAK functionality.

LSS10999 wrote on 2026-06-12, 06:21:

Wolf3D-based games are fine. No issues. […]
Show full quote

crazii wrote on 2026-06-12, 05:40:

BTW PVI has no effect on real mode games, I think it is another problem with wolf3d.

Wolf3D-based games are fine. No issues.

The MIDI stutter (playback being a bit slow) was observed in DIGPAK SDK's MENU sample program.

To be precise, the MIDI portion is called MIDPAK, and the MENU sample program can be used to test both DIGPAK and MIDPAK functionality.

OK. There's still a long way to go. 😁

Yuck.

The amd based asus ultrabook I resurrected is only missing pc speaker functionality.

Video wise, it has odd judder with jazz jackrabbit, but gets over 60fps on quake in vesa modes (with mtrr enabled)

I use it with vsbhda and svardos.
if I get an option to turn pcspeaker pins on for the hda audio with sbemu, i'd switch. (This lacks any kind of legacy pc beeper, so this pin getting enabled is the only possible way to have that. I can enable the pin in linux, and it works there after doing so. But the csm does not enable it on boot)

It needs a new cpu fan. The original one has worn bearings that I 'placated' with sprayable white lithium grease mixed with ronsonol lighter fluid in a syringe. (Lets me apply a very very thin coating, since the lighter fluid evaporates).

Now it just has a low buzz instead of shrieks and death rattles, but it is still doomed. I should look into a higher airflow replacement.

wierd_w wrote on 2026-06-12, 13:06:

(This lacks any kind of legacy pc beeper, so this pin getting enabled is the only possible way to have that. I can enable the pin in linux, and it works there after doing so. But the csm does not enable it on boot)

I remember there is a pc-speaker config in the datasheet. it can be checked .

LSS10999 wrote on 2026-06-12, 05:08:

- StarGunner (freeware version) crashes with a VM86 exception 06, error 0000.

Just debugged stargunner and its setup, and found 3 problems in vdpmi: 1) int67h ax=de00h, VCPI detection bug, VCPI is not supported but shouldn't crash on it, 2) reading cr0 not handled for v86, 3) DPMI memory resize bug.
it now runs with SBEMU.

Maybe I can try to add VDS and test VDPMI on a real SB/compatible machine later. the MIDI stutter problem could be related to timer handling.

EDIT: I think most PM games don't use VDS, but needs to check. Did duke3d have SFX on the last build (SBEMU_VDPMI_04.zip)? now it only init sound successfully with /PVI=0? There could be another bug between the #04 and 05 zip, that prevents the PM games using DMA.

crazii wrote on 2026-06-12, 17:01:

EDIT: I think most PM games don't use VDS, but needs to check. Did duke3d have SFX on the last build (SBEMU_VDPMI_04.zip)? now it only init sound successfully with /PVI=0? There could be another bug between the #04 and 05 zip, that prevents the PM games using DMA.

I don't recall there's a SBEMU_VDPMI_04 build in this thread... the one I initially used was this one which was the latest at that time.

AFAIK DUKE3D did not have any issue with it. Sound worked fine there. The stutter I experienced was due to other reasons (namely sound quality settings).

LSS10999 wrote on Yesterday, 01:34:

crazii wrote on 2026-06-12, 17:01:

EDIT: I think most PM games don't use VDS, but needs to check. Did duke3d have SFX on the last build (SBEMU_VDPMI_04.zip)? now it only init sound successfully with /PVI=0? There could be another bug between the #04 and 05 zip, that prevents the PM games using DMA.

I don't recall there's a SBEMU_VDPMI_04 build in this thread... the one I initially used was this one which was the latest at that time.

AFAIK DUKE3D did not have any issue with it. Sound worked fine there. The stutter I experienced was due to other reasons (namely sound quality settings).

OK. SBEMU_VDPMI_04 was posted on github only. can you test the the SBEMU_VDPMI_03 to see if it has sounds for other pm games? except terrafire/stargunner which will crash for sure. if it works for the sb DMA, then there should be some weird changes affecting the result.

BTW the PVI should be effective, it is a simple flag that set/reset the PVI big of CR4, as I tested and also tested by Yacko83, the duke3d setup's obvious one-time stutter is gone with /PVI=0 and with SBEMU.

crazii wrote on Yesterday, 01:55:

LSS10999 wrote on Yesterday, 01:34:

crazii wrote on 2026-06-12, 17:01:

EDIT: I think most PM games don't use VDS, but needs to check. Did duke3d have SFX on the last build (SBEMU_VDPMI_04.zip)? now it only init sound successfully with /PVI=0? There could be another bug between the #04 and 05 zip, that prevents the PM games using DMA.

I don't recall there's a SBEMU_VDPMI_04 build in this thread... the one I initially used was this one which was the latest at that time.

AFAIK DUKE3D did not have any issue with it. Sound worked fine there. The stutter I experienced was due to other reasons (namely sound quality settings).

OK. SBEMU_VDPMI_04 was posted on github only. can you test the the SBEMU_VDPMI_03 to see if it has sounds for other pm games? except terrafire/stargunner which will crash for sure. if it works for the sb DMA, then there should be some weird changes affecting the result.

BTW the PVI should be effective, it is a simple flag that set/reset the PVI big of CR4, as I tested and also tested by Yacko83, the duke3d setup's obvious one-time stutter is gone with /PVI=0 and with SBEMU.

Did some detailed tests (both MS-DOS and FreeDOS) and discovered something. I've edited the previous report to reflect this.
(EDIT: The previous 03 build behaves the same way with the updated 05 build, in places that didn't crash back then.)

If I run Terminal Velocity or DUKE3D right after boot, both games will work fine. /PVI has little to do with it.

However, if AstroFire/TerraFire or other similar protected mode games have been run before (and without sound there), then audio is broken for pretty much everything protected-mode.
- Terminal Velocity will only play sound for a brief moment before going silent.
- DUKE3D (1.3d) fails to init the sound card complaining about IRQ. I previously tested with EDUKE which simply reported error when initializing sound card without further explanation.

So I suspect these protected mode games may have modified something regarding system IRQ in a way that left the system in a broken state, while DUKE3D and Terminal Velocity behaved correctly.
Since Terminal Velocity can output sound for a bit, I think DMA is still fine. It's the IRQ that was broken. Optionally, IRQ-related tests in SBDIAG all fail in this condition.

And there's another issue with VDPMI, regarding Tyrian 2000.
- In SETUP, keyboard feels very, very sluggish.
- The game can start and show the XSIV Games logo, but keyboard no longer responds at all. The game probably did not hang, though.

(PS: I used a modded EDID dongle to force everything including DOS to 144Hz, and I do recall Tyrian 2000 behaves negatively with unusual refresh rates regarding music playback but the game itself works fine even using the hidden "Wild" detail mode.)

LSS10999 wrote on Yesterday, 03:03:

However, if AstroFire/TerraFire or other similar protected mode games have been run before (and without sound there), then audio […]
Show full quote

However, if AstroFire/TerraFire or other similar protected mode games have been run before (and without sound there), then audio is broken for pretty much everything protected-mode.
- Terminal Velocity will only play sound for a brief moment before going silent.
- DUKE3D (1.3d) fails to init the sound card complaining about IRQ. I previously tested with EDUKE which simply reported error when initializing sound card without further explanation.

So I suspect these protected mode games may have modified something regarding system IRQ in a way that left the system in a broken state, while DUKE3D and Terminal Velocity behaved correctly.
Since Terminal Velocity can output sound for a bit, I think DMA is still fine. It's the IRQ that was broken. Optionally, IRQ-related tests in SBDIAG all fail in this condition.

Thank you for the tests.
It seems that it breaks the states of VDPMI but I can't think of any states related to such irq behavior.

LSS10999 wrote on Yesterday, 03:03:

And there's another issue with VDPMI, regarding Tyrian 2000. - In SETUP, keyboard feels very, very sluggish. - The game can star […]
Show full quote

And there's another issue with VDPMI, regarding Tyrian 2000.
- In SETUP, keyboard feels very, very sluggish.
- The game can start and show the XSIV Games logo, but keyboard no longer responds at all. The game probably did not hang, though.

(PS: I used a modded EDID dongle to force everything including DOS to 144Hz, and I do recall Tyrian 2000 behaves negatively with unusual refresh rates regarding music playback but the game itself works fine even using the hidden "Wild" detail mode.)

Another compatible issue I guess. I was using the tyrian binary from GOG and there was a delayed/incorrect keyboard in game once, after some VDPMI code changes. I though I had fixed it. the game and setup is fine with my T5720/T5530 and laptop now, only a little bit slower music in game compared to ESC menu on think clients, probably due to slow CPUs (800MHz/1GHz).
Is the 144Hz applied to the system timer too, or only the monitor?

crazii wrote on Yesterday, 10:04:

Is the 144Hz applied to the system timer too, or only the monitor?

I think it's only the monitor. Most games (e.g. Wolf3D, Skyroads) do not misbehave with high monitor refresh rates but there are a few that do.

Affected games that I know:
- Jazz Jackrabbit's in-game speed is tied to refresh rate so everything is very fast. Need to turn on "Slow Motion" option to make it normal. Menu and cinematics are fine.
- Stargunner behaves similar to Jazz Jackrabbit. Need to set the game speed to "Slow" in options to make in-game speed normal. Menu and cinematics are fine there as well.
- Arya Vaiv (a vertical shooting game) seems to be completely tied to monitor refresh rate while in-game. Both music and gameplay run very fast with such high refresh rate. Main menu is fine, however.
- Tyrian 2000's music kind of hangs with high refresh rate, though sound effects are fine and gameplay speed is normal. Music can be played normally when the refresh rate is at 60-75Hz.