digger wrote on 2025-01-07, 00:47:

don't those Vortex86 SBCs have PC/104 interfaces, which are basically ISA slots in a different form factor?

Not all of them. Some of them are even smaller and lack any sort of expansion.

Apologies if this is a stupid question, but if I have a DOS installation/machine where SBEMU is working (VIA 8237 southbridge), can I install Win3.11 and use some standard SoundBlaster drivers, expecting them to interface with the already running emulation? Or do Win3.11 drivers actually attempt to work directly with hardware at a lower level?

Well, that's the point of the emulation - to make existing code that tries to interface with the hardware at a low level think that the SB hardware is actually there.

The issue I would expect with Windows is more that it wouldn't play nice with JEMM.

AFAIK windows 3.x doesn't run under JEMM. Also HDPMI mentions only windows std. mode not enhanced (386) mode. Maybe it would be possible with HDPMI+QEMM in std. mode.

Does SBEMU support line-in/microphone input?

justin1985 wrote on 2025-01-07, 18:30:

Apologies if this is a stupid question, but if I have a DOS installation/machine where SBEMU is working (VIA 8237 southbridge), can I install Win3.11 and use some standard SoundBlaster drivers, expecting them to interface with the already running emulation? Or do Win3.11 drivers actually attempt to work directly with hardware at a lower level?

It really doesn't make much sense to use SBEMU for this. SBEMU exists, because there was no widely used vendor-neutral sound API in DOS. (VBE/AI was an attempt by VESA to introduce one, but it was too late to market to ever take off.)

This is why DOS games either access sound card hardware directly, or use proprietary driver SDKs that were available at the time (Miles, DIGPAK, etc).

One of the advantages of Windows (even Windows 3.x) was that it had a hardware abstraction layer and a standard driver API for applications to access sound hardware. Basically all operating systems after DOS had this.

And Microsoft made Driver Developer Kits (DDKs) available to developers basically for free (even then), so any experienced software developer could write one.

So for Windows 3.x (and pretty much every OS newer than that), developing drivers for newer hardware would be the way to go, not low-level Sound Blaster emulation.

A very nice example of this is the new vbesvga driver project, which allows modern graphics cards with VBE support to finally work on Windows 3.1 in high-color mode.

An open source unified Intel HDA driver for Windows 3.x would be very useful, for instance!

So I really don't get why people insist on making SBEMU compatible with Windows. That's really not what it's for.

As there's no unified AC97/HDA/SBlive driver for win 3.x it may be more viable to use SBEMU or make it compatible with win than writting complete windows driver. I'm not much interested in sound for win 3.x but someone else may give a try with QEMM386. It supports QPI api and shoul be compatible with windows. At least Win95 that I used together with QEMM 9.0

RayeR wrote on 2025-01-09, 15:04:

As there's no unified AC97/HDA/SBlive driver for win 3.x it may be more viable to use SBEMU or make it compatible with win than writting complete windows driver. I'm not much interested in sound for win 3.x but someone else may give a try with QEMM386. It supports QPI api and shoul be compatible with windows. At least Win95 that I used together with QEMM 9.0

QEMM works with Windows 3.x and Windows 9x because it supports GEMMIS. This allows Windows to take over the tasks from the EMM when it starts, and to hand it back to the EMM when it exits to DOS.

But that also means that the EMM is not active while Windows is running, so the I/O port trapping functionality of the EMM doesn't work then either.

And the way how SBEMU enables hardware emulation for protected mode games, namely by accessing a port-trapping API in HDPMI, also wouldn't work to my knowledge, since Windows acts as the DPMI server while it's running.

Unless there is some way for Windows to piggy-back on an already loaded DPMI server/host when it starts up? Is that even possible? I don't think Microsoft would have bothered to implement that, since it wanted Windows to take over everything as the "OS".

On the other hand, the Wikipedia page on DPMI does mention how a beta version of 386MAX implemented "true DPMI", allowing it to run KRNL386.EXE from the command line. However, I'm not sure if that would be enough to have a fully functional Windows 3.x environment running in 386 Enhanced Mode on top of another DPMI host. (Does anybody here know?)

I know that there are Windows applications that implement I/O port trapping. One such tool is called "Dongle Cracker" and this guy used it to use a Covox Speech Thing connected to a PCMCIA parallel port at a non-standard I/O address in Windows 3.1.

But that would require SBEMU to be forked and ported to Windows to work. And at that point, I really believe it would be easier to implement a generic HDA and/or AC'97 ICHx driver for Windows 3.x from scratch instead. And the reliability and latency would most likely be better in the latter case as well.

No, like Sauron, Windows does not share power.

It wants to be the only EMM running, and it wants to be the ONLY DPMI server running.

You'd need to hack the windows DPMI server to accept the port trapping we need, and need to either bamboozle windows into thinking JEMMEX is EMM386, OR-- Hack EMM386 to give it loadable module support.

Ok, if windows suspends EMM unable to do RM port trapping then this idea falls, no way. For HDPMI it's only mentioned it allows run windows in std mode not 386 mode, so then PM port trapping wouldn't work too...

digger wrote on 2025-01-09, 09:22:

...
An open source unified Intel HDA driver for Windows 3.x would be very useful, for instance!

RayeR wrote on 2025-01-09, 15:04:

As there's no unified AC97/HDA/SBlive driver for win 3.x it may be more viable to use SBEMU or make it compatible with win than writting complete windows driver. I'm not much interested in sound for win 3.x but someone else may give a try with ...

Win 3.x drivers (together with Pascal code for 16-bit Delphi 1) exist for both AC97 and HDA but like in many cases of such one man projects they work for some and not for others since they were tested only on limited number of hardware.
http://www.win3x.org/win3board/viewtopic.php? … =17965&start=20

wierd_w wrote on 2025-01-09, 16:08:

No, like Sauron, Windows does not share power.

It wants to be the only EMM running, and it wants to be the ONLY DPMI server running.

You'd need to hack the windows DPMI server to accept the port trapping we need, and need to either bamboozle windows into thinking JEMMEX is EMM386, OR-- Hack EMM386 to give it loadable module support.

"Faking" or hacking EMM386 wouldn't help here either, since EMM386 (even the one included with Windows 3.x) also hands over all control through GEMMIS when Windows 3.x starts in 386 Enhanced mode. Same with all other EMMs that support GEMMIS (notably newer versions of QEMM and 386MAX, as well as the EMM integrated in DOSBox).

Jemm currently does not support GEMMIS, unfortunately. There's an open feature request for this on GitHub.

But even if GEMMIS support is eventually added to Jemm, that still won't solve this problem, since indeed Windows will be in control of all protected mode and V86 stuff while it's running.

Having GEMMIS implemented in Jemm would still be very useful though, since it would allow Windows 3.x and Windows 9x to be started from DOS seamlessly, even when Jemm is loaded, without having to reboot and manually select another boot mode first. But this wouldn't help getting SBEMU to work in Windows at all.

Basically, the only options that I can think of that could get SBEMU to work with Windows 3.x in 386 Enhanced Mode are the following:

• Use System Management Mode (SSM), which is basically a mode with even higher privileges than Ring 0, which usually only the BIOS has access to. I believe this is the way how PS/2 keyboards are emulated when USB keyboards are plugged in. This method is known to be very slow, however. And it might require some BIOS hacking to gain access to it. We're treading into the realm of hard-core hacking voodoo rituals here.
• Turn SBEMU into a hypervisor that leverages the hardware-assisted virtualization features of modern x86 CPUs (Intel VT-x and AMD-V extensions). It would have to switch into protected mode or long (64-bit) mode and then run DOS on top of it in a VM with limited hardware access, allowing direct access to things like VGA, but intercepting access to the sound cards it wants to emulate. That would blow up the scope of SBEMU immensely.
• Have SBEMU leverage another hypervisor designed for running DOS in mind. Basically such a hypervisor would be something like "EMMX64": functionally similar to EMM386, except that it would use the aforementioned hardware-assisted virtualization extensions on CPUs that support them, instead of the V86 mode supported by 386 CPUs. This EMMX64 would then expose a port trapping API to the guest VM that would be running DOS, and SBEMU would then be able to tap into that API. But then why even run SBEMU inside the VM? Why not have the hypervisor handle the emulation outside of the DOS VM as well, so we can leverage the additional cores of a multi-core CPU? Also, at this point, it would require such an EMMX64 project to be developed first, which would be outside the scope of the SBEMU project.

Keep in mind that having SBEMU somehow make use of the Intel VT-x and AMD-V extensions would make it incompatible with older systems, namely everything that was released before 2007 or so.

Really, the most practical and proper solution for running Windows 3.x and Windows 9x on newer hardware with sound support is to develop native drivers for newer audio devices. The same goes for video (VBE with high-color support and hopefully accelerated video through VBE/AF at some point) and disk drivers (native AHCI and NVMe drivers). We're already seeing work on this on the video front, with projects like vbesvga and the Windows 9x video driver for VirtualBox. And the late Rudolph R. Loew developed an AHCI driver for Windows 9x. (If any of you know of any other examples, please let me know, because I'm very much interested in learning about them and trying them out! Thanks.)

The DDKs for Windows 3.x and 9x are still available, and although driver programming for these older Windows versions is a bit arcane, there is documentation to be found for it, as well as example code, both in the Microsoft DDKs and in these existing open source projects. (Although I'm not sure if the source code of Rudolph Loew's AHCI9X driver has been publicly released yet.)

Really, let's keep Windows support outside the scope of SBEMU. The right tool for the right job. Also, SBEMU already needs a lot more work in its current state just as a DOS tool. Please, let's focus on that.

@Falcosoft: well, that's the whole point of open source projects, right? Have people collaborate on improving such software, fixing bugs, increasing compatibility, etc. At least there's already a project like that to provide a starting point. Although I'm a bit baffled about the choice to develop such a driver in Pascal. I think it's better to use C, assembly, or a combination of both for driver development. Or perhaps Rust. Wouldn't that be awesome, a Windows 3.x driver written in Rust? 😁

RayeR wrote on 2025-01-09, 16:52:

so then PM port trapping wouldn't work too...

Windows has its own API to trap port access but it is available for drivers only. SBEMUL.SYS is the good example of user of such API.
So the right solution is to insulate emulation of SB card from OS specific methods for trapping access to hardware and routing this trapped information to real sound renderer.

digger wrote on 2025-01-09, 18:48:

Although I'm not sure if the source code of Rudolph Loew's AHCI9X driver has been publicly released yet.

No. No AHCI.PDR nor ESDI_506.PDR from TBP3.0 sources.

digger wrote on 2025-01-09, 18:48:

I'm very much interested in learning about them and trying them out!

Really? Look at GPT, SCSI 64-bit LBA and 64-bit RAM Drive drivers for Windows 9x.

This is similar to what digger has said, maybe worded differently (for conceptualizing).

Something like DosBox could be created, for Dos, with the aim of using SBemu. One issue is native execution of code. Something similar to old QEMU's Kqemu, would be needed; this as opposed to complete CPU emulation. Some things would still need to me emulated, but you could run with fairly good speed. Then you have Win3x (and Win9x ?) support.

Although, if such contraption was built, you might as well provide the "DosBox like" emulator with its own multitasking kernel (sound server, network interfacing, etc). However, then using Sbemu would be a limiting factor, for the whole project.

I agree with digger, Sbemu is for Dos.

I think it would be better to start a project patching and developing improvements to Win3x, or develop a Dos focused replacement (mutlitasking Dos environment, with natural evolutions [like a clipboard]), in which you could run Win3x (and many other things) inside of.

But really, all of this is beyond the "current" developer potential/investment, we have available.

deomsh, from mfsn.org, has been working on adapting the HDA Win3x 16bit driver to Win9x, for some time now. I believe deomsh has a database of the different devices (and their underlying details). I think the base driver code is also available, but I'm not sure how it is licensed.

It is probably in the best interest, of all projects, to create a library for basic audio device support. You just need to build it, with the intention of supporting several projects. What we do have a lack of, is support for audio input. That "understandably" isn't a large focus.

That is what seems "to me" the next immediate consideration. Leaving Sbemu as it is, or developing a audio device library for Dos (and whatever else). crazii always wanted Sbemu improvements to also benefit Mpxplay. There was some "light" contention around a Sbemu fork, somewhat due to this. But maybe "all" could benefit from a driver library. But again, even that move may be beyond the current developer support available. And, it would mean an additional project would need stewardship.

Obviously, this isn't just a roadmap choice for Sbemu. Anyone could do this, at any point. Then it could be decided if Sbemu would benefit from using it (and any other project).

Jut putting this out there, in case it helps someone. If you are struggling to find hints, needed for porting you audio device over, you could also try giving the 4front OSS -> http://www.4front-tech.com/developer/sources/stable/bsd/ sources a peek. Not much good, if your device is 2020 or newer.

It just came to mind, due to the previous post. I've got a untested NeoMagic device, I've been meaning to port (if it already doesn't work).

The BSDs are also another place to look, instead of just Linux (sources).

L4MD4 wrote on 2025-01-15, 23:12:

Jut putting this out there, in case it helps someone. If you are struggling to find hints, needed for porting you audio device over, you could also try giving the 4front OSS -> http://www.4front-tech.com/developer/sources/stable/bsd/ sources a peek. Not much good, if your device is 2020 or newer.

It just came to mind, due to the previous post. I've got a untested NeoMagic device, I've been meaning to port (if it already doesn't work).

The BSDs are also another place to look, instead of just Linux (sources).

Yeah, I actually had looked into the OSS drivers, hoping that they would be easier to port, since they support a wide range of operatings systems (not just Linux, but also the BSDs and even Haiku OS).

But then in April 2024 @jiyunomegami submitted a PR in which they added support for additional sound cards, by porting ALSA driver sources from the Linux kernel. So I figured that would be the way to go forward. Crazii accepted and merged that PR a while ago and it's been part of SBEMU releases since.

jiyunomegami also provided some porting instructions for people who'd like to port additional Linux drivers to SBEMU.

The Linux drivers are GPLv2, which is compatible with the SBEMU license. SBEMU also needs to be licensed under GPLv2, since it uses sources from DOSBox.

Hence my concern with using Mpxplay drivers (or any Mpxplay code for that matter), due to possible license incompatibility issues, since Mpxplay isn't licensed under GPLv2. I believe that the Mpxplay developer imposed some kind of restriction where the sources from Mpxplay could not be used to develop an alternative project to Mpxplay. Although SBEMU is not an alternative to Mpxplay, this is still a restriction that would technically make the Mpxplay code incompatible with GPLv2 code.

There do appear to be GPLv2 license notices and references to Linux driver sources in some of the header and source files of the Mpxplay project. It's not up to me to determine whether or not the Mpxplay developer is in violation of any license. I just want SBEMU to not be affected by any such potential legal issues.

It's also relevant to know that even the ported Linux drivers still require some Mpxplay glue/shim code in order to work in SBEMU, at least the way they are currently integrated.

I believe that @crazii got permission from the Mpxplay developer to use the driver sources from the Mpxplay project in SBEMU, but I'd prefer to see some formal public statement where the Mpxplay developer officially allows those sources to be included (and relicensed) in GPLv2 projects such as SBEMU.

Anyway, Linux drivers tend to get more support than OSS drivers these days. Simply because a lot more people are working on them and maintaining them.

@digger That was a excellent reply.

So I figured that would be the way to go forward.

Its convenient. It is the most direct path.

I had a chance to play for a moment with MSI Z270 PC MATE MB with Realtek ALC887 (modding BIOS to accept Coffe Lake) and SBEMU worked fine out of the box. Just tested with Doom, SFX and music. I also tried YMF744 PCI soundcard with DSDMA but it failed to initialize properly so SBEMU is the only way here.

I localized exactly the build where the playback speed on SB Live/Audigy has broken: UserBuild_2024.02.06_02-04
The latest one with correct playback speed is UserBuild_2024.02.05_06-40
Now it would be needed to diff the sources...
changed files are only: au_base.c and main.c

au_base.c:

1//sample rates
2unsigned int mixer_speed_lq(PCM_CV_TYPE_S* dest, unsigned int destsample, const PCM_CV_TYPE_S* source, unsigned int sourcesample, unsigned int channels, unsigned int samplerate, unsigned int newrate)
3
4OK:  const unsigned int inend=(sourcesample/channels) << 12;
5BAD: const unsigned int inend=(sourcesample/channels - 1) << 12; //for n samples, interpolation n-1 steps
6
7OK:   intmp2=ipi < total-ch ? intmp1+ch : intmp1;
8BAD:   intmp2=intmp1+ch;

main.c:
there are more changes in MAIN_Interrupt() function seems related to resampling... diff main.ok main.bad

145a46,47
2> static int MAIN_LastSBRate = 0;
3> static int16_t MAIN_LastResample[SBEMU_CHANNELS];
41128a1131
5>     if(!digital) MAIN_LastSBRate = 0;
61135a1139,1143
7>         if(MAIN_LastSBRate != SB_Rate)
8>         {
9>             for(int i = 0; i < SBEMU_CHANNELS; ++i) MAIN_LastResample[i] = 0;
10>             MAIN_LastSBRate = SB_Rate;
11>         }
121163c1171
13<                 count = max(1, count*SB_Rate/aui.freq_card);
14---
15>                 count = max(min(2,count), count*SB_Rate/aui.freq_card); //need at least 2 for interpolation
161176c1184
17<                 int16_t* pcm = resample ? MAIN_PCMResample : MAIN_PCM + pos*2;
18---
19>                 int16_t* pcm = resample ? MAIN_PCMResample+channels : MAIN_PCM + pos*2;
201186c1194,1201
21<                     count = mixer_speed_lq(MAIN_PCM+pos*2, MAIN_PCM_SAMPLESIZE-pos*2, pcm, count*channels, channels, SB_Rate, aui.freq_card)/channels;
22---
23>                 {
24>                     for(int i = 0; i < channels; ++i)
25>                     {
26>                         MAIN_PCMResample[i] = MAIN_LastResample[i]; //put last sample at beginning for interpolation
27>                         MAIN_LastResample[i] = *(pcm + (count-1)*channels + i); //record last sample
28>                     }
29>                     count = mixer_speed_lq(MAIN_PCM+pos*2, MAIN_PCM_SAMPLESIZE-pos*2, MAIN_PCMResample, count*channels, channels, SB_Rate, aui.freq_card)/channels;
30>                 }

Excellent work, @RayeR!

I'm currently at work, but when I have some time at home, I'll try to track down the Git commit of this change to see if the commit message provides any clue as to why this was changed.

I can then try reverting that commit and making a release. But then again, that might break or regress any issue that this change was intended to fix...

Other input and insights from anyone are absolutely welcome! Thanks. 🙏🏽