Seems like a waste of time, better off spending that time developing DOSBox. 😀

If you insist though you'd have better luck talking with the developers who maintain DOS media players that work with current soundcards. (IIRC they support AC97)

No one here is interested in developing sound drivers for modern hardware. You might find a few crazy people interested in playing DOS games on modern hardware but no developers.

Some DOS games also have audio issues with the speed of modern computers so that wouldn't be very fun to troubleshoot.

I understand that this effort would indeed make no sense for the older simpler DOS games that run fine under DOSBox and actually would have timing issues when being run directly on newer hardware.

My emphasis is on the later DOS games that supported SVGA and required DOS extenders. Those "heavier" DOS games (from around '93-'96, the period leading up to the game industry's eventual migration from DOS towards DirectX) would still benefit from running on modern bare metal. And those also happen to be the games that are most likely to be based on one of those standardized audio driver frameworks.

For example: back in those days, I used to try playing Fatal Racing in 640x480 mode at an abysmal framerate, wondering when computers would finally be fast enough to play games at those resolutions with silky smooth framerates, and how awesome that would look.

Of course that's right before the 3dfx revolution happened, and apparently a 3dfx patch was also later released for Fatal Racing as well, but that's beside my point. 😀

Summarized: I'm curious to see how the heavier 32-bit DPMI/SVGA games would perform bare-metal on modern-day hardware, with sound and all. And particularly the latter point (sound support) is becoming more and more problematic as newer generation chipsets motherboards are released.

I just had this idea and it seemed cool enough to me to throw it out there, knowing that the reactions of people here would generally be either "meh", or "hey, that's cool, let's try it!".

In the case of the former: no biggie, and no offense taken. 😀

I think that it's an awesome idea, and I would try programming it, but the problem is, I don't know how to program! 🤣

Thats ok it only takes 3 weeks to learn c++

Perhaps Davros, but it takes a lot longer than that to become a good C++ programmer I'm afraid... 😉

Anyway, John Miles (the guy behind Miles Design) has released the AIL (version 2) SDK as open source on this site:

http://www.thegleam.com/ke5fx/

I guess it would be a good idea to try to create AIL2 drivers first, before figuring out a way to reverse-engineer the AIL3 API. I guess I could also just directly email him and ask him if there are also any plans to release at least the DOS version of AIL3, or alternatively, if it would be possible to implement AIL3-compatible drivers without the official SDK, using publicly accessible documentation.

I'll let you know if I get back a reply. 😀

For a driver to work you'll probably need to have some 'channel painting stream' to serve for where the emulated FM music goes through as well. Attempting full duplex emulation in DOS for that would be tough channelge

Since most music devices back in the DOS era didn't require DMA, they can still be supported well on normal hardware today, for instance through Yamaha PCI cards. It's mostly the DAC support that is so problematic these days, since in most games only DMA-enabled DACs (and therefore mostly only sound cards with ISA interfaces) were supported.

That's why I'd prefer to focus specifically on either LPT DAC (Covox/Disney Sound Source) drivers or unified AC97 DAC drivers first, since those would eliminate the necessity for ISA/DMA sound card emulation in many (later) DOS games.

An alternative project that would also be interesting (and perhaps more flexible) would be a motherboard/chipset-independent real-mode Sound Blaster emulator for either LPT DACs or AC97 audio devices (or both).

From what I gathered, the reason why Creative's Ensoniq-based DOS-mode SB emulator doesn't work on many newer motherboards is because the DMA emulation has to be implemented differently depending on chipset, and Creative's emulator hasn't been updated since 1997. A community-developed open-source replacement emulator that would work in real-mode and would be both chipset- and device-neutral (as well as continually maintained) could therefore prove quite useful.

By the way: does anybody know why no ISA sound cards ever used memory-mapped I/O for digital audio playback instead of DMA? Is it because the required upper memory was too scarce in most systems back then?

DIGPAK & MIDPAK Developers Kit v1.50
http://www.programmersheaven.com/download/647 … ipFileList.aspx

AC97 sound driver for DOS
http://www.bttr-software.de/forum/board_entry … swer&category=5

DIGPAK is just (PCM) wav audio?

Edit: more links
DMKIT v1.0 - http://www.oldskool.org/guides/tvdog/sound.html

Yeah, I was just about to post that bttr-software link myself. You just beat me to it, aqrit. 😉 (But the link to the DIGPAK/MIDPAK SDK is very interesting! More on that further below.)

The driver announced in that topic's OP is somewhat disappointing (closed source and reinventing the wheel with a completely new API, making it useless for any existing applications or games). However, further down in that topic it becomes clear that much of that driver's code is based on an earlier project still hosted here:

http://www.programmersheaven.com/download/232 … 7/download.aspx

This is code is open source, and apparently the author has been working on updates for later AC97 implementations.

Also, the open source Mpxplay project is mentioned in that same thread, which also contains integrated native DOS Drivers for both AC97 devices and even Sound Blaster Live! cards:

http://mpxplay.sourceforge.net/

Thanks for posting that link to the DIGPAK & MIDPAK Developers Kit, aqrit! What is currently the license for it? Does anybody know?

There is also some DIGPAK/MIDPAK API documentation to be found on these pages:

http://www.dpfiles.com/dpfileswiki/index.php? … nds_with_DIGPAK
http://hdebruijn.soo.dto.tudelft.nl/newpage/i … pt/out-7200.htm
http://www.gamedev.net/reference/articles/article261.asp

With the links gathered so far, we should in theory have enough documentation available to write rudimentary DIGPAK (and later perhaps also MIDPAK) drivers, as well as AIL2 drivers, at least for some AC97 implementations, LPT DACs, and possibly even some Sound Blaster PCI cards (borrowing code from Mpxplay in particular). 😀

If there's doubt over the whole licensing/reverse engineering thing, you could attempt to prototype a sound driver for an old Allegro 4.x branch which is statically compiled and no games I know of sold commercially with Allegro afaik.

It would indeed be a way to test driver code, but like you said no (commercial) games make use of Allegro (yet), and most action in the Allegro community seems to be focused on platforms other than DOS.

What's interesting is that someone in the Allegro forums had already mentioned the idea of building an Allegro driver on top of Mpxplay, since that project currently already supports some PCI sound cards and AC'97 devices in DOS:

http://www.allegro.cc/forums/thread/597192/761750

Going back to DIGPAK/MIDPAK: it appears that those APIs consist of INT 66h calls, not unlike VESA INT 10h calls for SVGA graphics. As a matter of fact, MIDPAK/DIGPAK was already adding preliminary support for some sort of VESA audio API that was being developed, but apparently never took off.

The MIDPAK and DIGPAK drivers are TSRs that add the proper interrupt routines to the DOS environment.

As an aside, I wonder if it would also be possible and practical to have DOSBox and DOSEMU implement those INT 66h routines in the environment on startup, just like the INT 10h VESA routines (optionally of course), providing a more direct sound interface to applications that are built on DIGPAK/MIDPAK, bypassing Sound Blaster emulation in such cases...