Have you checked all of the files at Creative Labs?

http://us.creative.com/support/downloads/down … type=0&x=23&y=9

Ofcourse.
All official creative software for DOS related to AWE based cards don't have required abilities.

In that case, you might try the SF2LOAD program on this page:

http://www.hammersound.net/hs_software.html

SF2LOAD is a win32 command line program, I don't know if it can run with HX

I'm still amazed that nobody made a dos sf2 loader, they are a lot of information about sf2 format, EMU8000 programing and there is sfxload for linux, provided by awesfx package, which do the same thing.

AWE32 rom has an echo which make me think it was recorded in the toilet

This tool is WIN32 console program, not for pure DOS.

Irony of this situation that there is exist software called AWEPLAY. This one load banks in pure DOS ok but only during play MIDI files and remove banks from memory after playing 🙁

SF2LOAD works under dos with HX but report an error, it think some dll to handle AWE32 throught win32 call are required.

I was looking at that as well. The readme for that program says the source is available from the author. Open Watcom is freely available, and it supposedly includes an assembler, so perhaps you could get the author's permission to mold it to your own purposes.

There is a bank loader for Linux. Maybe they've ported the program to DOS.

In AWE32 sdk, there a demo of sf2 loader in dos\demo folder
It loads sf2 but only plays wav.
There is a bug in commandline parsing, you have to type /SBK:soundfont.sf2 instead of /SF2:soundfont.sf2

sf2 handling in the libraries is old, it only handles 2.0 version of sf2.

Past few days I worked on a DOS AWE32 soundfont loader myself. The program is quite finished and it runs, but I am afraid it won't ever be very useful because of the principal setup of the EMU8k chipset:

The problem, or feature: Any soundfont file consists of Patch data and Preset data. You can load the sound patches to the ISA card patch RAM, but not the preset data. That is also why the same old EMU8k supports newer SF2 formats, because the EMU8k never parses the preset data. It could never be hardware MPU-401 compatible, because the EMU8k is useless without dedicated+running software that holds preset data and controls the proprietary midi interface, such as: AweUtil TSR, Windows AWE32 Drivers, Dos-game AWE32 drivers, DOS Soundfont midi players. All this software needs about 42kB of presets loaded in normal RAM just to use the 1MB ROM samples, And about 200kB of presets for a 6MB soundfont. The annoying thing in real mode dos programs is that single data structures exceeding 64k are hardly workable, so instead you need DPMI memory extenders and such. And as soon as the mentioned DOS programs are exitted, the preset data is flushed, and any Patch data in Patch ROM/RAM is orphaned and useles!
This is why the AweUtil TSR is required for MPU support and why it is so large. It is the price to pay for the semi-soft-coded and flexible soundfont system.

So as I see it, EMU8k and DOS-games were a risky combination from the start, It can produce custom midi music and even digitized sound effects, but only if every game has its own native software support for this. As it went, DOS game developers only included the basic ROM-presets and the basic proprietary midi handling. This kinda makes me doubt the entire usefulness of EMU8k hardware in DOS... It does better in Windows and its dosbox, but currently Timidity++ can cover that part quite nicely.

ADIP301.PDF, from the AWE32 SDK: ...For example, in a TSR program, after you have initialized the SB AWE32 hardware and loaded your SoundFont bank file, you can mark portions of your code that must stay resident (the MIDI engine, the embedded General MIDI preset data and any SoundFont preset data)...

Yeah all that extra memory that is so hardly sought after by many individuals... is really a waste in DOS 😐