Reply 1060 of 1293, by digger
- Rank
- Oldbie
jmarsh wrote on 2024-07-26, 04:00:Games that relied on ultramid were definitely the majority - however most of them had a static library version built into their sound drivers. Some of them would still show telltale signs of loading patches into memory on startup. It was a lot simpler than writing GUS output from scratch; you didn't have to know a thing about the hardware since ultramid provides API functions (via a software interrupt) for both music playback (by passing MIDI messages) and digital audio.
Interesting! I remember having to load UltraMID for many (real mode) games to work with my GUS back in the day, but I always thought that UltraMID was used only for music playback, as implied by the "MID" part in the name. I had no idea that UltraMID also provided an API for digital sample playback. But indeed, the documentation of the UltraMID INT 78h API in RBIL confirms this. Thanks, I learned something new today. 🙂
Would you (or others) happen to know if any games that supported the Gravis Ultrasound via UltraMID did so only for music playback, while accessing the GUS hardware directly or through another driver? I'm wondering this because the UltraMID API appears to provide a nice hardware abstraction layer that would allow for easier emulation, even on newer sound hardware without Intel 8257 (ISA) DMA support.
Of course, as you stated, some of those games would come wirh a statically compiled version of UltraMID, but it makes sense that such a built-in version would check for a pre-loaded (newer) version of UltraMID already being resident, right? Like later games that came with embedded versions of UNIVBE for VBE 2.0 support?
So it would appear that there are (at least) three real mode sound hardware abstraction APIs with varying levels of support in DOS games:
- INT 66h (DIGPAK/MIDPAK)
- INT 10h (VBE/AI)
- INT 78h (UltraMID)
Or did I misunderstand this?