Saved spot for followup Munt98 Walkthrough or testing attachments.

Additional followup.

sergm 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.

Yes I think some of what you interpreted might have been lost. It could be a translation issue but I'm not sure. 😀

But let me try to bring a little more clarity.

The Ultimate goal would be when it becomes possible MUNT and DOSBOX working in "REAL DOS" more specifically 95B or 98/SE DOS known as MS-DOS 7.0/7.1 due to the FAT32 support. This would allow running any early DOS based legacy title that supported the SB or MT-32 to be run without a real SB ISA card nor needing a Roland MT-32 hooked up. The only requirements could be just needing a USB Sound Card for external simplicity. The Video card probably wouldn't need a special video driver to run in "REAL DOS" and probably even the integrated GPUs should work fine in "REAL DOS" without needing a special DOS driver. The question is will DOSBOX for "REAL DOS" work fine in REAL DOS without an additional DOS video driver or could some sort of Bear Windows equivalent universal Video driver be embedded into DOSBOX for "REAL DOS" to avoid that issue. The the next stage is a USB DOS driver for the USB Sound device to interface with DOSBOX for "REAL DOS" which will send the appropriate MIDI signals to MUNT for "REAL DOS".

The current goal now is getting MUNT98 perfected for ease of use installation similar to XP.

Other Operating Systems I've tested such as Vista 64-bit and later OS were for experimental purposes to see what problems if any existed for MUNT and DOSBOX and only the MIDI Mapper from Coolsoft was required to resolve it. I never had any plans on testing it on later than XP OS due to the size of the installed 64-bit OS was usually 16GB or larger. All that wasted space on a cheap USB storage device could be consumed by DOS programs instead.

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 😉

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.

The XP 32 bit and Vista 64 bit testing was just in case someone who wanted to use MUNT on another OS had a way to do it from just one post. I had tested Vista 64-bit and all that was required aside from the DOSBOX.conf alteration is the addition of Coolsoft's Midi Mapper and I'm sure W7 and W10 work the same with it. The problem on those newer OS is the lack of being able to choose your default MIDI output device. I'm not sure about the Vista 32-bit version or XP-64 bit version if it applies to those as I haven't tested to see if they lack the proper MIDI Mapper in them.

But for the easiest use of your MUNT and DOSBOX combined XP 32-bit is the most graceful and easiest solution.

Now I understand your thought process of hey if I'm going to play something I will do it on DOSBOX on a modern OS. While that is true and the preferred modern OS method since you can multitask and not require rebooting the system.

But there are advantages of having a smaller OS size and being able to fit on a USB and boot in just one second for regular W98 SE DOS is possible. So if you take in the fact < 1MB to install the W98 SE DOS and then running the MUNT port that is "REAL DOS" based and then if a DOSBOX port can be run in "REAL DOS" then you will have the best of both running in a very compact environment probably within 10MB -> 100MB total. Then the rest of the space could be for all your old legacy DOS software. Even something like 16GB could store probably more than enough DOS titles that existed that were heavily MIDI based. Most CD titles moved onto to audio tracks so those are best served on more modern OS anyhow.

But for example older pre CD audio titles like Dune 2, Warcraft 1, 2, Prince of Persia 1, 2, King's Quest 1-6, Space Quest 1-6, Police Quest 1-4, Leisure Suit Larry 1-3, 5, Wing Commander 1, 2 and many other titles to list for the most part would best fit this scenario of compact DOS legacy titles that could work on 2.5GHz modern motherboards that lack ISA and PCI slots, and USB Audio does work with 98 from my testing since I have tested your MUNT98 with the DOSBOX it does work. I know one person working on USB 2.0 drivers that would be willing to later program a USB DOS driver for the USB Audio device that could be used for the SB emulation so it's just a matter of time and getting the right parts together but even using a PCIe sound card or onBoard sound device with some Universal DOS SB emulation interface module could be possible once the foundation is laid people will try to fill in those missing gaps. But for the moment focusing on the MUNT98 ease of use installation perfected before moving to the true epitome of the holy DOS Grail.

One thing you mentioned about the MUNT emulation I was curious about since at the moment is very CPU intensive like DOSBOX but maybe there is a way to tap into the extra cores that Windows 98 doesn't access and are sitting idle? That would prove useful on quad core systems then you could keep the MHz down to 800 on all the cores keeping the heat down. If this could happen then MUNT98 would be very useful on modern computers lacking both ISA and PCI slots and using a simple USB Audio device which is a PNP device requiring no extra drivers.

7. Why DOSBox needs ISA slots? All this becomes weirder and weirder...

DOSBOX doesn't need ISA slots but for systems without ISA slots is where DOSBOX is useful to do the SB emulation since any PCI based Sound Card is just too inferior to work successfully and even on a P4 testing the Ensoniq PCI DOS SB emulation was intermittent and not smooth and I think some DOS programs wouldn't work with it. On much modern chipsets it doesn't work since you can't install the DOS SB emulation so DOSBOX is a necessity. But for systems that still could have an ISA slot to use a real MT-32 such as a P4 you could use a real SB and then use your MUNT for the MT-32 emulation if it was powerful enough. I'm not sure if a P4 can handle both the DOSBOX and MUNT on a single core P4 but if a modern day 2.5GHz could handle it on one core maybe a 3.0GHz P4 single core could barely handle it. But I have used a P4 with real SB and real MT-32 so it is capable of true hardware on a single core.

Now you bring up some good points of question why would someone try to install say 98, DOSBOX, and MUNT on a modern day computer instead of XP or XP PE as you suggested. Compactness would be the biggest advantage and I do foresee some issues for installing XP PE and W7 PE on newer chipsets. I haven't tested any XP PE or W7 PE so if you have any recommended ones I'll do some more testing. But the biggest problem I see is the eHCI ports being removed so xHCI is not native to XP or W7 so I'm not sure how your XP PE will react or even boot anymore on those modern chipsets lacking the eHCI. Try testing your portable PE OS on a Z170/Z270 Intel USB 3.0 port and see if it can self boot.

The 98 DOS will boot on either USB 1.1 to USB 3.1 ports without additional USB drivers. So this gives it an extra leg up on newer hardware on top of not requiring to register/activate the OS or more bloat. I know you brought up XP PE as not needing to activate but isn't PE more of a bare bones lacking some vital XP functions? You say it works with DOSBOX and MUNT without problems? Can you run any XP SP3 Compatible program on it or is it relegated to the XP non SP compliant programs? Can you combine the 98 boot with the XP PE and use the NT Boot Loader? Or is the XP PE its own self booter and stand alone you can't add it it as part of the BOOT.INI for the XP Boot loader?

If there is a way to load into 98 DOS and then use the command line to boot into XP PE without rebooting the system or if not then a way to reverse engineer the NT boot loader then you can reenter it from the 98 DOS command line to choose another NT OS to boot such as the XP PE.

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.

Yes the SoftMPU was the DOS method of not requiring the ISA card to do the interfacing to the MT-32. So if your MUNT could somehow be ported and merged to run under "REAL DOS" then this takes it a step further and only the DOSBOX in "REAL DOS" would solve some of the other incompatibilities you mentioned to slow it down properly.

But there are still a lot of native DOS games that can run outside of DOSBOX and use the MUNT running in the background which it did fine in XP but not in 98.

Download the game demos attachment and you can try all 4 and they will work with MUNT loaded in XP and not using DOSBOX at all. When going to 98 only DUNE 2 cannot run inside 98 at all and must be run outside in "REAL DOS" but does run in DOSBOX.

So a possible SoftMPU / MUNT for "REAL DOS" merger would be helpful to run older games that supported the MT-32 (mostly Sierra titles) and possibly Monkey Island 1/2 would would work since it does an excellent job of emulating that MIDI intro sound track I'm sure it should be quite compatible. Now another thing that might be interesting to see MUNT do is Adlib and Adlib GOLD compatibility. A lot of the older DOS titles made use of the Adlib MIDI before Sound Blaster was around to add the digitized voices so many could benefit if MUNT for REAL DOS could do Adlib and Adlib GOLD MIDI emulation giving MUNT a dual purpose in REAL DOS. I know you had thoughts about doing a SC-55 add on so MUNT could become a sort of MAME equivalent of a Multi MIDI emulation program instead of just MT-32 based once it has been perfected.

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.

In XP I'm not using a Sound Blaster card it's the onboard Realtek audio and all of what I described in my testing MUNTXP worked fine with those 4 demos I included in the attachment as I tested as many as I could to see which ones worked without DOSBOX being required since the focus was to test the MUNT MT-32 emulation only and not have DOSBOX involved.

Now in 98 Dos Prompt not "REAL DOS" none of those programs were detected at all by the MUNT98. Only inside the DOSBOX did MUNT98 actually pick up the MIDI messages.

Also while in XP MUNT had no timing issues and worked perfectly outside of DOSBOX just using the "Command Prompt". That was where the brunt of my 50+ Demo testings and looping testing over a few days resulted in the top 4 I felt due to compatibility and compact size were the best for MUNT or MT-32 testing under XP and later retested on 98 which only DOSBOX could interact with the MIDIYOKE program but you still had to add all 16 instruments manually into MUNT98 before running the DOSBOX or it didn't work.

If just working on the MUNT98 console side how can we add all 16 instruments instead of 1 at a time manually? Can Munt98 add the option to use Ctrl+A to select all MIDI inputs, or Ctrl for single selection, or Shift for Multi selection be added when selecting the MIDI inputs?

Also after they are added could you create a stored MIDI inputs folder to group them as one MIDI input device and allow saving it so it doesn't forget into by saving it to a regular ASCII text file like MUNTMIDIINPUTS.CFG.

For example the MidiYoke0-15 Instruments had to added manually one at a time due to the way MUNT doesn't allow MultiSelection or Ctrl+A to select ALL.

But if your MUNT98 could implement what MIDIYOKE does maybe it could save a bunch of steps.
Within the 98 MIDI instruments configuration you have to add all 16 channels one at a time for a Custom. The default Microsoft Roland GS Wavetable Synth contains all their own instruments in one easy selection. That's why I was wondering if there was a program to replicate the same thing for a custom instrument to contain all 16 MIDI channels or more for other ones like the SC-55. Then selecting just that one custom instrument which contained all those MIDI channels would be simpler. Then going to your MUNT98 you'd only have to add just that one instrument instead of all 16 MIDIYoke channels or worse if the MIDI device has more channels doing it one at a time is very time consuming. After exiting MUNT98 it forgets it and has to be redone so that's why I've recommended MUNTMIDIINPUTS.CFG to preload stored MIDI instruments in groups and later when you develop the SC-55 it would only be one SC-55 instrument containing all those channels/instruments rolled into one. But the option to preload a MIDI device or instrument set that has been configured should be an option in MUNT98.

I think most of what I describe might be easier to be shown in photo snapshots but let me know if anything is unclear.

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.

The optimization I was talking about was just the MUNT program itself no matter how many cores the OS could handle any MUNT optimization to speed it up without loss of accuracy / authenticity would benefit any OS and any single or multicore computer running it. But as said earlier if there is a way to tap into those unused cores in 98 that would be a nice bonus for this program even dual core users using 98.

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 😉

Yes I know MUNT's goal is accuracy/authenticity which I like also and I have tested the others including the SF2 font types which don't come as close especially using DUNE 2 intro as the source test. 😉
Which is another reason I am excited MUNT 2.2 had done a lot since 1.3 and more interest in making it better.

But even for simplistic use of MT-32 emulation could the original Microsoft Roland GS Wavetable Synth just be overwritten with the MT-32 table versions for testing purposes? I'd like to see how well it replicates minus the ability to load samples like a real MT-32 or MUNT sounds. It would not alter the CPU work load much I'm assuming since it's just playing the MT-32 instruments without synthesizing them like a real MT-32. You could call this branch MUNT 98 Lite for underpowered single core systems.

95DosBox wrote:

But let me try to bring a little more clarity.

The Ultimate goal would be when it becomes possible MUNT and DOSBOX working in "REAL DOS" more specifically 95B or 98/SE DOS known as MS-DOS 7.0/7.1 due to the FAT32 support. This would allow running any early DOS based legacy title that supported the SB or MT-32 to be run without a real SB ISA card nor needing a Roland MT-32 hooked up. The only requirements could be just needing a USB Sound Card for external simplicity. The Video card probably wouldn't need a special video driver to run in "REAL DOS" and probably even the integrated GPUs should work fine in "REAL DOS" without needing a special DOS driver. The question is will DOSBOX for "REAL DOS" work fine in REAL DOS without an additional DOS video driver or could some sort of Bear Windows equivalent universal Video driver be embedded into DOSBOX for "REAL DOS" to avoid that issue. The the next stage is a USB DOS driver for the USB Sound device to interface with DOSBOX for "REAL DOS" which will send the appropriate MIDI signals to MUNT for "REAL DOS".

I'm grateful for the clarification. So, now we can discuss it with more sanity.

The current goal now is getting MUNT98 perfected for ease of use installation similar to XP.

Other Operating Systems I've tested such as Vista 64-bit and later OS were for experimental purposes to see what problems if any existed for MUNT and DOSBOX and only the MIDI Mapper from Coolsoft was required to resolve it. I never had any plans on testing it on later than XP OS due to the size of the installed 64-bit OS was usually 16GB or larger. All that wasted space on a cheap USB storage device could be consumed by DOS programs instead.

I don't think you need the Coolsoft or any other sort of MIDI mapper to route MIDI stream from DOSBox to munt. This is not an issue with DOSBox at all since the MIDI port it uses is configurable. You can easily change the port number using midiconfig command (and even select the port by name in the recent SVN versions). But even finding the port number is easy with command "mixer /listmidi". The Vista MIDI mappers are only necessary when the MIDI application has no means to select the output port. These include the damn Windows Media Player, btw 😀 So, this shouldn't be a problem with the proposed setup.

But for the easiest use of your MUNT and DOSBOX combined XP 32-bit is the most graceful and easiest solution.

True. But again, only if you lock yourself to stick with Microsoft systems. Trust me, these are not the best. Specifically, I wish Windows 95 never existed because of its famous instability but it won the market and defeated OS/2. So yes, compared to Win98, XP is a great deal because it is not only provide for better support (and will continue to be better supported in future) but also more stable.

But there are advantages of having a smaller OS size and being able to fit on a USB and boot in just one second for regular W98 SE DOS is possible. So if you take in the fact < 1MB to install the W98 SE DOS and then running the MUNT port that is "REAL DOS" based and then if a DOSBOX port can be run in "REAL DOS" then you will have the best of both running in a very compact environment probably within 10MB -> 100MB total. Then the rest of the space could be for all your old legacy DOS software. Even something like 16GB could store probably more than enough DOS titles that existed that were heavily MIDI based. Most CD titles moved onto to audio tracks so those are best served on more modern OS anyhow.

Here, I object. I completely fail to understand the disk size argument. If you can avoid loads of problems just by buying a larger USB stick for a few bucks, then it's a reasonable trade-off. Besides, there are USB-HDD of 1TB and more. Sorry, but I'm not an enthusiast of stripping software size down to absolute minimum. This approach usually leads to non-portable unmaintainable code in assembly which will quickly become out of use and forgotten. Though, there are of course ways to get rid of extra fat modern OSes usually suffer from, that's right. But most "lite" builds of Windows 98 or XP are usually bad. All goes well until you need to install some software that requires missing components. Usually this is hard to debug and fix. Instead of hacking Windows systems, I'd recommend to look closer to Linux distros. Making VCPI drivers for DOS for modern hardware is indeed a fun but I find a little sense in reinventing the wheel. Modern Linux kernel likely provides support for all sorts of hardware you can find on a desktop systems. Moreover, you are not limited in using only x86/amd64 arch. I'd better suggest to select a minimal Linux distro like Knoppix. You should go further and only keep necessary components that are required to run DOSBox and munt. Perhaps, you can even reduce the kernel size. Interesting task would be to make DOSBox to run in a Linux console, so you could get rid of X11. Then you'll get a Live system likely of less size than Win 95 with much better hardware support and more features.

One thing you mentioned about the MUNT emulation I was curious about since at the moment is very CPU intensive like DOSBOX but maybe there is a way to tap into the extra cores that Windows 98 doesn't access and are sitting idle? That would prove useful on quad core systems then you could keep the MHz down to 800 on all the cores keeping the heat down. If this could happen then MUNT98 would be very useful on modern computers lacking both ISA and PCI slots and using a simple USB Audio device which is a PNP device requiring no extra drivers.

Well, that is again about re-writing things in DOS which already exist in Linux. Linux kernel handles SMP well, why not use it? The real pure DOS gives very minor advantage in compatibility compared to DOSBox emulation. Moreover, you can boot and run authentic DOS files. Fairly saying, I doubt one can make the necessary support of modern hardware in DOS better than Linux and DOSBox do already. These things are VERY time & cost consuming to be done properly.

Now you bring up some good points of question why would someone try to install say 98, DOSBOX, and MUNT on a modern day computer instead of XP or XP PE as you suggested. Compactness would be the biggest advantage and I do foresee some issues for installing XP PE and W7 PE on newer chipsets. I haven't tested any XP PE or W7 PE so if you have any recommended ones I'll do some more testing. But the biggest problem I see is the eHCI ports being removed so xHCI is not native to XP or W7 so I'm not sure how your XP PE will react or even boot anymore on those modern chipsets lacking the eHCI. Try testing your portable PE OS on a Z170/Z270 Intel USB 3.0 port and see if it can self boot.

I played with Windows XP PE ages ago. But since Windows Vista PE became available, I quickly forgot about the former. Unlike Windows XP PE environment (which is text-based in official builds), Windows Vista PE is an official build that contains GUI and all necessary hardware support to run Windows setup. This means, that you can pick the PE environment from the latest Windows 10 release, and it will support loads of modern devices. Again, no activation or serial numbers bullshit is built in. Official tools from Microsoft allows you to customise the PE environment and add drivers and applications (e.g. DOSBox). Then all this stuff is packed. For instance, I have an old recovery USB with Windows 7 PE handy. I added about 20 third party apps, so I need not to type characters in a black command line window 😀 And all this nice thing fits into 160 MB. Though, it requires 512MB of RAM to work. But again, with Linux you have much more possibilities to customise your live system.

The 98 DOS will boot on either USB 1.1 to USB 3.1 ports without additional USB drivers. So this gives it an extra leg up on newer hardware on top of not requiring to register/activate the OS or more bloat. I know you brought up XP PE as not needing to activate but isn't PE more of a bare bones lacking some vital XP functions? You say it works with DOSBOX and MUNT without problems? Can you run any XP SP3 Compatible program on it or is it relegated to the XP non SP compliant programs? Can you combine the 98 boot with the XP PE and use the NT Boot Loader? Or is the XP PE its own self booter and stand alone you can't add it it as part of the BOOT.INI for the XP Boot loader?

Yes, I think a dual boot is possible. But still I see no reason to have multiple systems onboard which would contradict with the idea described above.

But there are still a lot of native DOS games that can run outside of DOSBOX and use the MUNT running in the background which it did fine in XP but not in 98.

To be fair, I'm lazy to compose the list of games which runs too fast or too slow without DOSBox. You have to trust me, it is not a single game. This problem is one of the main reasons because VDMSound is dead (after dropping 16-bit support in amd64 systems).

So a possible SoftMPU / MUNT for "REAL DOS" merger would be helpful to run older games that supported the MT-32 (mostly Sierra titles) and possibly Monkey Island 1/2 would would work since it does an excellent job of emulating that MIDI intro sound track I'm sure it should be quite compatible. Now another thing that might be interesting to see MUNT do is Adlib and Adlib GOLD compatibility. A lot of the older DOS titles made use of the Adlib MIDI before Sound Blaster was around to add the digitized voices so many could benefit if MUNT for REAL DOS could do Adlib and Adlib GOLD MIDI emulation giving MUNT a dual purpose in REAL DOS. I know you had thoughts about doing a SC-55 add on so MUNT could become a sort of MAME equivalent of a Multi MIDI emulation program instead of just MT-32 based once it has been perfected.

Really not planned. I'm sure DOSBox is already more than that 😉 It contains good emulation of SBs, GUS, Adlib and tons of other old hardware. There is a simple way to add mt32emu as well, and you'll get them all now and for free!

Now in 98 Dos Prompt not "REAL DOS" none of those programs were detected at all by the MUNT98. Only inside the DOSBOX did MUNT98 actually pick up the MIDI messages.

Not correct statement. Munt does not detect anything that runs inside a DOS session. The virtual machine either provides a direct access to the hardware for a game or emulates that hardware. Munt is quietly sitting waiting for a Windows application to connect via a Windows MIDI port to it. DOSBox does the emulation right, and (provided that it is configured correctly) connects to munt. The same way VDMSound works. It emulates old sound hardware, and specifically, routes MIDI data to a Windows application for synthesising. If your sound card driver does not emulate ports of MPU-401, it won't ever send MIDI messages to munt. No magic.

Also while in XP MUNT had no timing issues and worked perfectly outside of DOSBOX just using the "Command Prompt". That was where the brunt of my 50+ Demo testings and looping testing over a few days resulted in the top 4 I felt due to compatibility and compact size were the best for MUNT or MT-32 testing under XP and later retested on 98 which only DOSBOX could interact with the MIDIYOKE program but you still had to add all 16 instruments manually into MUNT98 before running the DOSBOX or it didn't work.

What I really really don't understand is why you need 16 MIDI ports. My current setup I use to route MIDI from DOSBox to mt32emu-qt in a VM with Windows 98 SE:
1. MIDI Yoke installed and configured with 1 (!) port.
2. The default MIDI device is left unchanged, and it is the virtual SB MIDI port.
3. DOSBox config contains midiconfig=1 in [midi] section, so it sends MIDI to MIDI Yoke.
4. mt32emu-qt is started and 1 MIDI-in port is opened to get MIDI data from MIDI Yoke.
--------
That's all. Of course, mt32emu-qt could be more clever and have a possibility to open a MIDI-in port automatically. But I've already created an issue about it at SourceForge to never forget that 😉

The optimization I was talking about was just the MUNT program itself no matter how many cores the OS could handle any MUNT optimization to speed it up without loss of accuracy / authenticity would benefit any OS and any single or multicore computer running it. But as said earlier if there is a way to tap into those unused cores in 98 that would be a nice bonus for this program even dual core users using 98.

Munt core contains no bloated code, be sure. Everything it does is just to do the synthesis in a way we consider optimal. Unfortunately, further optimisations are often system-specific, so I don't think it is a must for now. But these are possible for sure. Most obvious speed improvement would be the explicit use of SSE. But this code won't be cross-platform. Besides, some of C compilers already do vectorisation automatically. And lastly, the synth core is not finished yet to start polishing.

But even for simplistic use of MT-32 emulation could the original Microsoft Roland GS Wavetable Synth just be overwritten with the MT-32 table versions for testing purposes? I'd like to see how well it replicates minus the ability to load samples like a real MT-32 or MUNT sounds. It would not alter the CPU work load much I'm assuming since it's just playing the MT-32 instruments without synthesizing them like a real MT-32. You could call this branch MUNT 98 Lite for underpowered single core systems.

Most notable attempt to emulate MT-32 this way was actually made by Roland. Their VSC thing contains the MT-32 sample bank, so it can sound correctly though not authentic. Also, SB AWE32 also had such a sample bank as well as GUS. Plus, you can simply make an instrument mapping to General MIDI instruments like it is done in VDMSound. Either way, it will be acceptable for playing MIDI tunes composed to use standard patches only. Any custom instrument set the game loads to MT-32 requires to change the mapping. This is the main reason for munt to exist 😉

sergm wrote:

But let me try to bring a little more clarity.

I don't think you need the Coolsoft or any other sort of MIDI mapper to route MIDI stream from DOSBox to munt. This is not an issue with DOSBox at all since the MIDI port it uses is configurable. You can easily change the port number using midiconfig command (and even select the port by name in the recent SVN versions). But even finding the port number is easy with command "mixer /listmidi". The Vista MIDI mappers are only necessary when the MIDI application has no means to select the output port. These include the damn Windows Media Player, btw 😀 So, this shouldn't be a problem with the proposed setup.

Ahh a new useful DOSBOX command to use for troubleshooting. Strange is I checked the MIDI list and it shows the MT-32 Synth Emulator as 0.

On my DOSBOX.conf I have it set to 1 and without this it didn't work prior and defaulted to the MS Roland GS WT Synth.

This Coolsoft just helps select the default MIDI output device since it's missing at least from a recent Vista 64-bit test. I don't use Vista and later for DOSBOX but since I was testing out your Munt with DOSBOX I wanted to go ahead and see if what other users were complaining about needing Coolsoft's program to fix the MIDI device issue and it was true at least on my clean Vista 64-bit setup. If I didn't use the Coolsoft program it would default to the MS Roland GS WT Synth like on XP.

Maybe trying out the 0-3 could have solved it in the DOSBOX.conf and I didn't test them all however after I got Munt working in XP this was the method I used but I also had the default MIDI output device selected in XP which didn't use MUNT until the DOSBOX.conf file had this added midiconfig=1 because there was no MUNT working prior.

True. But again, only if you lock yourself to stick with Microsoft systems. Trust me, these are not the best. Specifically, I wish Windows 95 never existed because of its famous instability but it won the market and defeated OS/2. So yes, compared to Win98, XP is a great deal because it is not only provide for better support (and will continue to be better supported in future) but also more stable.

I skipped 95 at least for primary use several decades ago but 98 is probably the best of that generation. I haven't had much experience using ME quite yet to give a full eval. 95A had a FAT16 limitation that existed and heavy BSOD issues from being a beta tester. 98's SE is for the most part much more stable than 95 since the drivers were matured by the end of life although not as stable was Windows 2000 and later NT versions. But XP is my preferred OS as you said for stability reasons and a reason I worked on getting Z170 and Z270 working on XP for a friend. I have noticed differences between 98 and XP's way of treating DOS programs in their own "Dos Prompt" and "Command Prompt" windows. OS/2 was an interesting branch but I think it was simply too big then to have succeeded. Maybe had it come out on 3 floppy disks instead or waiting for a CD-rom release it might had more exposure. I think it took over half an hour to install all the floppy disks which 95 also had their own floppy disk armada when it came out. I think the biggest pet peeve then was the DOS compatibility was not as good as MS-DOS or the 95/98 MS-DOS 7.X. From a business perspective I'm sure this didn't impact those customers. I think on the gamer's side it hurt them but if gaming wasn't so prevalent then and DOS was all business I think OS/2 probably would have taken off. Maybe they should have made a more a compact OS/2 version and distributed it for free and charged more for the subsequent versions once it got adopted.

Here, I object. I completely fail to understand the disk size argument. If you can avoid loads of problems just by buying a larger USB stick for a few bucks, then it's a reasonable trade-off. Besides, there are USB-HDD of 1TB and more. Sorry, but I'm not an enthusiast of stripping software size down to absolute minimum. This approach usually leads to non-portable unmaintainable code in assembly which will quickly become out of use and forgotten. Though, there are of course ways to get rid of extra fat modern OSes usually suffer from, that's right. But most "lite" builds of Windows 98 or XP are usually bad. All goes well until you need to install some software that requires missing components. Usually this is hard to debug and fix. Instead of hacking Windows systems, I'd recommend to look closer to Linux distros. Making VCPI drivers for DOS for modern hardware is indeed a fun but I find a little sense in reinventing the wheel. Modern Linux kernel likely provides support for all sorts of hardware you can find on a desktop systems. Moreover, you are not limited in using only x86/amd64 arch. I'd better suggest to select a minimal Linux distro like Knoppix. You should go further and only keep necessary components that are required to run DOSBox and munt. Perhaps, you can even reduce the kernel size. Interesting task would be to make DOSBox to run in a Linux console, so you could get rid of X11. Then you'll get a Live system likely of less size than Win 95 with much better hardware support and more features.

Yes I prefer a fully intact OS although in 98's situation I installed the Full Size but installing the Compact Size would reduce the foot print from 500MB to somewhere around 200MB or so I think. Probably more components could be removed today that are unnecessary if the use is just for the gaming engine. This doesn't affect 98's compatibility. Only going to 98Lite there may be problems unless you are genuinely removing stuff that is not OS related like media files. Even the Compact 98 size is usable as I used to use that version and just added a few of the components I needed. In the Full version they add a couple of large components that aren't vital but I installed them to just to get the entire feel of the OS as it was meant to be experienced at the time. The Full Version of 98 runs extremely fast today even though only one core is utilized.

I'm not sure how many of these Linux boot possibilities will fit on a 1.44MB floppy disk. The 98 idea I think would be easier to install without adding a special video card that has the right OS drivers. There will be a point where XP and W7 drivers will not be available on newer graphics cards however when booting to DOS it will work without a video driver. And the other issue I mentioned is eHCI ports will cause most of these bootable PE's to fail on modern systems.

I haven't played around with Linux as much as you to give a proper eval. The Linux idea would be interesting but with so many flavors and so many different hardware possibilities how would it accommodate with the appropriate drivers? Has Linux developed universal video and audio drivers that works with DOSBOX and MUNT and what about the eHCI removal issue can it be booted off newer chipsets? As far as I can tell only Windows 8.0 and up could boot directly off xHCI ports natively which should apply to the PE version. Although I'm not a fan of 8.0 I'm curious if your XP, Vista, and W7 PE can be booted properly on the xHCI ports?

I don't think porting DOSBOX and MUNT to work in "REAL DOS" would reinventing the wheel but fixing the wheel if DOS could once again run these programs as intended but with the help of emulating the SB and MT-32 and possibly other sound devices down the road.

Also one final thing that could be possible with 98 is once booted into "REAL DOS" you could set up a Ramdrive and have the 98 OS run off the Ramdrive and set up another Ramdrive to store a good chunk of your DOS software. Then you could in theory remove the USB flash drive but just leave the USB audio device installed. Later when someone with the know how can tap into the Intel HD iGPU and AMD iGPU they could actually use the HDMI audio out for the sound output then that would remove the need for a separate USB audio device making everything run on pure RAM only. There's nothing more portable than that and you could go to any machine and just set it boot off the USB and you wouldn't have to tamper with opening up the computer at all. While USB flash drives have gotten a bit cheaper over the years it doesn't mean the load time will be reduced. If DOS boots in less than one second how long does the typical PE take to boot up to the desktop?

Can you remove the USB device after your WIN PE is loaded?

Have you tried making Ramdrives inside the WINPE or a way to load the WINPE to run off a Ramdrive? That would be very interesting.

Well, that is again about re-writing things in DOS which already exist in Linux. Linux kernel handles SMP well, why not use it? The real pure DOS gives very minor advantage in compatibility compared to DOSBox emulation. Moreover, you can boot and run authentic DOS files. Fairly saying, I doubt one can make the necessary support of modern hardware in DOS better than Linux and DOSBox do already. These things are VERY time & cost consuming to be done properly.

It's not necessarily about whether "Real DOS" is more compatible than say using Linux although I enjoy using the natural DOS CLI. Because either way the end result is still using "DOSBOX" and "MUNT". But I would think "DOSBOX" and "MUNT" if ported to "REAL DOS" should run faster due to less overhead. I remember running DOS and then running Windows 3.1 and running the same DOS program within it. You could see how much slower it was running the DOS program within Windows 3.1. Now this was during the old 486 days so maybe it isn't as noticeable on modern computers. But the real advantage could be faster boot up times and possibly faster or more stable emulation on slower machines. Now if DOSBOX and MUNT for "REAL DOS" could both use more than 1 core and all the cores of the CPU you would see a drastic improvement and probably the most stable DOS emulation possible.

Yes it could be very time consuming to program and thus the DOS "Holy Grail" and with that their name would be sealed in history just as Bill Gates is to Microsoft. But what cost are you referring? I don't think the cost would change if you have an old copy of 98 in possession. You won't necessarily be buying any new OS to use it. Although if you couldn't afford to buy a $10 used copy of 98 off eBay then FreeDOS would be an alternative. The goal might seem trivial to you but whomever gets this done first will be solidified in the history books. And so far everything I've tested MS-DOS 7.1 has worked in everything including the latest chipsets so once this final throne is taken no one is going to care if DOSBOX or MUNT works in some new Linux distro or any other newer Windows OS as there will always be a new Linux or Windows OS to take its place but DOS is the originator. Although maybe some MAC users would have a fit at first but from what I recall all recent MACs are Intel CPU based so they should also be able to boot and use it as well. 😉

I played with Windows XP PE ages ago. But since Windows Vista PE became available, I quickly forgot about the former. Unlike Windows XP PE environment (which is text-based in official builds), Windows Vista PE is an official build that contains GUI and all necessary hardware support to run Windows setup. This means, that you can pick the PE environment from the latest Windows 10 release, and it will support loads of modern devices. Again, no activation or serial numbers bullshit is built in. Official tools from Microsoft allows you to customise the PE environment and add drivers and applications (e.g. DOSBox). Then all this stuff is packed. For instance, I have an old recovery USB with Windows 7 PE handy. I added about 20 third party apps, so I need not to type characters in a black command line window 😀 And all this nice thing fits into 160 MB. Though, it requires 512MB of RAM to work. But again, with Linux you have much more possibilities to customise your live system.

I agree with you if Vista has a built in GUI and my preferred 64-bit version to use if it still retains the original Vista desktop user interface with the ability to revert to Classic mode. Glad to know the PEs don't require any sort of activation. I've only used recovery ones that are made within Windows so I'm not sure if you're talking about the same bare bones recovery PE as I didn't think those could be customized. I kind of suspected there wouldn't be any activation but I'm not sure how advanced these PE builds are and what kind of programs they are capable of running? For example could the Vista PE add the SP2 and the DX11 patches on top of it?

You are also correct about the RAM usage issue. 512MB of RAM used does seem rather low for the W7 PE. Regular Vista 64-bit seems to hog about 4.7GB minimal to even boot properly to the desktop but safely runs with 5.7GB of RAM. I tried squeezing as much of the remaining memory for the Ramdrive. So if your PE uses only 512MB of RAM it must be missing a lot of components to run a full blown 64-bit SP2 DX11 program. But it can run DOSBOX and MUNT with a 160MB PE so it does prove useful.

As for the memory comparison DOS would barely use the first 640KB or less than 1MB. I'm not sure how much the "DOSBOX" and "MUNT" for "REAL DOS" might end up using memory wise but even if it had to use XMS memory I can't see it both using more than 64MB total? The first 4GB is detected by 98 "REAL DOS" so whatever remains could be reallocated for a large Ramdrive so at worst you'd still have room for a good 3.0GB to 3.5GB 32-Bit Ramdrive.

To be fair, I'm lazy to compose the list of games which runs too fast or too slow without DOSBox. You have to trust me, it is not a single game. This problem is one of the main reasons because VDMSound is dead (after dropping 16-bit support in amd64 systems).

Don't worry I know there is a huge list of incompatible DOS programs which was one of the issues of me not switching to 2000 and XP completely but dual booting with 98. Even during the demo testing the King's Quest IV Demo had a bug where it ran too fast but I was able to modify it enough to be used as a MT-32 test program despite the speed issues.

Really not planned. I'm sure DOSBox is already more than that 😉 It contains good emulation of SBs, GUS, Adlib and tons of other old hardware. There is a simple way to add mt32emu as well, and you'll get them all now and for free!

Yes DOSBOX would be more than that but at the moment DOSBOX for "REAL DOS" doesn't exist but if somehow your MUNT for "REAL DOS" could exist it will still be an advancement but once "both" have been ported to "Real DOS" is when the real magic of the final Holy Grail is unleashed.

Not correct statement. Munt does not detect anything that runs inside a DOS session. The virtual machine either provides a direct access to the hardware for a game or emulates that hardware. Munt is quietly sitting waiting for a Windows application to connect via a Windows MIDI port to it. DOSBox does the emulation right, and (provided that it is configured correctly) connects to munt. The same way VDMSound works. It emulates old sound hardware, and specifically, routes MIDI data to a Windows application for synthesising. If your sound card driver does not emulate ports of MPU-401, it won't ever send MIDI messages to munt. No magic.

In XP the Realtek onBoard audio has no problem doing this in the "Command Prompt". I don't think this is a Sound Blaster issue. But perhaps 98 is different in the way it detects or receives the MIDI messages. But again even those same 3 demos did send the proper MIDI signals to the MS Roland GS Wavetable Synth and this was prior to even using the MidiYoke. So there must be a way for Munt98 to tap directly to receive MIDI messages in the 98 "Dos Prompt" windows just like it does in XP for the "Command Prompt" windows.

What I really really don't understand is why you need 16 MIDI ports. My current setup I use to route MIDI from DOSBox to mt32emu […]
Show full quote

What I really really don't understand is why you need 16 MIDI ports. My current setup I use to route MIDI from DOSBox to mt32emu-qt in a VM with Windows 98 SE:
1. MIDI Yoke installed and configured with 1 (!) port.
2. The default MIDI device is left unchanged, and it is the virtual SB MIDI port.
3. DOSBox config contains midiconfig=1 in [midi] section, so it sends MIDI to MIDI Yoke.
4. mt32emu-qt is started and 1 MIDI-in port is opened to get MIDI data from MIDI Yoke.
--------
That's all. Of course, mt32emu-qt could be more clever and have a possibility to open a MIDI-in port automatically. But I've already created an issue about it at SourceForge to never forget that 😉

Perhaps I am configuring the MIDIYoke wrong or something in the configuration of the MIDI channels in 98. I never had to do this before in XP. But without doing what I had done I wasn't able to receive any of the MIDI signals to MUNT98 until all 16 channels were added individually. Maybe you have better instructions on what to do in your 98 MIDIYOKE / MUNT98 setup. I've added photos of what mine looks like when working maybe you will find the mistake.

Was there another MIDIYoke program you were using or a better one that configures all the 16 channels easier in one stroke?

Munt core contains no bloated code, be sure. Everything it does is just to do the synthesis in a way we consider optimal. Unfortunately, further optimisations are often system-specific, so I don't think it is a must for now. But these are possible for sure. Most obvious speed improvement would be the explicit use of SSE. But this code won't be cross-platform. Besides, some of C compilers already do vectorisation automatically. And lastly, the synth core is not finished yet to start polishing.

Yes keep polishing it for now. I wasn't sure if Munt 2.2 was the final revision.
Don't worry about further optimization until the synth core is 1:1 100%.
I'm just talking way down the road when MUNT has reached perfection that a real MT-32 can't be differentiated.
There are still many ideas I would like to see the chance to improve the MUNT interface along the way.

Most notable attempt to emulate MT-32 this way was actually made by Roland. Their VSC thing contains the MT-32 sample bank, so it can sound correctly though not authentic. Also, SB AWE32 also had such a sample bank as well as GUS. Plus, you can simply make an instrument mapping to General MIDI instruments like it is done in VDMSound. Either way, it will be acceptable for playing MIDI tunes composed to use standard patches only. Any custom instrument set the game loads to MT-32 requires to change the mapping. This is the main reason for munt to exist 😉

In other words nothing but MUNT. 😊

95DosBox wrote:

Ahh a new useful DOSBOX command to use for troubleshooting.

Well, these two commands I mentioned are old and famous. And they have never failed before for me. Please investigate why this fails for you.

I'm not sure how many of these Linux boot possibilities will fit on a 1.44MB floppy disk.

You'll be surprised, but I had an old ISOLINUX-based recovery CD cd080526 that is only 3643KB. It can reset passwords in Windows NT if occidentally have forgotten. It's a completely stripped down Linux that allows to run in console a couple of programs built in. Something like that might probably be what you want.

The 98 idea I think would be easier to install without adding a special video card that has the right OS drivers. There will be a point where XP and W7 drivers will not be available on newer graphics cards however when booting to DOS it will work without a video driver. And the other issue I mentioned is eHCI ports will cause most of these bootable PE's to fail on modern systems.

I missed the point. As I understand it, DOS and Windows 9x that runs on top of the DOS core only boots fine while the system BIOS (or BIOS emulation in EFI of today's 64-bit systems) provide necessary support. I have a 800MHz Celeron with 4 USB1.1 ports which cannot boot from any USB device, until BIOS is upgraded. BTW, some weird EFI I've seen (mostly in laptops) do not allow to boot DOS at all until you change an option Legacy/UEFI in the setup. Though, all the other EFI I touched do provide support for both boot methods seamlessly. Similarly, Windows PE will boot so long the BIOS or UEFI USB boot works. Next, when the NT kernel is initialised, it needs a USB driver to work with the device. Why? Because in your lovely DOS accesses to USB device are 16-bit and thus terribly slow. In Windows 10 PE all necessary support for USB should be present already. Otherwise you couldn't install Windows 10 on the system and M$ wouldn't live with that. But again, you can add necessary USB/SCSI/SATA or whatever else drivers in a Windows XP PE build provided they exist and work in a normal Windows XP installation.

Similar situation is with video. DOS is only able to use the video card if the video BIOS provides support the particular DOS application needs. For example, high-resolution graphics modes may be available via VESA interface or may be not (depending on the video BIOS). There is nothing you can do but write a dedicated video driver for that video card. Though, I think the very basic VGA modes are almost always supported, so old games should run just fine (if at all).

I haven't played around with Linux as much as you to give a proper eval. The Linux idea would be interesting but with so many flavors and so many different hardware possibilities how would it accommodate with the appropriate drivers? Has Linux developed universal video and audio drivers that works with DOSBOX and MUNT and what about the eHCI removal issue can it be booted off newer chipsets?

Oh, don't worry. No matter how huge the number of distros around, they are all based on the very same Linux kernel (well, on different versions and often with patches). The number of hardware the kernel supports is impressive. I think you should definitely give it a try. Perhaps, Ubuntu is the best Live CD/USB to start with and having some experience you can proceed in researching further. Ubuntu does allow quite convenient way to build a Live system.

As far as I can tell only Windows 8.0 and up could boot directly off xHCI ports natively which should apply to the PE version. Although I'm not a fan of 8.0 I'm curious if your XP, Vista, and W7 PE can be booted properly on the xHCI ports?

Just yesterday, booted off my old Windows 7 32-bit PE. Intel Pentium G4400 Skylake, Northbridge rev. 07, Southbridge PCH rev. 31, xHCI.

I don't think porting DOSBOX and MUNT to work in "REAL DOS" would reinventing the wheel but fixing the wheel if DOS could once again run these programs as intended but with the help of emulating the SB and MT-32 and possibly other sound devices down the road.

Hmm, I still think it would. No need to make yet another OS on the DOS base. Enough. Windows 3.x / 9x experience taught this is not a good idea. The only sane way I would imagine is porting monolithic DOSBox to a DOS extender like Watcom or DOS4GW with adding necessary support to access video card and HDMI / USB audio hardware directly. In 32-bit it'd be fast enough, and within DOSBox it'd be very compatible. I think this is the only way to run a game with any hardware emulation that requires a clean i386 real mode to start. Again, it'd be easy to slow down / speed up games. But considering tiny sizes possible with systems based on Linux kernel and readily available support for tons of existing hardware, I'd go the latter way.

Also one final thing that could be possible with 98 is once booted into "REAL DOS" you could set up a Ramdrive and have the 98 OS run off the Ramdrive and set up another Ramdrive to store a good chunk of your DOS software. Then you could in theory remove the USB flash drive but just leave the USB audio device installed. Later when someone with the know how can tap into the Intel HD iGPU and AMD iGPU they could actually use the HDMI audio out for the sound output then that would remove the need for a separate USB audio device making everything run on pure RAM only. There's nothing more portable than that and you could go to any machine and just set it boot off the USB and you wouldn't have to tamper with opening up the computer at all. While USB flash drives have gotten a bit cheaper over the years it doesn't mean the load time will be reduced. If DOS boots in less than one second how long does the typical PE take to boot up to the desktop?

Can you remove the USB device after your WIN PE is loaded?

Have you tried making Ramdrives inside the WINPE or a way to load the WINPE to run off a Ramdrive? That would be very interesting.

FYI: Windows PE since Vista boots from a ramdrive. Moreover, it's a compressed ramdrive. After booted up, you can safely remove the PE USB stick or CD. The load time is a few seconds to minutes. This mostly depends on how shitty the system BIOS is providing access to a USB-HDD device. In the latter case, a bootable CD is a viable alternative. In Windows XP based PE builds, ramdrives are also heavily used since having booted from a CD you cannot do much without it. But a compressed WIM (or a ZIP folder) is a nice place to keep games. Not mentioning Linux Live CDs which are also compressed images and the native kernel support allows more ramdrives to be set up with ease.

I agree with you if Vista has a built in GUI and my preferred 64-bit version to use if it still retains the original Vista desktop user interface with the ability to revert to Classic mode. Glad to know the PEs don't require any sort of activation. I've only used recovery ones that are made within Windows so I'm not sure if you're talking about the same bare bones recovery PE as I didn't think those could be customized. I kind of suspected there wouldn't be any activation but I'm not sure how advanced these PE builds are and what kind of programs they are capable of running? For example could the Vista PE add the SP2 and the DX11 patches on top of it?

In the official Windows PE, there are many limitations, that's right. It's only intended to setup normal Windows installation plus a couple of recovery tricks, no more. We should start with mentioning that official Windows PE for NT4, 2K and XP provided no GUI at all. But those "extended" PE builds I mentioned above add many features to the official PE, so you can even play 3D games finely. As for the official Windows PE for Vista+, it lacks OpenGL and DirectX support. I believe these can be added, though for DOSBox this is not crucial (though unpleasant, yeah). To run on any official PE, DOSBox needs to be recompiled without OpenGL support. Also note, a PE for 64-bit Windows provides no support for 32-bit applications, btw 😀 So, better be stick with a 32-bit PE.

As for the memory comparison DOS would barely use the first 640KB or less than 1MB. I'm not sure how much the "DOSBOX" and "MUNT" for "REAL DOS" might end up using memory wise but even if it had to use XMS memory I can't see it both using more than 64MB total?

Be sure, hardware emulation will cost RAM. At the very least, you need RAM to load DOSBox itself and the ROM images for MT-32 emulation.

Even during the demo testing the King's Quest IV Demo had a bug where it ran too fast but I was able to modify it enough to be used as a MT-32 test program despite the speed issues.

🤣

Yes DOSBOX would be more than that but at the moment DOSBOX for "REAL DOS" doesn't exist but if somehow your MUNT for "REAL DOS" could exist it will still be an advancement but once "both" have been ported to "Real DOS" is when the real magic of the final Holy Grail is unleashed.

See, most of us do not need DOSBox for real DOS. Rebooting each time you'd want to play a game is not an option. Building a DOS-based PC on a newest hardware also makes no sense, it's just a waste of resources. DOSBox is right now more than suitable. It's truly portable, unlike those BIOS+DOS setups you have in mind. You can compile and launch DOSBox in virtually any 32-bit GUI-enabled system, so it could be ported in theory even to DOS extended, if only DOS provided minimal hardware support for required hardware.

In XP the Realtek onBoard audio has no problem doing this in the "Command Prompt". I don't think this is a Sound Blaster issue. But perhaps 98 is different in the way it detects or receives the MIDI messages. But again even those same 3 demos did send the proper MIDI signals to the MS Roland GS Wavetable Synth and this was prior to even using the MidiYoke. So there must be a way for Munt98 to tap directly to receive MIDI messages in the 98 "Dos Prompt" windows just like it does in XP for the "Command Prompt" windows.

In XP, the DOS virtual machine does the routing of MIDI for us. It contains a poor MPU-401 emulation in UART mode, so it is able to capture MIDI stream from a game and send it to the default Windows MIDI device. With Windows 9x things are quite different. If your audio driver is WDM based, it may easily add similar emulation via the miniport driver that WDM already provides. Or may not. Or it may send the MIDI stream to the internal synth instead. Depends on the driver. I'd suggest you to look at the VDMSound port for Windows 9x if you're still interested. Hopefully, it is exactly what you want. And let me remind you that mt32emu can (and actually should) be added to DOSBox. I don't think it'd be hard to get a SVN DOSBox build for Windows 9x 😉 Adding any nice graphical features to the monolithic DOSBox+mt32emu seems to be an easier task than dealing with MIDI routing in case VDMSound works not great.

Perhaps I am configuring the MIDIYoke wrong or something in the configuration of the MIDI channels in 98.

That's quite possible.

Was there another MIDIYoke program you were using or a better one that configures all the 16 channels easier in one stroke?

No, this is the only one I've worked with that supported Windows 9x. The rest requires Windows XP.

Yes keep polishing it for now.

I'm on it 😉

Update: With VMDSound installed, both Adlib emulation and MIDI routing works fine in the VM with Windows 98 SE. But, how shitty all this works...

sergm wrote:

I missed the point. As I understand it, DOS and Windows 9x that runs on top of the DOS core only boots fine while the system BIOS (or BIOS emulation in EFI of today's 64-bit systems) provide necessary support. I have a 800MHz Celeron with 4 USB1.1 ports which cannot boot from any USB device, until BIOS is upgraded. BTW, some weird EFI I've seen (mostly in laptops) do not allow to boot DOS at all until you change an option Legacy/UEFI in the setup. Though, all the other EFI I touched do provide support for both boot methods seamlessly. Similarly, Windows PE will boot so long the BIOS or UEFI USB boot works. Next, when the NT kernel is initialised, it needs a USB driver to work with the device. Why? Because in your lovely DOS accesses to USB device are 16-bit and thus terribly slow. In Windows 10 PE all necessary support for USB should be present already. Otherwise you couldn't install Windows 10 on the system and M$ wouldn't live with that. But again, you can add necessary USB/SCSI/SATA or whatever else drivers in a Windows XP PE build provided they exist and work in a normal Windows XP installation.

Similar situation is with video. DOS is only able to use the video card if the video BIOS provides support the particular DOS application needs. For example, high-resolution graphics modes may be available via VESA interface or may be not (depending on the video BIOS). There is nothing you can do but write a dedicated video driver for that video card. Though, I think the very basic VGA modes are almost always supported, so old games should run just fine (if at all).

I'm not sure which generation the Celeron you have didn't boot off the USB. It could be P3 days USB booting wasn't standardized just yet.
The P4 I was using has USB 1.1 and USB 2.0 ports. Back in the day I wasn't using USB much but it does boot 98 off the USB with no issues. Although on the P4 USB 2.0 was much slower than on a Ivy Bridge. Drastic boot up time difference. It almost seems like USB 2.0 in the past was somehow slower than today's USB 2.0 even underclocking the system and reducing the cores to 1.
So far on all my systems not one has trouble booting to DOS. This includes booting off a USB floppy drive or USB device. I do have a Ivy Bridge laptop around that I could test to see if this changed but I have a feeling it should work just like the desktop version. What generation laptop did you test that couldn't boot to DOS via USB? Was this Intel or AMD?

As for W10PE yes that would be a viable option for not dealing with xHCI headaches or slipstreaming the USB drivers before hand. Also note what is the size of W10PE? Another thing I noticed was the bootloader was changed so if the PE acts like a real partition then maybe it could be made into a MultiOS boot device. Again this experimenting will take time but I'll keep this on the side to investigate down the road.

I want to focus on the improvement of Munt especially the 98 installation. I will investigate these alternatives you mentioned more in depth later after Munt 98 has improved to XP's level of ease of use. 😀

Just yesterday, booted off my old Windows 7 32-bit PE. Intel Pentium G4400 Skylake, Northbridge rev. 07, Southbridge PCH rev. 31, xHCI.

Your custom PE must have slipstreamed the xHCI drivers for your MB. Try installing a clean original W7 DVD off a USB optical drive. You will find it cannot install. The only other way it to use a real internal SATA optical drive but you will have to slipstream the xHCI drivers onto a new W7 DVD. Fortunately Intel xHCI drivers exist for W7 but once they kill of xHCI and move to say USB 4.0 then W7 is killed off from MS for xHCI driver support you will be dealing with the issue XP faces now.

Hmm, I still think it would. No need to make yet another OS on the DOS base. Enough. Windows 3.x / 9x experience taught this is not a good idea. The only sane way I would imagine is porting monolithic DOSBox to a DOS extender like Watcom or DOS4GW with adding necessary support to access video card and HDMI / USB audio hardware directly. In 32-bit it'd be fast enough, and within DOSBox it'd be very compatible. I think this is the only way to run a game with any hardware emulation that requires a clean i386 real mode to start. Again, it'd be easy to slow down / speed up games. But considering tiny sizes possible with systems based on Linux kernel and readily available support for tons of existing hardware, I'd go the latter way.

It could be that WinME might be a better OS for DOSBOX since it started supporting WDM drivers. Maybe it is possible to mix a 98 DOS and have WinME run on top of it. I could force it myself for a later test.
The easiest way to get DOSBOX working at least under "REAL DOS" in the future would be to directly connect to the Intel HD Graphics and the HDMI Audio out. Since almost every Intel CPU has this integrated graphics built in you won't need to deal with video cards issues, USB sound device, or any additional sound card. The BIOS allows adjusting the shared video memory usually between 32MB to 2GB in some cases. This should cover at least 70% of the computers out there in one shot without adding any new hardware to get it to work. Once xHCI DOS drivers are realized then you could even add other USB devices like USB gaming controllers.

In the official Windows PE, there are many limitations, that's right. It's only intended to setup normal Windows installation plus a couple of recovery tricks, no more. We should start with mentioning that official Windows PE for NT4, 2K and XP provided no GUI at all. But those "extended" PE builds I mentioned above add many features to the official PE, so you can even play 3D games finely. As for the official Windows PE for Vista+, it lacks OpenGL and DirectX support. I believe these can be added, though for DOSBox this is not crucial (though unpleasant, yeah). To run on any official PE, DOSBox needs to be recompiled without OpenGL support. Also note, a PE for 64-bit Windows provides no support for 32-bit applications, btw 😀 So, better be stick with a 32-bit PE.

Noted. Unfortunate you can't use the Vista 64-Bit PE and use DOSBOX inside it. What's missing between Vista 64-bit standard and PE to fix this? The real Vista 64-Bit works although with the 16GB+ bloat to get the job done.

Be sure, hardware emulation will cost RAM. At the very least, you need RAM to load DOSBox itself and the ROM images for MT-32 emulation.

Yes but I don't think the DOS based version we would consume in the 512MB region for all of this to happen. 😊
This leaves more room for other types of emulation like the SC-55 you had planned. Anyhow I agree it's not urgent at the top of the list. I just see it as more of a final hurdle sort of like climbing the highest mountain. Not cause we need to or going to outer space but because it's one of the milestones of achievement. The same could be said why spend all the effort to make MUNT great when one could buy a real one for $100-$150 that works the way intended. People still can hook up the real MT-32 via USB some might say. So some may find MUNT illogical in their own way. Not me. 😈 This is probably your greatest achievement.

See, most of us do not need DOSBox for real DOS. Rebooting each time you'd want to play a game is not an option. Building a DOS-based PC on a newest hardware also makes no sense, it's just a waste of resources. DOSBox is right now more than suitable. It's truly portable, unlike those BIOS+DOS setups you have in mind. You can compile and launch DOSBox in virtually any 32-bit GUI-enabled system, so it could be ported in theory even to DOS extended, if only DOS provided minimal hardware support for required hardware.

Yes it's not really about it being the only purpose for a system and thus a waste of resources. I set up a multiple OS setup for testing so I can switch between each when necessary. But imagine the typical scenario you have access to someone's computer then yes you can just plug in your USB device and load DOSBOX directly. Now another scenario you are at a store that sells laptops which probably have the OS password locked or USB port access locked. Now some of these laptops you could just reboot the system and hopefully it has USB boot still enabled and you could boot your USB DOS DOSBOX/MUNT in a few seconds and you're in and autocopy some program and disconnect the flash drive and run it in the Ramdrive. Now if you're booting into some PE you might draw some attention when they see you accessing the Windows like desktop interface they recognize that should be locked. Most people today probably wouldn't understand DOS if they saw it so if you left the machine running it'd probably keep looping the game and the employee would pound the touch pad and try to quit out of it not knowing they were in DOS and eventually just unplug the laptop and let it reboot into the Retail demo mode again not knowing anything suspicious. Now if you were in DOSBOX inside Windows PE I'm sure the employee would try Alt-tabbing or Task Manager to get out and see what you were doing.

But for the DOS hardware support it will be when the Intel HD Graphics combined with the HDMI audio out has been programmed for DOSBOX support so all you'd need is just a HDTV output via HDMI. Or say HX-DOS Extender adds a set of on board audio support drivers for Realtek which usually is found on most modern systems. I think it's just a matter of time with the right people this will be done.

In XP, the DOS virtual machine does the routing of MIDI for us. It contains a poor MPU-401 emulation in UART mode, so it is able to capture MIDI stream from a game and send it to the default Windows MIDI device. With Windows 9x things are quite different. If your audio driver is WDM based, it may easily add similar emulation via the miniport driver that WDM already provides. Or may not. Or it may send the MIDI stream to the internal synth instead. Depends on the driver. I'd suggest you to look at the VDMSound port for Windows 9x if you're still interested. Hopefully, it is exactly what you want. And let me remind you that mt32emu can (and actually should) be added to DOSBox. I don't think it'd be hard to get a SVN DOSBox build for Windows 9x 😉 Adding any nice graphical features to the monolithic DOSBox+mt32emu seems to be an easier task than dealing with MIDI routing in case VDMSound works not great.

I'll have to do some testing of the other SB sound cards in 98. But from what I understand a special DOSBOX with your MUNT integrated would be a better solution but would that solve not needing to use MIDIYOKE? The current DOSBOX I use is the regular one and it works fine in 98 and it isn't a special build for 9x.

[What MUNT 98 needs for testing]

But for now on your Munt 98 console
Where it shows the MIDI Input with the + sign.
When adding the MIDI channels it only allows single selection.
Is there a way for you to make it so it allows Ctrl+A to Select All in the Window?
Holding the Ctrl+Left Mouse button should allow single selecting and deselecting.

Then a way to store the selected Channels as one MIDI input so when Munt98 is reinvoked you could have stored MIDI Inputs predefined under the
+ - Properties Record
[MIDI INPUT 1] [MIDI INPUT 2] [MIDI INPUT 3] [MIDI INPUT 4]

So in this case say the 16 channels I selected could be stored as MIDI INPUT 1.

Then whenever I have Munt98 relaunched I could simply click [MIDI INPUT 1] which has all the selected MIDI channels that I had selected stored here it would readd these to the MIDI INPUT window for Synth 1.

And another check box option under "OPTIONS"
Start Iconized
Show LCD balloons
Show connection balloons

ROM Configuration...
MIDI INPUT Preload Configuration <--- (Here is where you select from MIDI INPUT 1 - 4 your default preloaded MIDI INPUT assignment) so here you could select from a drop down list:
NONE
MIDI INPUT 1
MIDI INPUT 2
MIDI INPUT 3
MIDI INPUT 4

I hope you can add this into the next MUNT 98 build SergM at your convenience and I'll test it out and give you feedback.

I would try to add these myself if you let me use the source code and showed me what steps you did to compile it and I'd just keep trying to tweak this for 98 but I think for the moment it'd be easier for you to add this portion into it for testing to save time.

Thanks. 😁

God save us. I've completely forgotten what a crap it is that Windows 98!
Never again.
Never ever.
Never ever ever ever!

Yes, I swear I only run Windows 9x in a virtual machine from now on. For the sake of heath of hardware 😀

Well, the munt MIDI driver for Windows 9x will miss at least one feature. It cannot determine the application which opens a MIDI port because this is always the MM system. It is currently unstable but I hopefully can reimplement the way of message sending more safely from the damn Windows 9x API point of view. Maybe rewriting it as a WDM driver would be easier but I saw enough BSODs in my life. Windows 9x is bad enough, don't want to make it even worse with my buggy kernel mode driver 😉

After hundreds of reboots, I become to a thought about DOSBox for DOS thing.

As I already mentioned, new systems are mostly EFI based and often EFI implementations are not great. Especially in emulation of BIOS functions. For instance, my old Aspire E1-771G cannot boot to any MBR partition unless to switch the boot mode Legacy/UEFI. So, if the EFI is protected by a password or a SecureBoot crap is engaged, this will be fatal to the whole idea.

Also, provided the boot up from a USB flash occurs, it'd be better chances to boot in UEFI mode. Moreover, I think DOSBox ported as a EFI module would run even better in this environment, since it is x64 with native support for some important hardware. So, no emulation over emulation thing (EFI-BIOS-DOS-DOSBox). Unfortunately, EFI does not provide full support for every single device the system has, so I'm still pretty sure Linux kernel would be a better choice as the foundation. I won't be surprised if you find yourself copying driver code from Linux kernel to use with the DOSBox port 🤣

95DosBox wrote:

Your custom PE must have slipstreamed the xHCI drivers for your MB.

No. I only added applications most useful for recovery purposes. The rest of the system is vanilla.

95DosBox wrote:

It could be that WinME might be a better OS for DOSBOX since it started supporting WDM drivers. Maybe it is possible to mix a 98 DOS and have WinME run on top of it. I could force it myself for a later test.

No way. Windows ME requires DOS 8.0. Also, you can easily get DOS 8.0 on a floppy by creating the recovery disk. IIRC, I used to use a patch for this DOS to make it boot from a HDD, a couple of bytes need to change.

95DosBox wrote:

What's missing between Vista 64-bit standard and PE to fix this?

A lots of 😀 The "Windows on Windows" thing is completely cut out. But there are no things to worry.
1. DOSBox can be recompiled as a 64-bit application.
2. 32-bit Windows PE runs great on any amd64 system.

95DosBox wrote:

This leaves more room for other types of emulation like the SC-55 you had planned.

Not planned. For a complete all-in-one audio emulation look at DOSBox SVN-Daum from ykhwong.

95DosBox wrote:

[MIDI INPUT 1] [MIDI INPUT 2] [MIDI INPUT 3] [MIDI INPUT 4]

I'm sure there is something really wrong with that. To route MIDI stream from a single application to another, you need only one MIDI Yoke loopback port. It is capable to route all 16 channels, no need to split (if only you want some channels to be filtered out or routed to another application/MIDI port).

95DosBox wrote:

Most people today probably wouldn't understand DOS if they saw it so if you left the machine running it'd probably keep looping the game and the employee would pound the touch pad and try to quit out of it not knowing they were in DOS and eventually just unplug the laptop and let it reboot into the Retail demo mode again not knowing anything suspicious.

🤣
I'm pretty sure the same happens with a Linux box. It may appear even more scaring 😉

sergm wrote:

95DosBox wrote:

It could be that WinME might be a better OS for DOSBOX since it started supporting WDM drivers. Maybe it is possible to mix a 98 DOS and have WinME run on top of it. I could force it myself for a later test.

No way. Windows ME requires DOS 8.0. Also, you can easily get DOS 8.0 on a floppy by creating the recovery disk. IIRC, I used to use a patch for this DOS to make it boot from a HDD, a couple of bytes need to change.

I have a special boot structure.

You see my C: is just for the boot partition.
I install 98 on the D:
So when I plan to I'm going to try and install ME clean onto the D: or E: partition. What I guess will happen is ME will overwrite my C: boot partition with its DOS 8.0 non DOS environment. I'm going to use my saved image from DOS 7.1 and overwrite the C: boot partition to restore it back. Then it should allow me to run Win ME but retain the DOS 7.1 front without patching.

But if somehow it doesn't I'll try using that ME DOS patch to fix the DOS lock out but I can't see ME would dislike DOS 7.1 using my trickery. Most people probably install to C: which makes it harder to separate their 98 DOS from ME.

[MUNT98 PERFORMANCE UPDATE RESULTS]
I did further testing comparing MUNT's CPU consumption.
When run on XP on a dual core at 1.6GHz I found that it barely scratches the CPU utilization of 8% average and 12% peak on DOSBOX but Munt doesn't seem to even hit 1%.

So if we converted this value to a single core it should mean in XP DOSBOX with MUNT uses 16% to 24% max peak on 1.6GHz. This would lead you to think even a 400MHz single core Ivy Bridge Celeron should be able to handle it near full 100% CPU utilization.

On 98 if I ran just DOSBOX alone and used the SB emulation only (NO MUNT) I was able to run it at 800 MHz single core and it was very fluid and no sluggishness. But in order to use the MUNT98 without slowdown I had to increase it to 3.0GHz on a single core.

SergM I think the MUNT98 files there is something that is not optimized correctly because it should actually run faster on 9X despite being a single core. I would think even a 1.0 to 1.5 GHz single core would be more than enough power to run DOSBOX with MUNT98 but in comparison with XP it should be 400MHz. I'm not sure why but I'm willing to help you troubleshoot what is causing this extreme sluggishness. Is there anything in the code you are compiling that could be causing the unexplained CPU load?

I also tested Mame emulation and 800 MHz it runs smoothly on the single core in 98. So if both DOSBOX and Mame have no issues with any sluggishness I think it's isolated to MUNT98.

I'm sure there is something really wrong with that. To route MIDI stream from a single application to another, you need only one MIDI Yoke loopback port. It is capable to route all 16 channels, no need to split (if only you want some channels to be filtered out or routed to another application/MIDI port).

I was able to test different ways of using the MIDIYOKE but also testing the way 98 interfaces with it. One thing I found was using the Custom theme allows you to possibly mix different instruments from different Synths. But I also found that when I originally tested MIDIYOKE I chose 16 Ports assuming the 16 MIDI Channels would require one for each so I've corrected it before reading your note. So 1 Port is all that is needed.

But also I was troubleshooting the original problem was I didn't realize some issues with DOSBOX and MUNT to enable the sound with MIDIYOKE.

If you attempt to run MUNT first before DOSBOX it can freeze and crash the system.

So I had to run DOSBOX first then run MUNT to avoid this problem.

Then you must manually add the MIDIYOKE junction 1 input after launching MUNT98.

Then you can run the DOS program in DOSBOX and MUNT98 will intercept the MIDI signals.

After doing more testing and reboots to see how MIDI configurations are saved it is better to "NOT" use the "Custom configuration" for MIDI output but use
"Single instrument" and MIDIYOKE junction 1. This makes it easier and Windows remembers this MIDI output setting.

Now since MUNT98 can't auto detect the MIDIYOKE junction input 1 when launched I need your help to include an extra feature for MUNT.

I can add the MIDIYOKE junction 1 input into MUNT98 using the + button but I want a way to store it inside MIDIINPUT.cfg

Can you add a checkbox option to preload a MIDI INPUT from MIDIINPUT.cfg to skip an extra few steps so it's as simple as the XP version?

When MUNT98 is launched it will then scan MIDIINPUT.cfg for previously saved MIDI INPUTS and add those to the console window screen automatically instead of needing to use the + button.

I'm not sure how MUNT identifies "MIDI Yoke Junction: 1" once added so if it uses a special Hardware ID name in MUNT to identify it this would be useful for putting inside MIDIINPUT.cfg.

So in the
MIDIINPUT.cfg file you will see in regular text.

MIDIINPUT = "MIDI Yoke Junction: 1" (or however MUNT98 identifies this MIDI Yoke Junction 1 device internally)

MUNT98 obviously detects this as a MIDI Input device when using the + button so unless there is another way to point to it directly like XP this is the only way I can think of to make it automatic saving it in a MIDIINPUT.cfg file to preload and set to always keep scanning for this MIDI device automatically.

Also can you add a check box option to start MUNT in "Test MIDI Driver" mode which displays the MT-32 status info LED panel rather than the regular blank canvas? I would like to see this check box option for Munt98 and XP.