Methanoid wrote on 2024-10-14, 14:41:

If I use JEMMEX or HIMEMX then SBEMU detects my AMD GPU HDA audio but both DOOM and DUKE3D crash when loading the protected mode […]
Show full quote

If I use JEMMEX or HIMEMX then SBEMU detects my AMD GPU HDA audio but both DOOM and DUKE3D crash when loading the protected mode Dos4GW thing

If I dont use JEMMEX/HIMEMX then SBEMU doesnt detect my GPU HDA so no sound.

Interesting I don't see any posts from people confirming they have GPU HDA working (Nvidia or AMD) so maybe thats the problem I have
SBEMU compatibility reports list | Navigation thread

I guess I am forced to use onboard sound or a sound card?

As for VSBHDA ( and - at least - old versions of SBEMU ): sound output via HDMI is deactivated in the HDA driver code. HDMI devices install their very own HDA device, and this device has only "digital" widgets. The driver code will simply skip such HDA devices. See source SC_INTHD.C, flag AC_WCAP_DIGITAL ( 2 occurances ):

1	if(node->type == AC_WID_AUD_OUT) {
2		if(node->wid_caps & AC_WCAP_DIGITAL)
3			return 0;

I haven't tried if HDMI would work if this "digital" filter is removed, because I have no HDMI monitor available.

Hello good people, I'm struggling with make sbemu work with my P4S5A/DX+(V5.1A) (https://www.ecs.com.tw/he/Product/Motherboard … s/specification).
Apparently it works fine in doom, but when I try blood (demo version) it hangs up when the music is enabled, apparently works flawlessly with just sounds (even at 44100), but as soon I enable the music from blood setup, it hangs sometimes after less than a minute, sometimes a bit more.
I tried the general midi switch(/SCMPU) but it makes sbemu to crash with an error.
I've tried different switches: /t6, /fixtc, /k44100 (or the standard value), nothing apparently fixed the issue.
I don't know if it's a blood issue, my motherboard that is flaky, in doom apparently everything works fine.

Pro tip: write down the error, and attach any logs if they exist

Nemo1985 wrote on 2024-10-25, 15:19:

Hello good people, I'm struggling with make sbemu work with my P4S5A/DX+(V5.1A) (https://www.ecs.com.tw/he/Product/Motherboard … […]
Show full quote

Hello good people, I'm struggling with make sbemu work with my P4S5A/DX+(V5.1A) (https://www.ecs.com.tw/he/Product/Motherboard … s/specification).
Apparently it works fine in doom, but when I try blood (demo version) it hangs up when the music is enabled, apparently works flawlessly with just sounds (even at 44100), but as soon I enable the music from blood setup, it hangs sometimes after less than a minute, sometimes a bit more.
I tried the general midi switch(/SCMPU) but it makes sbemu to crash with an error.
I've tried different switches: /t6, /fixtc, /k44100 (or the standard value), nothing apparently fixed the issue.
I don't know if it's a blood issue, my motherboard that is flaky, in doom apparently everything works fine.

Try with VSBHDA: https://github.com/Baron-von-Riedesel/VSBHDA

myne wrote on 2024-10-26, 01:24:

Pro tip: write down the error, and attach any logs if they exist

Are you talking about the error when I use the /SCFM or /SCMPU?
Here is it:

Let's see if it's going to be of any use.
While when blood crashes I get no error log just an hard lock.

vico wrote on 2024-10-26, 03:11:

Try with VSBHDA: https://github.com/Baron-von-Riedesel/VSBHDA

Unlucky it doesn't support any sis chipset and infact it doesn't detect any sound card.

Edit: I experience the same crash on duke3d (shareware version) if any emm is loaded, otherwise duke runs fine with music turned on, while blood it hangs in any condition with turned on music.
I really wonder if the problem is my motherboard or what.

Edit: I can add that if SBEMU is loaded the speedsys benchmark hangs during the memory speed test.

digger wrote on 2024-08-24, 13:36:

wierd_w wrote on 2024-08-20, 05:03:

It might be worthwhile to make sbemu 'multi cpu aware', just to saddle core 1 (and not core 0) with such servicing.

That would require the implementation of a multi-core process scheduler in SBEMU. At that point, we'd be basically turning SBEMU into a mini-OS. Although it's an intriguing idea to unlock the unused core(s) of modern multi-core CPUs in DOS, it would blow up the scope of the SBEMU project considerably. Perhaps if an EMM manager such as Jemm could be extended to offer multi-core support, and expose such functionality through some sort of DOS API, that could be a way for SBEMU and other emulators to tap into such functionality.

I love this idea, but come to think about it, this is just a hypervisor, at this point we should probably just run qemu-kvm on linux and call it a day, especially considering crazii expressed interest in emulating VESA on modern GPUs.

Well, until we get that sb16 bug fixed in qemu:
https://gitlab.com/qemu-project/qemu/-/issues/469

digger wrote on 2024-08-24, 13:36:

That would require the implementation of a multi-core process scheduler in SBEMU. At that point, we'd be basically turning SBEMU into a mini-OS. Although it's an intriguing idea to unlock the unused core(s) of modern multi-core CPUs in DOS, it would blow up the scope of the SBEMU project considerably. Perhaps if an EMM manager such as Jemm could be extended to offer multi-core support, and expose such functionality through some sort of DOS API, that could be a way for SBEMU and other emulators to tap into such functionality.

Would it though...?
Is there any reason the second cpu can't be treated like any other device?
Load driver, let it do its thing. Report back to kernel as required.

You would have cache coherency and contention issues, as the other cores are not actually discrete cpus with their own private L1, like on very early SMP boards.

This and more, are what shedulers deal with, to ensure out of order, and asynchronous transactions dont evict cache entries, and that race conditions dont occur from memory changing while the other CPU thinks it hasnt, because it already started an instruction fetch cycle with now outdated data from its own, earlier cache read.

Making sure the cores dont step on each other this way is very needed.

Maybe if you could fully disable the cache use of all the other cores?

Is that even possible to set?

However, I was thinking more along the lines of:

CPU1 runs a VERY MINIMAL program, that writes on the IO bus, and raises bus control lines, AS IF it were a discrete CPU.

EG, it raises the bus hold request, bus hold acknowledge, bus check, bus request, etc... as if it WERE a discrete CPU, with core 0 checking for and responding appropriately, these 'seemingly internally raised' signals.

This way core 0 and core 1, can stay more or less in concert, by having waitstate and condition checks on said signals.

It's probably *completely* off base, but I wonder if you could DO that...

Falcosoft wrote on 2024-10-14, 14:57:

Methanoid wrote on 2024-10-14, 14:50:

Falcosoft wrote on 2024-10-14, 14:45:

What is the crash messages when you use HIMEMX and loading DUKE3D ?
I'm sure it's not the same as in case of JEMMEX.

It just hangs... I get the DOS4GW loading text and then machine non responsive.. No useful messages. Same with DOOM. I'm sorry, I just assumed that cos AMD HDA devices appear in the code that they would work. I need to dig out a 3.5mm speaker or audio cable and try the Onboard sound that I have avoided like the plague!!

Even if you do not want to use your DOS setup this way such a test would be helpful to determine if the crashes/errors have anything to do with your chosen video card's HDA output or also happens with your onboard HDA anyway.

Hi, I installed a SB Live and removed the card with the Audio HDMI codec and put a Win98 compatible card with no audio portion. I disabled the LPT/COM and onboard sound in BIOS. HWinfo reports IRQ5 is taken by SATA so by default SBemu uses IRQ7 and I can also use the /i=7 switch but both get me a loud buzzing from the sound output. If I ignore that and try to run DOOM it hangs (no output or error messages). I guess since I am using SB Live I could use that in DOS anyway but would be nice to get SBemu working for more options

Methanoid wrote on 2024-10-28, 20:56:

Falcosoft wrote on 2024-10-14, 14:57:

Methanoid wrote on 2024-10-14, 14:50:

It just hangs... I get the DOS4GW loading text and then machine non responsive.. No useful messages. Same with DOOM. I'm sorry, I just assumed that cos AMD HDA devices appear in the code that they would work. I need to dig out a 3.5mm speaker or audio cable and try the Onboard sound that I have avoided like the plague!!

Even if you do not want to use your DOS setup this way such a test would be helpful to determine if the crashes/errors have anything to do with your chosen video card's HDA output or also happens with your onboard HDA anyway.

Hi, I installed a SB Live and removed the card with the Audio HDMI codec and put a Win98 compatible card with no audio portion. I disabled the LPT/COM and onboard sound in BIOS. HWinfo reports IRQ5 is taken by SATA so by default SBemu uses IRQ7 and I can also use the /i=7 switch but both get me a loud buzzing from the sound output. If I ignore that and try to run DOOM it hangs (no output or error messages). I guess since I am using SB Live I could use that in DOS anyway but would be nice to get SBemu working for more options

The 1st thing you should try is to switch the HDD controller form AHCI/RAID mode to compatibility/IDE mode. It can sound counter intuitive but e.g. on my Thinkpad T430 without this modification no EMS memory manager can work without crashes.

AHCI controllers sit on parts of the adapter rom region, and exactly which parts seem to be very motherboard specific.

Using an 'X=foobar' directive to make the ems manager completely ignore certain regions, can alleviate this issue.

Eg, if your ahci controller hangs onto E000, all the way up to the bios at F000, you would add

X=E000-EFFF

Sadly, this use of the area does NOT come with the device presenting a rom header byte sequence at its start, to tell DOS to keep its hands off.

This makes 'figuring out where the boandaries are' a trial and error task.

wierd_w wrote on 2024-10-30, 01:25:

AHCI controllers sit on parts of the adapter rom region, and exactly which parts seem to be very motherboard specific. […]
Show full quote

AHCI controllers sit on parts of the adapter rom region, and exactly which parts seem to be very motherboard specific.

Using an 'X=foobar' directive to make the ems manager completely ignore certain regions, can alleviate this issue.

Eg, if your ahci controller hangs onto E000, all the way up to the bios at F000, you would add

X=E000-EFFF

Sadly, this use of the area does NOT come with the device presenting a rom header byte sequence at its start, to tell DOS to keep its hands off.

This makes 'figuring out where the boandaries are' a trial and error task.

Unfortunately sometimes even setting the correct region to exclude is not enough since the AHCI firmware corrupts the extended BIOS data area anyway:
https://github.com/PluMGMK/ahcifixd.sys

SBEMU has been working on my X230 Thinkpad flawlessly. And now that I tried it on a X280 it also mostly works. But there are some freezes while playing sounds once in a while for a split second and the sound kind of buzzes. It happens both with digital sound in Doom and Adlib in Attack of petscii robots. Is there a way to get rid of that? The laptop has Realtec HDA sound.

Hi,
I'm happy to report, that SBEMU works on Vortex86MX based eBOX-3350MX.
There may be memory mapping conflicts (mine reported E401-EC00), probably due to USB controller (there's no PS/2 port).
Could not get IRQ7 to work (could be USB conflict as well). Had to use IRQ5 instead.

Otherwise, very slow USB drive speeds in DOS and keyboard lags (not related to SBEMU).

I suppose, other Vortex86 SoC's with integrated HDA design should be compatible with SBEMU (DX2, DX3 amd MX at least)

I just registered at Vogons just to leave this message of success. I have a Dell Optiplex GX260 2.4 GHz P4 with Intel 845G chipset and 2GB ram. Currently setting it up as a Windows 98 game machine and I thought that dos was out of the question due to the lack of an ISA slot. Enter crazii and his wonderful sound blaster emulator for dos, just got it up and running with Jemmex and my first quick attempt was with Apogee's Raptor. All of the sounds seem to work just fine, if just a tiny bit off. I couldn't be happier!

Thank you so much for breathing new life into such an old system, manufactured in 2003 this box was on the tail end of Windows 98 support so it contains all compatible hardware. Now with sbemu it can also be a kick ass dos box at the same time, you guys are the best!

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.

Does anyone else have any issues with the BOOM game in freedos? It's a version of Doom that uses the Allegro library. It seems to freeze while loading. I'm thinking it has something to do with allegro because the setup program, asetup.exe, doesn't want to run either. I've been able to run several other games just fine, and all the drivers and dll for sbemu loads without any problems. It seems to be some kind of memory issue.

Sorry if this issue has been addressed before, but this thread has gotten pretty long.

@CMR779

Unfortunately I don't have an answer but I also experienced the same issue. First tried sbemu on freedos 1.3 with a few games including boom and freedoom and sound didn't work. I dug out some old Dos installs that I had put together 20 years ago and they seem to work just fine. If they both use the same libraries for sound than you're probably correct.

I've used Sbemu with the Dos port of Mplayer. It uses Allegro, for audio. That was with an early version of Sbemu. I haven't testing it in a while.

It's time for another report. My last report was here: Re: SBEMU: Sound Blaster emulation on AC97

• Hexen and FastDoom in HiRes work when run without jemmex (real mode disabled).
• Populous 2 goes past Loading screen now. Sound works. Unfortunately game is not stable on my PC and hangs after some time. Looks like jemmex memory issues again. I've tried Populous 2 in VirtualBox and didn't face any problems.
• Virtual Pool needs "jemm386 NOVCPI" and I have to run it in lower resolution than normal.