DOSBox…Now With MT-32 Emulation
The Wing Commander CIC is reporting that a custom build of DOSBox has been released, which incorporates the MUNT emulation patch to add true Roland MT-32 support to the DOS emulation environment.
Though it was intended as a prosumer-grade MIDI synthesizer, the MT-32 quickly became an effective standard for high-end sound in computer games, and several games were built which to this day offer the best possible sound experience to users with either an actual MT-32 setup or a decent emulator. Several Origin games — Wing Commander, Wing Commander Academy, Wing Commander 2, Savage Empire, Martian Dreams, Ultima Underworld, Ultima Underworld 2, Ultima 6, Ultima 7 and Serpent Isle — were released with support for the MT-32, and arguably sound their best when they are able to take advantage of that system.
Anyhow…some lion of technology who goes by the moniker Taewoong is responsible for the custom DOSBox build, and you can download it from his site. He has also uploaded a video of the first mission in Wing Commander to show off just what the custom build is capable of.
Sonic goodness.
For you Wing Commander and Ultima fans who want the best possible sound experience when playing your favourite games in DOSBox, this is now officially your best available option; be sure to check it out.
This had been available for years 😉
Well, I just heard about it. And evidently so did Chris at the CIC.
Not sure what to say about the ROMs…maybe they’re included? I know nothing about MUNT, so I can’t begin to speculate how this thing was ultimately put together.
And if I’m not mistaken you still need the ROMs which might or might not be copyrighted… See http://www.artworxinn.com/alex/history.htm
It has been around for years but it wasn’t in a usable state, as far as I’m concerned, until a couple of months back. It’s not always perfect but it’s often hard to distinguish from the real thing with the recent updates.
The ROM’s aren’t included. Roland tried very hard to shut MUNT down many years back and very nearly succeeded. Reverse engineering isn’t actually illegal however which is what saved it but they were no longer allowed to supply the ROM’s which are still under Roland’s copyright. In theory you have to extract them from your own MT-32, although apparently no one is allowed to tell you how to do this either.
I can’t see why Roland took this stance on hardware they haven’t manufactured in years and never will but it does make you realise how lenient EA are by comparison.
As Pix wrote Munt wasn’t very good until recently when Sergm joined the development tean and development picked up again. Regardless of that Yhkwongs dosbox built used Munt for years. And also Exult and ScummVM are offering a variation of munts mt32 emulation, but only if the Roms are there. Exult uses the old unprecise emulation, don’t know about ScummVM. (btw Pentagram doesn’t use munt as U8 didn’t have MT32 music – mentioning this because Exult and ScummVM both use a variation of Pentagrams music backend ;))
@pix: I do understand where Roland comes from. Even if you aren’t using it, you have to protect your IP if you can. But don’t get me wrong, even though I understand them I hoped for a different stance on this 😉
And sorry, this just came as a surprise for me as I thought everyone knew munt and where it is included 😉
Sounds awesome. I have two MT-32s and a CM-32L and it’s pretty accurate sounding. The reverb might not be as strong but I’d have to compare side-by-side. Also if you need the ROMs just Google “roland mt32 control rom”.
This is interesting:
http://yro.slashdot.org/story/03/12/14/2329244/Roland-Backs-Down-On-MT-32-Emulator
It says Roland failed to file for copyright on the ROMs for the MT-32 way back in the day, and therefore have no copyright over them. Strange.
@Sanctimonia, the slashdot article is basicly just a pointer to the site I linked to in my second post 😉
It’s a legal landmine even Canadacow (original author of munt) is afraid to step on hence no direct link to the roms on his site.
Ah… My bad.
I was hoping it had been settled but I guess with a company as big as Roland not too many folks want to take chances. I don’t blame them. At least it’s still in the wild in various places, so it’s not like it really needs to be hosted on the emulator site.
What I haven’t been able to figure out is if an OS X build of DOSBOX+Munt exists.
Search whether the Megabuild 6 of Dosbox has munt patched in. There is an OS X version of that available. If it does then it will be the old munt without the recent good changes. You might have to compile dosbox+munt patches yourself. I did that some weeks ago. If you do remember to build dosbox and the needed libs in 32bit. 64bit only works correctly for dosbox SVN (not version 0.74) and is much slower than the 32bit compile (the dynamic core of Dosbox that is).
I just try to build an OSX version of DOSBox with MUNT support last two days. Since I have not much experience in those things I dropped a few bricks (e.g. I did it for 0.73 and not 0.74). Finally I get it working too. I wrote down just a few notes for me to remember how i did. The notes are not well phrased, but if someone is interested in I upload them.
http://www.megaupload.com/?d=3IH00C3L
Here is the result of the work I did, an DOSBox 0.73 with MUNT 0.1.3 for OSX (I use 10.6):
http://www.megaupload.com/?d=34EY66XZ
I also include an example configuration in file “DOSBox 0.73 Preferences” that is placed after first execution under /Users/username/Library/Preferences/DOSBox 0.73 Preferences .
Important is here the midi section to activate mt32 support:
[midi]
mpu401=uart
mididevice=mt32
samplerate=44100
midiconfig=
The MT32 Rom’s are not included to get no problems with roland. If you have them rename them to MT32_CONTROL.ROM and MT32_PCM.ROM (exact writing is important here!) and copy them to your app bundle of DOSBox to DOSBox.app/Contents/Resources/ (I change the code of MUNT to look in this folder).
If you did all correct you can read in the console log files of OSX after start DOSBox:
MT32:Set sample rate to 44100
MT32:Debug _synth->open OK
MIDI:Opened device:mt32
First start of DOSBox need a while because MUNT create a cache file (*.raw) in same directory of the roms. Also the start of first game inside DOSBox need a while, because an second cache file is created(*.raw).
Again I repeat to build DOSBox for OSX with MT32 support for OX. But today I use the actual SVN trunk version I just check out today (so it is an 0.74 or better).
http://www.megaupload.com/?d=H1K2C53L
Enjoy!
Sorry, but the new 0.74 from SVN build crashes when running an DPMI programm in DOS (program that uses dos4gw or csdpmi) and I don’t know why. The 0.73 I did earlier witch CVS did not have this problem.
Did you compile in 32bit?
Yes I compile 0.73 (CVS) and 0.74 (SVN) with ‘-arch i368’. I also try 0.74 with ‘-arch x86__64’ (you just have to comile also MUNT lib for 64 bit). Dosbox 0.73 works fine with DPMI programs and 0.74 crashes. Just a while ago I saw that the craches are related to the “core” option of 0.74. With simple and normal also 0.74 is working. Problems start here dynamic and auto.
Yes, that’s why I wrote you need SVN of Dosbox (not 0.74) for 64bit, the dynamic core crashes on OSX up to 0.74. And since with 0.74 core is set to the value auto it crashes as soon as a program needs (or runs better) with dynamic core.
SVN has a fixed dynamic core for 64bit but due to the nature of Dosbox, it is much much slower in 64bit.
If your 32bit compile crashes on dynamic core it probably isn’t fully 32bit 😉
yeah, somethings wrong there with your built.
Yes both my 32bit build and my 64bit build were crashing.
I wondering if this could be related with the C_DYNAMIC_X86 and C_DYNREC pre-compiler switches that are part of cpu.cpp? It is because if I grep inside config.log from my 0.73 an my 0.74 build it looks like if they were set vice versa from autogen.sh.
What is the difference between C_DYNAMIC_X86 and C_DYNREC? Why there are two different dynamic cores in dosbox and which is the one I need? If I really needed this dynamic feature? I not really saw a visible difference in speed between normal and dynamic in 0.73.
I’ll write down the environment settings I use for compiling dosbox on os x (and with which I have no problem with dynamic core).
Dynrec core is very much needed for speed, you might not have noticed it in whatever game you tried but I noticed it quite a lot (and of course a benchmark will showcase it).
There are dynamic cores dependent on the target system since it needs to be written for each cpu type. Maybe you didn’t clean properly between compiling for 64 and 32bit…
export CFLAGS='-I/opt/local/include -O2 -arch i386'export CXXFLAGS=$CFLAGS
export CPPFLAGS=$CXXFLAGS
export LDFLAGS='-L/opt/local/lib -O2 -arch i386'
export CC='/usr/bin/gcc-4.2 -arch i386'
export CXX='/usr/bin/g++-4.2 -arch i386'
export GCOV='/usr/bin/gcov-4.2 -arch i386'
./autogen.sh
./configure --prefix=/opt/local --disable-sdltest --disable-alsatest --enable-core-inline
make clean
make
obviously I use MacPorts but you can change that in Ldflags and the configure prefix 🙂
I’m also used to using –enable-core-inline, don’t know if that chnages anything.
Hmm, I try to build DOSBox exact with the lines you post here, but than I got problems while linking dosbox together with libmt32emu.a.
ld: warning: in /usr/local/lib/libmt32emu.a, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
“MT32Emu::Synth::playSysex(unsigned char const*, unsigned int)”, referenced from:
So I decide to compile MUNT with exact same environment settings you use for dosbox itself.
But than I got a few compiler errors while compiling asm code inside i386.cpp of MUNT.
i386.cpp: In function ‘float MT32Emu::iir_filter_3dnow(float, float*, float*)’:
i386.cpp:217: error: PIC register ‘ebx’ clobbered in ‘asm’
I have no bloody idea what is a PIC register and why the compiler need it and why he con not save it itself? Anyway at least I know a something about assembler and so push and pop the ebx register in all effected code lines and also remove the ebx register from the list of changed registers at end of asm statement.
The compiler now compile MUNT and also the linker link the DOSBox. Now I enjoy the MT32 sound in the new SVN trunk DOSBox and also DPMI programs working again. 🙂
Big thanks for your good help here!
Yeah! So the munt code put 64bit in…
Can you report your changes upstream to munt?
Here is the new build for those who are interested in:
http://www.megaupload.com/?d=P1PVX4NR
64bit? Not really. As I told you I use the compiler settings that you post here before for DOSBox and MUNT. And as far as I know means “-arch i386” 32bit and “-arch x86_64” is for 64bit. So we have now an 32bit version.
Anyway here is the diff of src/i386.cpp of MUNT 0.1.3:
58d57
< "push %%ebx n"
62,63c61
< "pop %%ebx n"
: “=r”(result) : : “eax”, “ebx”, “ecx”, “edx”);
79d76
< "push %%ebx n"
83,84c80
< "pop %%ebx n"
: “=r”(result) : : “eax”, “ebx”, “ecx”, “edx”);
155d150
< "push %%ebx n"
217d211
< "pop %%ebx n"
219c213
: “eax”, “ebx”, “mm1”, “mm2”, “mm3”, “memory”);
357,358c351
< __asm__ __volatile__(
__asm__ __volatile__(
394d386
< "pop %%ebx n"
396c388
: “eax”, “ebx”, “ecx”, “edx”, “edi”, “esi”, “mm1”, “mm2”, “mm3”, “memory”);
Sorry last copy & paste miss some code. Here is the patch in an file:
http://www.megaupload.com/?d=CJ0MAGUP
I meant that *before* the munt part had the wrong architecture, 64bit, according to the linker error 😉
Oh, btw, for simple text files pastebin.com is much more useful than megaupload.
Sorry for misunderstanding I’m no native english speaker. This pastebin.com site is a great idea I didn’t know it before. Because of the syntax highlighting even a boring diff result looks great. 😉
http://pastebin.com/JKdzRLWd
And no, the MUNT asm code not contains any 64 bit code. I see just 32 bit intel code and a bit MMX and 3Dnow opcodes.
I think somewhere in DOSBox code the compiler keyword ‘register’ is used to declare an variable to tell the compiler that he try to hold this variable in an processor register. The compiler decide to use “ebx” for it. When later, while linking, the MUNT library tell the linker that ebx is changed in asm code the linking fails. So I just save the ebx register at the stack when it is changed in asm code of MUNT.
I still wondering why this problem just occurs when I use your options to compile DOSBox while my options didn’t have this problem while linking. Maybe an different setting of pre-compiler options hide or unhide the register keyword that causes the problem. Anyway, since your options let DPMI programs work with dynamic core it was definitely the better choice. 😉
hi,
I’m the guy who posted the video
I fear your mac build is using very old code for munt, the 0.1.3 code is the one that has been up for years. And is leaves much to be desired. They took down the munt reloaded branch which had this code, as they are nearing the release of the next official version. but I have no idea when that will be. It is highly recommended that you compile from Taewoong’s source available at his site if you can. I tried it myself and ran into a minefeild of crazy dependencies that i wasn’t very able to get through, but it looks like you have had more luck.
I could not found any source at Taewoong’s site? Just saw already compiled Windows and Linux binaries without source? Can you post here the link to his newer MUNT source if you know were it is?
http://ykhwong.x-y.net/xe/?module=file&act=procFileDownload&file_srl=438&sid=9984eaa99d3398e369a50882920f9b7d
it’s on the download page if you scroll down a little above the bottom. Granted it’s a little small.
ahh links from off site don’t apparently work. It’s there the file is source.7z
After some searching in net I think actual sources can be found here:
https://github.com/munt/munt
And sources can be checked out with SVN with:
svn checkout http://svn.github.com/munt/munt.git
yup that will work too. You didn’t see Taewoong’s source code though?
No your link shows me only an login box and I have no idea about user ID and password.
Anyway yesterday I compile the newer MUNT and saw that they really have changed a lot in last 6 years (the difference between the sources I use before and the actual).
For example the waveformcache files are not longer created since tables.cpp has been complete changed.
Also the building mechanism has changed to cmake. This causes me a lot of trouble since it creates on 10.6 by default 64bit bit code of MUNT that I can not link to the 32bit DOSBox (it is 32bit to avoid the crashes with DPMI programs). So first I had to find out how to tell cmake to create 32bit code.
cmake -D CMAKE_OSX_ARCHITECTURES=i386 .
I also add than my patch to new MUNT that looks for the ROM’s inside the Resources folder of the application bundle and now it works and I listen the new MT32 sound. 🙂
Finally here is the new build for OSX:
http://www.megaupload.com/?d=B1Z8A20Q
You know, with all these builds and suchlike that keep getting posted…did you want me to set up a project entry and FTP access for you?
Better option than Megaupload, if not quite as “click here to submit”-quick.
Yes, it is an good idea.
I was looking around if I could find an new DOSBox with MUNT support for OSX, but only found Linux and Windows builds. Thats why I decide to compile it for my self. And I want other OSX users to have this builds too thats why I upload them to Megaupload. But an FTP Access from Project Entry would be the better option.
MT32: I can set you up FTP access, but what email account should I send details to?
well as I said ,that link doesn’t work as there is something blocking it from being posted off his blog. I was trying to tell you that it is on his website on his DownloadSVN Builds page towards the bottom in small print called source.7z
Anyway Thanks for the source Mac build from scratch. I guess yours would be of newer code and of only the Mt-32 patch. Which is useful.
EDIT
I should say, DownloadSVN Builds page clicking on the 7/5/2011 for windows page then scrolling down near the bottom
Yesterday I start to create an AU (Audio Unit) for OSX that includes MUNT. So you can use the MT32 Synth as audio component (plugin) in OSX apps that support this interface (like DOSBox with AU Lab, GarageBand, Intuem 4(an OSX midi player), and maybe more…).
It is just a start and maybe no perfect software, but it is still working with good sound. 🙂
I wrote a message to one of the MUNT developers at github if they let me add the source of the AU module.
I try to create an new account here as Stino that contains an mail address since I not want to post this public here. Unfortunately this website is closed an I need an Invitation Code to enter that I not have.
@WTF DRAGON: It’s me the MT32FORDOSBOX. 😉 Since I’m now registered here I change my avatar pic back to first one I got here. And you should know my Email now.
I’m joint into the MUNT development and make the new code of the Audio Unit for OSX public at Gidhub.
The other developers will check my fork and maybe they bring it back into the main branch of MUNT. We will see…
I fear I was having some difficulty with your dosbox mac version mostly because of the problems with SDL 1.2 and lion in fullscreen. As such I tried my own hand at it using a patched SDL. I also decided to make the changes to Alun Bestor’s excellent mac integrated dosbox program called Boxer v1.1. This is in part because it’s source had an xcode file already setup ;), but also has many wonderful features for mac users. The munt code was taken from ykhwong’s build as I didn’t see the specific dosbox patch on the munt git.
In order to get working put your ROM files in your dosgame.boxer folder and add “mididevice mt32” into the autoexec section of your games “DOSBOXPrefrences.conf”
http://www.mediafire.com/?8cb8394u6d6cwhc
I should also note that I was using xcode4 so the usual PPC support boxer promises is lost.
Yes, I also saw that DOSBox get problems with Lion and Fullscreen. But also other SDL programs like Scummvm show this behavior. This was one of the reasons, other was missing rosetta support, why I go back to my Snow Leopard. And I will stay a while at SL until the teething troubles are gone.
Yah well, boxer apparently already had the issue fixed using Lions built in fullscreen method via spaces. It really is a well thought out program
WCNUT – would u mind please posting the link to your BOXER patched version with MUNT for OS X? I’ve been searching high and low for MT32+BOXER+MUNT support forever… stumbled upon this amazing thread!!!
Sry forgot I deleted it as I posted a newer one on the CIC anyway here is an even newer one
http://www.mediafire.com/?xre50a18hofv3tt
No PPC support though as I have xcode4
Well I have been talking with the author of boxer and he will now include munt in future. It’s now in the source code, but he is still tweaking it to make its use as streamlined as possible.