Today I finally solved a nagging problem that always seemed like it had to have some sort of reasonable solution. Creative’s DIAGNOSE.EXE utility is quite useful when working with any Sound Blaster 16 derivatives (Sound Blaster 16, AWE32, Sound Blaster 32, AWE64). But there’s an annoying oddity related to the fact that many SB16-based cards have an MPUEN jumper which can disable the MPU-401 interface, typically accessible at port 330h. This jumper is very useful when a SB16 is combined with something like a Roland SCC-1 or a Turtle Beach Maui.
When the MPUEN jumper is set to disable the Sound Blaster’s MPU-401 interface, DIAGNOSE stops working:
This seems very unsatisfactory; the MPUEN jumper is well documented, so why would DIAGNOSE refuse working when the default setting is changed? After all, a user might not care for MPU-401 compatibility at all, or might have a system where ports 300h and 330h are already occupied by other hardware (SCSI HBAs, network cards) and needed to force the SB16’s MPU-401 to be disabled. Well, there is a solution…
And it’s very simple. All it takes is to run
and DIAGNOSE.EXE will skip MPU-401 detection entirely and continue on to the next test:
The /DMPU switch appears to be undocumented and I could not find it mentioned anywhere. Yet it seems so obvious—the string ‘/dmpu’ appears in DIAGNOSE.EXE in plain text—that someone surely must have figured this out years ago? I’m not the first person to run into this problem, either.
The /DMPU switch was verified to exist at least in DIAGNOSE.EXE versions 4.01, 4.02, 4.04, and 4.06.
A remaining minor mystery is the fact that DIAGNOSE.EXE should under some conditions show a different MPU-401 test menu with added “Disable” option (it’s in the executable). This might possibly only apply to PnP Sound Blasters.