VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1620 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1621 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Vsync code has not been touched since borrowing from DOSBox SVN or incorporated from DOSBox Daum. I do not test that code, so I don't know if it works.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1622 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1623 of 2397, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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

How To Ask Questions The Smart Way
Make your games work offline

Reply 1624 of 2397, by LeXa2

User metadata
Rank Newbie
Rank
Newbie

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

  • Build types, direct3d output: so, is it expected that d3d backend is missing from mingw SDL1 builds? Is it that the build environment (i.e. mingw-project supplied headers + linux based cross-compiler targeting win32/win64) lacking some key elements required to build d3d output? Something else? Build configuration issue? You name it?
  • Build types, sdldraw: what SDL version is it based on? SDL1?
  • 3dfx emulation. It is still not clear from your reply what is the difference between “software” and “opengl” types of emulation. What emulator is being used for “opengl”? I assume you hadn’t resorted to implement your own glide wrapper inside DosBox-X, had you? Am I correct that DosBox-X does not support gulikoza’s type of glide emulation, i.e. “glide2x pass-through” to the host system where it is expected to be handled either by the real 3dfx hardware or by the glide wrapper of a user choice?
  • FREECG98.bmp. From your explanation I assume that this file might also be used by mingw builds. Why is it omitted from those? CMakeLists.txt/Makefile error?
  • Direct3d backend for SDL2. Totally agree with your point about a bad idea to hack around cross-platform lib to tie in a support of a backend relying on a platform-restricted API. Better idea would be to move on with something cross-platform in nature like Vulkan. Don’t know if SDL2 supports it but if not yet then it’s just a question of time obviously. On the other hand I can barely see the profit of using 3D APIs for DosBox except for possibility to use shaders. And from this PoV Vulkan backend won’t provide much compared to OGL 4.x. A bit more interesting approach might be to try using OpenCL kernels to implement shader-style post processing but that’s another story 😀.

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?

Last edited by LeXa2 on 2018-12-08, 05:53. Edited 2 times in total.

Reply 1625 of 2397, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 1626 of 2397, by LeXa2

User metadata
Rank Newbie
Rank
Newbie
TheGreatCodeholio wrote:
... a heavily modified in-tree version of SDL1. The in-tree modifications add support for things not originally supported by SDL […]
Show full quote

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

Reply 1627 of 2397, by LeXa2

User metadata
Rank Newbie
Rank
Newbie
DosFreak 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.

Reply 1628 of 2397, by rapilot

User metadata
Rank Newbie
Rank
Newbie
dosmax wrote:
A little hint for everyone else who wants to try this out: The above dosbox.conf [autoexec] section isn't entirely correct. The […]
Show full quote

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?

Reply 1629 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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

Reply 1630 of 2397, by walterg74

User metadata
Rank Member
Rank
Member

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?

Reply 1631 of 2397, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 1632 of 2397, by walterg74

User metadata
Rank Member
Rank
Member
DosFreak wrote:
Depends on what you are looking for. Define "better". What features are you looking for? You can use Munt with anything that s […]
Show full quote

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?

Reply 1633 of 2397, by rapilot

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 1635 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Ringding 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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1636 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by TheGreatCodeholio on 2018-12-27, 06:06. Edited 1 time in total.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1637 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1638 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1639 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I've incorporated the Xorg 1.20.1 patch, though none of my systems are running that version of Xorg so I can't directly test it right now.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.