VOGONS


Dosbox Win95 - disk size 2GB limit hack?

Topic actions

Reply 60 of 66, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I find the existence of vDosPlus to be very encouraging – a derivative of DOSBox with its own specific goals and patches applied.

There's no reason someone couldn't make a similar build of DOSBox specifically directed towards running Windows 95 – except for the fact that it apparently will never work particularly well and is generally not a good idea.

Serious Callers Only wrote:

Expanded IMGMOUNT/IMGMAKE can we admit that no one uses the 'raw' ability on dosbox upstream for anything else than mounting windows or freedos images?

As I mentioned before, there are some ancient PC games that are intended to run directly from a boot floppy. Some of these games do not have a DOS filesystem (or even anything recognizable as DOS).

Reply 61 of 66, by Kisai

User metadata
Rank Member
Rank
Member
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"

Reply 62 of 66, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Just a FYI for anyone that wants to try:
the patch to support qcow2 (especially its write redirect/snapshotting feature) is unsuitable to use on large images, since the patch implementation is of the naive sort that reads the affected image into memory.
This is sorta of a problem when the image is 1+gb which is when i'd want to redirect writes to a smaller file if they're on a read-only file system overlay with a r+w filesystem mount. A pity, maybe libqcow will eventually support the write and snapshot part of the format in a better way and the patch can use that instead.

Anyway, i still think a fake equivalent of scandisk/fdisk/dir (or lower level interfaces if feasible) etc for windows that communicates directly with dosbox/native filesystem would be much more convenient for users and enable some advantages that are impossible with images, but it seems the whole virtual machine / emulator industry and devs think it's not worth it, so i doubt it will ever happen.

Another clear (ish) alternative for large games is IDE cdrom emulation and that was explored in other patches. That + a small image for the game is more or less equivalent in separating most of the read only part of the data from the write part with the typical minimal install (even if you have to change cds and still lose deduplication and have extra useless 'cd error correction data' bah).

Reply 63 of 66, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Any progress on the subject?

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 64 of 66, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Dosbox-x appears to want to create a 'Joliett emulation' layer for imgmount. This would allow isos mount to work on dosbox+windows 95+-
I'm trying to convince them to expand the cue format to allow a directory in place of the binary track. This would build a 'fake' cd-rom / dvd that is actually a dir that windows sees. Non writable thou. This bypasses all the FAT32 hard cases of filesystem integration in windows that would fail with a dir mount. Fdisk trying to be dumb, defragmentation etc.

I actually think a 'virtual joliett emulator' is something that upstream might accept... It solves a major need in dosbox.

Reply 65 of 66, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Any progress on the subject?

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.