L4MD4 wrote on 2025-08-07, 18:16:

3lectr1c wrote on 2025-08-05, 03:50:

Trying to run it under DOS mode in Windows 98.

I'm not sure what you mean, by "DOS mode". If you mean anything other than booting straight to DOS (before Windows loads) don't do that.

If you are trying to accomplish this sort of thing from a Win98 dos prompt, there is VDMSound for Win9x; but it is buggy and not for slower machines.

Is there no way to make this work under DOS mode? Being forced to run pure DOS would be an enormous pain.

What's the verdict for the best, tiny laptop that can run SBEMU successfully (including the new soundfont support) these days?

I've been looking through my box of old laptops and I've found an old Dell Latitude X1 - a 2005-ish sub-notebook; slightly larger than an EEE PC 900, but still functional and the battery holds (some!) charge. It's a 1.1GHz Pentium-M on Intel 915 chipset.

I was able to get VSBHDA working on this Dell Latitude X1.

It's supported as an ICH6 device, and so far the compatability seems pretty good - it needed a little bit of massaging memory managers and UMBPCI to get them playing nicely with each other, but it mostly worked without any real problems and virtually everything loads to UMB leaving 626kb free.

The biggest issue I've faced is that I cannot have VSBHDA and the Broadcom packet drivers for the built-in NIC and MTCP (ftp / ftpsrv) all at the same time; it gets really flaky at that point. Instead I reboot to an alternative config.sys/autoexec.bat menu entry that skips loading VSBHDA components and instead just runs the Broadcom driver and MTCP - at that point it's perfectly stable, so I'm happy with that as a workaround.

Results so far:

vsbhda16
- Xargon - FM ok, digital ok
- Prince of Persia - FM ok (persia adlib), in SB mode (persia sblast) it reverts to PC speaker
- Prince of Persia 2 - FM ok, digital ok (configured as SB Pro for both)
- Wolf3d - FM ok, digital ok
- Blake Stone 1 - FM ok, digital ok
- Blake Stone 2 - FM ok, digital ok

vsbhda
- Doom (v1.9 Ultimate Doom) - FM okay, digital ok, Soundfont MIDI ok
- Duke3d (v1.4 Atomic Edition) - FM okay, digital only in centre channel*, Soundfont MIDI ok

Soundfont support also appears to work well enough on the 1.1GHz Pentium-M to not cause any noticeable slowdown in Doom and Duke3d when I tried it - I tried with a simple 8MB GM soundfont and with a bigger 32MB one, and no noticeable difference in performance (except load times - the 1.8" drive in this thing is slooooow!). I'd guess there will be a ceiling to this though.

On this laptop there's a harsh cut off in volume levels as anything below /VOL9 is almost inaudible. Setting the volume to /VOL9 in most cases then seems to max it out resulting in speaker distortion. In games that have an in-game mixer (e.g Doom or the Duke3d setup tool) you can then adjust the levels to a more appropriate setting.

The biggest disappointment so far is the lack of digital audio on the left and right channels in Duke3d - that's a bit of a killer at the moment. The setup tool sounds the "Centre" test, but then "Left" and "Right" tests are completely silent.

It is only a mono speaker device though (it's a fairly tiny machine - only slightly larger than a Thinkpad 240)... so there's that to consider, but it does make a cracking little portable system!

3lectr1c wrote on 2025-08-07, 23:16:

L4MD4 wrote on 2025-08-07, 18:16:

3lectr1c wrote on 2025-08-05, 03:50:

Trying to run it under DOS mode in Windows 98.

I'm not sure what you mean, by "DOS mode". If you mean anything other than booting straight to DOS (before Windows loads) don't do that.

If you are trying to accomplish this sort of thing from a Win98 dos prompt, there is VDMSound for Win9x; but it is buggy and not for slower machines.

Is there no way to make this work under DOS mode? Being forced to run pure DOS would be an enormous pain.

I was just trying to do the same exact thing on a Pentium 4 system (specs here https://theretroweb.com/motherboards/s/intel- … -bayfield#chips) for HOURS and then i got the feeling there is NO WAY you can make it work, at least for real mode. Best i could do was to obtain emulation without real mode.

If the desire is to use windows, why don't you just install DosBox to win98 machine?

3lectr1c wrote on 2025-08-07, 23:16:

Is there no way to make this work under DOS mode? Being forced to run pure DOS would be an enormous pain.

There is no way using the current technology of SBEMU.

Basically put, Windows 95 and SBEMU do the same thing: They execute DOS programs under control of an operating system that has 32-bit drivers controlling modern hardware. They use the DOS virtualization technique (actually: real-mode/8086 virtualization technique) introduced with the 80386, executing real DOS code "virtual 8086 mode" (often shortened to "virtual mode" or "V86" mode). There can only be one system that provides the backend to these virtual machines, the "virtual machine monitor" (VMM). In case of SBEMU, SBEMU itself is the virtual machine monitor (in cooperation with JEMM and QPIEMU.DLL) for real mode games. It's similar for protected mode games (like DOS4GW games): These games are using DPMI to interface with a protected mode operating system which again can emulate hardware. In case of SBEMU, the DPMI interface is provided by the special HDPMI version shipped with SBEMU, and SBEMU "plugs into" that specific DPMI implementation.

In either case, SBEMU provides an virtual DMA controller and a virtual interrupt controller, so that sound blaster DMA and IRQs can be emulated in software. SBEMU can do that because it is the only component that emulates virtual hardware. There is no 32-bit operating system kernel that also tries to do these tasks (well, actually EMM386/JEMM do some DMA virtualization to handle EMS/UMBs properly), so SBEMU can do that. On the other hand, with Windows 95, the Windows 95 kernel already has the "Virtual DMA Device" and the "Virtual PIC device" as the central implementation of DMA and IRQ virtualization. SBEMU is unable to provide its own hardware virtualization while running in a Windows 95 DOS box.

To get SBEMU for Windows 95, a different approach would need to be taken: Instead of virtualizing the DMA controller and the interrupt controller itself, SBEMU would need to be a Windows 95 kernel module (a .VXD file) that can interface with the Windows 95 DMA and IRQ virtualization drivers. SBEMU is (in my oppinion) partly re-inventing the virtualization of DMA and IRQ channels. I'm unsure whether I like that, or providing SBEMU as VXD for Windows 3.1 or Windows 95 would be a smarter approach. While I do understand many people don't want to boot Windows 95 to run DOS games, running a Windows 3.1 32-bit Kernel (no GUI shell needed) to back up SBEMU may be an interesting approach. It's not that interesting, though, as I don't think you can find a lot of AC97 or HDA sound drivers for Windows 3.1, so they would need to be written as well...

There is one 3.x hda driver.
One thing that baffles me is that hda and ac97 are fundamentally different. It just seems silly that they were so different while implementing the same thing, and both designed by Intel

mkarcher wrote on 2025-08-17, 10:34:

There is no way using the current technology of SBEMU. […]
Show full quote

3lectr1c wrote on 2025-08-07, 23:16:

Is there no way to make this work under DOS mode? Being forced to run pure DOS would be an enormous pain.

There is no way using the current technology of SBEMU.

Basically put, Windows 95 and SBEMU do the same thing: They execute DOS programs under control of an operating system that has 32-bit drivers controlling modern hardware. They use the DOS virtualization technique (actually: real-mode/8086 virtualization technique) introduced with the 80386, executing real DOS code "virtual 8086 mode" (often shortened to "virtual mode" or "V86" mode). There can only be one system that provides the backend to these virtual machines, the "virtual machine monitor" (VMM). In case of SBEMU, SBEMU itself is the virtual machine monitor (in cooperation with JEMM and QPIEMU.DLL) for real mode games. It's similar for protected mode games (like DOS4GW games): These games are using DPMI to interface with a protected mode operating system which again can emulate hardware. In case of SBEMU, the DPMI interface is provided by the special HDPMI version shipped with SBEMU, and SBEMU "plugs into" that specific DPMI implementation.

In either case, SBEMU provides an virtual DMA controller and a virtual interrupt controller, so that sound blaster DMA and IRQs can be emulated in software. SBEMU can do that because it is the only component that emulates virtual hardware. There is no 32-bit operating system kernel that also tries to do these tasks (well, actually EMM386/JEMM do some DMA virtualization to handle EMS/UMBs properly), so SBEMU can do that. On the other hand, with Windows 95, the Windows 95 kernel already has the "Virtual DMA Device" and the "Virtual PIC device" as the central implementation of DMA and IRQ virtualization. SBEMU is unable to provide its own hardware virtualization while running in a Windows 95 DOS box.

To get SBEMU for Windows 95, a different approach would need to be taken: Instead of virtualizing the DMA controller and the interrupt controller itself, SBEMU would need to be a Windows 95 kernel module (a .VXD file) that can interface with the Windows 95 DMA and IRQ virtualization drivers. SBEMU is (in my oppinion) partly re-inventing the virtualization of DMA and IRQ channels. I'm unsure whether I like that, or providing SBEMU as VXD for Windows 3.1 or Windows 95 would be a smarter approach. While I do understand many people don't want to boot Windows 95 to run DOS games, running a Windows 3.1 32-bit Kernel (no GUI shell needed) to back up SBEMU may be an interesting approach. It's not that interesting, though, as I don't think you can find a lot of AC97 or HDA sound drivers for Windows 3.1, so they would need to be written as well...

Thanks for the great explanation, this really sheds some light on why it wasn't working. Shame that this is the way it is, but I understand the limitations. I will have to give it a try in pure DOS soon.

Kekkula wrote on 2025-08-17, 06:25:

If the desire is to use windows, why don't you just install DosBox to win98 machine?

Because that's way more clunky and cumbersome, and at that point, why not just use my modern PC? I want Windows to be installed on my machines as well because it makes file transfer easy, and I also run Windows software.

3lectr1c wrote on 2025-08-20, 22:03:

Because that's way more clunky and cumbersome, and at that point, why not just use my modern PC? I want Windows to be installed on my machines as well because it makes file transfer easy, and I also run Windows software.

Sorry, for the late reply. Fortunately a, kind and knowledgeable, forum member stepped in and clarified.

What version of Win9x are you using, and on what kind of machine?

For Win98, there is the sbemul patch http://sweetlow.orgfree.com/download/ . I haven't used it, yet; but it may improve native Windows SB support.

If you have a desktop (PCI/ISA), an audio card with "known" Windows SB (DOS) compatibility could be used. If you don't mind Win XP/2000, VDMsound is pretty stable, on those systems. If the system is an older Intel Chipset (ICH4, or older), you'll have more native Win SoundBlaster emulation functionality. I know on Intel Ich5 (and probably newer) there was still digital or FM emulation; but it wasn't consistent for every game.

I have a poor old Gateway Solo 5300, and the ES1371 is Fine. But, for the enthusiast it isn't enough. If your willing to use SBEMU, then a card like that would be okay-ish.

Its no less clunky than DosBox, but VirtuallyFun has some blog posts about using older versions of Qemu (working SB emulation), for Dos games. He has also done some work, to isolating and compile older Qemu versions with the fastest CPU emulation (maybe needing recompiled, if you're not using a kernel extender). I know, with both DosBox and Qemu, finding the right SDL DLL can make a world of difference (performance). AFAIK, no one has compiled or collected the best SDL/OpenGL DLLs for Win9x (un-accelerated). It seems to not get a lot of attention. I've (cross)compiled SDL, for myself, using an older MinGW. I probably should have tweaked it more, as it lacked some graphics functions; but it drastically improved performance. Also not mentioned often, is the SDL environmental variables; that contribute to SDL's system performance. I guess, if you're running a faster/video-accelerated machine, some of that won't matter as much.

A bit off topic, but VBSHDA has (Standard Mode) support for Win3x. There are different file-managers, for Win3x, that offer an improvement over the included one.

But, for Dos, there is also (Necromancer's Dos Navigator). If you can wrap hour head around the dual-plane file management style, you may never want to use anything else. To this day I use Midnight Commander (MC) on Linux, and UFO on dos. I've even found an older Win32 MC, for Win9x. If you need to work with tons of folders, at one time, maybe the common windowed managers might work better. But for most file tasks, I can't say enough about slowly learning the TUI file-managers. This option eases working with file management, in Dos. Many even have built in support for archived files (view/create/extract). There are a good handful of Norton Commander clones out there. Its a bit limited, for me, But DosZip Commander is another good one. I almost forgot to mention, almost every Norton clone has a built-in Text file viewer/editor.

The other disadvantage of file-management, in Dos, is easy USB support. If you work out the right drivers and driver loading tools, you can have an easy to use batch file for mounting and un-mounting USB drives. But, this might be dependent on your hardware/configuration agreeing on compatibility.

If your Machine can boot off of USB, then you could make a Dos bootable USB drive; then just boot from it and copy files to your internal drive (or run them right off of it). Dos rebooting is pretty quick. It obviously isn't as fast as switching tasks with a Multitasking Kernel 😉

This is all surplus information. It seem I've had to much time to spare, today.

I've started testing all of the games in my "standard" CF/mSATA image that I squirt on to every new build.

This is on a Dell Latitude X1 (ICH6) using VSBHDA:

https://www.target-earth.net/wiki/doku.php?id … x1#game_testing

About 150 entries so far. A good set of working titles - more work perfectly than don't work at all.

I previously sought out "perfect" DOS compatible laptops and am seeing no worse results with VSBHDA than I did with devices that had native sound support (either Yamaha or ESS chips).

It's still not perfect, but it's looking really good and at the very least opens up the choice of hardware for native DOS gaming considerably.

Hi again!

I can hapily report that Sbemu works very well on the Samsung Q1 Ultra so we can add one more device to the compatibility list as i have not seen it over there if i am not mistaking

L4MD4 wrote on 2025-08-22, 04:28:

Sorry, for the late reply. Fortunately a, kind and knowledgeable, forum member stepped in and clarified. […]
Show full quote

3lectr1c wrote on 2025-08-20, 22:03:

Because that's way more clunky and cumbersome, and at that point, why not just use my modern PC? I want Windows to be installed on my machines as well because it makes file transfer easy, and I also run Windows software.

Sorry, for the late reply. Fortunately a, kind and knowledgeable, forum member stepped in and clarified.

What version of Win9x are you using, and on what kind of machine?

For Win98, there is the sbemul patch http://sweetlow.orgfree.com/download/ . I haven't used it, yet; but it may improve native Windows SB support.

If you have a desktop (PCI/ISA), an audio card with "known" Windows SB (DOS) compatibility could be used. If you don't mind Win XP/2000, VDMsound is pretty stable, on those systems. If the system is an older Intel Chipset (ICH4, or older), you'll have more native Win SoundBlaster emulation functionality. I know on Intel Ich5 (and probably newer) there was still digital or FM emulation; but it wasn't consistent for every game.

I have a poor old Gateway Solo 5300, and the ES1371 is Fine. But, for the enthusiast it isn't enough. If your willing to use SBEMU, then a card like that would be okay-ish.

Its no less clunky than DosBox, but VirtuallyFun has some blog posts about using older versions of Qemu (working SB emulation), for Dos games. He has also done some work, to isolating and compile older Qemu versions with the fastest CPU emulation (maybe needing recompiled, if you're not using a kernel extender). I know, with both DosBox and Qemu, finding the right SDL DLL can make a world of difference (performance). AFAIK, no one has compiled or collected the best SDL/OpenGL DLLs for Win9x (un-accelerated). It seems to not get a lot of attention. I've (cross)compiled SDL, for myself, using an older MinGW. I probably should have tweaked it more, as it lacked some graphics functions; but it drastically improved performance. Also not mentioned often, is the SDL environmental variables; that contribute to SDL's system performance. I guess, if you're running a faster/video-accelerated machine, some of that won't matter as much.

A bit off topic, but VBSHDA has (Standard Mode) support for Win3x. There are different file-managers, for Win3x, that offer an improvement over the included one.

But, for Dos, there is also (Necromancer's Dos Navigator). If you can wrap hour head around the dual-plane file management style, you may never want to use anything else. To this day I use Midnight Commander (MC) on Linux, and UFO on dos. I've even found an older Win32 MC, for Win9x. If you need to work with tons of folders, at one time, maybe the common windowed managers might work better. But for most file tasks, I can't say enough about slowly learning the TUI file-managers. This option eases working with file management, in Dos. Many even have built in support for archived files (view/create/extract). There are a good handful of Norton Commander clones out there. Its a bit limited, for me, But DosZip Commander is another good one. I almost forgot to mention, almost every Norton clone has a built-in Text file viewer/editor.

The other disadvantage of file-management, in Dos, is easy USB support. If you work out the right drivers and driver loading tools, you can have an easy to use batch file for mounting and un-mounting USB drives. But, this might be dependent on your hardware/configuration agreeing on compatibility.

If your Machine can boot off of USB, then you could make a Dos bootable USB drive; then just boot from it and copy files to your internal drive (or run them right off of it). Dos rebooting is pretty quick. It obviously isn't as fast as switching tasks with a Multitasking Kernel 😉

This is all surplus information. It seem I've had to much time to spare, today.

I pretty much exclusively collect laptops, so the use of this would be to improve the DOS compatibility on my systems without good DOS audio. Link to the patch is down at the moment, will check it again at a later date. I definitely do want to explore some DOS file managers! If I can find a way to dual-boot pure DOS and Windows 98, that could be a good option. Can't try much right now as I'm at college now, the one retrogaming laptop I brought is DOS compatible already 😀