veelstekel wrote on 2024-05-13, 08:04:

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 […]
Show full quote

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.

I put this in my AUTOEXEC.BAT:

SET BLASTER=A220 I7 D1 T4

and then edited the doom configuration file, DOOM started, but I only got music, and when DOOM does crash at "I_StartupSound" it just sits there and does nothing until you press a key on the keyboard, and then it shows a JemmEx error.

I am likely going to give up on this thin client and try another type.

MoneySquirrel wrote on 2024-05-13, 22:17:

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.

Yes. The game works well, there is sound and music. In the Setup of the game, I selected SB PRO, SBEMU was launched without parameters.

will1384 wrote on 2024-05-13, 23:37:

I tried that yesterday like this: […]
Show full quote

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

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.

Sorry to hear that. Best I can tell you, is just wait and see. Crazii is pretty actively plugging away at fixing the odd and obscure initilization quirks of some HDA chipsets, and his work coincidentally resolved a similar set of problems I was having on a Toshiba laptop.

I'd say it is probably down to an issue with the audio chipset in your thin client being a little strange to initialize.

@wierd_w
I'd say it is probably down to an issue with the audio chipset in your thin client being a little strange to initialize.

Probably the down problem, 5 types of machines i tried, all of them are good, at least with my favorite titles.

I just found that VSBHDA 1.5 pre1 was silently released and it fixes the extreme low volume level. I checked on my SB Audigy and now the output volume is similar to SBEMU or MPXPlay as expected. Thx.
[ https://github.com/Baron-von-Riedesel/VSBHDA/ … es/tag/v1.5pre1 ]

BTW interesting that I stopped receiving notifications to new posts in this watched thread. Should I have to configure something in my personal settings to keep watching threads until I explicitly unwatch it?

Has anyone got sound effects working in Traffic Department 2192? Music works fine but the config doesn't give any options expect PC speaker and running with /sb doesn't make any difference.

Guys is it possibly to add AMD CS5536 Geode companion AC'97?

hooddy wrote on 2024-05-16, 11:36:

Guys is it possibly to add AMD CS5536 Geode companion AC'97?

Well I think you need to port this driver: https://github.com/torvalds/linux/tree/master … pci/cs5535audio
On the github a creation of a porting guide is already requested: https://github.com/crazii/SBEMU/issues/111
Here is a list of already ported drivers: https://github.com/crazii/SBEMU/pull/98

krotan wrote on 2024-05-04, 13:34:

Testing 10b4. 1. Fast Tracker v2.12 It works, but the soundblaster is not recognized. 2. Scream Tracker v3.21 Doesn’t work, it s […]
Show full quote

Testing 10b4.
1. Fast Tracker v2.12
It works, but the soundblaster is not recognized.
2. Scream Tracker v3.21
Doesn’t work, it says “initialization...” and hangs.
3. Impulse Tracker v2.15
Works great.
4. CHASM - The Rift
Doesn't start.
But if you first run the command hdpmi32i.exe -d, it starts and works well, but without sound.
Reports an error initializing sound.
5. DooM LEGACY v1.30
Same as chasm.

Thanks, what's your PC spec? I'll try to fix those when time is avialable.

zyzzle wrote on 2024-05-05, 03:27:

crazii wrote on 2024-05-04, 02:50:

Here's early test edition of SBEMU with new DPMI (let's call it 1.1-alpha1 release candidate 1 for now),
which includes the new DPMI I'm working intensively on for more than 2 months.
It's been tested by veelstekel for couple of days but now he is temporarily unavailable, so I post the zip here for an early testing.

Thanks for this beta version of your new DPMI!

I got it working with Tyrian and Jazz Jackrabbit on the same laptop (Kaby Lake, Realtec ALC259 HDA PCI sound). However, the initial load process was a bit unstable (I got a freeze on one of three attempts). The batch file I created loads Jemmex, then QPIEMU, then your VDPMI.EXE (with no commandline options), then SBEMU (-F44100 -VOL9 -A220 -I5 -D1 -T6), then sets BLASTER=A220 I5 D1 H5 T6 environment variable.

OK, it is at early prototype stage so such problems are not unexpected. But the remaining problems on beta4 will be fixed before moving to this one.

Demolition-Man wrote on 2024-05-05, 12:16:

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

No, it should work as before, but since it have breaking changes and is not well-tested so things might not work as before. feel free to report any issues. 😁

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 haven't seen such problems for now, but only one that annoys me if booted from USB stick.
The LH will crash instantly whenever you use it.
The USB controller needs physical addressed like all other PCI busmaster devices, and the BIOS simulation probably treat the UMB as conventional mem and use it directly for USB transfer. but some UMB regions are page mapped, the address is virtual not physical.

But if a program loads (copy) itself to UMB, it is OK, i.e. CTMOUSE without LH still works in UMB.
and, LH works after USBDDOS installed, which doesn't use the INT21 input memory directly for USB transfer but copy it to an dedicated memory location.
Seems no easy way to solve it without a usb driver - the BIOS is unable to get the paging information, even if it can preserve some RAM for legacy usb simulation and perform copy on INT13h, the preserved RAM might be page mapped when v86 monitor present.

@crazii
Hello again, I have difficulties with the English language, especially when it gets too technical. So I apologize if I didn't understand something correctly. There are currently two different versions of SBEMU? A “normal” one and one that only works with AC97 variants with HDA? But that's the only way you can play certain protected mode games? Only newer integrated AC97 variants have this HDA?! I always test every new version of SBEMU immediately, but I only have the T5710 ThinClient for this. But this machine seems to have enough problems running certain DOS games, even without any audio driver or SBEMU. Not meant to be mocking, I tested Beta4 extensively, apart from the fact that parts of the text are now colorful, nothing has changed. Everything that runs runs exactly as before. I don't have many bugs to report. Dune 2 has the usual loudness problems in the intro, which also occurs with real non-Soundblaster sound cards. Settlers 2 also has strange sound problems in connection with the mouse but only in the menu, although I think it's the thin client. I still have a few questions: I've only ever tested Soundblaster Pro emulation. What happens now if I switch completely to SB16 emulation? Does this change anything in terms of compatibility? Does the sound really change? Does SB16 emulation perhaps need more resources?

Should I perhaps write a current list of what works with SBEMU on the ThinCient? Without a CD-ROM and with limited storage space, it's not that extensive. I already had a big list here, only it was with a Socket A Duron 900 system, where I have now switched to a board with an ISA slot.

I'm telling too much again. I also wanted to thank you again for this great and usable SB Emulator (SBEMU). The ThinClient would otherwise just be a slow Win 98SE machine, so there is far better DOS sound support than with the much too large and otherwise difficult VIA driver.

So thank you for the great work!

crazii wrote on 2024-05-16, 21:08:

Thanks, what's your PC spec?

ASUS Eee PC 900, Realtek HDA

Neufena wrote on 2024-05-15, 16:05:

Has anyone got sound effects working in Traffic Department 2192? Music works fine but the config doesn't give any options expect PC speaker and running with /sb doesn't make any difference.

It hangs at the command line for me. I had to use tppatch to fix a few of the files too.

It hangs at the command line for me. I had to use tppatch to fix a few of the files too.

I've applied tppatch already and everything works except the sound effects. Adlib music is fine but the game refuses to see the Soundblaster

crazii wrote on 2024-05-16, 21:41:

I haven't seen such problems for now, but only one that annoys me if booted from USB stick. The LH will crash instantly whenever […]
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 haven't seen such problems for now, but only one that annoys me if booted from USB stick.
The LH will crash instantly whenever you use it.
The USB controller needs physical addressed like all other PCI busmaster devices, and the BIOS simulation probably treat the UMB as conventional mem and use it directly for USB transfer. but some UMB regions are page mapped, the address is virtual not physical.

But if a program loads (copy) itself to UMB, it is OK, i.e. CTMOUSE without LH still works in UMB.
and, LH works after USBDDOS installed, which doesn't use the INT21 input memory directly for USB transfer but copy it to an dedicated memory location.
Seems no easy way to solve it without a usb driver - the BIOS is unable to get the paging information, even if it can preserve some RAM for legacy usb simulation and perform copy on INT13h, the preserved RAM might be page mapped when v86 monitor present.

If you would like, I can attempt to do a raw binary dump of some of the regions that cause serious issues when included on my test machines (One compaq laptop, one HP laptop, and one Toshiba laptop. All have a region in the UMA that causes serious hangs or other profound problems when included, that do not present with a proper ROM header, are not really writable, but contain mystery data.) for your investigation-- Sadly, the region is different on every one of them.

tested sbemu 11alpha1. results:
games:
Wolfenstein3d: failure due to insufficient memory
Chasm-The Rift: failure due to error 003 (I don't know what it is)
DooM LEGACY v1.30: failure, hangs
trackers:
Scream Tracker v3.21: works great!!!!!!
Fast Tracker v2.12: failure, hangs
Impulse Tracker v2.15: failure due to insufficient memory, but if you free up the memory it works fine!
XTC-play v0.97c: failure due to sound blaster is not recognized

My Alpha 1.1 tests were not very successful. Everything is displayed in green so enable, but only real mode games work, except Prince of Persia (FX). All protected mode games are stuck with DOS4GW.

crazii wrote on 2024-05-16, 21:41:

I haven't seen such problems for now, but only one that annoys me if booted from USB stick. The LH will crash instantly whenever […]
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 haven't seen such problems for now, but only one that annoys me if booted from USB stick.
The LH will crash instantly whenever you use it.
The USB controller needs physical addressed like all other PCI busmaster devices, and the BIOS simulation probably treat the UMB as conventional mem and use it directly for USB transfer. but some UMB regions are page mapped, the address is virtual not physical.

But if a program loads (copy) itself to UMB, it is OK, i.e. CTMOUSE without LH still works in UMB.
and, LH works after USBDDOS installed, which doesn't use the INT21 input memory directly for USB transfer but copy it to an dedicated memory location.
Seems no easy way to solve it without a usb driver - the BIOS is unable to get the paging information, even if it can preserve some RAM for legacy usb simulation and perform copy on INT13h, the preserved RAM might be page mapped when v86 monitor present.

Zen2 booted from an external USB SSD, the mapping that LH sees is good, there is really no ROM area. CTMOUSE uploaded + many more, the image rescue is up, without 600k+.
Config: B450PRO/R3800X/Motherboard Voice/SB0060/Chinese RTL M2 Case/8GB+90GB FAT32 Partitions.

The remaining 32K umb, on the other hand, may be a rom area, I'm not sure it's free ram.