VOGONS


SourceForge.net project ("Munt")

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by KingGuppy

User metadata
Rank Member
Rank
Member

I started a SourceForget.net project for the MT-32 emulator some time ago, and finally got around to committing some code to it. The project is here:

http://sourceforge.net/projects/munt/

This is based on Canadacow's latest version, with quite extensive changes.

Reply 1 of 74, by Alkarion

User metadata
Rank Member
Rank
Member

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?

Reply 2 of 74, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

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? 😀

Reply 3 of 74, by KingGuppy

User metadata
Rank Member
Rank
Member

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 😀

Reply 4 of 74, by Srecko

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    midi_mt32.h
    File size
    2.8 KiB
    Downloads
    1091 downloads
    File comment
    Add #include "midi_mt32.h" in midi.cpp below HAVE_ALSA #endif.
    File license
    Fair use/fair dealing exception

Reply 6 of 74, by Snover

User metadata
Rank l33t++
Rank
l33t++

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.

Yes, it’s my fault.

Reply 9 of 74, by KingGuppy

User metadata
Rank Member
Rank
Member

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.

Reply 10 of 74, by Srecko

User metadata
Rank Member
Rank
Member

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?

Reply 11 of 74, by Alkarion

User metadata
Rank Member
Rank
Member

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.

Reply 15 of 74, by Alkarion

User metadata
Rank Member
Rank
Member

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.

Reply 16 of 74, by Snover

User metadata
Rank l33t++
Rank
l33t++

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.

Attachments

  • Filename
    SQ3_1.ogg
    File size
    808.13 KiB
    Downloads
    815 downloads
    File comment
    Space Quest 3 opening using Munt 0.1.1β. Apologies for the clicking/studdering, clearly my CPU is inadequate. :)
    File license
    Fair use/fair dealing exception

Yes, it’s my fault.

Reply 18 of 74, by Srecko

User metadata
Rank Member
Rank
Member

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.

Reply 19 of 74, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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!