I have a little more information to share regarding Mega-Em. The good news is that it should be possible to get it running on most configurations, even with the common Microsoft HIMEM.SYS version 3.x, though it's not necessarily ideal. Although still somewhat finicky, Mega-Em is not nearly as picky about the EMM386 configuration as it may at first appear. In my testing, the key seemed to be reducing the amount of extended memory visible as XMS via HIMEM.SYS. By default, under MS-DOS 6.x, this is about 64 MiB. Under these conditions, no combination of arguments to EMM386 seems to work.
There may be other ways of consuming extended memory before HIMEM.SYS loads, so that there is less available, but I didn't test that approach. The method that worked turned out to be relatively simple, and doesn't require finding old versions of HIMEM.SYS or other memory managers: set the BIOS setting usually labelled something like "OS Select for DRAM > 64MB" to OS2. This has the effect of "lying" to DOS, and getting HIMEM.SYS to report a total of about 16 MiB of XMS. With this, many common configurations of EMM386 will end up working with Mega-Em.
With Mega-Em finally loaded, it was time to try testing it. I have to admit that results seemed to vary. Even with the official AMD/Eye & I ROM, MIDI playback using General MIDI emulation seemed to be generally inferior to the results obtained via the included PLAY.EXE or under Windows 3.1. Whether this is normal behaviour isn't yet clear. FM emulation via Mega-Em is actually significantly worse than the results obtained using IWSBOS, and this just using some of the oldest FM-enabled software on the PC: the Ad Lib JukeBox.
Quite a number of pages ago, the question was asked whether we could use a custom ROM with Mega-Em, in particular to provide UltraMID functionality. So far, I can only give a tentative maybe (it's better than "no", isn't it? 🤣 ). I have only been able to get semi-sane playback with Mega-Em so far. To begin with, Mega-Em does not appear to require or make use of the SBOS chunk in ROM. When loading, it appears to scan the ROM and pick out the necessary instrument information. Playback sounds somewhat normal, but with a hint of the sort of sound you can still experience in shock__'s earliest recordings with the test ROMs of the time. My current working theory is that when it scans the ROM, it uses the addresses and other instrument parameters, but ignores the referenced DATA chunks that tell it which ROM bank actually contains the data. So, instruments that are actually in the first bank play mostly normally; those in other banks give that familiar sound. This seems to suggest that having a single-bank 4 MiB ROM would give the result being sought.
Actually testing that theory will take a while. I don't know of any 4 MiB, 5V flash ICs in either a SOP-44 or TSOP-48 package, which is what would be required to test that now. If anyone knows of such a part, please enlighten me; bonus points if it's reasonably priced. Failing that, we will likely have to wait for the single-board ROM daughterboard prototype on ARGUS, which I planned to start designing right after someone successfully tests the current carrier-board-plus-ROM-module design. So far, nobody has all of the pieces of that puzzle.
EDIT: I stand corrected; I should be able to stuff an 8-bit version of GSFULL4M, possibly even with SBOS chunk, into a single 2 MiB bank for testing. I will try that over the next few days.
EDIT 2: I already generated the ROM image, but the SBOS chunk wouldn't fit. I will program the module, test and report back when I can.