Thanks very much for integrating my TinySoundFont changes!

crazii wrote on 2026-05-11, 15:24:

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.

Hi. I tested "sbemu-1.1apha1-rc1.zip" under Windows 98 in MS-DOS mode, with the standard original HIMEM.SYS + EMM386.EXE (+ BURNMEM.SYS before them, to limit the total amount of available memory), and ran SBEMU after exiting WINDOWS as follows:

SET BLASTER=A240 I7 D3 H5 T6
VDPMI.EXE /MAXMEM=16 /V1=0 /I16TO32=1 /VM=1 /PVI=0 /UMB=1
SBEMU /SC2

Everything started up correctly and appeared in green in all lines, with a characteristic click in the speakers:

I ran SETMAIN.EXE (the Duke3D audio configurator) and the sound + music appeared after the appropriate configuration (SB16 + ADLIB). In the Duke3D game itself, the sound and music work properly after this.

After the game, you can unload VDPMI.EXE from memory using the "/u" parameter, but how can you unload SBEMU itself from memory?

Overall, I like idea of optional compatibility with EMM386, especially since it eliminates unnecessary hardware restarts.

Thanks.

A quick update: I am trying to finish the /VMPU and /VMSF re-setting from a second run of SBEMU.

This is involves disk IO in a TSR in (the technically the right way ) or pre-load it and pass it to the TSR (hacking and poor maintenance). not very easy & straightforward. It may not be worth the effort, but I feel compelled to finish it. it may help for some testing purpose, e.g. switch between different soundfonts to compare the results.

DoZator wrote on 2026-05-15, 09:42:

After the game, you can unload VDPMI.EXE from memory using the "/u" parameter, but how can you unload SBEMU itself from memory?

On unloading, VDPMI will free all extended memory for DPMI clients, including SBEMU, so theoretically you don't need to unload SBEMU, except that there might be some little remnants of conventional/UMB memory used by SBEMU not freed, which needs a simple protocol to perform cleanups for it, this part will be done in the future.

DoZator wrote on 2026-05-15, 09:42:

Overall, I like idea of optional compatibility with EMM386, especially since it eliminates unnecessary hardware restarts.

Yes I like that idea too. But unfortunately it won't work properly for VDPMI. I guess you need restart to switch to Windows, right? there is another long way: to support GEMMIS so that Windows can run with VDPMI. this is planned but not the priority for the time being. I think it's a matter of time, please stayed tuned 😁.

crazii wrote on 2026-05-15, 10:14:

I guess you need restart to switch to Windows, right?

Yes, this is true when SBEMU is loaded into regular memory. And if you load it into the upper memory (LH SBEMU /SC2), then the return to WINDOWS is correct, you just need to unload VDPMI.EXE /U, but SBEMU remains loaded in the upper memory, and you can see it in the DOS window of WINDOWS using mem /c /p, and it only takes up 640 bytes 😁

UPDATE:
1. the soundfont file now can be changed by a second run of SBEMU with new /vmpu or /vmsf settings.
but there might be problem if the new soundfont file is larger than 6M.
2. They TSF memory is optimized using a look up table. previously it needs about 8MB memory for a 4MB soundfont file, now it's about 4M.
3. the message for change of settings by SBEMU after initial installation, old value & new value are marked with color (red and light green) for better experience.
3. soundfont file name is also colored in installation message.

I tried to set a tag and push a new release build, but there's an error without message in the github release job.
EDIT: seems freedos's sha256 has updated to 1.4, fixed by update to FreeDOS1.4, but the yaml not updated yet, there is one image file not released.

Another question: is there any sound font files (for old cards) that is GPL compliant? it will be better if SBEMU is shipped with a default soundfont file.

DoZator wrote on 2026-05-15, 11:31:

Yes, this is true when SBEMU is loaded into regular memory. And if you load it into the upper memory (LH SBEMU /SC2), then the return to WINDOWS is correct, you just need to unload VDPMI.EXE /U, but SBEMU remains loaded in the upper memory, and you can see it in the DOS window of WINDOWS using mem /c /p, and it only takes up 640 bytes 😁

I knew that SBEMU has a mess with RM memory: some small piece of mem blocks in mem.exe output, but didn't work on it yet. I think I will fix the dirty stuff in the future. the PSP will probably be relocated to UMB too.

I'm setting this up on a Thinkpad T42 and while it works I have a small problem with Jemmex, stating:

"System memory found at dc00-dffff, region might be in use
Warning: no suitable page frame found, EMS functions limited."

Jemmex and SBEMU still loads however and most games still seem to work. Ran memstat incase anyone knows how I can fix this.

1conventional memory (Int 12h): 636 kB
2XBDA at segment 9f00, size 2 kB
3Int 15h, ah=88h, extended memory: 0 kB
4Int 15h, ax=E801h:
5ext. memory below 16 MB: 15360 (0x3c00) KB
6ext. memory above 16 MB: 7926 64 KB blocks = 495 MB [1000000-1ff5ffff]
7Int 15h, eax=E820h:
8 address range          size       type 
9----------------------------------------------------
10000000000-00009efff      9f000  1 (available)
1100009f000-00009ffff       1000  2 (reserved)
120000d2000-0000d3fff       2000  2 (reserved)
130000dc000-0000fffff      24000  2 (reserved)
14000100000-01ff5ffff   1fe60000  1 (available)
1501ff60000-01ff76fff      17000  3 (ACPI reclaimable)
1601ff77000-01ff78fff       2000  4 (ACPI NVS)
1701ff80000-01fffffff      80000  2 (reserved)
180ff800000-0ffbfffff     400000  2 (reserved)
190ffc00000-0ffffffff     400000  2 (reserved)
20----------------------------------------------------
21available: 510 MB, ACPI: 100 kB, rsvd: 8 MB, total: 519 MB

Single 512MB stick.

AaronS wrote on 2026-05-23, 20:49:

I'm setting this up on a Thinkpad T42 and while it works I have a small problem with Jemmex, stating: […]
Show full quote

I'm setting this up on a Thinkpad T42 and while it works I have a small problem with Jemmex, stating:

"System memory found at dc00-dffff, region might be in use
Warning: no suitable page frame found, EMS functions limited."

Jemmex and SBEMU still loads however and most games still seem to work. Ran memstat incase anyone knows how I can fix this.

Copy code to clipboard

1conventional memory (Int 12h): 636 kB
2XBDA at segment 9f00, size 2 kB
3Int 15h, ah=88h, extended memory: 0 kB
4Int 15h, ax=E801h:
5ext. memory below 16 MB: 15360 (0x3c00) KB
6ext. memory above 16 MB: 7926 64 KB blocks = 495 MB [1000000-1ff5ffff]
7Int 15h, eax=E820h:
8 address range          size       type 
9----------------------------------------------------
10000000000-00009efff      9f000  1 (available)
1100009f000-00009ffff       1000  2 (reserved)
120000d2000-0000d3fff       2000  2 (reserved)
130000dc000-0000fffff      24000  2 (reserved)
14000100000-01ff5ffff   1fe60000  1 (available)
1501ff60000-01ff76fff      17000  3 (ACPI reclaimable)
1601ff77000-01ff78fff       2000  4 (ACPI NVS)
1701ff80000-01fffffff      80000  2 (reserved)
180ff800000-0ffbfffff     400000  2 (reserved)
190ffc00000-0ffffffff     400000  2 (reserved)
20----------------------------------------------------
21available: 510 MB, ACPI: 100 kB, rsvd: 8 MB, total: 519 MB

Single 512MB stick.

This is a very common issue on modern systems. Your board probably has some option ROMs taking up certain UMB regions, limiting available UMB you can use for other stuffs (TSRs).

For conventional memory, MEM /D outputs might give some hints... though I'm not sure if there's any utility that can reveal more details...

If EMM can't find a contiguous 64KB block it will not be able to set up the page frame so some EMS functions will not work as expected, but since SBEMU and games do work, this is probably not important in this scope.

Some usual suggestions:
- Disable onboard PXE option ROMs* if present.
- Disable onboard external SATA controllers if you're not using them.
- Set SATA to IDE mode if possible. AHCI mode also installs option ROMs but the size varies, and may be negligible in some systems.

* This includes boot managers such as Plop Boot Manager that can be installed as a PXE ROM replacement. From my experience, if booting from there, about 40KB of UMB region will be permanently occupied.

LSS10999 wrote on 2026-05-24, 03:39:

This is a very common issue on modern systems. Your board probably has some option ROMs taking up certain UMB regions, limiting […]
Show full quote

AaronS wrote on 2026-05-23, 20:49:

I'm setting this up on a Thinkpad T42 and while it works I have a small problem with Jemmex, stating: […]
Show full quote

I'm setting this up on a Thinkpad T42 and while it works I have a small problem with Jemmex, stating:

"System memory found at dc00-dffff, region might be in use
Warning: no suitable page frame found, EMS functions limited."

Jemmex and SBEMU still loads however and most games still seem to work. Ran memstat incase anyone knows how I can fix this.

Copy code to clipboard

1conventional memory (Int 12h): 636 kB
2XBDA at segment 9f00, size 2 kB
3Int 15h, ah=88h, extended memory: 0 kB
4Int 15h, ax=E801h:
5ext. memory below 16 MB: 15360 (0x3c00) KB
6ext. memory above 16 MB: 7926 64 KB blocks = 495 MB [1000000-1ff5ffff]
7Int 15h, eax=E820h:
8 address range          size       type 
9----------------------------------------------------
10000000000-00009efff      9f000  1 (available)
1100009f000-00009ffff       1000  2 (reserved)
120000d2000-0000d3fff       2000  2 (reserved)
130000dc000-0000fffff      24000  2 (reserved)
14000100000-01ff5ffff   1fe60000  1 (available)
1501ff60000-01ff76fff      17000  3 (ACPI reclaimable)
1601ff77000-01ff78fff       2000  4 (ACPI NVS)
1701ff80000-01fffffff      80000  2 (reserved)
180ff800000-0ffbfffff     400000  2 (reserved)
190ffc00000-0ffffffff     400000  2 (reserved)
20----------------------------------------------------
21available: 510 MB, ACPI: 100 kB, rsvd: 8 MB, total: 519 MB

Single 512MB stick.

This is a very common issue on modern systems. Your board probably has some option ROMs taking up certain UMB regions, limiting available UMB you can use for other stuffs (TSRs).

For conventional memory, MEM /D outputs might give some hints... though I'm not sure if there's any utility that can reveal more details...

If EMM can't find a contiguous 64KB block it will not be able to set up the page frame so some EMS functions will not work as expected, but since SBEMU and games do work, this is probably not important in this scope.

Some usual suggestions:
- Disable onboard PXE option ROMs* if present.
- Disable onboard external SATA controllers if you're not using them.
- Set SATA to IDE mode if possible. AHCI mode also installs option ROMs but the size varies, and may be negligible in some systems.

* This includes boot managers such as Plop Boot Manager that can be installed as a PXE ROM replacement. From my experience, if booting from there, about 40KB of UMB region will be permanently occupied.

Yes, thanks!
Even on my Thinkpad t540p (2010s), there is config to disable LAN/NIC option ROM, and usb support in BIOS setup, which will free some uma space to work with EMS.

Another choice is to try /EMSX with VDPMI, the page frame is at F000 so it doesn't use any other uma spaces.

UPDATE:
I have merged the main branch code to the vdpmi branch of SBEMU, so now it has more drivers and MPU soundfont support. for an easy setup: copy a .sf2 to the sbemu folder and rename it as sbemusf.sf2, then launch sbemu with /vmpu.

other updates:

1. fix VDPMI freeze on old CPUs.
this is a bug due to aggressive optimization recently after adding v86 monitor, the protected mode to real mode switch (only used on loading & unloading) is in a non-standard way that doesn't work on old CPUs.

2. /SAFE option
previously when VDPMI detected a option ROM but if it is writable (probably a shadow RAM), the memory region is taken for UMB/EMS. It's not safe but may work, e.g. some LAN/NIC option roms are generally not used unless network functions is used. /SAFE=1 will leave the shadow RAM as it is, and won't use it for UMB/EMS. default value is 1.
If /SAFE=0 is set, then the memory region will be used, with a warning message for using unsafe regions.

3. /I and /X option
similar to the Ixxxx-xxxx or Xxxxx-xxxx option of EMM386, e.g. if some region like C000-CFFF is not safe to use, but the driver failed to detect full portion of it, then use /X=C000-CFFF to exclude it. note that the format is /I= and /X=, '/' and '=' are always needed.
don't worry about the command line length limit, a config file is long ago planned, mostly with some options and VXD list, and options for each VXD, it's just not the very good time to add that yet.

4.compatibility fix for /EMSX with SBEMU.
now sbemu should work better with vdpmi's /EMSX option

5.an old bug exposed by /EMSX with wofl3d
the bug is not an EMS or /EMSX bug, but exposed in some old code. and because wolf3d doesn't release XMS or EMS on exit, which requires a patch or a .bat with NOEMS and NOXMS option, I was considering add memory resource monitor to free xms/ems handles that program fails to free, e.g. on some extreme cases that a program is terminated abnormally. but I don't think it's the priority now, this is not done.

6. fix sound distortion for VT8233/8235/8237/82C686 in SBEMU.

7. compatibility fix for SDLPAL (dos edition) by adding a simple mouse driver.

EDIT: 8. added OPL active detection and it has bugs and should be fixed on next release.

crazii wrote on 2026-05-24, 09:41:

1. fix VDPMI freeze on old CPUs.
this is a bug due to aggressive optimization recently after adding v86 monitor, the protected mode to real mode switch (only used on loading & unloading) is in a non-standard way that doesn't work on old CPUs.

oooh interesting. I tried finding this change on github but failed 🙁 Does it have anything to do with "very first instruction after enabling protected mode has to be an intra-segment (not inter-segment) jump" required to flush the queue? Recently when dissasembling post year 2000 bios (Pentium4/Core2/Atom era) I found it using short jumps to same segment and ignoring this completely:

1Unreal_FFD56    proc near               ; CODE XREF: CPU_MicrocodeUpdate+A↑j
2                                        ; VGA_BIOS_Shadow+20↑p ...
3 lgdt    fword ptr cs:[bx]
4 mov     eax, cr0
5 or      al, 1
6 mov     cr0, eax
7 jmp     short $+2
8; ---------------------------------------------------------------------------
9
10loc_FFD64:
11 mov     ax, 8
12 mov     ds, ax
13 assume ds:nothing
14 mov     es, ax
15 assume es:nothing
16 mov     eax, cr0
17 and     al, 0FEh
18 mov     cr0, eax
19 jmp     short $+2
20; ---------------------------------------------------------------------------
21loc_FFD75:
22 xor     ax, ax
23 mov     ds, ax
24 assume ds:nothing
25 mov     es, ax
26 assume es:nothing
27 retn
28Unreal_FFD56    endp

rasz_pl wrote on 2026-05-24, 14:15:

crazii wrote on 2026-05-24, 09:41:

1. fix VDPMI freeze on old CPUs.
this is a bug due to aggressive optimization recently after adding v86 monitor, the protected mode to real mode switch (only used on loading & unloading) is in a non-standard way that doesn't work on old CPUs.

oooh interesting. I tried finding this change on github but failed 🙁 Does it have anything to do with "very first instruction after enabling protected mode has to be an intra-segment (not inter-segment) jump" required to flush the queue? Recently when dissasembling post year 2000 bios (Pentium4/Core2/Atom era) I found it using short jumps to same segment and ignoring this completely:

No, not quite like that. When I first learn pm/rm switch around the year 2007-08, many online sources (or maybe books, I don't remember) say a short jump to flush the instruction cache. I still remember that but now the short jump not used. a far jump seems fine, maybe there are pitfalls there, I think a immediate far jmp after setting cr0 should work good, but now vdpmi doesn't do a immediate far jmp, there are some codes between them.

The aggressive optimization was to remove the 16bit pm data selectors, change a 32bit pm segment regs to real mode segments directly, seems work quite fine on my laptop,
the hidden part (size,limit,32 or 16) of the sreg descriptors seems being set.

But testing on an old PC, the real mode sregs values looks correct after pm to rm, and it can execute correctly for a short while, but with weird, un-explainable hangs. the fix is to change the sregs from 32bit to 16bit pm selectors before switch to real mode. so that the hidden size/limit/32or16 info is correct before setting them to real mode segments. I think its related to UNREAL mode, which I was also interested and tried it with Borland C back in the day.

crazii wrote on 2026-05-24, 14:55:

but now vdpmi doesn't do a immediate far jmp, there are some codes between them.

I would definitely try following intel gospel and put far jump to different selector directly after switch. This seems to be standard in all pre 2000 bioses and what Intel demanded in documentation.

crazii wrote on 2026-05-24, 14:55:

But testing on an old PC, the real mode sregs values looks correct after pm to rm, and it can execute correctly for a short while, but with weird, un-explainable hangs.

that deffo sounds like unflushed TLB

rasz_pl wrote on 2026-05-24, 15:47:

I would definitely try following intel gospel and put far jump to different selector directly after switch. This seems to be standard in all pre 2000 bioses and what Intel demanded in documentation.

Yes you're right. I wasn't reading the mode switch part from intel manual. although have read a lot on the v86 section and 32-16 mixing and transition section. currently the code in between is OK to move around.

rasz_pl wrote on 2026-05-24, 15:47:

that deffo sounds like unflushed TLB

No, not like it. but it reminds me that it is complicated. the pm stack before mode switch, is at hi-address, >1M, and not 1:1 identity mapped, after set cr0, the stack is not available. changing to 16bit selector whose base addr is at conventional memory and identity mapped, is a simple way. I'm not using a far jmp directly but a equivalent "retf" is used, which requires a working stack. so I was doing like this: "set cr0, set ss to real mode seg, retf". to fix it, a far jmp is needed, like this "set cr0, far jmp, set ss to rm" which should work. but that piece of code is relocatable and needs hot patch to the far jmp address when it moves/floats around. that is not worth the effort for the optimization, to optimize out a 16 bit data selector that is only used during loading/unloading. so the removed data selector is added back.
now the real mode ss is set after retf. no extra "critical" operations in between them.

Thanks guys, disabling USB in the bios did the trick! I tried disabling PXE boot alone but the problem with no page frame was still there.

Re: fascinating Plain DOS 2 Core Demo.

Dos dual core proof of concept code.
Wonder if this could be useful for sbemu?
Surely having a whole processor to use could improve things?

myne wrote on 2026-05-28, 03:51:

Re: fascinating Plain DOS 2 Core Demo. […]
Show full quote

Re: fascinating Plain DOS 2 Core Demo.

Dos dual core proof of concept code.
Wonder if this could be useful for sbemu?
Surely having a whole processor to use could improve things?

Very interesting. I think it'd be better added in the supervisor level, e.g. jemm or hdpmi or vdpmi. I'm currently busing on improving sbemu sound quality and bugfixes, I will take a look later.

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.

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.