Reply 1620 of 2419, by TheGreatCodeholio
- Rank
- Oldbie
SDL2 builds are limited to "surface" output only. OpenGL support is not implemented and it's probably not a good idea to hack around the window for Direct3D the way the Daum code did with SDL1.
SDL2 builds are limited to "surface" output only. OpenGL support is not implemented and it's probably not a good idea to hack around the window for Direct3D the way the Daum code did with SDL1.
3Dfx: I was not aware Daum had a voodoomem option, perhaps that didn't make it.
You may need to configure dosbox.conf to enable PCI emulation.
DOSBox-X does not provide a glide2x.ovl, I've instead been using the real glide files from a 3Dfx install CD-ROM image which seems to work fine with DOSBox-X.
OpenGL 3Dfx emulation has always been a bit funny with DOSBox-X and it has to do with the fact that it's sharing OpenGL context with DOSBox-X's OpenGL rendering. I've done some work to try and help but it's not perfect. This is work done to make it work generally OK on both Windows (OpenGL) and Linux (MESA OpenGL).
You may have noticed as well that DOSBox-X disables resizing and maximization while OpenGL 3Dfx mode is active. Resizing the window more often than not screws up the OpenGL viewport. In fact DOSBox-X was also fixed not to permit bringing up the mapper or configuration GUI in that mode either for that reason.
Mingw-w64 compiled binaries can run on <XP but you can't use the posix (Posix is supported only on XP+ with Mingw-w64) build which is the default for MSYS2 and Linux repos. You have to use the dwarf win32 build which can be manually downloaded from the Mingw-w64 site or you can compile Mingw-W64 for Win32. Check my compilation guides linked in my signature on my Google drive for instructions. I use Mingw-w64 to compille DOSBox to support Pentium Pro+ machines on DOS,NT 3.50+ and 95+. I use the original Mingw for less than Pentium Pro since I haven't bothered to figure out how to recompile Mingw-W64 to support less than Pentium Pro. Support for processors that low is really an edge case anyway but nice to have.
/EDIT clarified which mingw-64
@TheGreatCodeholio
Oh wow, I wasn’t expecting to get so many answers that soon 😀. Thanks a lot for this.
Parsing through my wall of questions I see that – as expected – some of them still need some more clarifications.
Ah, and one more thing: are there any DosBox-X public wiki-es out there that are open for users contributions? I know how irritating it is to answer approx the same set of questions again and again and again on forums. It won’t take long time for another person like me to come to this thread with about the same queries. So I’d like to spend an hour or two – while I have these spare hours on the weekend – to update some wiki page with the information I gathered from your answers. Question is where to find this wiki if any.
@DosFreak
Emm, your reference to “posix build” of mingw looks a bit obscure. Are you reffering to threading model (“posix” vs “win32”, latter one lacks C++11 threading primitives) or to exception handling style which can be DWARF (only for 32bit, don’t propagate over non-mingw stacks), SJLJ (which is no joy for DosBox I suspect as it can’t properly handle page faults) or SEH? I mean, you’re intermixing the use of term “dwarf” with “posix” which are related to different properties of a build. Could you please clarify a bit?
Sorry, was referring to the win32 dwarf build of mingw-w64 here: https://sourceforge.net/projects/mingw-w64/fi … f-rt_v6-rev0.7z
MSYS2 and Linux only offer pre-compiled posix mingw-w64 which results in executables that are incompatible with <XP.
wrote:... a heavily modified in-tree version of SDL1. The in-tree modifications add support for things not originally supported by SDL […]
... a heavily modified in-tree version of SDL1. The in-tree modifications add support for things not originally supported by SDL1 and fix many annoying bugs. ... I'm content with modifying SDL1 in-tree where needed.
The idea is that the SDL1 code in-tree is modified as I need it (since SDL1 is considered deprecated) ...
My modified SDL1 code supports extra features including foreign keyboards, display DPI determination, and support for menus in Windows and Mac OS X.
... the DOSBox SVN dynamic core (dynrec) was recently ported to DOSBox-X which now enables dynamic core on 64-bit x86_64 as well as ARM processors.
Well, it makes things a bit complicated for one who would like to get DosBox-X running on non-X RPi with a decent-enough speed. Is it still possible to compile DosBox-X with external SDL1? I'm asking as that's a hard requirement on any RPi to use a forked and patched SDL1.2 with special dispmanx/rpi backend to be able to blit anything fullscreen without spending CPU cycles on resizing - and CPU cycles are precious on RPi. The question of possibility to use RPi-patched SDL1 with DosBox-X is even more actual right now as you had porter new dynamic compiler code from upstream which is able to emit more-or-less fast ARM code making possible to emulate resource demanding apps without falling into turtle/slideshow territory. Hmm, I guess I'd try to give it a go this Sunday on one of my RPi-s. I won't be compiling on RPi itself obviously, it's way faster to use quemu-user "container style emulation" on x86-64 linux system for this 😀. Would report back my findings if stars would align and I'd manage to get it done.
wrote:Sorry, was referring to the win32 dwarf build of mingw-w64 here: https://sourceforge.net/projects/mingw-w64/fi … f-rt_v6-rev0.7z
Okay, I see. Your link points to 32bit mingw with DWARF style exception handling and WIN32 style threading. From what you write I assume that the important part here is to use WIN32-style threading instead of posix-style (winpthreads). As for exception handling - I'd stay with dwarf on 32bit and seh on 64bit - as already mentioned earlier I suspect that SJLJ won't cut for the way DosBox handles "hardware exceptions" in guest essentially by converting them to C++ expections on the host side.
wrote:A little hint for everyone else who wants to try this out: The above dosbox.conf [autoexec] section isn't entirely correct. The […]
A little hint for everyone else who wants to try this out: The above dosbox.conf [autoexec] section isn't entirely correct. The CD-ROM has to be mounted with a drive letter as first parameter like usual, not with the bus number. At least for me using the win32 build 😉 . Otherwise oakcdrom.sys (or any other CD-ROM driver I tried) refuses to find a drive.
My working [autoexec] section looks like this:
[autoexec]
# floppy disk from DOSlib test code by ./make.sh and ./make.sh disk imgmount 0 "path_to_floppyimage\disk.ima" -t floppy -fs none
# C: drive for Win95
imgmount 2 "path_to_hdd_image\hdd.img" -size 512,63,32,512 -t hdd -fs none -ide 1m
# D: drive with Windows 95 install CD-ROM
imgmount D "path_to_cd_image\cd.iso" -t iso -fs iso -ide 2m
# Now start Win95
boot -l c
On a sidenote: this looks very, very promising. A more than useful addition to Dosbox!
I tried the same autoexec.bat. But the problem is that once I boot from a drive, access to a cdrom is lost. That drive letter is no longer there. For example, when I try:
# floppy disk
imgmount 0 "dosbd.ima" -t floppy -fs none
# C: drive for Win98
#imgmount 2 "win98hdd9.img" -size 512,63,64,1023 -t hdd -fs none -ide 1m
# D: drive
imgmount d "enc2000.iso" -t iso -fs iso -ide 2m
Then when i enter boot -l c, I can no longer access it.
If I just use numbers for the drives, that does not work with cd roms. For example, if I try
imgmount 0 "dosbd.ima" -t floppy -fs none
imgmount 2 "win98hdd9.img" -t hdd -fs none -size 512,63,64,1023 -ide 1m
imgmount 3 "encyc2000.iso" -t iso -fs iso -ide 2m
It then says, a letter must be used for the iso and I can not just assign images to numbers.
I tried, booting into windows, and then running an imgmount after the boot. But then dosbox crashes, so I can't do that either.
So, how can I have a drive image remain after a boot, so it can be seen in windows?
The SDL v12 patches for dispmanx video (Raspberry Pi) seem to be here:
https://github.com/vanfanel/SDL-1.2.15-raspbe … /master/PATCHES
https://github.com/vanfanel/SDL-1.2.15-raspbe … ATCHES/rpi.diff
Hi all, is this considered the best version to use these days? I have been using the "plain" 0.74 version, and would like something better with more features and specially munt support?
Depends on what you are looking for.
Define "better".
What features are you looking for?
You can use Munt with anything that supports it. Install it and use it with DOSBox.
wrote:Depends on what you are looking for. Define "better". What features are you looking for? You can use Munt with anything that s […]
Depends on what you are looking for.
Define "better".
What features are you looking for?
You can use Munt with anything that supports it. Install it and use it with DOSBox.
I guess probably glide support would be one, and regarding munt, wasn’t there a version with it builtin or something like that?
I found the answer to my own question. First, to get a cdrom image to work in windows 98 without daemon tools, you need to make sure you are using dosbox-x and not dosbox.
To get a cd rom image to work with Windows 98, you need to make sure autoexec.bat and config.sys on the hard drive image contain lines to load cd rom drivers.
dosbox.config should contain lines like these
[autoexec]
imgmount 2 "win98hdd9.img" -size 512,63,64,1023 -fs none -ide 1m
imgmount d "enc2000.iso" -t iso -fs iso -ide 2m
and also contain this:
[ide,primary]
enable=true
int13fakev86io=true
[ide,secondary]
enable=true
int13fakev86io=true
Next find oakcdrom.sys on the windows 98 install cd and move it to the root directory of the windows 98 hard disk image
Next, check that CONFIG.SYS on the windows 98 hard drive image looks something like this:
DOS=HIGH,UMB
DEVICE=C:\WINDOWS\HIMEM.SYS
FILES=40
STACKS=9,256
LASTDRIVE=Z
DEVICEHIGH=C:\OAKCDROM.SYS /D:MSCD000
AUTOEXEC.BAT should look something like this:
PATH C:\WINDOWS;C:\WINDOWS\COMMAND
SET TEMP=C:\WINDOWS\TEMP
MSCDEX /D:MSCD000
Now load dosbox and enter "boot -l c".
If application does not find cd drive
You need to install a cd rom controller. To do this, go to control panel and then add new hardware. After it does its plug and play check, click automatically search for new hardware. It will search for all non plug and play hardware. Once it finishes, it will install a bunch of hardware devices. This will take some time, which is normal. Then boot the windows 98 image. You will see a blank screen for a while, which is normal.
Once it finishes, review your system devices in control panel. A cdrom controller should be listed.
Applications should now be able to find the cdrom drive image.
Note also that after you do the above in adding new hardware, graphics speed should also be increased. Which means windows will run faster! Windows will be a lot less slow!
FYI The patch in svn r4177 referenced from this other thread is also required for DosBox-X and works (tested on Fedora 29 x86_64).
wrote:FYI The patch in svn r4177 referenced from this other thread is also required for DosBox-X and works (tested on Fedora 29 x86_64).
I haven't come across that, however I did fix a very similar and serious problem with Centos 7 and SDL1 where going fullscreen caused DOSBox-X to get stuck in an infinite loop entering/leaving fullscreen mode. The problem in the SDL1 library in-tree was treating all Focus change events as loss of focus from the non-fullscreen window, even if it only lost focus to the alternate window it made for fullscreen. The fix I applied was to have it check whether loss/gain of focus happened to the ONE window of interest (so, once fullscreen, it didn't care anymore of the non-fullscreen X11 window lost focus), which resolved the issue here.
Latest development news: I've gotten DOSBox-X to show working menus on Mac OS X for both SDL1 and SDL2 builds, to show a few basic commands (mapper, configuration GUI, and pause) in the dock menu (the menu that you get when you command-click the application icon in the dock). I also managed to get ahold of a Macbook Pro with the "touch bar" and add the same shortcuts to the touch bar.
NOTE: To avoid pulling your hair out like I did, do not develop touch bar support over SSH on the Macbook, because the touch bar will not show anything from your NSTouchBar object unless the program is run from the local terminal or local desktop.
On Windows (Windows 7 or higher) I figured out how to add buttons to the preview thumbnail the task bar shows when you hover over, and added 3 buttons for mapper, configuration GUI, and pause.
On Linux, fixes for Centos 7 were made including the aforementioned infinite loop and unresponsive keyboard/mouse that occurred if you tried to go fullscreen from the SDL1 build.
If your Mac OS X system has a high enough resolution display to enable "High DPI" mode, SDL1 builds of DOSBox-X now offer an option to enable "HighDPI" mode so that the window is scaled down to match the pixels on the retina display 1:1 (so you can use that extra resolution for some cool looking scalers).
On the PC-98 side, emulation has improved enough that generally any game not using funky copy protection tricks, hardware-specific tricks, or hacky disk change detection will work fine now.
It turns out the reason most games were hanging up or requiring you to move the mouse constantly is that, unlike the IBM PC, the mouse hardware on PC-98 is basically a latch for mouse motion and a periodic interrupt at 120Hz. This is so well known many games will actually use the mouse interrupt as a timer as well as mouse input. Quite different from IBM PC/AT hardware where the PS/2 mouse only interrupts the system if motion or button clicks happen.