DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-12-07 @ 06:59

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 578
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-12-07 @ 07:00

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 578
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-12-07 @ 07:05

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.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 578
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby DosFreak » 2018-12-07 @ 09:48

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
User avatar
DosFreak
l33t++
 
Posts: 9980
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox-X branch

Postby LeXa2 » 2018-12-08 @ 01:48

@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.
LeXa2
Newbie
 
Posts: 4
Joined: 2018-12-06 @ 16:56

Re: DOSBox-X branch

Postby DosFreak » 2018-12-08 @ 02:01

Sorry, was referring to the win32 dwarf build of mingw-w64 here: https://sourceforge.net/projects/mingw- ... v6-rev0.7z

MSYS2 and Linux only offer pre-compiled posix mingw-w64 which results in executables that are incompatible with <XP.
User avatar
DosFreak
l33t++
 
Posts: 9980
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox-X branch

Postby LeXa2 » 2018-12-08 @ 02:05

TheGreatCodeholio wrote:... 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.
LeXa2
Newbie
 
Posts: 4
Joined: 2018-12-06 @ 16:56

Re: DOSBox-X branch

Postby LeXa2 » 2018-12-08 @ 02:10

DosFreak wrote:Sorry, was referring to the win32 dwarf build of mingw-w64 here: https://sourceforge.net/projects/mingw- ... 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.
LeXa2
Newbie
 
Posts: 4
Joined: 2018-12-06 @ 16:56

Re: DOSBox-X branch

Postby rapilot » 2018-12-08 @ 03:36

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

Code: Select all
[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?
rapilot
Newbie
 
Posts: 2
Joined: 2018-12-08 @ 02:50

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-12-08 @ 05:56

hail-to-the-ryzen
Member
 
Posts: 249
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby walterg74 » 2018-12-09 @ 23:51

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?
walterg74
Newbie
 
Posts: 92
Joined: 2018-3-20 @ 16:45

Re: DOSBox-X branch

Postby DosFreak » 2018-12-09 @ 23:59

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.
User avatar
DosFreak
l33t++
 
Posts: 9980
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox-X branch

Postby walterg74 » 2018-12-10 @ 00:14

DosFreak wrote: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?
walterg74
Newbie
 
Posts: 92
Joined: 2018-3-20 @ 16:45

Re: DOSBox-X branch

Postby rapilot » 2018-12-10 @ 03:57

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!
rapilot
Newbie
 
Posts: 2
Joined: 2018-12-08 @ 02:50

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest