So this is the closest I've heard: There's been a version of HX Extender with Win32 support and AC97 sound support in DOS. People have loaded it, then run modified versions of DosBox in DOS. Unfortunately you still take the massive DosBox performance hit (because everything is being emulated) but still an interesting idea.

https://www.japheth.de/HX.html

digger wrote on 2020-05-12, 18:21:

Take for instance DOS/32A, an open-source drop-in for DOS/4GW. Could skilled coders (members of this forum perhaps) integrate a Sound Blaster emulator in
it,which would be accessible by the game, and which would output the sound (or at least the digital audio part) to something universal such as a parallel port DAC
like a Covox Speech Thing, or perhaps even to a more modern common audio device, such as a USB audio device, AC'97, HD Audio, etc?

Something like this already exists, albeit for Real-Mode titles only (but links into EMM386 which uses V86, similat ro DOS/4GW)..
- TEMU
- Virtual SoundBlaster
- Covoxer

https://en.wikipedia.org/wiki/Covox_Speech_Thing#Emulators
http://www.vcfed.org/forum/showthread.php?65247

http://www.dosforum.de/viewtopic.php?t=1188
Sound Blaster Emulator for Dos?

digger wrote on 2020-05-12, 18:21:

Is this a crazy idea?

No, not at all I think. With a little bit of work, some of the emulators mentioned above could be integrated into a DOS/4GW type of software.
That being said, I have little experience at writing emulators or intercepting I/O calls.
Maybe some other limiting factors exist, like DMA.

These concern using the host soundcard in DOS but could be useful:
http://www.bttr-software.de/forum/forum_entry.php?id=16121
https://bitbucket.org/neozeed/q2dos/src/maste … /libau.src/src/
https://sound-dos.ucoz.ru/load/source_code_sound_lib/1-1-0-7
https://sourceforge.net/p/mpxplay/discussion/ … hread/fa5ec648/
https://sound-dos.ucoz.ru/load/new_hxdos_exte … er_2_17/1-1-0-8
https://www.bttr-software.de/forum/forum_entry.php?id=15450
https://github.com/Baron-von-Riedesel

BinaryDemon wrote on 2020-05-12, 23:33:

So this is the closest I've heard: There's been a version of HX Extender with Win32 support and AC97 sound support in DOS. People have loaded it, then run modified versions of DosBox in DOS. Unfortunately you still take the massive DosBox performance hit (because everything is being emulated) but still an interesting idea.

https://www.japheth.de/HX.html

Indeed. Interesting approach, but it seems kind of absurd to emulate an entire computer in a DOS extender on a machine that could otherwise run the same code natively, all of that just to get sound working. The sound card is all you should have to emulate. (Not to dismiss the creativity and serious effort that went into a solution like that, by the way.)

Jo22 wrote on 2020-05-13, 06:56:

No, not at all I think. With a little bit of work, some of the emulators mentioned above could be integrated into a DOS/4GW type of software.
That being said, I have little experience at writing emulators or intercepting I/O calls.
Maybe some other limiting factors exist, like DMA.

Yeah, this is currently beyond my knowledge as well, I'm afraid. I've just started dabbling in retro DOS software development in C and assembly, but it's just baby steps for me for now.

I took a look at the source code of DOS/32A, and it was overwhelming. All assembly, and not a lot of comments in the code. Plus no one appears to have worked on it in quite some time. But still, it's there and it's open source.

As for DMA programming, I tried some very rudimentary Sound Blaster DAC programming in real mode assembly a while back, and although it was quite a bit of work for me just to perform a single-cycle DMA transfer, it does seem that at the end of the day, it's basically a matter of putting the audio data at a certain place in memory and then programming the I/O ports of both the Intel 8237 DMA controller and the Sound Blaster itself.

So all the DOS extender should be able to do is trap and handle the relevant I/O port access instructions performed by the game being hosted by it. So I guess that would require the DOS extender to run in a more privileged mode than the game itself? Isn't that what's already required for the DOS extender to be able to trap and redirect software interrupts (10h, 21h) and such? After a brief glance through the DOS/32A documentation, it seems like the DOS extender already is capable of trapping both hardware and software interrupts. So it must already be running at a higher privilege (ring?) than the game its hosting, and therefore it should also be able to trap and redirect access attempts to I/O ports, right? (Can anybody more knowlegeable please chime in here? 😇)

DosFreak wrote on 2020-05-13, 20:24:

These concern using the host soundcard in DOS but could be useful: http://www.bttr-software.de/forum/forum_entry.php?id=16121 ht […]
Show full quote

These concern using the host soundcard in DOS but could be useful:
http://www.bttr-software.de/forum/forum_entry.php?id=16121
https://bitbucket.org/neozeed/q2dos/src/maste … /libau.src/src/
https://sound-dos.ucoz.ru/load/source_code_sound_lib/1-1-0-7
https://sourceforge.net/p/mpxplay/discussion/ … hread/fa5ec648/
https://sound-dos.ucoz.ru/load/new_hxdos_exte … er_2_17/1-1-0-8
https://www.bttr-software.de/forum/forum_entry.php?id=15450
https://github.com/Baron-von-Riedesel

Oooh, there is indeed some useful stuff there. I've been looking for easy (or at least easier) to use libraries to program modern sound hardware in DOS, even separate from this topic. Thanks for sharing. 🙂

digger wrote on 2020-05-12, 18:21:

So the problem with most purely software-based Sound Blaster emulation solutions is that they only work with real-mode games, since it requires trapping I/O port access.

Which ones are you thinking of, specifically?

By the way, what is the license of the Mpxplay source code, anyway? According to Wikipedia, it's GPL. According to the author, it's "opensource", without elaborating. According to the Mpxplay project page on Sourceforge, it's "other". And the ZIP file containing the source code doesn't contain any LICENSE or COPYING files, and I can't find any info about licensing (or GPL or anything like that) in the README or any of the other documentation files bundled with the sources.

I'd love to use this code in my projects, but I'm hesitant to do so without being certain about the license terms.

Jorpho wrote on 2020-05-13, 21:43:

digger wrote on 2020-05-12, 18:21:

So the problem with most purely software-based Sound Blaster emulation solutions is that they only work with real-mode games, since it requires trapping I/O port access.

Which ones are you thinking of, specifically?

Basically the same ones that Jo22 mentioned earlier:

Jo22 wrote on 2020-05-13, 06:56:

Something like this already exists, albeit for Real-Mode titles only (but links into EMM386 which uses V86, similat ro DOS/4GW). […]
Show full quote

Something like this already exists, albeit for Real-Mode titles only (but links into EMM386 which uses V86, similat ro DOS/4GW)..
- TEMU
- Virtual SoundBlaster
- Covoxer

I mean, other than purely software-based emulation, the only other way I know is hardware-assisted emulation, such as how the Gravis Ultrasound cards worked with the SBOS TSR. The GUS basically monitored the relevant I/O ports for Sound Blaster emulation in hardware, and left the actual emulation of the DSP to SBOS to do in software. (Again, if I'm incorrect, feel free to correct me.)

This way, protected mode games would work as well, since it wouldn't require games to run in V8086 mode in order to be able to handle the I/O port trapping.

Another example of hardware-assisted emulation I believe would be the VIAFMTSR utility that enabled Adlib/OPL3 FM emulation on certain VIA southbridges that already had an ability in hardware to emulate Sound Blaster Pro cards.

The problem with hardware-assisted Sound Blaster emulation is that any hardware-assisting involving ISA DMA would have to be done on an actual ISA card. Although Tiido has been looking into some sort of ISA DMA handling through use of the LPC bus on some motherboards, but that remains a work in progress. Also, the LPC bus is expected to be dropped in new motherboard chipsets soon as well (and may already be gone in the latest motherboards, I'm not sure?).

I'm also aware of certain emulators that leveraged certain ISA DMA emulation features through PCI (DSDMA and such, that stuff was called???), but I believe this required the right combination of PCI sound card chipset and motherboard chipset for that to work properly, and it ceased to work in newer motherboard chipsets.

And then there is the possibility of having a hardware-assisted hypervisor on modern CPUs emulating ISA sound cards for a host VM running DOS "natively" (as in: without emulating an entire CPU). But ideally, we would want such a hypervisor to pass through the VGA card for direct access, to have an as "native" feeling experience as possible (and the performance to match). I'm currently not aware of any hypervisors that can pass through a VGA card to a DOS host, while offering high quality Sound Blaster emulation at the same time. The Sound Blaster emulation in both VirtualBox and KVM/QEMU is not the best. I've read it was recently improved in VMWare, but I like my hypervisors open source, thank you very much.

Are there any emulation strategies I may have omitted?

DDMA requires chipset support. DSDMA does not and works on pretty new chipsets... it really should work on any system that still has a PCI slot.

digger, if you really do make something like this, and you don't call it "VDMSound for DOS", it would be a crying shame 😁
(it's unlikely it could help, but the "VDMSound for Win9x" port should have source available...)

You do not need to worry about hardware DMA such as (PC/PCI or DDMA), they are protocols for hardware to emulate 8237-like DMA on PCI. For software based implementation, you would simply emulate and implement states tracker for 8237 by trapping all its ports and figuring out the right moment to construct DMAs on AC97/HD Audio to playback a sample. AC97 and HD Audio DMA engines are quite complicated with linked lists and rings, and I hope you find a good library to reuse, such as the one from MpxPlay. If you have the library to deal with samples playback on AC97/HD Audio, then I think SoundBlaster PCM playback should not be very difficult in theory, since it is just the same PCM data from one source to another. The FM music OPL2/3 is more complicated because that requires a PCM samples generator from the OPL commands, but there are matured libraries available for that purposes, such as the one from MAME.

digger wrote:

... we would want such a hypervisor to pass through the VGA card for direct access ...

Modern CPUs can now completely realize VGA in software faster than any true hardware VGA on ISA/PCI. VGA != GPU and it is literally not accelerated, hence there is no value in pass-through for direct access. Hypervisors only implement pass-through for hardware candidates that can offload the CPUs, such as GPUs, compute ASICs/FPGAs and high-performance network/storage controllers.

If any hardware companies had wished to keep SoundBlaster compatibility, it was a trivial in designs to add minimum logic for port trappings and DMA translation. If you consider Moore's Law, then it is essentially "free". Unfortunately, SoundBlaster compatibility was synonymous with DOS, everyone wanted them dead to prevent them from unnecessarily holding back platform evolution and the lure of market into upgrades/refresh cycles for growth.

digger wrote on 2020-05-13, 22:07:

Are there any emulation strategies I may have omitted?

There is also software-based virtualization.
It tries to shift Ring-0 code to a lower privilege level to intercept hardware access and uses a combination of dynamic code scanning/patching, interpretation and memory write-protection traps to deal with edge cases.
This is how VMware used to do it before hardware-assisted x86 virtualization was a thing.
It is also ridiculously complicated.