SBEMU + Windows 98SE + Boot menu

Example of how to setup a boot menu for Windows 9x so that the SBEMU driver ++ is only loaded when booting DOS.

Windows will fail to load if jemmex is loaded for instance.
Tested on Windows 98SE, but I believe it will also work on 95 and 98.
The following code assumes the files in SBEMU.zip have been extracted to the folder: C:\SBEMU\

AUTOEXEC.BAT

1@ECHO OFF
2GOTO %CONFIG%
3
4:WINDOWS
5rem Commands here are only run with Windows
6GOTO END
7
8:DOS
9C:\SBEMU\jload C:\SBEMU\qpiemu.dll
10C:\SBEMU\hdpmi32i -r -x
11C:\SBEMU\sbemu
12rem Commands here are only run with DOS
13
14:END
15rem Commands here are run with both DOS and Windows
16
17
18rem Keep C:\WINDOWS\WIN.COM at the end if the file
19if %config%==WINDOWS C:\WINDOWS\WIN.COM

CONFIG.SYS

1[MENU]
2menuitem=DOS, Start DOS (SBEMU)
3menuitem=WINDOWS, Start Windows
4menudefault=WINDOWS, 10
5
6[DOS]
7DEVICE=C:\SBEMU\jemmex.exe
8
9[WINDOWS]
10

MSDOS.SYS
Change the BootGUI value from 1 to 0.

1...
2BootGUI=0
3...

The MSDOS.SYS might not be editable or visible, to fix this use the following command:

1attrib -r -s -h MSDOS.SYS

crazii wrote on 2023-03-15, 07:47:

By default the PCI buffer size is 16384 bytes, and 16 bit stereo 22050Hz PCM format will be used, and so the total delay of the buffer is about 185ms, you may use "/k44100" to use higher sample rate, which will halve the delay.

I already did have that setting turned on in my testing.

Is it possible to make the buffer size configurable?

sledge wrote on 2023-03-15, 11:42:

Can someone try Cubic Player / Open Cubic Player, please?

In my case (Asus EEE netbook) playback works, but the screen is erratically jumping up&down and text is outputed ("trapcli pushf pop ax 0246 0246")

I tried it, reported in the other thread. My setup: HDA audio, /A220 /I5 /D1 /H5 /T6 /K44100. Open Cubic player doesn't work for me, I only get static using Cubic's SBdrv from the Config file. Changing settings to /I7 or /T5 or /T1, changing from /H5 to /H7 didn't work, either. Couldn't diagnose it further, unfortunately. Strange problem.

I had no problems with the display in Cubic Player, however. It is fine, it's just the audio that is nothing but loud static. Other media players, such as DOS port of Mplayer works perfectly for me, using Allegro audio wrapper for SB16 output @ 16/44.1.

Yesterday I tried to run sbemu on a MB with a onboard ES1371 sound hw. It was accespted by sbemu, but no sound was rendered.

I checked the source, added the missing IRQ routine and activated interrupts, but this didn't help. Running MPXPLAY on this MB revealed that it also had problems ( no sound ). I noticed that in the source there are some bits prominently used that aren't memtioned in the ES1371 data sheet.

My question is: has anybody successfully ever run MPXPLAY with ES1371 hardware ( Ensoniq AudioPCI or any of the AudiioPCI-based SB cards )?

Baron von Riedesel wrote on 2023-03-16, 05:00:

Yesterday I tried to run sbemu on a MB with a onboard ES1371 sound hw. It was accespted by sbemu, but no sound was rendered.

I checked the source, added the missing IRQ routine and activated interrupts, but this didn't help. Running MPXPLAY on this MB revealed that it also had problems ( no sound ). I noticed that in the source there are some bits prominently used that aren't memtioned in the ES1371 data sheet.

My question is: has anybody successfully ever run MPXPLAY with ES1371 hardware ( Ensoniq AudioPCI or any of the AudiioPCI-based SB cards )?

Would these cards be a priority since they already have original DOS drivers?

Having one driver that works on everything would be a benefit, but what are the other reasons for wanting to support these cards?
Better OPL3 emulation?

http://www.vogonsdrivers.com/dosearch.php?q=audiopci

Gammitin wrote on 2023-03-08, 09:57:

Hi Crazii, […]
Show full quote

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 (nForce boards not tested so far)
• 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.

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).
Any suggestion and bug report are welcomed.

1.0 Beta2:
SBEMU.zip

Hi Crazii,

I've made myself an MS-DOS 6.22 and 7.1 installer for your amazing SBEMU project, I was wondering if you would mind if I shared the installer with the community, it's making a big buzz to be honest. Having an installer would open it up to users that are not as savvy with Dos. Wondering if this would be ok, wanted to check as I don't want to redistribute files etc without permission for you. If so what credits etc. do you want in it?

You can catch me over on Twitter, as it's where I spend most of my online time: https://twitter.com/Gammitin?t=ulv5eScJiQgodgjQCa9vXQ&s=09

Thanks

It's definitely OK, thanks. 😁

Kamerat wrote on 2023-03-08, 20:49:

Still no sound with /VOL9. […]
Show full quote

crazii wrote on 2023-03-08, 07:51:

Kamerat wrote on 2023-03-06, 17:09:

Nice piece of software! […]
Show full quote

Nice piece of software!

Did some initial testing on a few systems:
AMD B450 (MSI B450M MORTAR TITANIUM): Working, used front panel audio connector.
AMD RS880M (Toshiba Satllite C660D-113): Intializes with /I5 option, Duke Nukem 3D and Doom starts without complaining but i hear no audio. Tried the /O option for chainging output without success.
Intel HM175 (MSI GT72VR 7RD Dominator): Partially working, laptop only output sound on bass (?) port. /O0 option works as it should with headphones.
Lenovo Thinkpad X390: Locks when SBEMU tries to initialize.

Emmm, yet another PCs that reported not working. Can you try /VOL9 on the AMD RS880M to make sure it is not a volume problem?

Still no sound with /VOL9.

I also get no sound with MPXPLAY even that it detects IHD. Maybe the driver from MPXPLAY is the problem?

This is the device:

Copy code to clipboard

1 Bus 0 (PCI Express), Device Number 20, Device Function 2
2 Vendor 1002h Advanced Micro Devices, Inc. [AMD/ATI]
3 Device 4383h SBx00 Azalia (Intel HDA)
4 Subsystem ID FF1E1179h Unknown
5 Subsystem Vendor 1179h Toshiba Corporation
6 System IRQ 7, INT# A

There was problem on MPXPlay and I did some fix, tested working by folk here, when MPXPlay doesn't work but SBEMU does. There might be more problems that are not fixed.
It uses IRQ7, so you need to use IRQ5 for SBEMU, I saw you've already done that. So what's the BLASTER env after running SBEMU?

MBH wrote on 2023-03-13, 12:18:

2. I think no one tested SBEMU on VIA VT8237R yet? At least, I haven't read about it.

No, not tested. Interesting that MPXPlay's source doesn't have VT8237R but only VT8233/VT82C686, it might be a compatible chip. Unfortunately I only tested it on a VT82C686 laptop. I'll check the code again to see if anything is wrong.

keenmaster486 wrote on 2023-03-15, 19:06:

crazii wrote on 2023-03-15, 07:47:

By default the PCI buffer size is 16384 bytes, and 16 bit stereo 22050Hz PCM format will be used, and so the total delay of the buffer is about 185ms, you may use "/k44100" to use higher sample rate, which will halve the delay.

I already did have that setting turned on in my testing.

Is it possible to make the buffer size configurable?

Not for now. MPXPlay has static (compile-time) configure for each driver. I remember trying changing the total buffer size but failed. but changing the period buffer size works for doom (the whole buffer is divided into periods, the number of periods might be fixed and cannot be changed by the chip/card spec). but with smaller value it will cause high frequency of interrupts, which might be not friendly to old CPU.
I can further reduce the period buffer size and build a low-latency-testing version for you to test. but small buffer may also cause distortions since interrupt routines might not be called strictly in time that can feed enough data to the soundcard.

urbanus wrote on 2023-03-16, 06:02:

Would these cards be a priority since they already have original DOS drivers?

The situation of AudioPCI based cards is similar to other Creative PCI cards ( SB Live, Audigy). Namely they use almost the same DOS drivers that stopped working a long time ago on Intel chipsets and never worked on Nvidia, ATI/AMD chipsets.

Falcosoft wrote on 2023-03-16, 07:16:

urbanus wrote on 2023-03-16, 06:02:

Would these cards be a priority since they already have original DOS drivers?

The situation of AudioPCI based cards is similar to other Creative PCI cards ( SB Live, Audigy). Namely they use almost the same DOS drivers that stopped working a long time ago on Intel chipsets and never worked on Nvidia, ATI/AMD chipsets.

Ahhh, good point! 👍

I'm well aware of the chipset limitation, but that issue didn't hit me, and that this is a solution to that problem.
Let's make SBEMU work on all PCI cards then 😉

crazii wrote on 2023-03-16, 06:53:

Interesting that MPXPlay's source doesn't have VT8237R but only VT8233/VT82C686, it might be a compatible chip.

I think VT8233 is identical to VT8235 and VT8237(R+) in terms of sound. At least if I understand german Wikipedia right. VT8235 added USB2.0 and VT8237(R+) added SATA and Raid. Starting with VT8237"A" they switched to HD Audio.

Baron von Riedesel wrote on 2023-03-16, 05:00:

My question is: has anybody successfully ever run MPXPLAY with ES1371 hardware ( Ensoniq AudioPCI or any of the AudiioPCI-based SB cards )?

An interesting question. Nearly 20 years ago, I had an AudioPCI (physical PCI-based sound card, using ES1371 chipset, re-labled as Sound Blaster 128) plugged into an i440BX-based motherboard. As I recall, its DOS-based SB emulation was poor, being limited to 8-bit and 22050 sample rate only. And of course required QEMM and EMS pageframe, etc. It was kludgy, supported fewer games than SBEMU does now with my "modern" HDA chipset.

It would be interesting, indeed if I could run SBEMU on such a system, to get much better, "native" SB16 support which SBEMU now provides. Your post serves as inspiration for me to search for the old card, which I know I still have in the old stockpile. When I've got a system up and running using that ES1371-based PCI card, I'll try SBEMU on it and report back.

Given that even after custom modification of the SBEMU source which you did, still didn't get the ES1371-based PCI sound working, I'll put my chances of getting it working "out of the box" as low!

zyzzle wrote on 2023-03-16, 13:33:

When I've got a system up and running using that ES1371-based PCI card, I'll try SBEMU on it and report back.

sbemu surely won't work in its current state - try mpxplay.

I'm unsure if the ES1371 sound hw on my board works at all - the DOS drivers I downloaded from VOGONs didn't work. The last option to try are the win9x drivers...

crazii wrote on 2023-03-16, 07:03:

keenmaster486 wrote on 2023-03-15, 19:06:

crazii wrote on 2023-03-15, 07:47:

By default the PCI buffer size is 16384 bytes, and 16 bit stereo 22050Hz PCM format will be used, and so the total delay of the buffer is about 185ms, you may use "/k44100" to use higher sample rate, which will halve the delay.

I already did have that setting turned on in my testing.

Is it possible to make the buffer size configurable?

Not for now. MPXPlay has static (compile-time) configure for each driver. I remember trying changing the total buffer size but failed. but changing the period buffer size works for doom (the whole buffer is divided into periods, the number of periods might be fixed and cannot be changed by the chip/card spec). but with smaller value it will cause high frequency of interrupts, which might be not friendly to old CPU.
I can further reduce the period buffer size and build a low-latency-testing version for you to test. but small buffer may also cause distortions since interrupt routines might not be called strictly in time that can feed enough data to the soundcard.

I think it would be a good idea to focus on lowering sound latency as much as possible at some point in the future. One of the reasons that people like to play retro games natively (apart from authenticity) is not to deal with lag caused by emulation on modern operating systems... Hmm... I had not thought that latency could be an issue on such a baremetal OS as DOS.

Keep up the great work!

crazii wrote on 2023-03-16, 07:03:

I can further reduce the period buffer size and build a low-latency-testing version for you to test. but small buffer may also cause distortions since interrupt routines might not be called strictly in time that can feed enough data to the soundcard.

Hmm, I am interested in trying this since my laptop has a Pentium M, not exactly a lightweight DOS CPU. But maybe I would need even more than that.

Intel HDA got me interested. Does this mean all codecs on the HDA Bus or just Intel? The HDA bus is a very different beast from AC97 and if you managed this I would be twice as thrilled as I already am about this project.

BurnedPinguin wrote on 2023-03-16, 18:31:

Intel HDA got me interested. Does this mean all codecs on the HDA Bus or just Intel? The HDA bus is a very different beast from AC97 and if you managed this I would be twice as thrilled as I already am about this project.

It feels like a wiki page or something should be made where this could be documented.
What should work, what does work and how well.

Idk

BurnedPinguin wrote on 2023-03-16, 18:31:

Intel HDA got me interested. Does this mean all codecs on the HDA Bus or just Intel? The HDA bus is a very different beast from AC97 and if you managed this I would be twice as thrilled as I already am about this project.

Not just Intel, according to the source code of MPXPlay, it also supports some SIS VIA boards, and ATI/nVidia (possibly HDMI sound through graphics cards), and Creative devices.

crazii wrote on 2023-03-16, 23:25:

Not just Intel, according to the source code of MPXPlay, it also supports some SIS VIA boards, and ATI/nVidia (possibly HDMI sound through graphics cards), and Creative devices.

Hence, my original confusion with HDA (High definition audio) and IHD (Intel High Definition audio). Mpxplay identified mine as both HDA and IHD. libau says HDA. SBEMU says HDA.

So, HDA is a superset of *many* PCI sound chipsets, not just Intel-based ones.