Just tried Dune 2 with Yamaha YMF744 and SBEMU. This time speech works but when I run the game there's a loud hanging note which disrupts sound experience.

Hi ! Just to say that I installed SBEMU on two different machines :
* Intel NUC (don't remember the model) under FreeDOS 1.3. Some good results, just a problem with Pinball Dreams which freeze as soon as the sound should start (but Doom is ok for example...). I'll try with DOS 7.1...
* Dell Precision M6300 (Core 2 Duo E8400) under DOS 7.1. No sound from the internal speakers but perfect from the 3.5mm output ! (Really perfect ! Sound is incredible !). So... A very very nice portable solution to play old DOS games ! 😀

Thank you for this software masterpiece !

eM-!3 wrote on 2024-12-02, 00:07:

Just tried Dune 2 with Yamaha YMF744 and SBEMU. This time speech works but when I run the game there's a loud hanging note which disrupts sound experience.

Try beta 3 of sbemu. Anything after that had issues with my ymf724. Also, the sound effects will just stop at some point, but that's a bug with the game. There's a fix online that requires replacing some of the game's sound files.

mannycalavera wrote on 2024-11-21, 22:03:

There's a thread in this forum about installing Windows 98 in a laptop Dell D600 and i can confirm that sbemu works like a charm, making this laptop a great MD-Dos/Windows 98 setup.

I have a Dell D600 too and have been experimenting with the pd01x dock and a PCI sound card. And it actually works. So there are even more options for this laptop for retro sound.

eM-!3 wrote on 2024-12-01, 23:05:

...FastDoom in HiRes work when run without jemmex (real mode disabled)...

I'm using FastDoom v.1.06. Real mode is disabled, but there is no sound. What am I doing wrong?

Reports list updated.
SBEMU init output must by default include verbose PCI ID detection because people are clueless about their hardware (especially thin clients, laptops) which makes testing process ineffective.

Bruno128 wrote on 2025-01-01, 19:37:

Reports list updated.
SBEMU init output must by default include verbose PCI ID detection because people are clueless about their hardware (especially thin clients, laptops) which makes testing process ineffective.

PCI ID detection is only part of the problem, since many different HDA implementations use different codecs, which, if I understand correctly, all need to be explicitly supported by the driver.

But I agree that it would definitely help to have SBEMU display more friendly messaging if even the expected supported PCI IDs are detected in any of the devices in the system. And that doesn't seem hard to implement either. This actually seems like it would be within my abilities, with my still relatively limited C programming skills.

Out of curiosity, the developer seems not active anymore since last spring, any news?

As many of you have noticed, development and maintenance of SBEMU has stalled since crazii went off the radar. This isn't the first time that he has taken a hiatus from his GitHub projects. He had left, returned and resumed development on SBEMU before. And of course that's all perfectly within his right to do. He's working on these projects and sharing his work with everyone voluntarily, after all.

But it is becoming increasingly clear that in order for SBEMU to thrive, to fix the many reported bugs and issues, add requested features and help it mature, the project is going to need more volunteers who are skilled in C programming and preferably also specifically device driver programming.

I've been trying to make myself useful as a contributor to this project. Notably, I've been trying to set up a CI/CD pipeline with an automated test, to quickly detect breaking changes, but for some reason, I cannot get the output to work properly in a QEMU VM. Also, with some guidance, I started porting another driver from the Linux kernel sources over to SBEMU, but I've been working on other things as well, so progress on this has been slow. Help is absolutely welcome with all of these things, of course!

But ultimately, more skilled C hackers (more skilled and experienced than I) helping out with this project would really help.

Also, talking from a personal point of view here, it's still unfortunate that VSBHDA was "forked" from SBEMU over some differences in opinion w.r.t. how certain things should be handled and exposed in the tools that SBEMU depends on, notably HDPMI. Crazii had forked HDPMI to add functionality that he believed was necessary for SBEMU to properly work. But Baron von Riedesel, the maintainer of the upstream HDPMI, Jemm and QPIEMU.DLL projects that both SBEMU and VSBHDA depend on, implemented these things in these projects differently and then forked VSBHDA from SBEMU with the idea to keep it compatible with these upstream utilities.

It just feels to me that everyone would be served better if...

• ...the SBEMU and VSBHDA projects could reconcile their differences, and even if not merge outright, cooperate more and share code base and APIs so that both of them would depend on the same unforked upstream versions of HDPMI, Jemm and QPIEMU.
• ...we could rally more volunteers with the necessary skills to contribute to SBEMU, VSBHDA, or preferably both.

And to be clear, I deeply respect and appreciate the hard work that both Baron von Riedesel and crazii have poured into these amazing projects over the last few years. They finally cracked the problem of missing DOS sound support on newer hardware, and were the first to get this working even with protected mode DOS games, which was quite a feat. Now if only we can get more skilled and talented people to join in maintaining and improving these projects...

Let's make reliable and high quality universal legacy DOS sound device emulation a reality in 2025!

Curious to read what other people's thoughts are on this.

digger wrote on 2025-01-02, 00:52:

Curious to read what other people's thoughts are on this.

Can you build a relation tree between vanilla SBEMU, thp’s fork and VSBHDA? I’m really lost about which version of which is the most up-to-date qua issues resolved

Bruno128 wrote on 2025-01-02, 07:23:

digger wrote on 2025-01-02, 00:52:

Curious to read what other people's thoughts are on this.

Can you build a relation tree between vanilla SBEMU, thp’s fork and VSBHDA? I’m really lost about which version of which is the most up-to-date qua issues resolved

Well, to start with: thp's "sbemu-x" fork has already been merged back upstream into SBEMU. This can be derived from the fact that he added a notice about this to the README of his fork in the last commit in his fork, after which he archived his fork on GitHub:

**The changes in this project have been merged upstream. It's recommended that you just use [SBEMU](https://github.com/crazii/SBEMU).**

So that leaves upstream SBEMU by crazii and VSBHDA by Baron von Riedesel (a.k.a. "japheth", a.k.a. Andreas Grech). And as far as I understand, these projects can be summarized as follows:

• SBEMU: The oldest of the two, developed by crazii (with help from Baron von Riedesel), that was the breakthrough w.r.t. proper DOS sound device emulation in both real mode and protected mode games. It currently depends on Jemm and QPIEMU (a loadable module for Jemm that emualtes QEMM's I/O port trapping API) for real mode emulation, and a separate fork of HDPMI for protected mode emulation.
• VSBHDA: Kind of a fork of SBEMU by Baron van Riedesel, made to work with the unforked upstream versions of Jemm, QPIEMU and HDPMI, all of which are projects that he developed and continues to maintain upstream. I'm not sure, but VSBHDA might actually just be a "fork" in a spiritual sense, and perhaps written from scratch. I haven't compared the code bases myself yet, to be honest.

If I understand the difference of opinions between Baron von Riedesel and crazii correctly, the disagreement lies with how protected mode port trapping is handled and made available by HDPMI. I believe that crazii was also exploring the development of an entirely separate DPMI server from scratch, written in C for better maintainability in his view.

If any of the mentioned parties read this, please feel free to provide any corrections or additions to this summary where needed! Thank you. 🙏🏾

Just to not forget:
With 1.0 beta4:
1. On NForce2 system (Abit NF7-S v2.0) ROTT hangs up on exit from game. OTOH SNDSETUP.EXE from the same ROTT exits smoothly.
2.readme: >except T6 for /T6 ... SBEMU should work for such cases, because no matter what '/T' is set, the full emulation is not stripped.
But it is simply wrong behaviour as stereo formats are different for 8 and 16-bit blasters. That's why trying to use /T4 leads to stereo swapped.
And for example Microsoft SBEMUL.SYS correctly differentiates T4 and T6 modes and respects this stereo format difference.

I think, at least my experience,.is that qpiemu is compatible for both sbemu and vsbhda. The difference is in hdpmi only - need to keep separate version for each which is not practical.
If I remember well there was some different opinions about sources that crazii included more source codes from mpxplay that might not be necedsary while japhet cleaned it out but it made it harder to keep update from mpxplay changes. But there might be also different opinions on hdpmi api as you told...

For me I see situation a bit suboptimal as I have to use both versions because of different features supported, even later sbemu still have a bug in speedup playback on sblive/audigy introduced in year 2024 and still wasn't fixed. Yes I should 1st search myself im what version exactly it has broken but time, time, time, I should first fix bugs and features in my own tools...

RayeR wrote on 2025-01-02, 14:20:

I think, at least my experience,.is that qpiemu is compatible for both sbemu and vsbhda. The difference is in hdpmi only - need to keep separate version for each which is not practical.

You're right, I should have been clearer about that part. Indeed, SBEMU uses the regular upstream versions of Jemm and QPIEMU.DLL for real mode emulation, as does VSBHDA. It's the HDPMI part, required for protected mode emulation, where the apparent "schism" appears to have happened between SBEMU and VSBHDA.

If I remember well there was some different opinions about sources that crazii included more source codes from mpxplay that might not be necedsary while japhet cleaned it out but it made it harder to keep update from mpxplay changes. But there might be also different opinions on hdpmi api as you told...

Actually, crazii acknowledged this, since japheth wasn't the only one that didn't like the dependency on Mpxplay sources for the backend sound drivers. I expressed concerns about this as well, due to the license implications being unclear. crazii expressed openness to eventually replacing these drivers, and later versions of SBEMU added support for additional PCI sound cards, based on Linux drivers ported over to SBEMU by jiyunomegami. Although those drivers do currently still use some source code from the Mpxplay project as "glue" or shim code. jiyunomegami provided a bit of a "porting guide" for Linux drivers in this GitHub post.

For me I see situation a bit suboptimal as I have to use both versions because of different features supported, even later sbemu still have a bug in speedup playback on sblive/audigy introduced in year 2024 and still wasn't fixed. Yes I should 1st search myself im what version exactly it has broken but time, time, time, I should first fix bugs and features in my own tools...

Don't feel bad. That's pretty much a problem that most of us have. So many projects to tinker with, so little time. 😕

But you're absolutely right about having these separate projects with different pros and cons to each of them, instead of having one unified project that has the best of both worlds.

I think a good next step would be to rally more volunteers to help with the project and make it a healthier open source collaboration with a larger development community around it than it's been so far.

I think I'm going to post a "help needed" banner in the README shown on the main page of the SBEMU project on GitHub. And maybe try to rally some potential contributers in the freedos-devel mailing list as well.

Do you think a separate topic here on Vogons ("C hackers wanted: SBEMU needs your help", or something like that) would be warranted here? I mean opening a separate developers/contributors topic, while this existing topic will remain for users and testers? What do you all think?

digger wrote on 2025-01-02, 21:22:

Do you think a separate topic here on Vogons ("C hackers wanted: SBEMU needs your help", or something like that) would be warranted here?

Trouble is any C hackers almost certainly have a million other projects they're neglecting 😀 (ask me how I know)

rasteri wrote on 2025-01-03, 13:24:

digger wrote on 2025-01-02, 21:22:

Do you think a separate topic here on Vogons ("C hackers wanted: SBEMU needs your help", or something like that) would be warranted here?

Trouble is any C hackers almost certainly have a million other projects they're neglecting 😀 (ask me how I know)

Oh, I'm sure. 😅 But the hope is that with enough C hackers contributing to it even sporadically, the project overall will still have a healthy average pace of improvement.

It's really not that easy for most people to understand each other's code.

You have to understand it before you can work on it.

It's why adding developers to a project often has a net value add less than the number of people.

Eg if 1 developer is 100%, 2 might be 180% and 3 might be 250.

There are exceptions if roles are clearly separate specialisations like UI and back end.

@myne Yes, I know, "the Mythical Man-month" and all that. Those are all valid points you make.

But still, an open source project with a large and thriving developer community around it would help it mature and improve way more quickly.

And of course such a community wouldn't form overnight. It would take time, for the reasons you mention.

SBEMU and VSBHDA have plenty of popularity on the user-side. Now if only we can draw in more experienced developers to help maintain and evolve these tools further.

Can SBEMU output to Covox/LPT-based dumb sound adapters? Asking because lots of Vortex86-based SBCs are very powerful but lack sound support. They do have parallel port headers though.

megatog615 wrote on 2025-01-06, 22:57:

Can SBEMU output to Covox/LPT-based dumb sound adapters? Asking because lots of Vortex86-based SBCs are very powerful but lack sound support. They do have parallel port headers though.

That would indeed be cool to add at some point. But don't those Vortex86 SBCs have PC/104 interfaces, which are basically ISA slots in a different form factor? That's what projects like the weeCee and the TinyLlama set out to do, right?