KormaX wrote on 2023-02-20, 17:43:

Bondi wrote on 2023-02-20, 16:56:

Blood works fine on my laptop. As well as other build games. I load just a XMS memory manager (himemx.exe or himem.sys) and disa […]
Show full quote

KormaX wrote on 2023-02-20, 16:30:

This is a very powerful project. I tested the previous test version with many games and a few other programs and the results are […]
Show full quote

This is a very powerful project. I tested the previous test version with many games and a few other programs and the results are the same as the other DOS'ers said: the project is very promising, does something nothing actually did before (as far as I know). Some games that find the sound card a funny way, doesn't find your interface, a problem also present in many existing resident drivers for many sound cards. I don't know if it can be fixed. Here are my experiences:

Prehistorik: If it doesn't crash, it works.
Prehistorik 2: Doesn't seem to find it. Also it crushes or freezes or runs with an uncontrollable way. Basically does as it likes.
Warcraft 2: The installer finds it and 'Your sound card works perfectly', but the game crushes.
Volfied: behaves as if no sound card were present.
Monkey Island: Doesn't see it.
Monkey Island 2: Doesn't see the sound blaster, but sees the AdLib.
Blood: The installer doesn't see the card. If I forcefully add a config file with the correct setup, the game cries that the card is not present.
Heroes of Might and Magic 2: Works.
Flashback: Works.
Superfrog: Freezes.
AdLib Tracker 2: Freezes
Snes9x: Freezes
ZSNES: Freezes
WWF Wrestlemania: The installer installs the card perfectly, but the game crushes with cryptic error messages in order to summon Cthulhu, without the option to take back control until reboot. If I load the executable with DOS32A, you can take the control back as I remember.

Also, could you please compile the proper version of JEMM386 together with JEMMEX as an alternative? I would like to try it with other XMS providers, also, once your project reaches maturity, it would be useful if it could be loaded on runtime (with LOADSYS, for example) and JEMM386 only refuses to load if an EMS server is present, while JEMMEX refuses to load even if an XMS server is present.

Regards:
KormaX

Blood works fine on my laptop. As well as other build games. I load just a XMS memory manager (himemx.exe or himem.sys) and disable real mode support (/RM0 switch). I think it worked with qemm too.
Warcraft 2 behaves similarly.
Also tried Screamer - cards detects fine, and the intro starts with sound, but then crashes.

I don't get it. If JEMMEX finds an XMS driver, it refuses to load. The newest, pre-release version of JEMMEX is required for SBEMU to work as QPIEMU.DLL is a JEMM386 module. How can you combine JEMMEX with an external XMS server (I use XMGR + UMBPCI, bythe way). Also, I did not know there is an /RM0 switch for SBEMU, but I'm gonna try it immediately.

I didn't use JEMM386 at all.

So am I right in thinking this may get DOS sound working on an nforce2 system?

crazii wrote on 2023-02-20, 09:10:

I think JUDAS might be an alternative. But first I think I'd contact the author of MPXPlay to clarify the license.

crazii wrote on 2023-02-20, 13:30:

I didn't build MPXPlay at all. But I think I can contact the author to integrate my fix.
BTW I just added BLASTER environment support (create one or change it). so you can forget about the BLASTER environment on next test release.

Maybe you can negotiate with the author of Mpxplay? Allow them to use your fixes and improvements in Mpxplay, in exchange for them releasing the sound driver sources under an open source license?

Because I'm really concerned that this might otherwise prevent SBEMU as a whole from being released as open source. (As in: really open source. None of the "for non-commercial use only" or "requires permission to use or make changes" or any such ristrictive caveats, no offense to the Mpxplay developer.)

Admittedly, I'm making a bit of an assumption here about how you wish to license your work, crazii. But you've been working on this in such an open and collaborative way. Also, you have already incorporated GPL-licensed code from DOSBox in the SBEMU project, and I don't think you would have done that if it wasn't your intention to release your work as open source as well, right?

ptr1ck wrote on 2023-02-20, 18:03:

So am I right in thinking this may get DOS sound working on an nforce2 system?

Correct. The README lists "Intel ICH / nForce", which I assume is nForce 1?

Didn't nForce2 support Intel HDA? Either way, it should work.

Why not try it out, and share your findings here? 🙂

KormaX wrote on 2023-02-20, 17:43:

I don't get it. If JEMMEX finds an XMS driver, it refuses to load. The newest, pre-release version of JEMMEX is required for SBEMU to work as QPIEMU.DLL is a JEMM386 module. How can you combine JEMMEX with an external XMS server (I use XMGR + UMBPCI, bythe way). Also, I did not know there is an /RM0 switch for SBEMU, but I'm gonna try it immediately.

That was my confusion as well. The included JEMMEX / JEMM386 with SBEMU doesn't load if any XMS driver is found. So, I had to disable my XMS driver (HimemX / HimemSX) from loading in order to load SBEMU.

I speculated above that turning off real mode via switch for SBEMU may help, and thanks for confirming the /RMo option exists.

ptr1ck wrote on 2023-02-20, 18:03:

So am I right in thinking this may get DOS sound working on an nforce2 system?

Can't see why not. The onboard audio chipset is what matters, This SBEMU project is using the libau PCI code database, it seems.

Any system that still has legacy 16-bit vBIOS code and legacy boot mode via CSM will probably work! In 2017, Intel annouced it would "discontinue" legacy boot support and switch to UEFI-only modes, to be effective in 2019-20. As far as I know no 11th or 12th or 13th gen core systems with onboard sound even support legacy boot any longer. Sadly and most unfortunately. A few motherboard manufacturers *claim* to have an option to sideload a Content Support Module which would allow DOS to boot and have the appropriate legacy 16-bit INT Calls, code etc. to make baremetal DOS booting possible.

digger wrote on 2023-02-21, 00:47:

Correct. The README lists "Intel ICH / nForce", which I assume is nForce 1? […]
Show full quote

ptr1ck wrote on 2023-02-20, 18:03:

So am I right in thinking this may get DOS sound working on an nforce2 system?

Correct. The README lists "Intel ICH / nForce", which I assume is nForce 1?

Didn't nForce2 support Intel HDA? Either way, it should work.

Why not try it out, and share your findings here? 🙂

Well now I need to put that system back together...

I don't think I have a big enough power supply on hand to fire it up. 🙁

ptr1ck wrote on 2023-02-20, 18:03:

So am I right in thinking this may get DOS sound working on an nforce2 system?

I didn't test on nForce system , I added the nForce because I read the MPXPlay source code. It seems support nForce, nForce2, nForce3.

1static pci_device_s ich_devices[]={
2 {"82801AA",0x8086,0x2415, DEVICE_INTEL},
3 {"82901AB",0x8086,0x2425, DEVICE_INTEL},
4 {"82801BA",0x8086,0x2445, DEVICE_INTEL},
5 {"ICH3"   ,0x8086,0x2485, DEVICE_INTEL},
6 {"ICH4"   ,0x8086,0x24c5, DEVICE_INTEL_ICH4},
7 {"ICH5"   ,0x8086,0x24d5, DEVICE_INTEL_ICH4},
8 {"ESB"    ,0x8086,0x25a6, DEVICE_INTEL_ICH4},
9 {"ICH6"   ,0x8086,0x266e, DEVICE_INTEL_ICH4},
10 {"ICH7"   ,0x8086,0x27de, DEVICE_INTEL_ICH4},
11 {"ESB2"   ,0x8086,0x2698, DEVICE_INTEL_ICH4},
12 {"440MX"  ,0x8086,0x7195, DEVICE_INTEL}, // maybe doesn't work (needs extra pci hack)
13 //{"SI7012" ,0x1039,0x7012, DEVICE_SIS}, // needs extra code
14 {"NFORCE" ,0x10de,0x01b1, DEVICE_NFORCE},
15 {"MCP04"  ,0x10de,0x003a, DEVICE_NFORCE},
16 {"NFORCE2",0x10de,0x006a, DEVICE_NFORCE},
17 {"CK804"  ,0x10de,0x0059, DEVICE_NFORCE},
18 {"CK8"    ,0x10de,0x008a, DEVICE_NFORCE},
19 {"NFORCE3",0x10de,0x00da, DEVICE_NFORCE},
20 {"CK8S"   ,0x10de,0x00ea, DEVICE_NFORCE},
21 {"AMD8111",0x1022,0x746d, DEVICE_INTEL},
22 {"AMD768" ,0x1022,0x7445, DEVICE_INTEL},
23 //{"ALI5455",0x10b9,0x5455, DEVICE_ALI}, // needs extra code
24 {NULL,0,0,0}
25};

But the compatibility needs to test out.

Baron von Riedesel wrote on 2023-02-20, 16:38:

Falcosoft wrote on 2023-02-20, 11:29:

Most likely this is not an SBEMU specific problem but a broader problem related to all DOS4GW titles running under v86 mode:

May also be a problem of the tool that activates WC. I have no problems activating WC on LFB and then running SBEMU. But if the region set to WC overlaps with the HDA memory mapped IO space ... probably not so good.

Why? I uses XMS to allocate the memory, does that means XMS didn't know the overlap? Oh, you mean the tool that activates writecombine doesn't notify XMM?

Just thought that SBEMU now entails the need for a usb mouse driver for DOS 😀

Bondi wrote on 2023-02-21, 12:35:

Just thought that SBEMU now entails the need for a usb mouse driver for DOS 😀

Making a slight off-topic detour in this response:

Some BIOSes might already automatically emulate a PS/2 mouse when a USB mouse is plugged in, the same way as how they emulate a PS/2 keyboard in legacy BIOS mode when a USB keyboard is plugged in. However, I believe they do so through SMM, which may entail some performance penalties, if I'm not mistaken.

Something worth testing and discussing in a dedicated topic, perhaps?

A simpler alternative would be to install a PCIe multi-I/O card with RS-232 ports and load a mouse driver that supports serial ports on non-legacy IO serial ports. Or even better, a well-written serial mouse driver that actually looks up the I/O port addresses of the serial ports in the BIOS data area. There is a DOS tool you can download somewhere that detects many modern PCI and PCIe multi-I/O cards and registers the corresponding COM and LPT ports in the BDA with the correct addresses, in effect making such ports addressable by well-written DOS software that doesn't hard-code any I/O addresses, but actually looks them up in the BDA. I forgot the name of the tool, but I can look it up for you if you want.

Sorry for the side quest. Back on topic. 😅

Bondi wrote on 2023-02-21, 12:35:

Just thought that SBEMU now entails the need for a usb mouse driver for DOS 😀

Some bios offer buggy driver, some bios offers disk only driver bug no mouse.
BTW here's a USB driver that I was working for, and it's indeed the original purpose of this thread, but that goes too far to a pure SB emulation.
DOS driver for RetroWave OPL3
This one includes a mouse/keyboard driver and a disk driver, but is experimental. I only tested on my NEC VersaS260 and VirtualBox.

There seems to be some retrogression with your latest (20-Feb) binary which sets the BLASTER variable without one needing to manually set it. With this version, I've run into incompatibilities with many real mode programs which "expect" only an 8-bit DMA and / or an SB 1.0 or Pro card.

So, I've found that your older (15-Feb) binary to the best overall for game compatibility so far. Using that, I manually:

SET BLASTER=A220 I7 D1

without the H or the T flags in the environment setting, and seems to produce better compatibility. For example, this is the only way I can get Dual Module Player v. 3.01 to recognize the emulated sound card at all (22.05 / 8 bit SB). Any other version of DMP, including 2.94 and 4.00 does not work with sound and SBEMU loaded, no matter which settings I use. Strangely only v. 3.01 works.

Also I appreciate your explanation above re: 16-bit protected mode games, and their incompatibility with SBEMU. This explains why Tyrian, Vanguard Ace, 4th Generation (and other Webfoot DOS games using RTM.EXE) won't work with sound.

I've also tried some DOS emulators:
ColEm v. 4.8 (Dos4GW protected mode) compiled for DOS = works! but sound is choppy and clipped on my Kaby Lake i5 / 8250u, like there's a buffering problem vs pure and strong on my Broadwell core i5 systems)
PCAE 2.5 (real mode) == works, with full sound
all no$cash emulators do not work with sound enabled ("Sound Blaster")
ApplePC v 2.52 (real mode) - Sound Blaster sound did not work.
C64S / 386 (real mode) do not work with sound.
Sidplay v. 1.44 (real mode) == works with SID sound, but very finicky / lots of JEMM exceptions thrown.
ZSNES / NESticle (CWSDPMI protected mode) by Bloodlust software == couldn't test due to not having any NES / SNES game ROMs handy. Seem to detect SB however.
Did not try AdvanceMame for DOS yet v. 0.106 (CWSDPMI)... will report back when I do.

I could not get DSS v 3.0 (CWSDPMI protected mode) - great Russian MODule and .pcm and .wav player) to work with SBEMU. Also:
Quickview v. 2.61 (DOS32A) = works, but author has provided his own PCI driver which works natively in 44.1 16-bit / stereo on Intel HDA and other pci chipsets
Mplayer DOS compile (CWSDPMI protected mode) by Khusraw works with SBEMU, however, a later (2017-18?) compile has native PCI drivers built in (I think libau as well, but could have been Allegro).

Finally, importantly, some (real mode and protected mode) games produce sound, but the audio is greatly sped up. This could be a bug with SBEMU, as I noticed also that MikMod v 3.2.9 and the DOS compile of Open MPT 0.6.8 (both CWSDPMI):
https://lib.openmpt.org/libopenmpt/download/
produce also the exact same sped-up audio on modules.

Adjusting samplerate to 22050, stereo or mono, bitdepth 8 bit or 16-bit makes no difference. Both MikMod and OpenMPT still produce the sped -up (approx 2x faster than normal) audio using SBEMU.

The games I've tested which exhibit this behavior (twice normal-speed audio) are:
The Last Eichhof (real mode) -- freeware by 1993 Alpha Helix group, a great, humorous shoot-up game.
Baryon (protected mode)

All of the above behaviors with SBEMU affect my three systems with HDA audio. The anomaly is ColEm, all versions from DOS versions tested, from 2.6 to 4.8 produced choppy audio on my 8250u Kaby Lake system vs clean audio on my core I5/5300 - 5600 systems. Same behavior with DOS versions of Marat Fayzullin emulators: fMSX, and AdamEm v. 1.8.1 for DOS.

More testing to come... next up some DOS demos from 1990s groups like Future Crew, etc.

KormaX wrote on 2023-02-20, 16:30:

Monkey Island: Doesn't see it.
Monkey Island 2: Doesn't see the sound blaster, but sees the AdLib.

I just tested my current build that Monkey Island 1& 2 is working. dunno if it worked before, but just wait for the next release 😁

zyzzle wrote on 2023-02-22, 05:56:

There seems to be some retrogression with your latest (20-Feb) binary which sets the BLASTER variable without one needing to man […]
Show full quote

There seems to be some retrogression with your latest (20-Feb) binary which sets the BLASTER variable without one needing to manually set it. With this version, I've run into incompatibilities with many real mode programs which "expect" only an 8-bit DMA and / or an SB 1.0 or Pro card.

So, I've found that your older (15-Feb) binary to the best overall for game compatibility so far. Using that, I manually:

SET BLASTER=A220 I7 D1

without the H or the T flags in the environment setting, and seems to produce better compatibility. For example, this is the only way I can get Dual Module Player v. 3.01 to recognize the emulated sound card at all (22.05 / 8 bit SB). Any other version of DMP, including 2.94 and 4.00 does not work with sound and SBEMU loaded, no matter which settings I use. Strangely only v. 3.01 works.

Also I appreciate your explanation above re: 16-bit protected mode games, and their incompatibility with SBEMU. This explains why Tyrian, Vanguard Ace, 4th Generation (and other Webfoot DOS games using RTM.EXE) won't work with sound.

I've also tried some DOS emulators:
ColEm v. 4.8 (Dos4GW protected mode) compiled for DOS = works! but sound is choppy and clipped on my Kaby Lake i5 / 8250u, like there's a buffering problem vs pure and strong on my Broadwell core i5 systems)
PCAE 2.5 (real mode) == works, with full sound
all no$cash emulators do not work with sound enabled ("Sound Blaster")
ApplePC v 2.52 (real mode) - Sound Blaster sound did not work.
C64S / 386 (real mode) do not work with sound.
Sidplay v. 1.44 (real mode) == works with SID sound, but very finicky / lots of JEMM exceptions thrown.
ZSNES / NESticle (CWSDPMI protected mode) by Bloodlust software == couldn't test due to not having any NES / SNES game ROMs handy. Seem to detect SB however.
Did not try AdvanceMame for DOS yet v. 0.106 (CWSDPMI)... will report back when I do.

I could not get DSS v 3.0 (CWSDPMI protected mode) - great Russian MODule and .pcm and .wav player) to work with SBEMU. Also:
Quickview v. 2.61 (DOS32A) = works, but author has provided his own PCI driver which works natively in 44.1 16-bit / stereo on Intel HDA and other pci chipsets
Mplayer DOS compile (CWSDPMI protected mode) by Khusraw works with SBEMU, however, a later (2017-18?) compile has native PCI drivers built in (I think libau as well, but could have been Allegro).

Finally, importantly, some (real mode and protected mode) games produce sound, but the audio is greatly sped up. This could be a bug with SBEMU, as I noticed also that MikMod v 3.2.9 and the DOS compile of Open MPT 0.6.8 (both CWSDPMI):
https://lib.openmpt.org/libopenmpt/download/
produce also the exact same sped-up audio on modules.

Adjusting samplerate to 22050, stereo or mono, bitdepth 8 bit or 16-bit makes no difference. Both MikMod and OpenMPT still produce the sped -up (approx 2x faster than normal) audio using SBEMU.

The games I've tested which exhibit this behavior (twice normal-speed audio) are:
The Last Eichhof (real mode) -- freeware by 1993 Alpha Helix group, a great, humorous shoot-up game.
Baryon (protected mode)

All of the above behaviors with SBEMU affect my three systems with HDA audio. The anomaly is ColEm, all versions from DOS versions tested, from 2.6 to 4.8 produced choppy audio on my 8250u Kaby Lake system vs clean audio on my core I5/5300 - 5600 systems. Same behavior with DOS versions of Marat Fayzullin emulators: fMSX, and AdamEm v. 1.8.1 for DOS.

More testing to come... next up some DOS demos from 1990s groups like Future Crew, etc.

Okay, I can remove the T & H settings and use it only for SB16 mode.
Meantime I'll debug the sped up games to see what's wrong.

Just added 16bit DMA - that means SB16 is supported, it might still have bugs, teste only with few games and their setup utilities.
and the speaker output vs headphone for Intel HDA should be done too, I have no PC to test it yet.

crazii wrote on 2023-02-22, 06:36:

Just added 16bit DMA - that means SB16 is supported, it might still have bugs, teste only with few games and their setup utilities.
and the speaker output vs headphone for Intel HDA should be done too, I have no PC to test it yet.

Cool! 👍 looking forward to testing it.

zyzzle wrote on 2023-02-22, 05:56:

The Last Eichhof (real mode) -- freeware by 1993 Alpha Helix group, a great, humorous shoot-up game.
Baryon (protected mode)

Good news that I probably fixed the problem 1hour ago before your post, it's related to sample rate conversion. There's still slight noise though.

- New Options added:
/T, set the sound blaster type, same meaning as the values in BLASTER variable. default value is /T5 (SB Pro), you may change it to 3 or 1 if encountering some emulation problems. /T6 (SB16) will add extra T6 H5 to BLASTER env var.
/O[1/2], for Intel HDA only: 0 - output to headphone, 1 - output to speaker. default value is 1.
/VOL[0-9] set volume. default value: 7.

- Added 16 bit DMA, tested 16bit sound in Quake & Duke3D.
- Fix sample rate conversion problem.
Note on some other compatibility issues: you may want to disable PM games if real mode games don't work, use /PM0. use /RM0 to disable real mode support. I think it's still a long way to go. not a easy one.

crazii wrote on 2023-02-22, 08:48:

- New Options added: /T, set the sound blaster type, same meaning as the values in BLASTER variable. default value is /T5 (SB Pr […]
Show full quote

- New Options added:
/T, set the sound blaster type, same meaning as the values in BLASTER variable. default value is /T5 (SB Pro), you may change it to 3 or 1 if encountering some emulation problems. /T6 (SB16) will add extra T6 H5 to BLASTER env var.
/O[1/2], for Intel HDA only: 0 - output to headphone, 1 - output to speaker. default value is 1.
/VOL[0-9] set volume. default value: 7.

- Added 16 bit DMA, tested 16bit sound in Quake & Duke3D.
- Fix sample rate conversion problem.
SBEMU.zip

Note on some other compatibility issues: you may want to disable PM games if real mode games don't work, use /PM0. use /RM0 to disable real mode support. I think it's still a long way to go. not a easy one.

Thanks for new version! I shall test it presently. (I feel like a kid in a candy store. SBEMU truly breathes new life into DOS games on "modern systems" and is fantastic).

One other strange regression with 20-Feb version: When I tried to disable real mode (/RM0) or protected mode (/PM0). That's /PM0 (number zero, not letter "O"!), I got a crash exeception thrown by JEMMEX.

That behavior doesn't occur in the 15-Feb binaries you posted. I can disable real mode or protected mode at will. Very strange.

But, this may all be moot / obsolete, as I'm about to test your new binary just posted. I'll stick to a few well-known games for SB16 (16 bit audio) testing, like Doom, Duke Nukem, Descent I / II, but I'll also test the MOD players as well and report back.