Cacodemon345 wrote on 2025-01-27, 14:28:

I probably can add Munt emulation, but I'm not sure about adding Tandy emulation.

I will think about the latter later.

I appreciate that! Shall I open a GitHub issue for munt support?

Tandy emulation is a bit less valuable, but it could be useful for games in which this is the best supported sound device. Those tend to be games that were released specifically with support for the PCjr and/or Tandy 1000 computers, before the Adlib and Sound Blaster cards became widely adopted and supported.

However, games from this earlier era still require patches in order for them to...

• ...enable 3-voice audio on systems other than the IBM PCjr and/or Tandy 1000
• ...enable this in combination with EGA or VGA graphics modes, without also automatically switching to the specific 16-color graphics mode that only the PCjr and Tandy 1000 systems supported
• ...support the newer I/O address (1E0h) that Tandy used for the 3-voice sound synth in later Tandy 1000 models, since IBM later repurposed the original I/O address (C0h) for the second DMA controller in the PC/AT (286)

(I believe there are many patches already floating out there to fix these issues in various games.)

So yeah, the "cost/benefit analysis" of implementing Tandy support (the number of games that would benefit from it versus the effort to implement support for it) is likely less than that of adding Roland MT-32/CM-32 support.

But you wouldn't have to start from scratch. And it's also likely a lot more trivial to emulate than DMA DAC or MIDI devices.

You can likely copy code from the PicoGUS project, which has already implemented Tandy emulation. And just support the later I/O address for it (1E0h), since I believe patches are already floating out there to get games to work on that port. Although on the other hand, the second DMA controller isn't used for anything anymore on modern systems, so if you were to trap and emulate the original Tandy 3-voice I/O address (C0h) that the PCjr and Tandy 1000 used and that the older games depend on, the only potential conflict you'd have would be with a virtual Sound Blaster 16 if VSBHDASF was emulating that together with the Tandy device. You could add logic to emulate Tandy on the original I/O address only if a Sound Blaster Pro or WSS card were emulated beside it, and emulate it only on the newer port if the emulator is configured to emulate a Sound Blaster 16 including high DMA.

Thanks for considering both features! I'll just create separate GitHub issues for both these features when I get home. You can of course just close the Tandy one if you decide not to support it.

Nemo1985 wrote on 2025-01-27, 16:11:

A troublesome configuration apparently, sorry... I just tried the beta4 it detects the soundcard correctly but has the very same […]
Show full quote

Cacodemon345 wrote on 2025-01-27, 16:06:

That's a lot of commits to traverse. Does it work on SBEMU 1.0beta4?

A troublesome configuration apparently, sorry...
I just tried the beta4 it detects the soundcard correctly but has the very same issues of beta5 with build engine.
If I can be of any help with troubleshooting and test I'm available.

The board in question uses a SiS chipset. Can you post a list of all PCI devices using "lspci -vvv" on Linux? I suspect it's using the unsupported SiS 7012 audio chipset.

Cacodemon345 wrote on 2025-01-27, 17:49:

Nemo1985 wrote on 2025-01-27, 16:11:

A troublesome configuration apparently, sorry... I just tried the beta4 it detects the soundcard correctly but has the very same […]
Show full quote

Cacodemon345 wrote on 2025-01-27, 16:06:

That's a lot of commits to traverse. Does it work on SBEMU 1.0beta4?

A troublesome configuration apparently, sorry...
I just tried the beta4 it detects the soundcard correctly but has the very same issues of beta5 with build engine.
If I can be of any help with troubleshooting and test I'm available.

The board in question uses a SiS chipset. Can you post a list of all PCI devices using "lspci -vvv" on Linux? I suspect it's using the unsupported SiS 7012 audio chipset.

Yes I can confirm it does even without checking, I know because find the right drivers for the soundacrd has been quite difficult.

How much grunt does this need? Would a 2010s thin client with a later Atom, like the ubiquitous Dell 3040, or one of the Geode / other AMD embedded CPU clients from HP be enough to work reliably?

https://github.com/Cacodemon345/VSBHDASF/releases/tag/v1.5

New release adding period size option for slower CPUs. Also attempted backporting of SiS 7012 support from SBEMU (not tested due to lack of real hardware), and there's a MPU-401 bugfix.

justin1985 wrote on 2025-01-27, 18:50:

How much grunt does this need? Would a 2010s thin client with a later Atom, like the ubiquitous Dell 3040, or one of the Geode / other AMD embedded CPU clients from HP be enough to work reliably?

It depends on single-thread performance. I believe that Pentium Dual-Cores will be able to handle this properly. No idea about Geode processors.

Cacodemon345 wrote on 2025-01-27, 19:07:

https://github.com/Cacodemon345/VSBHDASF/releases/tag/v1.5

New release adding period size option for slower CPUs. Also attempted backporting of SiS 7012 support from SBEMU (not tested due to lack of real hardware), and there's a MPU-401 bugfix.

Thanks!
I tried the new version with standard settings (I used the "set blaster=A220 P330 I7 D1 H5 T6") and blood works like a charme, I've let it run for 10 minutes with no issues, while before it hanged after like 30 seconds.
For duke nukem 3d the situation is a bit more complicate, if I choose awe32 for music the game hangs during the preliminary loading (Checking music inits.), if I choose the general sound blaster sound works fine but it suffers from broken notes and noticeable slow down.
I also noticed that the general volume is quite low, should I use the /vol switch? What is the default value?
Link: https://youtu.be/MNjHR5lC8nI

You should use the MPU-401 option (in setup it should be called General MIDI). I don't know how well tested and optimized VSBHDA's OPL emulation is so I can't help on that front.

Since you appear to be using a Pentium 4 machine, you should try using the Pentium 4-optimized executable. I'd suggest the /PS option but it's not exactly hooked up to the AC97 backend.

Cacodemon345 wrote on 2025-01-27, 20:01:

You should use the MPU-401 option (in setup it should be called General MIDI). I don't know how well tested and optimized VSBHDA's OPL emulation is so I can't help on that front.

Since you appear to be using a Pentium 4 machine, you should try using the Pentium 4-optimized executable. I'd suggest the /PS option but it's not exactly hooked up to the AC97 backend.

Thank you for your patience.
General midi doesn't produce any output and hangs the system (both in duke3d and blood).
I'm already using the p4 optimized executable, I tried the /ps switch with 256,512 and 1024 without any difference, what is it supposed to do?
Just to be sure I'm not doing anything wrong, those are my current settings in autoexec.bat:
C:\UTIL\vsbhdasf\JLOAD.EXE C:\UTIL\vsbhdasf\QPIEMU.DLL
LH C:\UTIL\vsbhdasf\HDPMI32I.EXE -B -A
C:\UTIL\vsbhdasf\vsbhdap4.exe

If there's no TinySoundFont message when starting VSBHDASF it means the MPU-401 emulation isn't currently enabled, which will cause games trying to access it to freeze.

You need to set up the soundfont first (set SOUNDFONT=/path/to/soundfont.sf2) in the autoexec, and also set up the BLASTER environment variable specifying all the settings (including MPU-401) and then run VSBHDASF. It should at least print a line saying P=330 or P=300. You can attempt testing MIDI files with DOSMID, it should output music.

If the volume level is too low you can run with /VOL9.

Cacodemon345 wrote on 2025-01-27, 20:35:

If there's no TinySoundFont message when starting VSBHDASF it means the MPU-401 emulation isn't currently enabled, which will cause games trying to access it to freeze.

You need to set up the soundfont first (set SOUNDFONT=/path/to/soundfont.sf2) in the autoexec, and also set up the BLASTER environment variable specifying all the settings (including MPU-401) and then run VSBHDASF. It should at least print a line saying P=330 or P=300. You can attempt testing MIDI files with DOSMID, it should output music.

If the volume level is too low you can run with /VOL9.

Thank you it works like a charme now, if you like me to test any other application to ensure the compatibility i'm available.

Any tips for configuring JEMM properly when using a Soundfont under FreeDOS?

I tried on FreeDOS1.3 on my modern gaming PC and it successfully loaded 2GMGSMT.S2 (taken from a SB Live install image, just the first I had to hand). But when I tried running Doom, I got "DOS/16M error: not enough memory to load program" . An older game I tried (Lost Vikings) worked fine, but that doens't use General Midi anyway. I guess loading the soundfont is consuming a lot of memory, and it is a question of setting up Jemm differently - but I'm out of my depth here - any help appreciated!

If disk access speed is suspected (of causing slowdowns), use of xmsdsk to host the soundfont might be diagnostic / corrective?

justin1985 wrote on 2025-01-27, 22:12:

Any tips for configuring JEMM properly when using a Soundfont under FreeDOS?

I tried on FreeDOS1.3 on my modern gaming PC and it successfully loaded 2GMGSMT.S2 (taken from a SB Live install image, just the first I had to hand). But when I tried running Doom, I got "DOS/16M error: not enough memory to load program" . An older game I tried (Lost Vikings) worked fine, but that doens't use General Midi anyway. I guess loading the soundfont is consuming a lot of memory, and it is a question of setting up Jemm differently - but I'm out of my depth here - any help appreciated!

I noted with git released sbemu that I *need* to restrict the amount of XMS memory for it to not crash when games use it. It is simply not optional.

I would suggest using the max xms flags with jemmex and limiting to something 'sane' for a dos pc, like 32mb.

Try executing "jemmex novcpi" before running Doom, that should fix some issues with protected-mode executables

EDIT: I’ve done more testing with my eBox 2350MX. Using the /MV to limit voices or changing /PS has little to no effect. I’ve also tested a smaller SF2 (just under 1 MB), and there’s no noticeable difference in performance. My guess is that TinySoundFont heavily depends on FPU performance. The Vortex86MX has a terrible FPU; even at 933 MHz, it performs like a Pentium II running at 350 MHz.

I tried several programs, also the "infamous" alladin which always has been somewhat problematic.
With this lines works fine with soundfonts:
Config.sys:
DEVICE=C:\UTIL\JEMMEX.EXE X=TEST I=TEST I=B000-B7FF XMSHANDLES=32 X2MAX=16384

Autoexec.bat
LH C:\UTIL\VSBHDASF\HDPMI32I.EXE -B -A -R -X

I tried doom and fastdoom: Doom music works fine, doom sounds are garbled. Fastdoom doesn't work because it doesn't detect either the sound nor the music, classic. it says unable to find blablabla: -1.

Run JEMMEX with NOVCPI after loading VSBHDASF, because FastDOOM won't detect anything otherwise.

I only tested with Vanilla DOOM 2 v1.9 executable, not anything else. It may be running into strange sample rate issues that I forgot to take care of, since I only extensively tested it with the Sound Blaster 16 option.

Cacodemon345 wrote on 2025-01-28, 07:30:

Run JEMMEX with NOVCPI after loading VSBHDASF, because FastDOOM won't detect anything otherwise.

I only tested with Vanilla DOOM 2 v1.9 executable, not anything else. It may be running into strange sample rate issues that I forgot to take care of, since I only extensively tested it with the Sound Blaster 16 option.

With that it works fine, no audio issues with fastdoom but it worses very much the running of the classic doom audio which gets completely garbled, do you think it's a issue of my configuration?

Nemo1985 wrote on 2025-01-28, 07:42:

Cacodemon345 wrote on 2025-01-28, 07:30:

Run JEMMEX with NOVCPI after loading VSBHDASF, because FastDOOM won't detect anything otherwise.

I only tested with Vanilla DOOM 2 v1.9 executable, not anything else. It may be running into strange sample rate issues that I forgot to take care of, since I only extensively tested it with the Sound Blaster 16 option.

With that it works fine, no audio issues with fastdoom but it worses very much the running of the classic doom audio which gets completely garbled, do you think it's a issue of my configuration?

What's the BLASTER environment variable you're using? It needs to use `T6` (makes VSBHDASF emulate a SB16).

Cacodemon345 wrote on 2025-01-28, 07:56:

Nemo1985 wrote on 2025-01-28, 07:42:

Cacodemon345 wrote on 2025-01-28, 07:30:

Run JEMMEX with NOVCPI after loading VSBHDASF, because FastDOOM won't detect anything otherwise.

I only tested with Vanilla DOOM 2 v1.9 executable, not anything else. It may be running into strange sample rate issues that I forgot to take care of, since I only extensively tested it with the Sound Blaster 16 option.

With that it works fine, no audio issues with fastdoom but it worses very much the running of the classic doom audio which gets completely garbled, do you think it's a issue of my configuration?

What's the BLASTER environment variable you're using? It needs to use `T6` (makes VSBHDASF emulate a SB16).

I'm using it those settings: SET BLASTER=A220 P330 I7 D1 H5 T6

It's probably an issue of your configuration then, unfortunately. Make sure the executable is on v1.9. I don't know what else would cause the output to get garbled up.

One thing of note is that the Sound Blaster emulation code is somewhat of a mess; it's entirely possible to encounter weird machine-specific bugs.