BitWrangler wrote on 2023-03-06, 19:52:

Dang, trying to remember what I was doing in 1996 to just turn on CD input to a card all the time, so if you were in DOS and stuck a CD and hit play on the drive, you just heard it, no messing. So I'd hope, that would stick in a game that just put out CD audio and hoped you had it turned on.

Need MSCDEX.EXE and a CDROM driver interface driver loaded. SHSCD.SYS by Jason Brooks (?) works well, as many other such as OAKCDROM.SYS. But, not sure about modern SATA-drives in DOS. I think Jason Brooks DOS utilities, which include a dos RAM DISK and Virtual CD-ROM emulator as well, will work with real physical SATA CD / DVD drives in DOS.

You also need that audio cable, as already mentioned, physically connected from the CD drive to the motherboard or sound card itself. Don't think many "modern" motherboards, particularly laptops even have such a connector any more.

sparky4 wrote on 2023-03-06, 19:12:

how dose one compile it?
i really want to help test this

The compiled binary is already provided. Just download SBEMU.zip from the other thread (page 21), or download the binary posted by crazii in first post of this thread. Decompress the file and follow the directions in the readme.txt.

Let us know if you succeed in getting audio from SBEMU on a "modern" system.

sparky4 wrote on 2023-03-06, 20:25:

impulse tracker works perfectly on the Thinkpad T440p
what is this black magic?

It is some potent stuff! So does Dual Module Player, Mplayer, MikMod, Open MPT, and other trackers / players.

I couldn't get Cubic Player working or DSS (Digital Sound System, 2003 CWSDPMI Russian project) working, however. Cubic just gives static with its deviceSB drivers. Not sure how to fix that. Tried IRQ 5 / 7, changing /T from /T1 to /T5 to /T6, and samplerate from 22050 to 44100 or vice versa. Same result (static) with all on Cubic Player. And DSS can't detect any Sound Blaster card.

digger wrote on 2023-03-07, 01:00:

I do believe however, that secure boot mechanisms should always be implemented in a way that allows owners to install whatever OS they want on their devices, and also to disable such security features if they want to. Offered as a feature? Yes. Enabled by default? Yes. Forced upon the user whether they want it or not? F🤬k, no.

Sorry. I keep going off-topic here. Although it's clear that these topics are related. Ultimately this is about preserving native DOS gaming compatibility on as many kinds of hardware as possible, for as long as possible. On a modern legacy-free PC, ISA sound card emulation is one important part, but somehow being able to boot DOS from UEFI is another.

Agree completely, totally. Don't wall the garden off, but allow users to install whichever OS that they want. It's *their* computer, not yours. You (greedy, walled garden company) may 'paternalistically' think you "own" the user and the computer, but YOU DO NOT.

And, digger, thanks so much for the cogent and very clear clarification above on CSM and legacy option ROMs. It is the best I've ever read. And should be posted as the legacy for all who have a "modern" system to understand. Those three conditions must be met -- or not legacy (DOS) support!

It is a pretty tall order, but I'm sure within a short time, coding experts interested in preserving the 30-year legacy of important DOS software will have figured out how to do it. Running bare metal with compatibility is very, very important to many. I can only hope the backlash will continue and more will eschew the "security" limitations of Microsoft and Intel in the future...

This is also why the SBEMU project is so important and groundbreaking. The two topics are definitely intertwined.

zyzzle wrote on 2023-03-07, 04:22:

You also need that audio cable, as already mentioned, physically connected from the CD drive to the motherboard or sound card itself. Don't think many "modern" motherboards, particularly laptops even have such a connector any more.

The analog CD connector existed only in desktop IDE (PATA) 5.25'' optical drives. SATA optical drives no longer have it. This is what really made SATA optical drives different.

I'm not sure how laptops handle analog CD audio path, but there definitely was no "cables" for laptop drives.

If your motherboard doesn't have IDE ports, you can connect an IDE drive with an IDE-SATA adapter. With the analog CD cable connected to the drive and your soundcard, you can still use analog CD audio in OSes that predate digital CD audio, such as DOS and older Windows.

sledge wrote on 2023-03-05, 19:10:

Great stuff! Would this work with old netbooks? Asus EEE 701/90x for example?

Holy sh*t it works! I've just played Doom and Warcraft on Asus EEE 900HA under FreeDos. With sound! What kind of sorcery is this?! 😀 One thing that didn't work is Cubic Player, it plays "something", but the music is garbled.

georgel wrote on 2023-03-06, 03:19:

It would be interesting to dedicate a second CPU (core) where available to the emulation of the SB.

Multi core processing in DOS would be mind-blowing. Second core could run not only sb/opl emulation, but a whole software midi synthesiser.

digger wrote on 2023-03-07, 01:00:

Yes, it's actually for security reasons. The legacy boot mechanism of yore is a build-up of old standards that were never seriously designed with computer security in mind.

with a strong distinction of "security" here meaning software running on it being secured from You the user. Secure Boot is all about DRM [digital rights management aka you have no right to own anything], taking away complete control over your computer away from You.

rasz_pl wrote on 2023-03-07, 10:10:

with a strong distinction of "security" here meaning software running on it being secured from You the user. Secure Boot is all about DRM [digital rights management aka you have no right to own anything], taking away complete control over your computer away from You.

Indeed. It's more about the system vendors' (as well as the content providers') security rather than the users' own. Especially this one, which I think is pretty much what DRM (as well as other "trusted" mechanisms) is about.

Consumers need to trust the devices, and so do the service providers. The owner of a platform is not always the one to protect. For example, one of the biggest concerns of any content provider is its for-profit contents being transmitted to a rogue device that has been hacked by the owner. If the provider was not able to identify compromised devices, hackers could happily consume the received contents for free or even share with more people, resulting in direct profit loss for the provider.

On the other hands, I wonder if there are any effective use cases about making use of those "trusted" mechanisms to the user's own benefits, like being in full control of what could be run as well as whom to trust. For now, it's better not derail the topic.

sledge wrote on 2023-03-07, 06:24:

sledge wrote on 2023-03-05, 19:10:

Great stuff! Would this work with old netbooks? Asus EEE 701/90x for example?

Holy sh*t it works! I've just played Doom and Warcraft on Asus EEE 900HA under FreeDos. With sound! What kind of sorcery is this?! 😀 One thing that didn't work is Cubic Player, it plays "something", but the music is garbled.

Perhaps you could offer some insight? I'm trying with FreeDOS on an Asus Eee 701.

I'm running Jemmex by selecting it in the FreeDOS startup menu. (I had to replace the stock jemmex.exe with the SBEMU version in the FreeDOS /bin directory for that to work.)

Running the commands in the readme, qpiemu.dll and HDPMI32 load successfully. Then running SBEMU.EXE returns:

1Found sound card: Intel HDA
2Sound card IRQ conflict, abort.

[edit] Oh never mind 😁 I disabled card reader & LAN in BIOS, and the resources freed up. @crazii you are a wizard, thank you for your work!

@Pierre32: Isn't it absolutely magnificent? It actually turns these old netbooks into something useful! 😀 Btw. I too needed to replace jemmex, the one bundled with FreeDOS caused the machine to lock up. If you run into problems with some older games throwing "packed file is corrupt" error, run them with Loadfix, i.e. "loadfix ski.exe adlib" for Ski or Die with OPL music 😀

Sorry, have been through some off-topic discussions previously.

I'm considering giving this a try on some systems, but I've a question: Can I specify which audio card to use for SBEMU? If not, is there a priority order on deciding which audio device to use?

I have a discrete PCI sound card installed on the target system that works along with the onboard HDA (they're being used by different OSes), and both may be used for SBEMU, so I want to manually choose the audio device I want to use SBEMU with.

EDIT: Just took a look at the code and it doesn't seem to be implemented yet (though the related part is based on MPXPLAY and should in theory be doable).

I think someone wrote that had successfuly run ZSNES with sbemu.
When I run it (v 1.51) I get this beautiful pattern. Tried different menory managers (Jemm, qemm, himemx), different /T switches and IRQ 5/7, RM0. But could not find the right combination. Runs fine withou sbemu.

LSS10999 wrote on 2023-03-07, 13:14:

I have a discrete PCI sound card installed on the target system that works along with the onboard HDA (they're being used by different OSes), and both may be used for SBEMU, so I want to manually choose the audio device I want to use SBEMU with.

EDIT: Just took a look at the code and it doesn't seem to be implemented yet (though the related part is based on MPXPLAY and should in theory be doable).

It's surely doable, but how to tell SMEMU what card to use? Currently SBEMU scans the sound devices and uses the first it can handle. However,, in a system with a discrete sound card and a "modern" video card, there might be 3 HDA devices: the one on board, the discrete one and the one included in HDMI. They may be distinguished by the PCI bus/device numbers, but is the user supposed to know such infos?

Baron von Riedesel wrote on 2023-03-07, 15:18:

LSS10999 wrote on 2023-03-07, 13:14:

I have a discrete PCI sound card installed on the target system that works along with the onboard HDA (they're being used by different OSes), and both may be used for SBEMU, so I want to manually choose the audio device I want to use SBEMU with.

EDIT: Just took a look at the code and it doesn't seem to be implemented yet (though the related part is based on MPXPLAY and should in theory be doable).

It's surely doable, but how to tell SMEMU what card to use? Currently SBEMU scans the sound devices and uses the first it can handle. However,, in a system with a discrete sound card and a "modern" video card, there might be 3 HDA devices: the one on board, the discrete one and the one included in HDMI. They may be distinguished by the PCI bus/device numbers, but is the user supposed to know such infos?

The most practical solution from a usability perspective that I can think of: when run without a command-line argument that picks one, let SBEMU scan all PCI(e) devices and when it detects more than one supported physical audio device, show all the detected ones in a numbered list of device names, and require the user to pick one by specifying the number next to the desired output device as an explicit command-line argument. (And when only one supported audio device is detected, load successfully while using that one automatically, of course.)

Ditto in the case of multiple USB audio devices, once support for those is added too.

Would that be feasible to implement?

digger wrote on 2023-03-07, 22:50:

The most practical solution from a usability perspective that I can think of: when run without a command-line argument that pick […]
Show full quote

Baron von Riedesel wrote on 2023-03-07, 15:18:

LSS10999 wrote on 2023-03-07, 13:14:

I have a discrete PCI sound card installed on the target system that works along with the onboard HDA (they're being used by different OSes), and both may be used for SBEMU, so I want to manually choose the audio device I want to use SBEMU with.

EDIT: Just took a look at the code and it doesn't seem to be implemented yet (though the related part is based on MPXPLAY and should in theory be doable).

It's surely doable, but how to tell SMEMU what card to use? Currently SBEMU scans the sound devices and uses the first it can handle. However,, in a system with a discrete sound card and a "modern" video card, there might be 3 HDA devices: the one on board, the discrete one and the one included in HDMI. They may be distinguished by the PCI bus/device numbers, but is the user supposed to know such infos?

The most practical solution from a usability perspective that I can think of: when run without a command-line argument that picks one, let SBEMU scan all PCI(e) devices and when it detects more than one supported physical audio device, show all the detected ones in a numbered list of device names, and require the user to pick one by specifying the number next to the desired output device as an explicit command-line argument. (And when only one supported audio device is detected, load successfully while using that one automatically, of course.)

Ditto in the case of multiple USB audio devices, once support for those is added too.

Would that be feasible to implement?

Normally with existing MPXPLAY codebase it shouldn't be difficult to pick up a discrete sound card that is relatively unique in nature, such as CMI, ESS, SBLive/Audigy/X-Fi, etc.

The harder part would be how to distinguish different devices of the same nature, particularly common for Intel HDA (onboard, HDMI, or even Sound Core3D), as well as USB Audio Class devices. One most likely will need to obtain their vendor:device IDs in order to tell them apart.

LSS10999 wrote on 2023-03-08, 00:29:

The harder part would be how to distinguish different devices of the same nature, particularly common for Intel HDA (onboard, HDMI, or even Sound Core3D), as well as USB Audio Class devices. One most likely will need to obtain their vendor:device IDs in order to tell them apart.

The used MPXPlay code already does that. There isn't really that long of a list, of supported ven/dev. It is just that so many devices are covered by the AC97/HDA devices idents. All other audio devices would just be ignored. MPXPlay already has code, for user defined device selection. It would just need to be utilized or re-implemented by SBEMU.

Bondi wrote on 2023-03-07, 14:54:

I think someone wrote that had successfuly run ZSNES with sbemu.
When I run it (v 1.51) I get this beautiful pattern. Tried different menory managers (Jemm, qemm, himemx), different /T switches and IRQ 5/7, RM0. But could not find the right combination. Runs fine withou sbemu.

I have a similar pattern, with an old version of Wolf3d. That version has never worked on the tested machine. I always get a pattern like that, then a lockup. Without SBEMU, I get a buzzing noise too. With SBEMU, I get silence and the lock up.

I'm not mentioning it to get support for Wolf3d; other versions work fine (still without sound). I only mention it because the pattern is similar.

Did you have sound with ZSNES? Do you have sound with other Dos games/applications?

When I run ZSNES 1.51, with SBEMU, I get a bunch of mixed in black lines and it freezes.
If I run ZSNES, with out SBEMU, it is fine. But if I run "HDPMI32I -X -R" and ZSNES, without SBEMU, I get the pattern like yours.
I bet the same would be true with your system. HDPMI32I, without SBEMU, probably still causes an issue.

L4MD4 wrote on 2023-03-08, 03:52:

I have a similar pattern, with an old version of Wolf3d. That version has never worked on the tested machine. I always get a pat […]
Show full quote

Bondi wrote on 2023-03-07, 14:54:

I think someone wrote that had successfuly run ZSNES with sbemu.
When I run it (v 1.51) I get this beautiful pattern. Tried different menory managers (Jemm, qemm, himemx), different /T switches and IRQ 5/7, RM0. But could not find the right combination. Runs fine withou sbemu.

I have a similar pattern, with an old version of Wolf3d. That version has never worked on the tested machine. I always get a pattern like that, then a lockup. Without SBEMU, I get a buzzing noise too. With SBEMU, I get silence and the lock up.

I'm not mentioning it to get support for Wolf3d; other versions work fine (still without sound). I only mention it because the pattern is similar.

Did you have sound with ZSNES? Do you have sound with other Dos games/applications?

When I run ZSNES 1.51, with SBEMU, I get a bunch of mixed in black lines and it freezes.
If I run ZSNES, with out SBEMU, it is fine. But if I run "HDPMI32I -X -R" and ZSNES, without SBEMU, I get the pattern like yours.
I bet the same would be true with your system. HDPMI32I, without SBEMU, probably still causes an issue.

Wolf3d and many other games work fine with sound.
And I get no sound when get this pattern on snes ZSNES, it just locks. Once with one of the combinations I got a vertically rolling pattern, that was even more beautiful 😀
ZSNES uses cwsdpmi, maybe that's the reason. However I found it was zyzzle who ran ZSNES successfully.
What kind of system do you do your testing on?

tercio wrote on 2023-03-05, 17:44:

Congrats bro! This is a very good project! It's possible include support for Realtek Ac97 chips?

Theoretically It doesn't care what AC97 codec you have, but the motherboard, what kind of mobo do you have?