On Mon, 16 Sep 2019 17:18:18 -0600 st...@vwebr.net wrote: > This is kind of a sore point when using Windows-based virtualization > apps. > > Virtualbox (and I believe VMWare) support SoundBlaster 16, but only to a > certain extent (as in later versions of Windows). > > They don't support DOS sound, period. > > One of the things I noticed with DOS games is that I/O ports are not > supported (e.g. A220 and P330) by Virtualbox or VMWare's implementation. > > > Because I remembered that BIOS extensions are something that were used > many years ago to adapt machines BIOS that (for instance) didn't support > larger sized HDDs, I'm wondering if the same sort of thing can be done > to implement a much more accurate version of a SoundBlaster ISA card > which > allows DOS games to fully recognize an improved virtualized ISA sound > card and make use of it. > > I know that DOSBox is able to achieve sound for DOS games, so it seems > like something not too difficult unless the virtual app would block it > from working.
Well, the thing is, DOSBox isn't just a DOS implementation, like FreeDOS is. It's a DOS implementation plus a layer similar to VMWare or VirtualBox that emulates the hardware. It also has a narrower focus for the kinds of applications it tries to run well: It's focused on games, which made significant use of sound hardware. Since DOSBox is not just a DOS implementation, but also a hardware emulator, it knows that it's running on top of another OS, so it can just use the OS's sound API as a back end and let the OS and drivers take care of turning that into actual sound coming out of the speakers. FreeDOS either isn't running on top of another OS (on bare metal) or doesn't know that it is (under emulation or virtualization), so it, or a driver that it loads, has to talk directly to the hardware. For FreeDOS to emulate SoundBlaster sound, it would have to trap all accesses to the soundblaster hardware (probably easy enough for an EMM to do, if you have a 386 or better), and then it would have to translate the attempted soundblaster accesses into some standardized representation of the sound to be produced, and hand that off to a driver written for the sound hardware actually installed on the machine. Windows and Linux have huge collections of drivers already in existence, and MacOS runs on only one manufacturer's hardware, but FreeDOS would have to start from scratch. > I figured the easiest path would be something like what DOSBox uses, > except implemented in FreeDOS but a BIOS 'extension' is another avenue. > > I guess a BIOS extension would depend on having access to the code for > SeaBIOS or whatever Oracle or VMWare uses to virtualize hardware. A BIOS extension wouldn't help, because BIOS had no sound API. The PC architecture had no standardized on-motherboard sound beyond the PC speaker in the DOS era: everything was through expansion cards, and DOS didn't have a standardized sound API either. The closest thing to a standardized sound API was the fact that SoundBlaster had a fairly dominant market share, so if your software could talk to a SoundBlaster card, it would work on a good chunk of PCs. But it's the fact that applications had to talk to the hardware directly, without using the BIOS or DOS, that makes audio back-compatibility with DOS so difficult. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
