VOGONS


DOSBox w/ built in MUNT Emulation

Topic actions

Reply 20 of 41, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

Absolument.

Reply 21 of 41, by Reckless

User metadata
Rank Oldbie
Rank
Oldbie

I see no reason why the Windows driver control panel cannot use .NET. It's been out 3 years and doesn't make your machine 'unstable' after installation or when running .NET applications.

I've been developing .NET applications for almost 3 years now and it's a major productivity step forward when compared to the lash-it-up quick langauge of VB and 'cut grass with a pair of scissors' VC++. VS.NET 2005 with .NET 2 is a huge step again with lots of cool stuff for developers (shame some of this was missing from previous releases!).

Reply 23 of 41, by Reckless

User metadata
Rank Oldbie
Rank
Oldbie

I have the utmost respect for Mark from SysInternals. I do beleive however he had make a small mistake in his comparison of Notepad written in .NET vs. Notepad as supplied by the operating system.

The one supplied by the OS was written in C and is therefore the lightest all languages out there. C++ would have been probably been slightly heavier (only down to the MS C++ library), VB would have been larger still and yes one produced in a .NET langauge the largest of all. However .NET is Microsoft's answer to Java and to a lesser extent its own VB6 development evironment. It is *not* an answer to 'real' Windows development tools and langauges (C/C++) (well, not just yet anyway!).

I've no idea how resource 'hungry' a Java version of Notepad would be. Perhaps as big as VB but maybe not as big as a .NET version? I don't know but I do know what would look and work a lot better out of those three choices!

Agreed the platform requirements for a .NET application is a significant increase on that of any previous environment. However .NET is loaded and JIT'd on demand so no resources are used unless something loads the application. You simply don't have a bunch of resources being wasted with the .NET Framework 'running in the background' - it just doesn't. There are different rules about memory management (yes, you *still* have to take care of it yourself) so the hype about a .NET app never 'leaking' was rubbish. Bad object lifetime management can cause significant memory overhead as can bad usage of a simple object like a string. The biggest 'problem' is developers not understanding exactly how the garbage collector is helping and also *not* helping them!

If a developer decided to provide something as a .NET application as it was easier for them to do so, it would probably mean two things 1) it would actually get finshed/released as it was planned and 2) the end product would most likely have richer/better functionality and especially the UI than it would have been with a language such as C++.

Anyways I do accept that it's not the tool for everything. It would seem 'ideal' for the driver control panel given we're all after a rich easy to use UI sometime in the next 'x' months 😀

Reply 24 of 41, by Marauder

User metadata
Rank Newbie
Rank
Newbie

Here is another comparison between the latest MUNT CVS and real MT-32 from Legend of Kyrandia.

Reply 25 of 41, by canadacow

User metadata
Rank Member
Rank
Member

Not sure what CVS you are using, but my build is current with the CVS and MUNT sounds almost nothing like what you produced. Attached is what a build from the CVS should sound like. Minus some overdriving clicking (which I didn't notice before) and some lacking reverb, it sounds almost identical to the real thing.

We're really way overdue for a release.

Crap. MP3 encoder isn't cooperating today. I'll post an new Mp3 when I get more time. Oh I wish I had time.

Reply 26 of 41, by canadacow

User metadata
Rank Member
Rank
Member

Aha! Time!!!

Reply 27 of 41, by Marauder

User metadata
Rank Newbie
Rank
Newbie

How strange. I'm using the one HunterZ posted and I have all the MT-32 files in the directory.

Reply 28 of 41, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I'll try to dig out a copy of the game and test it out in the next couple of days to see what I get.

Marauder: You might try deleting your waveform cache files that Munt generates the first time you run DOSBox with a given MT-32 sampling rate. I've had things sound weird like that too for some reason, and I *think* deleting the cache file helps.

Reply 29 of 41, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Hi, since I've already posted this in the wrong thread, I'll post again here 😀
Could someone update these patches for current CVS of both Dosbox and Munt?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 30 of 41, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Why don't you use the standalone driver version instead? That way, you will never have to use a self-patched DOSBox again.

Reply 31 of 41, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I mostly wanted to be able to build newest versions whenever development might pick up again. But I'll try the driver 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 32 of 41, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Moe, I would agree except for two reasons:
- The standalone driver is Windows-only, while the patch allows MT-32 emulation on any platform supported by DOSBox
- The standalone driver is more out of date than the Munt CVS

Reply 33 of 41, by robertmo

User metadata
Rank l33t++
Rank
l33t++

ykhwong's dosbox cvs always contains mt32 emulation. I wonder whether he uses the latest munt cvs in it.

Reply 34 of 41, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Probably. Munt CVS hasn't changed for quite some time as far as I know.

Reply 35 of 41, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Moe, I would agree except for two reasons:
- The standalone driver is Windows-only, while the patch allows MT-32 emulation on any platform supported by DOSBox
- The standalone driver is more out of date than the Munt CVS

Now that I tried the driver I'm pretty sure about a third reason:
starting up Dosbox takes about ages to with this driver installed 🙁

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 36 of 41, by robertmo

User metadata
Rank l33t++
Rank
l33t++

are you sure? i think it takes ages only the first time when dosbox prepares waveformcache .raw files.

Reply 37 of 41, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

The driver uses libmt32, which is by definition always the latest munt available, and it is also available on Linux. OSX users are currently hosed, but I guess it won't be too difficult to start out with one of the two available drivers and use them to write an OSX-specific driver.

The waveform-cache is recreated every time if (and only if) munt can't write to the directory containing the ROMs.

Reply 38 of 41, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The waveform-cache is recreated every time if (and only if) munt can't write to the directory containing the ROMs.

Ah, I see, as a security minded person I'm running Windows as normal user and not as Administrator. So no write access to the system32 dir (where the roms get installed to).
Something that might be good to mention in the docs.
If I run any midi with the Munt driver as Admin it should work, then. Thanks for bringing that to attention for me.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 39 of 41, by robertmo

User metadata
Rank l33t++
Rank
l33t++

i think placing it in a doc is not a good solution.
I think munt should install itself into it's own folder and keep it's files in it.
Dosbox with inbuilt mt32 emulator keeps all the mt files in dosbox folder so there are no problems with it even if you are not an administrator.