In the mean time, it doesn't seem to be too hard to run mt32emu-qt on Windows 9x. It seems like Qt versions prior to 4.6.0 retained Windows 9x compatibility. There are only a few changes required to compile it with the minimal set of audio drivers using MinGW. Uploaded a test build. Again, it requires MIDI Yoke or the likes to route MIDI from e.g. DOSBox or a MIDI player to the synth.
wrote:Wait a minute. I don't get the point if this is about running games in DOSBox under Windows 98. All you need is to add mt32emu l […]
Wait a minute. I don't get the point if this is about running games in DOSBox under Windows 98. All you need is to add mt32emu library right into DOSBox. I'm sure there are DOSBox builds Win9x compatible around already.
Besides, I don't think it is enough to have just an Intel CPU to run Windows 9x on a modern PC. USB audio is likely OK, but which video drivers do you use? When I tried windows 98 on my notebook I got nothing more than 800x600x16 video mode, quite disappointing. Perhaps, it would be better if VESA modes were supported but I doubt this is always the case. Sorry, but I only see the point to run Windows 98 on supported hardware where you don't even need to use DOSBox. And unlucky, such hardware does not seem to be powerful enough for mt32emu engine to work in real time. Hence, I still see no need to bother with compatibility.
And indeed, there are tons of Windows PE builds around (for example, I used to use REATOGO in old times) that allows you to run XP from a USB drive (and of course from a CD). Actually, I think running Windows 7 PE is even easier. And I don't see the point to run exactly Windows at all. You can easily set up a Linux box, and DOSBox will run just fine there. Either with official munt packages or again compiled into DOSBox. The latter would look more convenient for me personally if I wanted to play games. I think a Linux box provides wast majority of advantages compared to an XP PE or Windows 7 PE builds (not mentioning Win9x which likely lacks drivers for newer hardware).
So, no, I don't get the point. For me, Windows 98 changes nothing in the sense of portable gaming.
To address the DOSBOX issue you are having. I've sifted through and tested over 50 Demos but focused on the ones that could run under just the Command Prompt in XP, later I did more testing in 98 and it could run under its DOS Prompt but use the MS Roland GS Wavetable Synth natively without the need of using DOSBOX. But of course most of the instruments are awful sounding since it's not a MT-32.
The laptop might not be the most suitable device to use for 98 but a Desktop can add the video cards for the drivers unless you got a real old laptop during the P3/P4 era then some older Intel Graphics might work. But there is a Bear Windows driver but I'm not sure if this driver will work for DOSBOX in your situation but it does allow higher than 16 Colors and DOSBOX seems to like 256 colors or more to work properly.
http://bearwindows.zcm.com.au/vbe9x.htm
But the Demos I have consolidated in this new thread post.
MUNT 98 Testing
They should work in 98 using the DOS Prompt inside 98 not "REAL DOS". The only exception is Dune 2 which didn't seem to work properly except using DOSBOX or running in "REAL DOS".
Some DOS programs will not run properly inside the 98 DOS Prompt but you need the MUNT98 to do the MT-32 emulation so you can't go to "REAL DOS" yet unless you've found a way to port this to work under "REAL DOS" then that would be a breakthrough and if running under "REAL DOS" you won't need to deal with the video drivers but just a USB sound card DOS driver.
There are probably more DOS programs that will run "outside of DOSBOX" but if your MUNT98 can be seamlessly integrated into 98 so the DOS programs can use MUNT in the background without DOSBOX that might decrease the CPU load. The really older titles play well using the 98 "Dos Prompt". Or if you are simply listening to MIDI files they could use another MIDI software player as long as 98 recognizes MUNT as the MIDI output device.
The XP and W7 USB method with PEs I haven't tested and how are you dealing with the display drivers for PE to get DOSBOX to work? Which XP and W7 PEs are you using and how large are each? Also the larger size of those two OS might pose a problem forcing you to get a larger USB flash drive. XP is smaller at around 2GB but the W7 64-bit will be around 16GB or more. The 98 could be around 500MB for full size but if compacted to its bare essentials it could be much smaller maybe under 100MB leaving more room on the USB device for storage.
This site seems to show a 58MB possibility or 51MB if no Swap File although I haven't tested that out.
http://www.litepc.com/98micro.html
XP requires activation so I'm not sure how you will get around that hurdle of a potential disabling of the OS one day where 98 seems to install as many times without any activation time limit. But for ease of use I agree XP seems to have it all.
The most portable you could get is "REAL DOS" < 1MB but until such a MUNT and DOSBOX port could happen 98 is the next best choice at the moment as far as size and compatibility.
<<Sorry, but I only see the point to run Windows 98 on supported hardware where you don't even need to use DOSBox. And unlucky, such hardware does not seem to be powerful enough for mt32emu engine to work in real time. Hence, I still see no need to bother with compatibility.>>
The 98 can run on the latest Intel chipset so far and the problem with the newer chipsets is going to be the lack of ISA slots (the need for DOSBOX) but the newer chipsets can handle more of the CPU burden. The emulation seems to be almost like a real MT-32 so is there any further way to optimize MUNT so it isn't so demanding?
It seems odd that the built in MS Roland GS Wavetable Synth barely uses any resources in comparison and I tested it down to 800MHz. Could a limited non programmable MT-32 Synth that overwrites the MS Roland GS Wavetable instruments only be done? It wouldn't be perfect but the instruments would sound better for static MT-32 games.
What about a better 98 MIDI mapper replacement?
Congratulations, you've really managed to confuse me 😀
So, let's start over. What is your ultimate goal? Do you want to run MT32 emulation in DOS, Windows 9x, XP or Vista+? Or everywhere? Do you want your games just to run a bit faster with Windows 9x? I'm really confused.
See, there are many problems with all those things you tried to describe. I hope I can add some clarification.
1. DOSBox is a really good thing for running DOS games. Accept that. Some people do want to build a native DOS environment and play "fair". It's their right and their love. But I'm afraid most gamers do not want to even reboot to play. So, a new PC with DOSBox on a modern OS is essentially what they want. Try not to fix what isn't broken 😉
2. If this is about running old games in a real DOS with MT-32 emulated, there are way too many problems. The emulation is quite demanding due to objective reasons on the one hand, and most of the old games require you to slow down the system on the other hand. If you disable CPU cache, you can forget about emulation in real time. Indeed, hardware of modern PCs are even less supported in pure DOS, btw. Are you sure your USB audio will work with SB emulation? I doubt it. You'll need a VCPI driver that emulates both SB and MPU-401 (yes, this one too!). Many MT-32 related games require MPU-401 in the intelligent mode, so SoftMPU project exists. Perhaps, we can join efforts and add actual emulation of MT-32 core, no idea. One thing is clear: there are a lot of effort to make this real for almost no reason.
3. Similar things apply if you want MT-32 emulation in Windows 9x DOS session. There must be a VxD driver that monitors accesses to hardware ports of SB (if you don't have a real SB of course) and MPU-401, and routes the data to the corresponding Windows drivers. AFAIK, the existing driver for routing MPU-401 ports does not work in the intelligent mode, but not 100% sure. There was a topic in VDMSound dev forum about but I'm not aware how did it go and what's the result. Again, there is a timing issue with old games in this environment. Besides, timer emulation just sucks. All these problems (and more) are already solved successfully in DOSBox.
4. In Windows 9x you can say good bye to all the cores except just one of your brand new multicore CPU. A pity. Even a dual core CPU easily handles the performance problem on Windows XP+ and Linux boxes. mt32emu works fine on a modern smartphone, so why one would need to optimise the existing mt32emu engine? I'm sure this is possible but the goal is different.
5. In Windows PE environment, the activation problem you are so scared of does not exist. You can easily add any video, audio or network drivers as soon as they are available. Indeed, you don't need a big flash drive. Windows X PE builds are considerably smaller than a full installation. Windows Vista+ PE is also far less than 16Gb as it is stored compressed in a WIM image. Same is with most of Linux "live" distros.
6. The wavetable synth built in Windows is faster because it does not synthesize the wave samples, it uses them from the table. Besides, it is not cross platform and heavily optimised. There are a lot of MT-32 "emulations" around that are much less demanding but this is not what we want to achieve with munt 😉
7. Why DOSBox needs ISA slots? All this becomes weirder and weirder...
I can see this being somewhat useful for those with real hardware to run DOS titles on one machine and high CPU late DOS titles/Win9x titles on another. The Win98 box could run synth for the DOS machine using a gameport MIDI adapter with no need for another more modern system.
All hail the Great Capacitor Brand Finder
Yep, sure. Besides, it seems that I can pull off the 16-bit Windows 9x driver. Found a free C++ complier from M$ in Windows ME DDK 😎
wrote:Congratulations, you've really managed to confuse me 😀
So, let's start over. What is your ultimate goal? Do you want to run MT32 emulation in DOS, Windows 9x, XP or Vista+? Or everywhere? Do you want your games just to run a bit faster with Windows 9x? I'm really confused.
SergM, I have replied to your posting in depth but I have moved it to my thread to avoid hijacking "Nic-93's" thread any further as the answer to his question is now true that MUNT is 98 finally compatible through my testing of your latest 9-11 build.
My full response is here. 😈
Re: MUNT 98 Testing
wrote:SergM, I have replied to your posting in depth but I have moved it to my thread to avoid hijacking "Nic-93's" thread any further as the answer to his question is now true that MUNT is 98 finally compatible through my testing of your latest 9-11 build.
Well, munt isn't fully compatible atm but I'm working on it... 😉
Yep, sure. Besides, it seems that I can pull off the 16-bit Windows 9x driver. Found a free C++ complier from M$ in Windows ME DDK 😎
Wait what isn't fully compatible at the moment and what's not working? It seems working only with DOSBOX in conjuction with the MIDIYOKE program but MUNT98 needs to work in the DOS Prompt Window also similar to the Windows XP Command Prompt. I've added more ideas to improve MUNT98 and MUNT in general in my thread. Also what did you mean by this statement? Is the current condition of MUNT98 more of stand alone app that must be run manually as I have been doing whereas the XP version is always running in the background as a process which is why it works inside Command Prompt instead of needing DOSBOX?
The MIDI driver seems to become usable, so I think there are two of the munt components compatible 😉
I probably stop at this point, though (at least for the near future).
sergm wrote on 2017-10-03, 05:26:The MIDI driver seems to become usable, so I think there are two of the munt components compatible 😉
I probably stop at this point, though (at least for the near future).
thank you!!! for making this work under win9x. i also fail to grasp the obsession with getting this to work in dos or a win9x dos virtual machine. i just wanted this to work under win9x the same way it works in xp & later. my use case for both is absolutely identical and this saves me from dual/triple booting yet another os.
i do have a couple feedback notes. first, i like to keep the mt32emu program running in the system tray and oddly it prevents my system from restarting or shutting down. it's not a big deal as no matter how many times a shutdown fails, i can still manually close the program and then successfully shutdown on the very next try.
second, i'm running this on a 1.8ghz athlon which is easily adequate horsepower for the emulation, but i'm still getting some stuttering under win98se. at one time or another i've had xp & linux installed on this very same system and never had a single hiccup with playback. given that, i have to think this has to be a specific issue with the os configuration, but i can't seem to figure it out. do you have any tips on what to look at?
Heh, I don't recall when my Win98 rebooted not because of a crash (I tried really hard at the times to put my PC to sleep overnight, etc.) but well, you sound like there is a specific problem. A quick question: do you have the "Pin Synth" checked?
Speaking of performance, let me remind that Win9x implements a weird multitasking scheme unlike WinNT or linux, notably when a DOS application is running. If you experience playback issues even when having mt32emu-qt running alone in the system, then it might be a peak in CPU load. In both cases, increasing audio latency in the "Audio Output"/"Properties" dialog is supposed to help. OTOH, a higher latency degrades gaming experience (or kills things like live performance). It might also help to boost priority of background applications, so the synth will be assigned more CPU time taken from the foreground app.
no, the pin synth box is not ticked. i don't even know what that does. i presume it has something to do with windows desktop settings?
your advice about adjusting the latency was spot on. i tripled the value from 100 to 300 and the stuttering has almost totally gone away. it's to the point where i'm satisfied and who knows what other improvements i might be able to make from the os side of things.
something else has cropped up though. for some reason i can't get mt32emu working with dosbox. i've tried using both midi yoke and the winmm midi driver with the same result: 'open failed 🙁' error message when clicking the mt32emu start button for the midi yoke/dosbox midi ports. i'm using the plain vanilla 0.74-3 dosbox branch on sourceforge. i don't have this problem with any other midi applications (or midi yoke) so i'm guessing there's something wrong on the dosbox side of things. i don't suppose you have any more concise insights on where to start looking for a fix? thanks.
stanwebber wrote on 2022-12-30, 07:03:no, the pin synth box is not ticked. i don't even know what that does. i presume it has something to do with windows desktop settings?
No clue. The behaviour of the 16-bit stuff buried in win98 is hard to predict, and the multimedia subsystem heavily relies on that. Maybe you can fix it by using different audio driver, e.g. WDM-based, if available.
your advice about adjusting the latency was spot on. i tripled the value from 100 to 300 and the stuttering has almost totally gone away. it's to the point where i'm satisfied and who knows what other improvements i might be able to make from the os side of things.
Right, but I personally find FX produced by a game via MIDI and delayed by 300 ms rather suboptimal. But that's entirely OK if you just want to listen to a tune.
something else has cropped up though. for some reason i can't get mt32emu working with dosbox. i've tried using both midi yoke and the winmm midi driver with the same result: 'open failed 🙁' error message when clicking the mt32emu start button for the midi yoke/dosbox midi ports. i'm using the plain vanilla 0.74-3 dosbox branch on sourceforge. i don't have this problem with any other midi applications (or midi yoke) so i'm guessing there's something wrong on the dosbox side of things. i don't suppose you have any more concise insights on where to start looking for a fix? thanks.
I do have an idea what may go wrong. In early days, windows was unable to share an audio device between applications. The introduction of WDM subsystem changed that all: a kernel mixer solved the device sharing problem at the expense of an additional delay (well, I guess 30 ms was not considered significant at the time). But some audio drivers were rewritten for compatibility with WDM system in such a way that quality suffered (experienced personally with YMF-740). So I used to swap the driver version from VxD to WDM back and forth 😒
Anyway, if your audio driver is unable to provide access to the device for two applications (specifically, DOSBox and mt32emu-qt), your best bet would be to use a DOSBox built with the integrated emulation, I think.
switching to wdm drivers occured to me as well. unfortunately, only win95 (snd930p.vxd) and nt (snd93x.sys) drivers were ever released for my card and i can't get the nt drivers to install in win98se.
i also have an awe64 gold that i might try. i know the vxd drivers are directsound compliant (just like wdm drivers). snd930p.vxd shows up as 'emulated' in dxdiag so maybe the result will be different with compliant drivers.
i dug up this dosbox branch compiled with mt-32. it has a way older version of munt, but it actually seems to work under win9x.
DOSBox-SVN + MT-32(v1.30) emulation
despite being compiled with mingw for win32, i can't get any of the dosbox-x builds with more current munt working in win98se.
Yeah, life goes on and on, the support for win9x platform's become scarce, and 16-bit stuff's hopelessly gone to the abandonware category.
Sadly, I can't immediately provide a win9x-compatible DOSBox build (technically), but probably this month. You could keep looking around, but note, even MinGW builds are incompatible with win9x if compiled with MinGW versions 4.8+.
A cheap trick you could do is to start mt32emu-qt first and check the "Pin Synth" box. In this mode, the audio is never stopped automatically, so when you start DOSBox later on, it will not play any sound, e.g. from SB or adlib. But MIDI will keep working, and you should be able to listen to your MT-32 at least.
sergm wrote on 2014-11-03, 11:51:Besides, it may be a better option to setup Linux on such a box... At least Linux box can be configured to require even less RAM while still be maintained and thus fully compatible with munt...
No linux setup with a GUI is going to run as efficiently or as smoothly as Windows 98 or XP.
I tried for years, on a Pentium III desktop with 512 MB of RAM, no less. It was slow as hell, whatever the GUI / WM was.
Windows 9X can run on 16 MB of RAM. Linux with a GUI can't.
Windows 9X and XP beat Linux in the lightweight memory and CPU usage category for breakfast.
i tried the dosbox compiled with munt v1.3.0 referenced above and, while the default instruments sounded ok, any custom instruments came across with a distorted computer synth sound. thinking it might be the older version of mt32emu i tried my hand at compiling a win9x build using mingw of the most recent 2.7.0 version. i had to remove '-ansi' from cmakelists.txt, but i managed to get a dosbox build working under win98se. unfortunately, the exact same issue with custom instruments exists even in mt32emu v2.7.0. you can hear it for yourself with the attached binary. do you have any thoughts on what might be going on?
hmm, another wrinkle has come up. mt32emu_qt throws an open failed error when trying to start a midi port using an already occupied mme audio device which is the EXPECTED behavior since my vxd drivers aren't directsound compliant and can only accept 1 connection at a time.
however, i found this virtual audio cable driver:
https://software.muzychenko.net/en/virtual-audio-cable-3/
it operates on the identical principal as midiyoke, but instead of looping midi-out > midi-in, it routes wave-out > wave-in. in essence i can create a virtual mme device that can accept unlimited connections and then use the included audio repeater tool to connect it to the opti930 vxd driver which is limited to 1 connection.
the virtual driver includes a control panel that lists the active connections and i've tested it with multiple applications connected and everything worked as expected.
here's the wrinkle: mt32emu_qt can connect to the virtual mme device with no issues EXCEPT when another application is connected. i get the same open failed error as if nothing has changed. what gives? the virtual mme device is purpose designed to accept multiple clients and nothing else has a problem with it.
stanwebber wrote on 2023-01-13, 03:31:here's the wrinkle: mt32emu_qt can connect to the virtual mme device with no issues EXCEPT when another application is connected. i get the same open failed error as if nothing has changed. what gives? the virtual mme device is purpose designed to accept multiple clients and nothing else has a problem with it.
Yes, that ought to be a solution, and what you get is strange. However, when a number of outputs connected, the audio mixer in the virtual cable is intended not only to mix the signals but also convert their sample rates and formats, if different (which is essentially what the WDM kernel mixer does). I'm pretty sure about the audio format that mt32emu-qt uses for the wave output, but the sample rate conversion might be an issue (no clue). I assume, changing the sample rate of mt32emu-qt output to e.g. 44100 (in the audio properties dialog) could improve the situation.
stanwebber wrote on 2023-01-11, 00:38:i tried the dosbox compiled with munt v1.3.0 referenced above and, while the default instruments sounded ok, any custom instruments came across with a distorted computer synth sound. thinking it might be the older version of mt32emu i tried my hand at compiling a win9x build using mingw of the most recent 2.7.0 version. i had to remove '-ansi' from cmakelists.txt, but i managed to get a dosbox build working under win98se. unfortunately, the exact same issue with custom instruments exists even in mt32emu v2.7.0. you can hear it for yourself with the attached binary. do you have any thoughts on what might be going on?
I gave it a go on my system and it works smoothly. Looking at the configuration, I'd suspect you experience buffer underruns rather than an overdrive distortion. That'd make sense if the "custom instruments" here require more CPU power than available. Indeed, the very same cure applies here as with mt32emu-qt. Try enabling mt32.thread and increasing mt32.prebuffer and maybe mt32.chunk sizes. Also, lowering mt32.src.quality might help to save a bit of CPU load.
