.

Kamerat wrote on 2023-03-10, 09:18:

If you want audio in Windows 9x on newer systems you can always use an USB audio adapter. You can also get PCIe based CMI 8738 off Ebay that should support Windows 9x, but don't expect Sound Blaster emulation to be working inside Windows when using VxD drivers. I'm pretty sure SBEMU never were intended for use with Windows 9x

So we are in agreement the, yeah?

Forgive me, I'm being waggish. You are giving great advice. But maybe you misunderstood me, or more likely quoted the wrong user. Maybs mez jutz types its badlies 😀 I do sympathize with sergio_prado's question. I am guessing the desire is to have an alternative, to the Win16 HDA driver. I personally, would rather use the USB driver.

Someone once pointed out to me, that some systems cannot use USB audio; as they only have USB3. I'm not ashamed to admit, I hardly use any machine that includes any USB3 support. I have a few. Just not doing anything with them. I can't speak to sergio_prado's situation. As you see, I am guessing.

crazii wrote on 2023-03-05, 06:13:

The source code of SBEMU can be found here: https://github.com/crazii/SBEMU

I have tried compiling the source using djgpp from http://delorie.com/djgpp/zip-picker.html inside DOSBox. I installed it on the emulated disk inside DOSBox, used RHIDE to open the project and generate the makefile (primarily because I get glitchy behavior from the mouse inside RHIDE if I try to make the project inside it). It stops with an error after a while. It looks like the C++ compiler downloaded from there is missing some headers (indeed the file it complains about does not exist). Which DJGPP do you use to compile? I'm attaching a screen capture below.

1c++config.h 
2123456789.1

has more than 8 characters in the filename hence why it will fail in DOS. When the compiler and associated .h files were unzipped the names got shortened to 8 chars. No idea how to fix it yet.

Baron von Riedesel wrote on 2023-03-10, 07:44:

Well, yes, of course. I had problems with those SB PCI cards on a second machine that I tried. Turned out that it's not a good idea to enable interrupts for the sound card before the sbemu IRQ handler is installed. So I modified sbemu a bit and it worked ...

Thanks, how to not enable interrupts for the sound card before the sbemu IRQ handler install? The PCI IRQ is assigned by PnP BIOS and I cannot do much with it. But I have to mention that Mpxplay and games with native libau (QDOS, Q2DOS, HexenII...) plays fine via my Audigy so it shouldn't be big problem. Do you have somewhere your modified version to try please?
BTW how IO port trapping works in Pmode? I thought it's possible only in V86 monitor for RM apps or via HW virtualization.

EduBat wrote on 2023-03-10, 12:25:

has more than 8 characters in the filename hence why it will fail in DOS. When the compiler and associated .h files were unzippe […]
Show full quote

Copy code to clipboard

1c++config.h 
2123456789.1

has more than 8 characters in the filename hence why it will fail in DOS. When the compiler and associated .h files were unzipped the names got shortened to 8 chars. No idea how to fix it yet.

the file is actually not present at all in the downloaded package. It simply doesn't exist.

Some more quick testing I did. Test machine is the same Zotac Zbox ID80, with FreeDOS 1.3 (Dec 2022) installed
I replaced the default jemmex.exe with version 5.84, and also added jload.exe 5.84.

Sound testing of various programs/games using SBEMU:

opl440.com (generates a 440Hz sound using OPL2): works 😀

XCOM: works 😀

Terror From The Deep: works 😀

Dune2: works 😀

Monkey Island: crashes with jemmex exception 🙁

Duke3D: works 😀

Laser Squad: hangs at startup/the sound selection screen if option 2 (sound blaster) is chosen, requires soft reboot. If option 1 is chosen (AdLib) it does not hang and OPL sound works. So a mixed bag. It still hangs if I specify the exact SB parameters on the command line (laser.exe /SB220 /SI5)

Frontier Elite 2: does not run at all. It's probably not sound related but jemmex related - this game requires expanded memory, and it says it cannot find any expanded memory despite it being enabled and usable by other programs. (this game runs perfectly fine in DOSBox FWIW)

Frontier First Encounters: crashes with jemmex exception. (it also runs perfectly fine in DOSBox FWIW)

Adlib Tracker II: crashes (also works fine in DOSBox)

stamasd wrote on 2023-03-10, 12:07:

crazii wrote on 2023-03-05, 06:13:

The source code of SBEMU can be found here: https://github.com/crazii/SBEMU

I have tried compiling the source using djgpp from http://delorie.com/djgpp/zip-picker.html inside DOSBox. I installed it on the emulated disk inside DOSBox, used RHIDE to open the project and generate the makefile (primarily because I get glitchy behavior from the mouse inside RHIDE if I try to make the project inside it). It stops with an error after a while. It looks like the C++ compiler downloaded from there is missing some headers (indeed the file it complains about does not exist). Which DJGPP do you use to compile? I'm attaching a screen capture below. command_001.png

You need a LFN driver. I was using DOSLFN, which can be found on the net.
EDIT: The real file is cxxconfig.h, djgpp will auto use that file.

RayeR wrote on 2023-03-10, 12:30:

Thanks, how to not enable interrupts for the sound card before the sbemu IRQ handler install? The PCI IRQ is assigned by PnP BIOS and I cannot do much with it.

That's done inside SBEMU - the source must be modified.

But I have to mention that Mpxplay and games with native libau (QDOS, Q2DOS, HexenII...) plays fine via my Audigy so it shouldn't be big problem.

Mpxplay doesn't use the soundcard's native interrupt mechanism, but the normal PIT timer. That's not an option for sbemu. The problem with SBLive is that there's no proper documentation.

Do you have somewhere your modified version to try please?

I really don't want to start a competition "Who has the best sbemu", so please wait till crazii has fixed this in his source!

BTW how IO port trapping works in Pmode? I thought it's possible only in V86 monitor for RM apps or via HW virtualization.

Then how would Win9x have managed to make DOOM work in a DOS-Box, without port trapping?

.

crazii wrote on 2023-03-10, 13:23:

You need a LFN driver. I was using DOSLFN, which can be found on the net.
EDIT: The real file is cxxconfig.h, djgpp will auto use that file.

I tried DOSLFN. With it loaded, RHIDE crashes at start. So I generated the makefile in RHIDE without DOSLFN loaded, and then again tried to compile it in CLI with "make -f sbemu.mak" after loading doslfn. It doesn't work, it gets confused right at the start. See screenshot. The same thing happens with the older version 0.34 of doslfn.

Also, there is no cxxconfig.h either. The only cxx* files in include/cxx/9/bits are: cxx0_warning.h, cxxabi_forced.h and cxxabi_init_exception.h. Nothing else is present in the downloaded gpp930b.zip file
I've actually gone and looked into old releases of DJGPP going back to 1998. None of the released gpp packages included either bits/c++config.h or bits/cxxconfig.h

stamasd wrote on 2023-03-10, 14:46:

I tried DOSLFN. With it loaded, RHIDE crashes at start. So I generated the makefile in RHIDE without DOSLFN loaded, and then again tried to compile it in CLI with "make -f sbemu.mak" after loading doslfn. It doesn't work, it gets confused right at the start. See screenshot. The same thing happens with the older version 0.34 of doslfn.

You simply cannot use DosBox ( or DosBox-X , for that matter ) to create SBEMU. DOSLFN doesn't work in these environments - and DOSLFN is needed for DJGPP.

Is there a way to redirect the PC Speaker sound to these newer sound cards? In some software/hardware fashion or through emulation?

This is a really great project! Let's hope that it will pave the way for other cool stuff such as emulating other sound devices (like Gravis UltraSound), graphical fixes for running games on new GPUs, drivers for modern gamepads, and more...

.

For such compilation tasks I use DOS window under WinXP-32b where LFN works, DJGPP works and it runs faster than bare DOS + DOSLFN....

.

In my case the problem seems to be that the Freedos installer cut the filenames when it unzipped the DJGPP file.
DOSLFN is loaded and working fine, as we can see in the left panel of DZ.
I'll work on it sometime later, probably during the weekend.

EduBat wrote on 2023-03-10, 19:15:

In my case the problem seems to be that the Freedos installer cut the filenames when it unzipped the DJGPP file.

In my case, I did not unpack the djgpp files in freedos. The machine dual boots freedos and Win7. I unzipped them under Win7 with 7zip and then copied them over the DOS partition. No issues with name truncation this way.

Baron von Riedesel wrote on 2023-03-10, 17:14:

stamasd wrote on 2023-03-10, 14:46:

I tried DOSLFN. With it loaded, RHIDE crashes at start. So I generated the makefile in RHIDE without DOSLFN loaded, and then again tried to compile it in CLI with "make -f sbemu.mak" after loading doslfn. It doesn't work, it gets confused right at the start. See screenshot. The same thing happens with the older version 0.34 of doslfn.

You simply cannot use DosBox ( or DosBox-X , for that matter ) to create SBEMU. DOSLFN doesn't work in these environments - and DOSLFN is needed for DJGPP.

DOSLFN does work in PCem or 86Box if you do need a virtual env with it working. You might already know that...

Can we leave the emulation promotion out if this thread please? Don't use emulators to compile unless you are extremely bored, compile on real hardware with or without virtualization. If you want to waste time do it in another thread.