I did more testing, added and keep adding compatibility report to port above, to avoid generating zillion post..

Vmware actually works quite well too, only slightly different game set is working.. maybe because who its virtual HW is implemented, maybe because how its HDA is implement. Its virtual videocard driver seems a bit better and has not 15 years , repeatly reported keyboard, never fixed bugs (Qemu is the same with these).
Im quite surprised how great compatibility actually is.. Im looking on compatibility from overall virtual machine perspective, lots of bugs are not sound related, but i doesnt really matter for user, which care if game run well or not.

There is big open question which slowdown utilities are working well. if any with virtual machines.. I tried for example, Warcraft I, slowdown, setmul.. set Virtual CPU speed cap, but i wasnt able to find working configuration.. even on 1% CPU on Core i9 9900K keyboard scrolling was too fast.. with slowdos, there big deley between each game update and key scrolling still was too fast. Lots of old games.. simply not using some real frame pacing and programmer to run fast as possible and its not working with super fast CPUs.

Overall situation:
My uneducated guess, is that sound cards arent super complex as lets say GPU, they just should to play some sound effect right at right time, that is all.. And number of there instruction or function to call, to make it happen should be pretty limited, low.. so it maybe does not need zillion hours of hour.. to adjust it and make it more compatible, there are simply only a few repeating problems..

General list of problems :

1. Machine crash on try to detect sound card.
2. Card detection fails for some reason.
3. Sound effect dont play at all
4. Sound effect play with some addition not wanted noise
5. Sound is lost after while for some reason
6. Sound or music effect are too silent for some reasons

- Lots of these problem are generated probably on based on differences how much standard is chipsets HDA implementation.. or maybe on bugs in its SB-EMU implementation, who knows.
- Its hard to tell how much bugs are generated but Jemmex itself, quite and lot for sure.. They are not maybe bugs, but there is not 100% parity with EMM386, Himem.sys or other Microsoft memory behavior, which games were developed for..

Because all virtual machines are the same, it should be hard to push compatibility further, it would help physical cards compatibility too and its much easier to test and it seems are some real deal and alternative to Dosbox or PCem.

There is Qemu too, but situation is quite same with Virtualbox, lots old Dos related bugs, in reported some of them year ago.. not real will to fix them, developer are lazy to simulate them, they would expect some ready to run virtual machine to set them or so.. which could not be done because MS-DOS license and they are lazy to setup it on their own 🙁 Other thing is really unfriendly virtual machine setup through commanline parameters and obsolete GUI wizards for Windows..

Today, I continued to test SBEMU, this time with QEMM and my PCI Sound Blaster card worked with it, as well as the game Terminal Velocity, which did not work with Jemmex!
The downside is, that QEMM doesn't support SETPVI.exe, which I use as a compatibility fix when needed.
According to the description:
SETPVI will set the PVI flag in cpu register CR4.
When this bit is set, it's not possible to disable interrupts in ring 3, since CLI/STI will modify the virtual interrupt flag (VIF) only.
Does anyone know, if theres another way to enable this fix or make SETPVI working while QEMM is active?

Well its shame that someone (it seems that Symantec+Norton does) who owns the rights is not selling some digital copy of QEMM to make buck or two.

Please how to get free memory on Impulse Tracker?

You need to create EMS memory, a lot of it, and free as much low memory as possible. So only load drivers that are needed for Impulse Tracker, because once you enable EMS the page frame will consume a lot of upper memory.

Question for both @crazii and @Baron von Riedesel:

I see that crazii's fork of HX/HDPMI has diverged from upstream. As of this time of writing, crazii's fork is both 34 commits ahead and 14 commits behind Baron von Riedesel's version: https://github.com/crazii/HX

Is it the intention to eventually reconcile these different changes, or are these separate forks permanent, with crazii's repo having required changes for SBEMU, whereas the upstream version will work only with VSBHDA?

I'm asking this, since I'm setting up a CI/CD pipeline for SBEMU through GitHub Actions Workflow. I have SBEMU building successfully in the pipeline, but when I want to have everything automatically packaged up for release, it's not clear which version of HDPMI32i.EXE should be included and from where it should be fetched. crazii's latest build of HDPMI32i.EXE in SBEMU.1.0beta3.zip has a checksum that I can't match with any of the releases in either the original or the forked HX repo.

It would be nice to have some clear versioning for HDPMI32i.EXE, since this is a key ingredient that makes SBEMU work in the first place. Even better if HDPMI could also be built automatically in a GitHub Actions Workflow. I'd be happy to help with that.

Thanks.

I've created Draft Pull Request out for setting up a CI/CD pipeline to have SBEMU built and packaged automatically into a ready-to-flash bootable USB image, whenever any changes are pushed.

I've asked @crazii to review it, but perhaps others here would be interested in reviewing it, and suggesting improvements as well?

I also have some outstanding questions that I hope others here might be able to help me with.

See https://github.com/crazii/SBEMU/pull/21

Thanks! 🙂

Well if these 2 implementations could not be merged into working version, maybe its possible merge them with some optimal command line switch.. to use original (withoutt it) or craziis implementations with it.. I used for my testing simply most newer versions of HDPMI and JLOAD, regardless of project.
I thing that such approach is better than have 2 different projects..

So far, I have tested about 20 well-known DOS games, two of them crashed at startup (Comanche and Spear of Destiny) and one (Witchaeven) works, but doesnt produce any sound ,even after sound setup.
Btw, Terminal Velocity also works with jemmex, the problem was too much RAM, which should be reduced to 32 or 64Mb.
Other workin games are: Gp2, Indy Car Racing 1&2, Doom 1&2, Heretic, Hexen, Wolf3d, X-Wing, Tie Fighter, Dark Forces, Descent, Indy 500 and few more.
Also, My SB card doesn't produce sound after all, even though it goes through a complete sbemu initialization with qemm, probably due to the lack of support for the ICH7 chipset, so I'll take it out and just use the onboard card, which produces really great sound.
At the moment, my main dilemma is how to free more conventional memory with Qemm 7.5, because every attempt with the optimize command crashes on the first reset.
The same happens if I manually add the switch "ON" and especially in the line where the swap file is located (SWAPFILE=DPMI.SWP SWAPSIZE=1024)
With default DEVICE=C:\QEMM\QEMM386.SYS, everything works fine, but I only have 547Kb of RAM.
With Jemmex I can free up 592Kb, which is enough for all the games I've tried so far, I don't know if it's possible to do better than that with this sbemu setup.
Since Jemmex has performed really well, I'm thinking of abandoning qemm completely, although its undoubtedly a powerful memory manager...

@retrofan011 Which version of Comanche did you try? There is a patch for earlier revisions of that game that makes them use a proper DOS extender. You might have better results trying SBEMU with this game if you have that patch applied.

You can find the patch in this GitHub issue thread (unrelated to SBEMU).

I managed to quick test 100 games in Vmware+SB-EMU:

Yeah virtual machine Dos gaming is now real deal and alternative to Dosbox, thanks to SB-EMU effort!

Compatibility rate is quite high 56% game are running, i would say that 15% game too fast problems, or other Vmware rendering problems (but SB-EMU part is fine) and 1/4 or 1/3 of games is sort not working, im testing some hard ones too, same as some PC spearker only game to keep testing mix about real.

These results are quite impressive results for such new project, i expected just few games running. I already wrote about VM gaming advantages above, but there are simply things with fast Dos Vm can do and all Dosbox ports so far cant too.. same as PCem.

It could get only better, with future releases of SB-EMU and some JEMMEX improvements.. You can see my errors it sheet.

Im quite low on conventional memory too - 568KB, what is not typical with virtual machines without JEMMEX, this actually used to be benefit of Dos VMs..

You can help me to make more games running, i was always able to try lots of configurations and push it a bit futher on my own.. but im not familiar with JEMMEX magic line parameters and some games are clearly complain about memory setup.. So far i used for all testing this:
DEVICEHIGH=C:\Drivers\JEMM\JEMMEX.EXE 32768 SB SPLIT RAM VERBOSE
So far i was lazy to tune it up.. I cant just from top of my head.

Some games still needs these runtime errors fixes, but i cont count them like not working.. i have somewhere already patched version.

Big question is now also if and which some slowdown utility would work with Vmware, i will not test VirtualBox its just worse.. not worth of saving money IMHO and i found some Dos related 15 years old unfixed bug reports, its same as QEMU, there is not real will to fix these things..

https://docs.google.com/spreadsheets/d/1VKadO … of=true&sd=true // Y+Z collumns at least now.. search for Vmware workstation 17+ SB-Emu, Sound blaster emulator +Wmware set to HDaudio in *.vmx file by sound.virtualDev = "hdaudio" + JEMMEX,IRQ5

retrofan011 wrote on 2023-06-04, 18:33:

Also, My SB card doesn't produce sound after all, even though it goes through a complete sbemu initialization with qemm, probably due to the lack of support for the ICH7 chipset, so I'll take it out and just use the onboard card, which produces really great sound.

FWIW, it's not related to the ICH7, the requirement for ICH5 or older is for legacy SB support for PCI sound cards when using their native drivers as it depends on hardware support that's only present in ICH5 and older. SBEMU outputs to PCI audio controllers in their native mode.
Looking earlier in this thread, you're the 2nd person to try a card based on the AudioPCI i.e. ES1371/1373/CT5880, Baron von Redesel was the first and he didn't get sound either, not even in MPXPLAY, which suggests a bug in the MPXPLAY sound driver.

digger wrote on 2023-06-04, 19:31:

@retrofan011 Which version of Comanche did you try? There is a patch for earlier revisions of that game that makes them use a proper DOS extender. You might have better results trying SBEMU with this game if you have that patch applied.

You can find the patch in this GitHub issue thread (unrelated to SBEMU).

Today I tested two patched Comanche versions, CD and standard HD, but still no sound.
I ran soundset.exe wth all valid parameters, tried with and without EMS memory, but no luck.
Has anyone managed to get sound from the Comanche so far and with what settings?
The good news is that the other few problematic games are not due to sbemu, I simply found other versions of these games (Spear of Destiny, Witchaven) and they work now.
Out of a total of about 20 games, currently only Comanche has no sound, although the game itself works perfectly.
The sample wasnt large, but still this percentage of working games with proper sound emulation is really good.

I tested my Commanche Maximum Overkill (its data are proven on some real machines), its the same setup enable to set it right, but it dunno if it actually testing something.. no sound in game..
I have some Commanche Maximum Overkill demo too.. and it even refuse to start with this message:
SYS Error: Unable to enter 32-bit, mode, processor is in virtual 8086 mode. Most likely you are running an EMS emulator such as QEMU or 386 Max. Pleas read manual for possible solutions.
So i would say JEMMEX problem..

This game is known to be picky as far as i remember..

ruthan wrote on 2023-06-05, 20:45:

I tested my Commanche Maximum Overkill (its data are proven on some real machines), its the same setup enable to set it right, b […]
Show full quote

I tested my Commanche Maximum Overkill (its data are proven on some real machines), its the same setup enable to set it right, but it dunno if it actually testing something.. no sound in game..
I have some Commanche Maximum Overkill demo too.. and it even refuse to start with this message:
SYS Error: Unable to enter 32-bit, mode, processor is in virtual 8086 mode. Most likely you are running an EMS emulator such as QEMU or 386 Max. Pleas read manual for possible solutions.
So i would say JEMMEX problem..

This game is known to be picky as far as i remember..

That's what that patch that I mentioned was for.

digger wrote on 2023-06-05, 22:27:

ruthan wrote on 2023-06-05, 20:45:

I tested my Commanche Maximum Overkill (its data are proven on some real machines), its the same setup enable to set it right, b […]
Show full quote

I tested my Commanche Maximum Overkill (its data are proven on some real machines), its the same setup enable to set it right, but it dunno if it actually testing something.. no sound in game..
I have some Commanche Maximum Overkill demo too.. and it even refuse to start with this message:
SYS Error: Unable to enter 32-bit, mode, processor is in virtual 8086 mode. Most likely you are running an EMS emulator such as QEMU or 386 Max. Pleas read manual for possible solutions.
So i would say JEMMEX problem..

This game is known to be picky as far as i remember..

That's what that patch that I mentioned was for.

Yes, patched game works normally, but stil no sound with sbemu...

has anyone tried to play Another World? I incredibly get the sound, but it sounds very bad and "croaking". I've tried in both real and protected mode, slow and fast hardware under settings but no luck, can't get it sound like on Dosbox, and i am using real PCI SB Live. If someone else tried or can confirm it sounds like this for everyone, i'll apprecciate that 😁

digger wrote on 2023-06-05, 22:27:

That's what that patch that I mentioned was for.

I have this problem only with demo and patch does seems to be only for full version..

VenomSpark wrote on 2023-06-06, 22:53:

has anyone tried to play Another World? I incredibly get the sound, but it sounds very bad and "croaking". I've tried in both real and protected mode, slow and fast hardware under settings but no luck, can't get it sound like on Dosbox, and i am using real PCI SB Live. If someone else tried or can confirm it sounds like this for everyone, i'll apprecciate that 😁

Dont be lazy check my sheet, i tested it too..

Bruno128 wrote on 2023-05-07, 22:47:

If you have a modern-ish graphic card with hdmi, run SBEMU /SCL to see if it is not trying to output to this HDA device.

I have finally fixed the problem by using the /o0 command line parameter. Everything now works fine. Tested on Doom and Duke3D. I now have a true DOS with sound on a Ryzen machine!

Just thinking loud, how hard would it be to add CMS emulation. If adlib emulation is present. Or maybe even Tandy emulation.