I tested the new alpha build too. Using a Yamaha ymf724 soundcard. Jazz Jackrabbit, Mortal Kombat, and even the first Alone in the Dark (wow) now have sound! But, I get crashes and hangs on pretty much all other games. Although, I get an error when trying to start Super Street Fighter 2 Turbo instead of a hang, so hopefully that's positive progress for that game. I also tried the new beta 4 and I get a very loud hum in Dune 2 that didn't exist in previous builds on this soundcard.

sbemu-1.1apha1-rc1.zip
This Version is only for newer PCs right?

The last stubborn title was also resolved. The Zen2 Madness is now running Tyrian, the legacy version 95 and the Opentyrian. Driver-Baron-Von-Rriedesel vsbhda V1.4.
Config.sys:
Limitmem.Sys 256
Jemmex
autoexec.bat:
start16.bat

Next to them item is the custom customary. Tested with the motherboard on integrated sound, I have not redirected to SB0060 for the time being.
It became now a complete ultimate retro machine as Ryzen config.

Is it possible that this could be extended to provide better support for old soundcards with bad SB support? I have an IBM Thinkpad 755c which would be a lovely dos gaming machine but the soundcard, CS4248, has a terrible TSR to provide SB compatibility. It takes up loads of memory and sounds horrible! It would be amazing if SBEMU would work for older cards like that. The card does have a Linux driver.

Neufena wrote on 2024-05-08, 10:41:

Is it possible that this could be extended to provide better support for old soundcards with bad SB support? I have an IBM Thinkpad 755c which would be a lovely dos gaming machine but the soundcard, CS4248, has a terrible TSR to provide SB compatibility. It takes up loads of memory and sounds horrible! It would be amazing if SBEMU would work for older cards like that. The card does have a Linux driver.

You should try it. You saved the starter files and edit it according to SBEMU/VSBHDA description. I don't know if it will work, it is not in the support, but a trial luck.

Neufena wrote on 2024-05-08, 10:41:

Is it possible that this could be extended to provide better support for old soundcards with bad SB support? I have an IBM Thinkpad 755c which would be a lovely dos gaming machine but the soundcard, CS4248, has a terrible TSR to provide SB compatibility. It takes up loads of memory and sounds horrible! It would be amazing if SBEMU would work for older cards like that. The card does have a Linux driver.

This is something I was asking for a long time, but for SB direct DAC mode. But it's hard to implement as I understand. CS4248 is just a codec and will probably require software resampling and also feeding it manually byte by byte. And that's probably quite heavy on the CPU too.

I had got some "HP T510 Thin Clients" to test with SBEMU, from what I can tell they have a "VIA Eden X2 U4200" CPU, "Chrome9 HD" video, and "VT8237A/VT8251 HDA" sound, so I installed an SD to IDE adapter on the IDE pins, and then installed DOS 7.1 from CD onto a SD card.

I setup my CONFIG.SYS like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=E000-EFFF

I excluded E000-EFFF because JEMMEX told me that region might be in use.

And I set my AUTOEXEC.BAT like this:

C:\JLOAD.EXE QPIEMU.DLL
LH C:\HDPMI32I.EXE -R -X
LH C:\SBEMU.EXE

DOOM will not run no matter what, DOOM always crashes right has it says "I_StarupSound", "Quake" and "Wolfenstein 3D" both run, both have sound, but you need to disable the BIOS's DOS keyboard emulation and use a PS/2 keyboard or the keyboard moves on it's own in game.

The "HP T510 Thin Clients" do work well for Windows XP and older games from the late 1990s, but I had wanted to use this for DOS.

Are we supposed to be using "LH" when loading hdpmi and sbemu? I haven't been. That might be related to your issues? Also, did you set the right irq and dma for Doom using setup.exe? Quake and Wolfenstein just use your "Set Blaster" environment variable, but Doom does not. You also might try using sound blaster 16 emulation with "sbemu /t6 /h5" and see if that makes any difference.

MoneySquirrel wrote on 2024-05-11, 07:24:

Are we supposed to be using "LH" when loading hdpmi and sbemu? I haven't been. That might be related to your issues? Also, did you set the right irq and dma for Doom using setup.exe? Quake and Wolfenstein just use your "Set Blaster" environment variable, but Doom does not. You also might try using sound blaster 16 emulation with "sbemu /t6 /h5" and see if that makes any difference.

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting there), then it wont hurt anything, and keeps a few kb of conventional from being used.

SADLY-- I have noticed on modern-ish machines (which SBEMU is made for), that "Actual Legacy Mode Booting" is.... Not really a consideration for the motherboard designer. Like, AT ALL. Almost all I have played with have some kind of mystery device stuck in the adapter region that does not properly identify itself, and acts somewhat like RAM, and has data where none should be like ROM, but does not identify with a realmode bios header, so DOS does not identify it as rom, and the system hangs up terribly when you map it out.

QEMM and company detect the bits that act like ram, and try to include it-- causing lockups.

The region in which that happens seems to be different, and of different sizes, on different modern computers. Sometimes its the whole damn adapter region, just about. This is why I only really feel safe including the monochrome display buffer, to get DOS to load high and into UMB on such systems! I have to meticulously experiment with what I can get, and what I cannot.

I suspect that the previous poster's reports of realmode trapping working, but protected mode trapping failing, comes from adapter memory area "Not really being free", and some system process wanting to do something with the region of memory that has been enabled for UMBs, which also happens to be were DOS is sitting, and HDPMI is loaded, causing severe problems.

I especially think this is the case, since the PS/2 keyboard and mouse emulation breaks. That means the realmode handler is getting klobbered by the upper memory area includes, usually.

We really need a tool to help better analyze the UMA on modern machines, to give a good idea of what regions we can include, or should exclude.

wierd_w wrote on 2024-05-11, 08:09:

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting ther […]
Show full quote

MoneySquirrel wrote on 2024-05-11, 07:24:

Are we supposed to be using "LH" when loading hdpmi and sbemu? I haven't been. That might be related to your issues? Also, did you set the right irq and dma for Doom using setup.exe? Quake and Wolfenstein just use your "Set Blaster" environment variable, but Doom does not. You also might try using sound blaster 16 emulation with "sbemu /t6 /h5" and see if that makes any difference.

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting there), then it wont hurt anything, and keeps a few kb of conventional from being used.

SADLY-- I have noticed on modern-ish machines (which SBEMU is made for), that "Actual Legacy Mode Booting" is.... Not really a consideration for the motherboard designer. Like, AT ALL. Almost all I have played with have some kind of mystery device stuck in the adapter region that does not properly identify itself, and acts somewhat like RAM, and has data where none should be like ROM, but does not identify with a realmode bios header, so DOS does not identify it as rom, and the system hangs up terribly when you map it out.

QEMM and company detect the bits that act like ram, and try to include it-- causing lockups.

The region in which that happens seems to be different, and of different sizes, on different modern computers. Sometimes its the whole damn adapter region, just about. This is why I only really feel safe including the monochrome display buffer, to get DOS to load high and into UMB on such systems! I have to meticulously experiment with what I can get, and what I cannot.

I suspect that the previous poster's reports of realmode trapping working, but protected mode trapping failing, comes from adapter memory area "Not really being free", and some system process wanting to do something with the region of memory that has been enabled for UMBs, which also happens to be were DOS is sitting, and HDPMI is loaded, causing severe problems.

I especially think this is the case, since the PS/2 keyboard and mouse emulation breaks. That means the realmode handler is getting klobbered by the upper memory area includes, usually.

We really need a tool to help better analyze the UMA on modern machines, to give a good idea of what regions we can include, or should exclude.

I had some time to play around with the "HP T510 Thin Client".

So I edited my CONFIG.SYS by adding "I=B000-B7FF" like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=E000-EFFF I=B000-B7FF

however the USB keyboard still moved on it's own in games.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE

but DOOM still stops at "I_StarupSound", BTW removing "LH" seems to have no affect on conventional memory.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE /T6 /H5

and ran DOOM's setup.exe file again, however DOOM still stops at "I_StarupSound".

will1384 wrote on 2024-05-11, 20:58:

I had some time to play around with the "HP T510 Thin Client". […]
Show full quote

wierd_w wrote on 2024-05-11, 08:09:

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting ther […]
Show full quote

MoneySquirrel wrote on 2024-05-11, 07:24:

Are we supposed to be using "LH" when loading hdpmi and sbemu? I haven't been. That might be related to your issues? Also, did you set the right irq and dma for Doom using setup.exe? Quake and Wolfenstein just use your "Set Blaster" environment variable, but Doom does not. You also might try using sound blaster 16 emulation with "sbemu /t6 /h5" and see if that makes any difference.

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting there), then it wont hurt anything, and keeps a few kb of conventional from being used.

SADLY-- I have noticed on modern-ish machines (which SBEMU is made for), that "Actual Legacy Mode Booting" is.... Not really a consideration for the motherboard designer. Like, AT ALL. Almost all I have played with have some kind of mystery device stuck in the adapter region that does not properly identify itself, and acts somewhat like RAM, and has data where none should be like ROM, but does not identify with a realmode bios header, so DOS does not identify it as rom, and the system hangs up terribly when you map it out.

QEMM and company detect the bits that act like ram, and try to include it-- causing lockups.

The region in which that happens seems to be different, and of different sizes, on different modern computers. Sometimes its the whole damn adapter region, just about. This is why I only really feel safe including the monochrome display buffer, to get DOS to load high and into UMB on such systems! I have to meticulously experiment with what I can get, and what I cannot.

I suspect that the previous poster's reports of realmode trapping working, but protected mode trapping failing, comes from adapter memory area "Not really being free", and some system process wanting to do something with the region of memory that has been enabled for UMBs, which also happens to be were DOS is sitting, and HDPMI is loaded, causing severe problems.

I especially think this is the case, since the PS/2 keyboard and mouse emulation breaks. That means the realmode handler is getting klobbered by the upper memory area includes, usually.

We really need a tool to help better analyze the UMA on modern machines, to give a good idea of what regions we can include, or should exclude.

I had some time to play around with the "HP T510 Thin Client".

So I edited my CONFIG.SYS by adding "I=B000-B7FF" like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=E000-EFFF I=B000-B7FF

however the USB keyboard still moved on it's own in games.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE

but DOOM still stops at "I_StarupSound", BTW removing "LH" seems to have no affect on conventional memory.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE /T6 /H5

and ran DOOM's setup.exe file again, however DOOM still stops at "I_StarupSound".

For Ryzen doom ok. USB Lighting Keyboard+PS2 Mouse ok.

What irq, dma, etc is sbemu using? Mine defaults to a220, i7, d1. The doom setup doesn't complain? Have you tried just music and no sound, and vice versa? Are you using the beta4 release of sbemu? You may want to try an earlier version too. Also, maybe try the freedos bootdisk in case it's related to that dos 7.1 install. Is anything else being loaded in your config.sys?

MoneySquirrel wrote on 2024-05-12, 01:04:

What irq, dma, etc is sbemu using? Mine defaults to a220, i7, d1. The doom setup doesn't complain? Have you tried just music and no sound, and vice versa? Are you using the beta4 release of sbemu? You may want to try an earlier version too. Also, maybe try the freedos bootdisk in case it's related to that dos 7.1 install. Is anything else being loaded in your config.sys?

SBEMU on my "HP T510 Thin Client" is also defaulting to 220, IRQ7 and DMA1, I am using "SBEMU - 1.0-beta4", I have tried FreeDOS and that did not help, I also tried QEMM but it locks up the "HP T510 Thin Client".

DOOM with no sound of any kind works.

DOOM with only music works.

DOOM with only sound and no music crashes.

will1384 wrote on 2024-05-11, 20:58:

I had some time to play around with the "HP T510 Thin Client". […]
Show full quote

wierd_w wrote on 2024-05-11, 08:09:

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting ther […]
Show full quote

MoneySquirrel wrote on 2024-05-11, 07:24:

Are we supposed to be using "LH" when loading hdpmi and sbemu? I haven't been. That might be related to your issues? Also, did you set the right irq and dma for Doom using setup.exe? Quake and Wolfenstein just use your "Set Blaster" environment variable, but Doom does not. You also might try using sound blaster 16 emulation with "sbemu /t6 /h5" and see if that makes any difference.

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting there), then it wont hurt anything, and keeps a few kb of conventional from being used.

SADLY-- I have noticed on modern-ish machines (which SBEMU is made for), that "Actual Legacy Mode Booting" is.... Not really a consideration for the motherboard designer. Like, AT ALL. Almost all I have played with have some kind of mystery device stuck in the adapter region that does not properly identify itself, and acts somewhat like RAM, and has data where none should be like ROM, but does not identify with a realmode bios header, so DOS does not identify it as rom, and the system hangs up terribly when you map it out.

QEMM and company detect the bits that act like ram, and try to include it-- causing lockups.

The region in which that happens seems to be different, and of different sizes, on different modern computers. Sometimes its the whole damn adapter region, just about. This is why I only really feel safe including the monochrome display buffer, to get DOS to load high and into UMB on such systems! I have to meticulously experiment with what I can get, and what I cannot.

I suspect that the previous poster's reports of realmode trapping working, but protected mode trapping failing, comes from adapter memory area "Not really being free", and some system process wanting to do something with the region of memory that has been enabled for UMBs, which also happens to be were DOS is sitting, and HDPMI is loaded, causing severe problems.

I especially think this is the case, since the PS/2 keyboard and mouse emulation breaks. That means the realmode handler is getting klobbered by the upper memory area includes, usually.

We really need a tool to help better analyze the UMA on modern machines, to give a good idea of what regions we can include, or should exclude.

I had some time to play around with the "HP T510 Thin Client".

So I edited my CONFIG.SYS by adding "I=B000-B7FF" like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=E000-EFFF I=B000-B7FF

however the USB keyboard still moved on it's own in games.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE

but DOOM still stops at "I_StarupSound", BTW removing "LH" seems to have no affect on conventional memory.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE /T6 /H5

and ran DOOM's setup.exe file again, however DOOM still stops at "I_StarupSound".

by default, jemmex tries to turn on umbs in the uma. You would need to exclude the whole umb region as well.

eg.

X=C000-FFFF, then have the include
I=B000-B7FF

and then slowly walking back that massive exclude bit by bit, through experimentation.

Even then, oddities with some HDA devices cause such crashes, I have found.

Also what version of Doom are you using? I've only used Ultimate Doom with sbemu. But usually Doom, Duke3d, Quake, and Wolf3d work mostly fine. It's the deeper dos library that can get problematic. Have you tried using a different irq and dma? Although strange that Quake works fine. Maybe Crazii will have some input. I have all of my usb ports disabled, but other than taking up irq's, usb never really caused any big issues for me in dos. It may have caused a conflict with my dos Ethernet driver, but I don't use that very often. I would also try one of the earlier versions from April on the GitHub page, as the beta4 did give me an issue with Dune 2. You can try "sbemu /i5 /d3" and also update the settings in Doom setup.

Doom DMX implementation is a complete mess.
What you can do is:
- Try IRQ 5 instead of IRQ 7 (I have one system which will not work on on 7)
- Edit the doom configuration file; set the the address; irq and dma all to "0", then use a correct BLASTER setting for the correct one.
(The code will basically ignore all settings in the setup and try to autodetect it; with the config setting to 0 and blaster setting it will ignore auto detection)
- Be aware with SBEMU the I_StartupSound can take significant time; wait at least 30 seconds.

The version from GitHub (1.0beta4) works. Tested in pure MS-DOS 6.22 on YMF754 in Z.A.R. with the /t6 parameter (SoundBlaster16) in 44kHz, 16-bit, Stereo mode. There are no complaints. I also checked Quake 1.06 without the /t6 parameter (Default settings) - it also works fine. System board based on Intel Q87 (Lynx Point).

DoZator wrote on 2024-05-13, 19:42:

The version from GitHub (1.0beta4) works. Tested in pure MS-DOS 6.22 on YMF754 in Z.A.R. with the /t6 parameter (SoundBlaster16) in 44kHz, 16-bit, Stereo mode. There are no complaints. I also checked Quake 1.06 without the /t6 parameter (Default settings) - it also works fine. System board based on Intel Q87 (Lynx Point).

Can you try Dune 2 with that card? I have a ymf724, and I get a loud hum with beta4.

wierd_w wrote on 2024-05-12, 18:30:

by default, jemmex tries to turn on umbs in the uma. You would need to exclude the whole umb region as well. […]
Show full quote

will1384 wrote on 2024-05-11, 20:58:

I had some time to play around with the "HP T510 Thin Client". […]
Show full quote

wierd_w wrote on 2024-05-11, 08:09:

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting ther […]
Show full quote

Assuming the UMB region it gets loaded into is "Genuinely Free" (no RAM, no ROM, no strange memory mapped IO device sitting there), then it wont hurt anything, and keeps a few kb of conventional from being used.

SADLY-- I have noticed on modern-ish machines (which SBEMU is made for), that "Actual Legacy Mode Booting" is.... Not really a consideration for the motherboard designer. Like, AT ALL. Almost all I have played with have some kind of mystery device stuck in the adapter region that does not properly identify itself, and acts somewhat like RAM, and has data where none should be like ROM, but does not identify with a realmode bios header, so DOS does not identify it as rom, and the system hangs up terribly when you map it out.

QEMM and company detect the bits that act like ram, and try to include it-- causing lockups.

The region in which that happens seems to be different, and of different sizes, on different modern computers. Sometimes its the whole damn adapter region, just about. This is why I only really feel safe including the monochrome display buffer, to get DOS to load high and into UMB on such systems! I have to meticulously experiment with what I can get, and what I cannot.

I suspect that the previous poster's reports of realmode trapping working, but protected mode trapping failing, comes from adapter memory area "Not really being free", and some system process wanting to do something with the region of memory that has been enabled for UMBs, which also happens to be were DOS is sitting, and HDPMI is loaded, causing severe problems.

I especially think this is the case, since the PS/2 keyboard and mouse emulation breaks. That means the realmode handler is getting klobbered by the upper memory area includes, usually.

We really need a tool to help better analyze the UMA on modern machines, to give a good idea of what regions we can include, or should exclude.

I had some time to play around with the "HP T510 Thin Client".

So I edited my CONFIG.SYS by adding "I=B000-B7FF" like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=E000-EFFF I=B000-B7FF

however the USB keyboard still moved on it's own in games.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE

but DOOM still stops at "I_StarupSound", BTW removing "LH" seems to have no affect on conventional memory.

Next I edited my AUTOEXEC.BAT like this:

JLOAD.EXE QPIEMU.DLL
HDPMI32I.EXE -R -X
SBEMU.EXE /T6 /H5

and ran DOOM's setup.exe file again, however DOOM still stops at "I_StarupSound".

by default, jemmex tries to turn on umbs in the uma. You would need to exclude the whole umb region as well.

eg.

X=C000-FFFF, then have the include
I=B000-B7FF

and then slowly walking back that massive exclude bit by bit, through experimentation.

Even then, oddities with some HDA devices cause such crashes, I have found.

I tried that yesterday like this:

DEVICE=JEMMEX.EXE X2MAX=8192 X=C000-FFFF I=B000-B7FF

and Doom still crashed, and the keyboard still messed up.

MoneySquirrel wrote on 2024-05-12, 22:02:

Also what version of Doom are you using? I've only used Ultimate Doom with sbemu. But usually Doom, Duke3d, Quake, and Wolf3d work mostly fine. It's the deeper dos library that can get problematic. Have you tried using a different irq and dma? Although strange that Quake works fine. Maybe Crazii will have some input. I have all of my usb ports disabled, but other than taking up irq's, usb never really caused any big issues for me in dos. It may have caused a conflict with my dos Ethernet driver, but I don't use that very often. I would also try one of the earlier versions from April on the GitHub page, as the beta4 did give me an issue with Dune 2. You can try "sbemu /i5 /d3" and also update the settings in Doom setup.

I am using the original DOOM from 1994, and I had already disabled all COM ports, Ethernet, and printer port in BIOS, when I try to use SBEMU /I5 /D3, SBEMU said IRQ 5 conflict, I have yet to try older versions of SBEMU.