The Sound Blaster Live! (and perhaps Audigy) series should be able to do this using VxD drivers.

The AWE64 can do that, especially with the memory upgrade. But this works best from withing Windows 98, not that well in pure DOS.

there is a font loader for linux, so there should be one for dos as well.

Apples and oranges, unfortunately. Creative had to go through some hoops to get MIDI playback out of the EMU chip working in DOS (titles expect real hardware and they were stuck with a clunky TSR to make it happen) whereas in Linux the devs had an API for programs to use and a lot more freedom to manage the hardware in the background.

The upshot is, it would be incredibly difficult to port work back to a DOS driver.

are You saying no one ever did this? that's weird in a world of free compilers and stuff

Well, there's MPXPlay, but that is only useful as a media player and not for games.

I must say, it would be nice to be able to load version 2 soundfonts under DOS and have your DOS game (either real or protected mode) access that soundfont as opposed to accessing the onboard 1 MB ROM.

I still think someone needs to make a super SB16 with true OPL3, an EMU8k, flash memory, and a bug free DSP/bus chip that has enough power to provide MPU401 functionality without requiring a TSR. Oh, SPDIF out and 95dB SNR would be nice as well.

I can dream, right?

Its strange that no company made it omitting problems. The other chip with sounbank import support is CS4624/30 chip which lets load soundbanks under windows and use them in dosbox. Still its DLS and not SF2.

whered you get a real opl3 now from? i can only think of emulation on the board?
emu8k is that extended version of sb with ASP, yes? games dont use this i thought?
flash? why is that better than simple ram which does not wear? also i could imagine an advanced midi engine would eat a lot of throughput?
there is one sb clone which only required the blaster line in dos - maybe use that?
spdif and snr? yes, you know how to dream :>

jesolo wrote:

I must say, it would be nice to be able to load version 2 soundfonts under DOS and have your DOS game (either real or protected mode) access that soundfont as opposed to accessing the onboard 1 MB ROM.

It is nearly, if not at all, impossible due to the weird mechanism of loading soundfonts to EMU8K. I tried to construct a protected DOS mode resident executable to fulfill the task and failed miserably. I am a diletant though, perhaps if someone more skilful at protected mode programming would tackle this, it would work somehow.

mrau wrote:

whered you get a real opl3 now from? i can only think of emulation on the board? emu8k is that extended version of sb with ASP, […]
Show full quote

whered you get a real opl3 now from? i can only think of emulation on the board?
emu8k is that extended version of sb with ASP, yes? games dont use this i thought?
flash? why is that better than simple ram which does not wear? also i could imagine an advanced midi engine would eat a lot of throughput?
there is one sb clone which only required the blaster line in dos - maybe use that?
spdif and snr? yes, you know how to dream :>

Flash chips avoid the need to upload soundfonts after every reboot. As for DSP requirements, it probably wouldn't require much as the EMU chip handles most of the playback itself. The most important part would be providing the hardware interface connecting DOS to the EMU chip which is relatively light, but best implemented on the card itself rather than with a driver.

bristlehog wrote:

jesolo wrote:

I must say, it would be nice to be able to load version 2 soundfonts under DOS and have your DOS game (either real or protected mode) access that soundfont as opposed to accessing the onboard 1 MB ROM.

It is nearly, if not at all, impossible due to the weird mechanism of loading soundfonts to EMU8K. I tried to construct a protected DOS mode resident executable to fulfill the task and failed miserably. I am a diletant though, perhaps if someone more skilful at protected mode programming would tackle this, it would work somehow.

im still not getting it, why protected? if it happens at boot, go real, or even unreal or whatever.

mrau wrote:

im still not getting it, why protected? if it happens at boot, go real, or even unreal or whatever.

The attached FAQ (Creative's own one that they shipped with the AWE32 & AWE64 cards) should perhaps answer some of your questions about the workings of the AWE chip.

I'm not a programmer at all, but generally speaking, the biggest issue relates to protected mode games where you are not able to load custom soundfonts under DOS, thereby "forcing" you to fall back onto the standard 1MB sample set that is stored in ROM on the card itself (the only way around this is to play your protected mode game under a command prompt from within Windows, which works in most cases).

My previous comment relates to the above - it would have been nice to be able to load a custom soundfont under DOS for protected mode games. But, in protected mode, the game has to support the AWE chip natively (directly in hardware) and Aweutil doesn't work in such a case (hence, you are not able to load any custom soundfonts).

With real mode games, it is a bit more customisable, but you are restricted to version 1 (*.sbk) soundfonts. Not many people bothered to release their soundfonts in the version 1 format, which also limits the number of "good" soundfonts out there.
The other downside is the issue about non maskable interrupts (NMI) and whether your motherboard supports it - otherwise, you cannot use Aweutil at all to load soundfonts (with the /EM:xx parameter).

Under Windows, however, this problem completely disappears and it becomes very customisable. Just a shame it is not the same under DOS (hardware limitations aside).

ok, so quite frankly this does not seem to be a programming problem, more like a hardware thingy as the root is not loading fonts, but actually using them -.-