Dominus wrote:There is a reason there is no mt32-emu support.
Edit: DOSBox doesn't want to support software piracy in any way. As long as the Roland ROMs are required and those legal status not completely clear, the DSOBox devs will (AFAIK) not build in support.
I've been using imgmount for CDs and for booting Dos and Windows 3.11.
Strange how mt32 support doesn't bother the scumm developers, yet they go screaming piracy when patches to fix bugs are made.
IMO, the MT32, Fluidsynth, and all the various scalers have a non-simple solution, dosbox needs to have a plug-in system like other emulators. Pretty much all emulators are skating around a piracy elephant in the room. You know your software is going to be used to primarily play pirated software, because extremely few people have the actual hardware and knowledge to make copies of ROM's. In the case of the MT32/CM64/LAPC-I, it was far more likely that someone could dump the LAPC-I if they had a 386 in their garage.
Of all the patches I've tried, the MT32 patch and the SDL2 patches are the only patches that apply cleanly to SVN. Only one line needs to be fixed to make MT32 work with SDL2 (the sdl thread line.) In my source I've knocked out some preprocessor ifdef/endif blocks to make it build under sdl1 or sdl2, or turn munt on or off during the compile so I can continue to try patches without horribly breaking the project.
That said, when I tried Win95 with the same build (as in I installed from my own non-B OEM disc) there doesn't appear to be enough hardware emulated in a stock dosbox to do anything practical. So if a 2GB patch can be applied and doesn't hurt the goals of DOSBOX, that seems OK. Where I'd like to see DOSBOX go is emulate the PC98 x86 hardware (eg DOS/V systems) as PC98 emulators are kinda terrible, closed, and there is only one http://www.yui.ne.jp/np2/ that has source code and seems to still be under development. That would allow emulation and potential localization of such games. Right now there is zero chance of being able to get any of those games to work and be distributed legitimately, because none of the PC98 emulators appear to have a FOSS license. But it's not likely that anyone on this side of the pond has such equipment to verify proper emulation either.
The ykhwong-daum build seemed to be a "be all end all" build before it stopped being updated, and common builds like dosbox-x and vdosplus don't cover either personal goals. Plus there are builds out there that are full of malware (emuCR) that I think the lack of a "daily build" system is hurting the reputation of the software, especially when GOG or STEAM use the 2010 0.74 build, fail to configure anything, and then kids will just package up the ykhwong mt-32 enabled dosbox, roms and all and post it on steam forums because users are lazy.
So as far as emulating large disks are concerned, it's probably something that wouldn't hurt, but should probably should be a part of a "patches for enabling the use if Win9x" build as one unified patch, rather than a series of patches that don't fully enable win9x.
Like off the top of my head:
- Large disk support (would requiring emulating ATA hardware so DMA can be enabled)
- Emulate PCI
- Emulate ACPI/APM https://forums.virtualbox.org/viewtopic.php?t=9918 so that it doesn't consume one cpu core at 100%
- Emulate VESA/VBE driver path http://bearwindows.zcm.com.au/vbe9x.htm
The catch is that this is pretty much what Bochs does already. Bochs doesn't emulate mt32's, GM synths, or any of the other quirks of the SB16 (or do they? http://svn.code.sf.net/p/bochs/code/tags/REL_ … L/bochs/CHANGES .) So pretty the argument is always going to be "make win95 run better" vs "just use something that does already"