Unisound, if I say wrong things correct me, in the case of Creative cards equipped with EMU chips, it is able to configure only the "soundblaster 16" part, i.e. digital audio and FM playback (which depending on the SoundBlaster/AWE 32 model, can be based either on OPL3 -> AdLib compatible or on Creative CQM); is unable to configure/initialize the EMU8000 chip. To configure/initialize the EMU8000 chip, in a DOS environment, you need Creative "aweutil." Under Windows 3.1 you will need to use the Creative drivers to utilize the MIDI synthesis capabilities of the EMU8000 chip.

igna78 is right. Furthermore, you should understand that MIDI playback using the EMU8000 chip is not just an initialization issue which could be handled by UNISOUND. The EMU8000 chip is a wavetable synthesis chip, which is able to mix up to 32 samples played back at individually different speeds, volumes, and stereo panning position. It also is able to apply basic effects like vibrato (periodically varying frequency) and tremolo (periodically varying frequency) per voice and chorus and reverb globally to the music. But the EMU8000 is not able to understand MIDI data. It has be told explicitly where the sample to be played is located in RAM or ROM, at what rate it is to be played, which effects should be applied at what strength using a basic low-level register-based programming model. Something has to interpret MIDI data and generate the corresponding EMU8000 programming instructions from it. This "something" is not included in the AWE32 hardware, but needs to be implemented in software.

There are three approaches commonly used on AWE32 cards:

1. The (modern) game you are using has an AWE32 music driver. In that case, this driver does the MIDI interpretation and directly programs the EMU8000 chip.
2. The (legacy) game accesses MPU401 ports. The AWE32 has been configured to generate a non-maskable interrupt as soon as this happens, which will trigger a MIDI interpreter that programs the EMU8000 chip. Creative Labs provided a MIDI interpreter with the AWE32 cards: It is a part of AWEUTIL, if you run it as TSR. Traditionally this mode is only compatible with real-mode software, but DOS32AWE (see a thread here on VOGONs) can plug the NMI-based MIDI emulation into protected-mode software.
3. The MIDI software is excuted in a virtualized environment (like the Windows 95 Dos Box). The operating system traps access to the MPU ports without hardware assistance and forwards the data to the MIDI driver currently installed in the operating system.

As long as you don't want to run a DOS game that supports the MPU-401 in a DOS box (may be full screen) of Windows, your only option is the second option: Load AWEUTIL to add the MIDI driver / MPU401 emulator software that can convert the MIDI output from the game into EMU8000 programming instructions.

Even with Unisound loaded, I think you still need to install the Creative AWE drivers in Windows to get audio there; I know that I had to do that for my AWE64. Unisound does allow my AWE64 to use its EMU synthesizer to play back music in games that support the card natively in DOS, but it can't load General MIDI emulation for DOS software since it's not a TSR and the developer doesn't intend it to be.

To find the Windows drivers, you may find what you need on the AWE 32 Install CD. If that doesn't have what you need, there are other similar driver packages available at the VOGONS Creative Labs driver library.

[SOLVED]

Thank you all for replying so quickly. These answers really helped me move this ahead. I actually got the synth engine working after including the AWE drivers + AWEUTIL.

I did read the Unisound document before installation. I guess I just overlooked the fact that it serves a different purpose and doesn't interact with any synth engines or wavetables.

One thing I couldn't seem to avoid was having the Creative drivers be fully installed. Does that not negate the Unisound driver then? I can tell that Unisound is more efficient but I haven't worked out how to integrate the two together. I disabled it so I could run the Creative installer clean and avoid conflicts. Now that the AWE drivers are in place, I'm not certain how I'd re-include Unisound. I guess it's a question disabling AWE Sound and FM first, then rolling Unisound back in? Is that worth doing? (I prefer the elegance of Unisound TBH.)

Also - I do realize that the EMU needs a host player to work and receive instructions. Does Media Player not act as one, even if it's really basic and isn't sending more elaborate data?

Lastly, I pulled the MPU card and CDROM out so the AWE could work uninterrupted during setup. I'll have to roll those card back in and see what happens. Hopefully it won't break things. I'm new to this set up.

Thank you again.

Soft Automaton wrote on 2024-01-27, 18:25:

One thing I couldn't seem to avoid was having the Creative drivers be fully installed. Does that not negate the Unisound driver then?

I expect that you can still replace CTCM (including CTCU) and DIAGNOSE.EXE by UNISOUND. I'm unsure whether this has an advantage, but if you enjoy manual control of PnP cards, this is likely easier than manually configuring CTCM using CTCU. If I remember correctly, UNISOUND lets you set BLASTER first, and then configures a PnP card to the settings you provided. That's the old way of doing things, which is not necessarily bad, but doesn't match the PnP philosophy. On the other hand, CTCM tries to embrace the PnP philosophy to automatically assign appropriate resources to Plug-and-Play cards, and later when you call DIAGNOSE, the settings chosen by CTCM are copied to the BLASTER variable, so the BLASTER variable describes what the PnP tools did, and doesn't prescribe what the PnP tools are going to do.

The value in the new-fangled PnP approach is that a PnP manager software will (try to) automatically adapt to system changes. Let's say you add an Adaptec 1542B SCSI card (I picked that specific model on purpose, because it is kind-of PnP compatible), and you have it configured in SCSI Select to use IRQ 5 (for whatever reason). CTCM will detect the PnP SCSI adapter and find out that it has already been activated on IRQ5 and this card supports no other configurations. Due to that, CTCM will automatically reconfigure the sound card, likely to IRQ9 (aka IRQ2). Furthermore, the BLASTER variable will also automatically change to contain I2 or I9 (which is basically the same, due to the IBM AT architecture). With Unisound, you would have to resolve the conflict manually.

Soft Automaton wrote on 2024-01-27, 18:25:

I guess it's a question disabling AWE Sound and FM first, then rolling Unisound back in? Is that worth doing? (I prefer the elegance of Unisound TBH.)

No, you don't disable SB32 functions using Creative utilities and re-enable using Unisound, you just ditch the Creative configuration utilities from AUTOEXEC.BAT and re-add the invocation of UNISOUND. Keep in mind that CTCM and DIAGNOSE are card configuration/initialisation utilities that can be replaced by UNISOUND. On the other hand, AWEUTIL is a synthesizer setup tool and MIDI interpreter, which just requires a card with the resources already set up. As long as the PnP resources are configured and correctly represented in the BLASTER variable (including "E620"), AWEUTIL is going to work. It does not depend on the tool used to set up everything. In case you have a PnP compatible BIOS and "Plug and Play OS installed: No" in the BIOS setup, the BIOS is already supposed to do the job that CTCM is meant for, and the call to DIAGNOSE to fix up the blaster setting should actually suffice.

Soft Automaton wrote on 2024-01-27, 18:25:

Also - I do realize that the EMU needs a host player to work and receive instructions. Does Media Player not act as one, even if it's really basic and isn't sending more elaborate data?

I guess you are talking about the Windows 3.1 or Windows 95 Media Player. That tool reads a MIDI file, and figures out what MIDI commands need to be sent at what time. It does not know what the different MIDI commands do, and even if it did, Media Player does not know how to "play a middle C at average volume on a Grand Piano". It just forwards the instruction to the MIDI driver. In the case of an MPU-401 driver (included with Windows), the MIDI driver just forwards the data to the hardware, and has a processor on a synthesizer board deal with it. In case of the OPL2/OPL3 driver, the driver configures the OPL chip to generate a sound the sounds somehow similar to a Grand Piano, and then starts a note using that configuration at a frequency of 532Hz. In case of the AWE synthesizer driver, the Windows driver tells the EMU chip to play a sample at a certain location in the wavetable ROM or wavetable RAM. You don't need AWEUTIL if you have the windows driver installed and only want to play MIDI files from within windows. AWEUTIL (as TSR) basically does the same thing the windows driver does, but it doesn't require windows to be loaded, and it interfaces to DOS-based MIDI software using the virtualized MPU-401 interface, whereas the windows driver uses the MCI MIDI API.