Yes it seems implemented in Linux so should be possible to port to DOS drivers...

Having trouble getting this working correctly with a SBLive CT4780. I can get it up and running, real and protected mode(no errors when running the commands in the howto) and I get sound. However, music is dreadfully slow on my Pentium 233 MMX and in 44100 mode it crashes the system. Descent, for example, seems to run slowly in the intro screens as the music is playing.

I guess the OPL emulation takes too much CPU; what if you disable the FM music and only work with Sound Effects?
Or what happens if you start up Epic Pinball, which uses Digital Music?

If that works you could perhaps combine SBEMU with OPL2LPT

veelstekel wrote on 2023-07-13, 17:23:

I guess the OPL emulation takes too much CPU; what if you disable the FM music and only work with Sound Effects?
Or what happens if you start up Epic Pinball, which uses Digital Music?

If that works you could perhaps combine SBEMU with OPL2LPT

Yes, I considered the possibility that SBEMU might be too CPU-intensive. I am going to try something like that.

I wonder if SBEMU could do 11025 it would be acceptable? At the moment it can only sample at 44100 and 22050. I wonder if it is using MMX/3DNow in any way? OpenWatcom seems to support MMX but maybe SBEMU isn't compiled with it.

Hasn't such machine PMMX an ISA slot? Why not use native SB or compatible and bother with SBEMU? Its for modern PCs without ISA...

RayeR wrote on 2023-07-14, 00:55:

Hasn't such machine PMMX an ISA slot? Why not use native SB or compatible and bother with SBEMU? Its for modern PCs without ISA...

I feel like this is kind of side-stepping the question. In my specific case I actually don't have an available ISA slot.

Anyway, another problem I have is that after I turned off OPL emulation, I have discovered that sound buzzes quite a bit with Soundblaster 16 mode in Descent(but not in Duke3d), even when I put the sample rate back up to 44100. Performance otherwise is pretty fantastic. It just seems to struggle on OPL emulation. I can get some performance back by using SBPro but the music still plays slowly.

Adding here:

I have an old mid 2000s era Toshiba with 2GB RAM, and AC'97 / ICH audio.
SBEMU finds it fine, and it seems working but I have run into some strange issues. I am unsure if it is related to strangeness of this machine or not:

This machine has a very strange memory map setup, and appears to be intended to live with winXP installed, not old realmode OSes like DOS or Win9X. The adapter rom region has the video bios and pals at C000-CFFF, with a few small 4k holes in this space. D000-DFFF is unambiguously free, but Clean-Booted system with no memory managers running, has MSD showing RAM mapped in here. Same with the E000-EFFF range.

That isn't too strange, except that MSD shows RAM mapped in there. EMM386 complains about RAM or Option Roms mapped into that space. MSD reports RAM, so that is not surprising.

At first, I thought maybe the system was just blanket turning on caching for the entire option rom space with no option to turn it off-- its a weaksauce phoenix bios, so I can see that being the case. So, I used himem.sys with /shadowram:off to try and turn it off. No dice. STILL maps RAM there. No idea why.

I interrogated it with UMBCHK from UMBPCI, because I was having severe stability issues, lockups, hangs, and other anomalous stuff when including that whole range for UMBs. DOS does not identify option ROMs in the region but the system is clearly using it for something important. UMBCHK identifies that the pages between E400 and EFFF are locked, and not available. After excluding this region, the lockups have ended, so I presume I have things "Configured Correctly" for QEMM97 now.

EG--

DEVICE=C:\QEMM\QEMM386.sys RAM X=B000-BFFF X=C000-CFFF I=D000-E3FF X=E400-FFFF FRAME=D000

which keeps it out of the monochrome screen buffer area (So things like infocom games play fine), and keeps it out of the small 4k holes in the C000 area, (and for some reason, out of some small 4k holes in the F000 area.), keeps UMBs neat and tidy, and out of "Whatever is trying to live at E400 that is so damn important."

Windows 98se is able to successfully boot, as long as the SBEMU driver is NOT loaded. It crashes early in the loading process if it is. The system is otherwise stable, and fully functioning like a champ, as long as the SBEMU driver is NOT loaded.
Which brings me to the problem--

games that use DPMI protected mode memory, like Doom, Doom 2, and Heretic, crash SPECTACULARLY as soon as digitized sound effects get played, when SBEMU is running. Fake OPL synthesis works just fine though-- Disable digitized sound effects, and it starts up and runs like a champ, just no sound effects.

I am unsure as to what causes this. Other games, like Wolfenstein 3d, or Warcraft II, work just fine.

I have tried various iterations on options for HDPMI32i, including keeping the LSB in low memory, and having all DPMI clients in separate memory spaces. LSB in low memory has no effect, and while "DPMI client in separate space" (-a flag) prevents crashing, it also prevents SBEMU from even producing sound with those games.
I have reproduced the same issue with JEMM386 and JEMMEX, both with win98se's fake "Dos 7", and with FreeDos. It happens regardless of the DOS running, or which of the memory managers is doing the job.

Strangely, Duke3D works just fine. Everything just works great. FM audio AND Fake OPL3.

Any suggestions?

edit--

Maybe try using the CWSDPMI.exe from duke3d to the affected games? Might be an issue with that extender not playing well with others?

wierd_w wrote on 2023-07-14, 06:46:

Maybe try using the CWSDPMI.exe from duke3d to the affected games? Might be an issue with that extender not playing well with others?

That won't work. You should be aware SBEMU needs HDPMI32i - and CWSDPMI and HDPMi32i both are DPMI hosts, that can only be used alternatively.

Since you mentioned that Duke3D works, but DOOM, DOOM2 and Heretic don't, it's pretty likely that the crashes are due to the "DOS4G/W" variant used by those games.

Baron von Riedesel wrote on 2023-07-14, 11:47:

wierd_w wrote on 2023-07-14, 06:46:

Maybe try using the CWSDPMI.exe from duke3d to the affected games? Might be an issue with that extender not playing well with others?

That won't work. You should be aware SBEMU needs HDPMI32i - and CWSDPMI and HDPMi32i both are DPMI hosts, that can only be used alternatively.

Since you mentioned that Duke3D works, but DOOM, DOOM2 and Heretic don't, it's pretty likely that the crashes are due to the "DOS4G/W" variant used by those games.

@Baron von Riedesel : thanks for clarifying. I have a follow-up question: exactly which version or build of HDPMI32i is usable for both SBEMU and VSBHDA? I'm asking this, since it's currently unclear exactly which build of HDPMI32i (from sources) is needed for both these emulators to work. Also, are there still two "forks" of HDPMI32i, or is there at this point a release (or specific Git commit) of the sources that can consistently build a version of HDPMI32i that works well with both emulators? Thanks again.

digger wrote on 2023-07-14, 15:27:

exactly which version or build of HDPMI32i is usable for both SBEMU and VSBHDA? I'm asking this, since it's currently unclear exactly which build of HDPMI32i (from sources) is needed for both these emulators to work. Also, are there still two "forks" of HDPMI32i, or is there at this point a release (or specific Git commit) of the sources that can consistently build a version of HDPMI32i that works well with both emulators? Thanks again.

There's currently no version of hdpmi32i that works with both sbemu and vsbhda - and, I'm afraid, it's virtually impossible to create such a version.

I am going to suggest that maybe the issue is related to the wonky hardware in that toshiba laptop.

I say this, because the exact same configuration (minus the memory area specific tweaking) on my Dell XPS 15, works like a charm with the same games that crash spectacularly on the Toshiba.

The Dell has a 7th generation i5 in it, and the Toshiba has a weaksauce AMD E240 "fusion processor." It would be worthwhile to know if other weak-knee'd laptops/netbooks from that era have similar issues, as it may be something related to the caching infrastructure of those processors and HDPMI32i. (Eg, the low-power E240 processor might have a 'bizarre' (to dos) pipeline or caching behavior. I've noted that MoSlo basically just stalls/hangs when I try to use it, for instance.)

I will just set up a USB thumb drive for use in my XPS 15, and just boot that when I want some real-metal DOS play.

There are a few games that dont seem to work correctly though, and fail to find the soundblaster being emulated, probably through an undocumented or nonstandard detection method. Dungeon Master, for instance, only detects Adlib, and insists the soundblaster is not present. Wizardry 7 likewise, fails to produce digitized sound with soundblaster (but it is known to have issues, even with DosBox. DosBox people suggest using PC Speaker for sound effects, but the interpolation method it uses to produce a differential frequency shift (and thus make discernable audio) with the PC speaker using just a fixed intensity pulse modulation with the PIC, creates a real nasty screeching with the AC97 codecs I have tried this with.

It would be real nice to get those working, but I am quite pleased with the games that do work so far.

I am really interested in this project, it looks like a MUST for the future of DOS audio.
Is it still active?

I have no audio issue with Toshiba Amilo Si 1848 by using latest version of SBEMU.

It's suposed to use a Realtek HD Audio. Intel HD audio (Realtek ALC861).

dontbugster wrote on 2023-07-18, 09:40:

I am really interested in this project, it looks like a MUST for the future of DOS audio.
Is it still active?

I've looking for updates in the GitHub project page, and there are no updates since the latest release (April 20).

such project is not easy. initial release can be easier than bug fixing cleaning up and perfection of the code

Github only shows what is pushed there.

He/she coule be working on things locally on their PC that we do not see.

Also, summer vacation time right now and perhaps some crunch time with studies or work before the summer.

I'm would be surprised if there are no further releases at some point.

I actually think the project should get picked up by FreeDOS.

megatog615 wrote on 2023-07-18, 16:43:

I actually think the project should get picked up by FreeDOS.

Getting maintained by a couple of devs could be great. And it is absolutely a game changer project, something never achieved like this before.

I just tried it on a different computer, an AMD phenom 3400 MHz and it totally works. That's amazing.

Definitely agreed. This is something that has been talked about for many years, but almost often written off as either not possible or not practical.

- Alex

megatog615 wrote on 2023-07-18, 16:43:

I actually think the project should get picked up by FreeDOS.

You're probably overrating the FreeDOS crowd's developer capacity. Those guys are quite happy running FD inside VBox and Qemu.

What might be considered, however, is to rename the "VDMsound" sub-forum to "SBEMU & VDMSound". These 2 projects have some relations.

And this thread should be moved to that renamed forum, the "Sound" sub-forum is the wrong place, covering sound hardware and sound hw drivers.

crazii wrote on 2023-03-05, 06:13:

Hi, I'm happy to announce that SBEMU is ready for more tests. :D […]
Show full quote

Hi, I'm happy to announce that SBEMU is ready for more tests. 😁

Purpose: for PCs with AC97/Intel High Definition Audio sound cards that doesn't have Sound Blaster support (vintage PCs after 2000 era, or modern PCs with HDA).
Supported PCI soundcards:

• Intel ICH
• nForce (nForce2 tested working)
• Intel High Definition Audio
• VIA VT8233 & VT82C686
• SB Live/Audigy (thanks to Baron von Riedesel for debugging)

Emulated cards: SB 1.0, 2.0, Pro, 16, 8 bit DMA & 16 bit DMA.
Notes: All on chip AC97 mother boards including Intel ICH and nForce both will reported as ICH. And it doesn't report the actual codec (e.g. realtek), but only the board (ICH). For HDA codec its the same.

Supported both real mode and protected mode games. Requirements:
HDPMI32i is needed for protected mode support, which is included in the zip file.
QEMM or JEMM is needed for real mode support. JEMMEX is included in the zip. It's optional, SBEMU can run without it and so without real mode support.

For more information, read the readme.txt in the zip and use /? in the command line.

Thanks to:

• MPXPlay's: sound card drivers
• DOSBox: DBOPL emulation
• HDPMI & JEMM: Port traps
• Folks in the forum that helped guiding & testing & improving the emulation

The original discussion can be found here: Possibility to write OPL3 sound driver for protected mode games, which initially intended for RetroWave OPL3 but then led to a pure soft emulation of SB & OPL.
The source code of SBEMU can be found here: https://github.com/crazii/SBEMU

Known issues: some games might not work properly, need more tests & improvement. 16 bit protected mode games are not supported - this remains a challenge so far.
Some games prefer VCPI over DPMI, need use "JEMMEX NOVCPI" AFTER loading HDPMI, or remove QEMM/JEMM and run the system without VCPI (also no real mode support).
Use /t6 to enable SB16 emulation.
Use /i5 to change the virtual IRQ if you get an IRQ conflict error, or adjust IRQ assignment in the BIOS.
Any suggestion and bug report are welcomed.

1.0 Beta3(latest):
Merge commit from HDPMI: add -x[n] option to limit memory further, -x1 limit mem to 128MB, -x2 limit mem to 64MB. this may help some games that do work with large memory. - thanks to @Baron von Riedesel.
Remove debug message for HDPMI.
Fix Epic Pinball sound spedup.
Add delay to DSP command 0Fh (IRQ request) to make Dynablaster work, and potentially other games.
Add DSP commands: 0E4h/0E8h (test read/write), 0E2h (DMA id), 045h (continue auto DMA).
Fix /Tn bug, /t2 as SBPro, instead of SB2.0. Thanks to @jtchip
Bugfix on VIA VT8233/8235/8237
SBEMU 1.0beta3.zip

1.0 Beta2c:
Add "/R" option to reset sound card driver, in case the soundcard is touched by other utilities.
Add SB direct mode handling (non-DMA, DSP command 10h) previously requested by @Bondi. tested game: Shanghai 2 - experimental, may have noises.
Bugfix on BLASTER env set. (seen on FreeDOS or MSDOS prior to 7.0)
Set power states for Intel HDA, fix compatibility issues for some PCs.
Bugfix on volume settings, disable mixer resetting on DSP resetting, make volume consistent among games and can be set properly by SB utilities.
Hack: double the "volume" of OPL so that it sounds near to the digital volume.
Other bugfixes that may fix functionality or improve stability.
SBEMU 1.0beta2c.zip

1.0 Beta2b:
Fix SB Live/Audigy interrupt.
Add option "/SCL" to list sound cards, use "/SC[n]" to select sound card.
Experimental: adjust sound buffer to reduce latency. (1/8 to original).
This is a single binary of SBEMU. You need HDPMI32i and JEMMEX in the 1.0 Beta2 zip.
SBEMU1.0beta2b.zip

1.0 Beta2:
SBEMU.zip

This is a note of thanks, I want to do crazii for his contribution to the development of the old soundboard emulator for the DOS platform, it was very important, in fact it was a milestone, because many people do not have more time to dedicate themselves to developing something for old systems like DOS, and this application was very desired, and you had the heart and free spirit to provide the source code, and besides the configuration file for compilation, the icing on the cake that was missing was just having put a license GNU there on github, anyway, your dedication was very important, from this moment on many people will be able to contribute with the code, just like it was with linux and other gnu systems or whatever the license. Anyway, you left your mark of contribution, just like Linus left with Linux. Thank you, and this is how the free community should be, no arrogance. I understand that you will no longer be contributing code, and this must remain with the free community, thanks again.