RayeR wrote on 2026-06-06, 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 2026-06-06, 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 2026-06-06, 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.

LSS10999 wrote on 2026-06-06, 15:09:

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.

I tested Astrofire it works fine, will test it on more machines.

Terrafire calls int67h ax=FFA5h, EMM386 get entry point which is not implemented, the return address is not set, probably 0 or random invalid. I've added the functions and it works now.
https://mirror.cs.msu.ru/oldlinux.org/Linux.o … tml/rb-7507.htm

the problem is on v86 monitor (EMM) not DPMI, I believe the VDPMI exception you saw was a "VDPMI VM86 Exception" (usually v86 related but might be DPMI bug), not a Client exception (definitely DPMI) or Server exception (core ring0 exception).

crazii wrote on 2026-06-06, 17:57:

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 i […]
Show full quote

LSS10999 wrote on 2026-06-06, 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.

It seems if I add /MV=B000 VDPMI will not crash the system, but it still doesn't make any difference.
Further inspection with MEM /D/P revealed that VDPMI might have always enabled the B000-B7FF region, as with or without /MV=B0o0 there are stuffs in that area.

Additionally, it seems MS-DOS MEM and FreeDOS MEM behave very differently in this aspect. If I try FreeDOS MEM with MS-DOS 7.10 kernel it reports 192KB of UMB with about 100KB used by kernel, just like what I observed in FreeDOS. The excessive amount of UMB is not reported by FreeDOS MEM when using JEMMEX/JEMM386.

crazii wrote on Yesterday, 01:05:

I tested Astrofire it works fine, will test it on more machines. […]
Show full quote

LSS10999 wrote on 2026-06-06, 15:09:

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.

I tested Astrofire it works fine, will test it on more machines.

Terrafire calls int67h ax=FFA5h, EMM386 get entry point which is not implemented, the return address is not set, probably 0 or random invalid. I've added the functions and it works now.
https://mirror.cs.msu.ru/oldlinux.org/Linux.o … tml/rb-7507.htm

the problem is on v86 monitor (EMM) not DPMI, I believe the VDPMI exception you saw was a "VDPMI VM86 Exception" (usually v86 related but might be DPMI bug), not a Client exception (definitely DPMI) or Server exception (core ring0 exception).

Sorry I didn't take note of the exception detail back then. All I remembered was that VDPMI printed a bunch of register states... I think it might indeed be what you described.

However, I think it might be an edge case, as when I tried Astrofire and Terrafire today (with and without /MV=B000), I could no longer reproduce that issue. Both games ran fine without the crash I observed, on both MS-DOS 7.10 and FreeDOS. At least I can enter the menu and exit the game. Haven't tested in-game behaviors yet.

LSS10999 wrote on Yesterday, 03:09:

It seems if I add /MV=B000 VDPMI will not crash the system, but it still doesn't make any difference.
Further inspection with MEM /D/P revealed that VDPMI might have always enabled the B000-B7FF region, as with or without /MV=B0o0 there are stuffs in that area.

/MV by default is enabled, default start addr is b000, so no need to set it again. you can use /MV=0 to disable it, or /MV=B400 to change the start address. /MV=xxxx is just the same as /I=xxxx-B7ff, with default xxxx=b000. any value of xxxx except 0 (disable) will be clamp to the range [b000, b700] - that was the bug that the clamp doesn't happen.

LSS10999 wrote on Yesterday, 03:09:

Additionally, it seems MS-DOS MEM and FreeDOS MEM behave very differently in this aspect. If I try FreeDOS MEM with MS-DOS 7.10 kernel it reports 192KB of UMB with about 100KB used by kernel, just like what I observed in FreeDOS. The excessive amount of UMB is not reported by FreeDOS MEM when using JEMMEX/JEMM386.

I will test on FreeDOS soon.

LSS10999 wrote on Yesterday, 03:09:

Sorry I didn't take note of the exception detail back then. All I remembered was that VDPMI printed a bunch of register states... I think it might indeed be what you described.
However, I think it might be an edge case, as when I tried Astrofire and Terrafire today (with and without /MV=B000), I could no longer reproduce that issue. Both games ran fine without the crash I observed, on both MS-DOS 7.10 and FreeDOS. At least I can enter the menu and exit the game. Haven't tested in-game behaviors yet.

OK, I was testing the setup.exe in terrafire to auto detect sound card, then it crashes on calling int67h ax=FFA5h. maybe the main game does not crash, I will rerun the game to see what happens.

EDIT: did more tests. setup.exe will definitely crash without implementation int67h ax=FFA5h. the game will execute setup.exe every time on launch, probably to check the config, if it crashes, then the config probably is reset to no SFX. and when no SFX, "int67h ax=FFA5h" not called anymore, later runs of the game does no crash, but with a flash of message "xxx (probably sound) disabled", and it has no sound. normally the flash of message seems sound blaster settings "Axxx Ix Dxx".

Conclusion: it is the problem of "int67h ax=FFA5h" not implemented. setup crash everytime, the game will only crash once. after that the game runs without sound.

crazii wrote on 2026-06-06, 13:22:

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...

Could you backport your VDPMI changes to USBDDOS? As I tried USBDDOS longer time ago it just hanged my PC...

crazii wrote on 2026-06-06, 15:56:

the duke3d stutter is probably caused by VDPMI, and another switch /PVI is added, it will help that with /PVI=0

Want to add a bit... when I tested a bit more with DUKE3D, without involving VDPMI (either with JEMM, or without any EMM installed), I noticed some stutters mainly happening when the game just launched, and as I play more the stutter lessens.

I think the issue is due to sound settings, as well as disk performance. However, I don't think disk performance is the bigger issue as from my experience on that system with AHCI, disk speed is much better in overall compared to IDE and this is without any (caching) driver loaded.

I'm currently using 8 voices, 16-bit stereo mixing at 22KHz. My CT2950 is modded with the fixed DSP firmware (4.17) and with 6T timing, which certainly solved a few issues I had elsewhere, but I'm afraid this is still not good enough to handle settings higher than this one. Setting sound quality options higher will lead to heavier stutters that further impairs gameplay at launch, although it may eventually diminish given enough time.

Not sure how much PVI matters for actual Sound Blaster cards (not SBEMU), but I'll consider testing that option a bit when the next version of VDPMI comes out, to see if this would affect the existing behaviors.

PS: It seems for my CT2950, DUKE3D indeed requires the "Reverse Stereo" option to ensure the channel output is on the correct speaker, as tested in its SETUP.

RayeR wrote on Today, 01:43:

crazii wrote on 2026-06-06, 13:22:

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...

Could you backport your VDPMI changes to USBDDOS? As I tried USBDDOS longer time ago it just hanged my PC...

Have you tried this fork build? NEW-Major version release- Patched 22 bugs USB driver for DOS (UHCI/OHCI/EHCI) - TESTERS WANTED
That fork had quite some fixes and PRs merged to my repo, but I don't have time to test/build yet. you can try it to see if anything changes.

The hang is not necessarily related to the mode switch code, it could be a bug in the usb driver. And VDPMI now removes the v86/VCPI detection (needed for USBDDOS), only the initial build in 2024 have that code.

LSS10999 wrote on Today, 03:28:

Want to add a bit... when I tested a bit more with DUKE3D, without involving VDPMI (either with JEMM, or without any EMM install […]
Show full quote

crazii wrote on 2026-06-06, 15:56:

the duke3d stutter is probably caused by VDPMI, and another switch /PVI is added, it will help that with /PVI=0

Want to add a bit... when I tested a bit more with DUKE3D, without involving VDPMI (either with JEMM, or without any EMM installed), I noticed some stutters mainly happening when the game just launched, and as I play more the stutter lessens.

I think the issue is due to sound settings, as well as disk performance. However, I don't think disk performance is the bigger issue as from my experience on that system with AHCI, disk speed is much better in overall compared to IDE and this is without any (caching) driver loaded.

I'm currently using 8 voices, 16-bit stereo mixing at 22KHz. My CT2950 is modded with the fixed DSP firmware (4.17) and with 6T timing, which certainly solved a few issues I had elsewhere, but I'm afraid this is still not good enough to handle settings higher than this one. Setting sound quality options higher will lead to heavier stutters that further impairs gameplay at launch, although it may eventually diminish given enough time.

Not sure how much PVI matters for actual Sound Blaster cards (not SBEMU), but I'll consider testing that option a bit when the next version of VDPMI comes out, to see if this would affect the existing behaviors.

PS: It seems for my CT2950, DUKE3D indeed requires the "Reverse Stereo" option to ensure the channel output is on the correct speaker, as tested in its SETUP.

I believe X99 with Xeon E5 is fast enough to perform voice mixing and resampling in CPU. Usually the stutter is caused by bad-timing, the most suspicious should be the disk IO, even it is fast, it might block the sound blaster IRQ being processed immediately.

PVI probably doesn't change anything compared to when VDPMI is not used. there is no PVI issue if you run only dos4gw without VDPMI. But VDPMI have different interrupt workflow (like preventing IRQ re-entrance to work better on slow CPUs) and with PVI=0, that might "affect" the result, but I don't know it becomes better or worse.

crazii wrote on Yesterday, 03:32:

LSS10999 wrote on Yesterday, 03:09:

Additionally, it seems MS-DOS MEM and FreeDOS MEM behave very differently in this aspect. If I try FreeDOS MEM with MS-DOS 7.10 kernel it reports 192KB of UMB with about 100KB used by kernel, just like what I observed in FreeDOS. The excessive amount of UMB is not reported by FreeDOS MEM when using JEMMEX/JEMM386.

I will test on FreeDOS soon.

Did a look of MEM /D/P using FreeDOS MEM (from both MS-DOS 7.10 and FreeDOS kernels), and it reported a 100KB UMB segment starting at B6FF with a name of "DOS" and description of "system code", covering the B700-CFFF region. This segment is not reported by MS-DOS MEM.

This kind of matched your current VDPMI behavior which enabled B000-B700. Normally the monochrome area would be B000-B7FF so the last 4KB was missed. I wonder if something important is residing in the B700-B7FF region.

crazii wrote on Today, 03:50:

Have you tried this fork build? NEW-Major version release- Patched 22 bugs USB driver for DOS (UHCI/OHCI/EHCI) - TESTERS WANTED

Thx, I missed that. COM port debug seems to be interesting, hope to see some messages on terminal.

Here's some interesting discussion of me with Bret J. more than 10 years ago about new MBs USB 2.0 EHCI topology and why older DOS USB drivers no longer works on modern EHCI USB 2.0 only systems: https://www.bttr-software.de/forum/forum_entry.php?id=14547
did you count such topology in your USBDDOS driver?

RayeR wrote on Today, 14:54:

Thx, I missed that. COM port debug seems to be interesting, hope to see some messages on terminal. […]
Show full quote

crazii wrote on Today, 03:50:

Have you tried this fork build? NEW-Major version release- Patched 22 bugs USB driver for DOS (UHCI/OHCI/EHCI) - TESTERS WANTED

Thx, I missed that. COM port debug seems to be interesting, hope to see some messages on terminal.

Here's some interesting discussion of me with Bret J. more than 10 years ago about new MBs USB 2.0 EHCI topology and why older DOS USB drivers no longer works on modern EHCI USB 2.0 only systems: https://www.bttr-software.de/forum/forum_entry.php?id=14547
did you count such topology in your USBDDOS driver?

My asus laptop is such a beast. No UHCI at all.

The new driver works on it.
It's still in testing, so grab a copy and post back in the appropriate topic.