This is great news. Btw, in the scummvm changelog it says that the data previously stored in drumpat.rom, Preset1.syx, Preset2.syx and patchlog.cfg is now stored in MT32_Control.rom. Is there any way for me to get hold of this file?

Put simply, this is just freaking awesome.

Please someone spank me if I'm wrong, but I believe this ROM handles the operation of the module via the front LCD panel. Thing is, I've got a Japanese CM-500. There's no front, no rear, no side panel whatsoever. Just checked under it to be sure, no panel there either. Does it mean my module doesn't have any mt32_control.rom at all? 😀

The microcontroller ROM controls the frontpanel (setting the LCD display and handling button presses) and the LA synth chip, and deals with MIDI events. It's pretty much in charge of the whole show; your CM-500 will certainly have one, though it's likely very different.

The code in the ROM is not actually interpreted by the emulator, I just mapped out the interesting data and read that in. Different firmware revisions to the one I used may well have the data in different places, and therefore won't work correctly with the emulator.

P.S. Donations of spare CM-500s gratefully accepted 😀

I wrote interface to dosbox based on canadacow's midi_mt32.h and mt32.cpp from scummvm.
However, I'm unable to test it and get emulator working without MT32_CONTROL.ROM
Please provide it somehow.

Sorry, I can't do that. The legality of distributing that file is just the same as with MT32_PCM.ROM (i.e. dubious).

KingGuppy: How dangerously outdated is the Win32drv source you're working with compared to the ScummVM/DOSBox-custom source? I've always felt that the Win32drv was the most important of the three, since it will then allow ANY program, not just ScummVM/DOSBox, to passthrough to a virtual MT-32.

The Windows driver just links with the mt32emu static link library. That library is completely up-to-date with the ScummVM version. So it should be the very latest (and theoretically best) code available anywhere.

Hey, awesome.
Now if only I could steal binaries from someone...
or, will this compile with MinGW? I suppose I should try. Man, it's been too long since I've done stuff with CVS, I've forgotten it all... checkout checkout...

Releasing binaries (and source tarballs) is a high priority for me, but I want to do some further testing first. The first person to test the new Windows driver (Canadacow, actually) was rendered half deaf, so I think people will appreciate me ironing out the remaining buglets before release 😀

I'm fairly sure it won't be possible to compile mt32emu_win32drv with MinGW without extensive modification. The mt32emu link lib compiles fine in that environment (and pretty much any other you care to throw at it), but isn't very useful to you by itself.

I thought that control ROM is just one-file package of drumpat.rom, patchlog.cfg and .syx files. Looking carefully at previous posts, I notice that it's a completely new ROM file.
Which are advantages from using this new copyrighted ROM instead of freely available files?

Ok, here's how to create MT32_Control.ROM:

1. Download the following file http://www.oldcrows.net/~patchell/mt32/mt32.zip. Extract it.
2. Download WinHex http://www.winhex.com/winhex-e.zip
3. Open WinHex and choose File Manager-> Unify -> Bytewise
Click ok and then choose the MT32A.BIN as first file and MT32B.BIN as second file. Write the output to MT32_Control.ROM.

That's it.

Srecko, the advantage is more accurate emulation. I'm using data from the ROM such as the PCM tuning which was previously based on not-really-accurate analysis.

I don't see that requiring two such ROMs is significantly worse than requiring one.

A binary release of the new Windows driver is now available:
http://sourceforge.net/project/showfiles.php?group_id=123616

Bug reports should preferably go in the munt project's bug tracker. Thanks for testing 😀

"Monkey Island 2" sounds ok, but "Dune 2" has actually random noices not music. Canadacow's dosboxmt32 sounds nice in "Dune 2".

Overall the emulator has made a giant leap forward. Comparing Wing Commander and Ultima Underworld to canadacow's last version shows this most clearly. Nevertheless there seem to be problems with custom patches being played under Dosbox. Perhaps this has something to do with the way Dosbox "talks" to the MPU-401. Westwood games also seem to have problems during MT-32 initialization. Interestingly, Monkey Island sounds differently when executed under ScummVM or Dosbox.

Munt 0.1.1 should be released soon, addressing issues with waveform generation (filename corruption) and improper application of custom timbres. There are still problems with volume overdrive, reverb delay/decay, and possibly some tuning issues. These should be corrected once KingGuppy has an actual MT-32 unit to more closely compare signals.

I just uploaded version 0.1.1 Win32 driver binaries and cross-platform library source. Many thanks to Snover for his very useful testing.

0.1.1 sounds much better than 0.1.

noticed problems (dosbox):
Trumpet volume low in "SQ3".
"Raiden" doesn't play some instruments (this was also problem in canadacow's version)
Tuning in "Laser Squad", "Time quest" , "Wing commander 2" intro bit off
"Gateway" - some bass instrument notes are not played (last worked in canadacow's february version?)
Spellcasting 201 - strange pitch slides (I don't know how it should sound though)
Sometimes crackling because volume goes out of range (it's cut off).

And thanks to Alkarion for link.

Wow - been a while since I checked up on MT-32 emulation. Looks like some interesting developments 😀

I just got Munt working and started testing it out with games in DOSBox. I then tested Indiana Jones and the Fate of Atlantis and was pleased to hear nice-sounding music in Roland mode. I also noticed that you can hear the crashing sound when Indy first appears by smashing through a window in the opening credits.

I then got the latest ScummVM win32 binary CVS snapshot (ScummVM 0.7.0CVS Dec 4 2004 23:40:02) and tried Fate of Atlantis with it. I noticed that regardless of whether I use the win32 MIDI driver version or the ScummVM integrated version of Munt, I can't hear that crashing sound I mentioned!

I would guess that this might be some sort of ScummVM issue? I remember that last time a played with ScummVM (months ago) the message console used to complain that it didn't know how to emulate/translate the crashing sound and wouldn't play it. I wonder if someone left that broken and just turned the warning off, and now it's getting in the way of Munt?

Also, KingGuppy: How do you synchronize the code between the win32 driver and ScummVM integrated flavors of your emulator? Do you use a common codebase, or do you have to back-port your changes from one to the other? Just curious 😀

Oh, and thanks!