DOSBox-X branch

[Hadden]

Hi

I've updated dosbox-x recently (I had SVN Daum ykwong build, from three years ago). So, I'm configuring it a bit.

Is big files patch still implemented? (I don't see any file bigger than 2gb anywhere, so I can't try any mount of them);

Keyboard mapper (default config) which worked fine in daum build, now have the wrong layout(it keyb).
I'm not very sure of how can I change it, or if I can import/export the mapper file (I'd take the one from older build, which seems pretty similar).

[stamasd]

Still interested in finding a solution to my LPT problem, see description in my post on the previous page in the thread.

[TheGreatCodeholio]

Still interested in finding a solution to my LPT problem, see description in my post on the previous page in the thread.

The direct LPT driver for Windows requires INPOUT32.DLL to allow userspace to access the parallel port I/O ports from userspace. Normally the Windows NT kernel keeps userspace applications (including DOSBox-X) isolated from direct hardware access.

[TheGreatCodeholio]

Hi

I've updated dosbox-x recently (I had SVN Daum ykwong build, from three years ago). So, I'm configuring it a bit.

Is big files patch still implemented? (I don't see any file bigger than 2gb anywhere, so I can't try any mount of them);

Keyboard mapper (default config) which worked fine in daum build, now have the wrong layout(it keyb).
I'm not very sure of how can I change it, or if I can import/export the mapper file (I'd take the one from older build, which seems pretty similar).

A change was made last year to remove the SDL 1.x library hack of forcing the US keyboard layout for DOSBox-X, and some new code was added for specific keyboard layouts. The changes involve both DOSBox-X and the modified SDL 1.x library in the DOSBox-X source tree.

Since I cannot possibly test every keyboard layout myself, I think the proper solution would be to write documentation in the source tree describing how to add support for more keyboard layouts.

[Timbi]

Considering how good DOSBox-X is and the future of it.
Wouldn't it be better to make DOSBox-X working only with images emulation of drives, without all the stuff which allows mounting host's directories and "external" tools? Simply it would be lighter.
I guess users have fun more while emulating whole OS instead of particular games.

[TheGreatCodeholio]

Considering how good DOSBox-X is and the future of it.
Wouldn't it be better to make DOSBox-X working only with images emulation of drives, without all the stuff which allows mounting host's directories and "external" tools? Simply it would be lighter.
I guess users have fun more while emulating whole OS instead of particular games.

I'd rather keep the ability to mount local directories as a drive, it's too useful, especially when it comes to retro development or patching games, while also providing the option to mount images as well.

[Timbi]

I'm getting an error telling "VGA Bios size too small" when vmem>than 4 MB and allow 32bpp vesa modes is true
Using the override doesn't help.
It does not happens on the other dosbox versions, what could it be?

[TheGreatCodeholio]

I'm getting an error telling "VGA Bios size too small" when vmem > than 4 MB and allow 32bpp vesa modes is true

It does not happens on the other dosbox versions, what could it be?

I already fixed that. The VESA BIOS modelist is so long it overruns the default 12KB originally allotted for the VGA BIOS. The latest code increases the VGA BIOS size to 16KB.

Or, you can eliminate the error by using dosbox.conf to set a VESA BIOS mode list cap.

[Timbi]

Thanks, it works now.

I like the scaler advinterp2x, but is possible to alter also the dosbox window pos x y during launching? Couldn't find the answer on the net.

Cheers

[hail-to-the-ryzen]

"If you want to control the position on the screen when creating a windowed surface, you may do so by setting the environment variables SDL_VIDEO_CENTERED=center or SDL_VIDEO_WINDOW_POS=x,y"
[http://sdl.beuc.net/sdl.wiki/SDL_SetVideoMode]

set SDL_VIDEO_WINDOW_POS=center
dosbox-x.exe

[hail-to-the-ryzen]

I read that a goal of dosbox-x is to handle non-recursive callbacks for BIOS and DOS functions:
https://github.com/joncampbell123/dosbox-x/issues/919

I assume this will solve some of the issues associated with "high level emulation" of the BIOS and DOS functions in dosbox-x, those inherited from dosbox. However, these HLE features appear to increase performance in int10h pixel functions by an order of magnitude.

I tested protected mode games and TOPBENCH in pcem versus dosbox-X. PCem shows 1/10th the performance in the video memory category versus dosbox-X. The pcem performance is much closer to real hardware speeds, but the mouse input and int10h pixel functions are typically too slow for practical use with the interpreter core.

Will the goal of non-recursive callbacks for BIOS and DOS functions in dosbox-x also substantially reduce the efficiency of the HLE features in the mouse and int10h code? Is it possible to easily port these HLE features to pcem?

[TheGreatCodeholio]

I don''t see how re-implementation of some BIOS functions can make anything slower. Practically anything INT 10h and INT 33h related draws cursors and text on the screen using setpixel, which is VERY inefficient! If you did that on real hardware you would get very poor performance.

A real implementation would know how to draw a cursor or text efficiently in VGA planar modes.

The goal is not to re-implement everything, but only what might be preempted in multitasking environments or virtualized.

[TheGreatCodeholio]

I don''t see how re-implementation of some BIOS functions can make anything slower. Practically anything INT 10h and INT 33h related draws cursors and text on the screen using setpixel, which is VERY inefficient! If you did that on real hardware you would get very poor performance.

A real implementation would know how to draw a cursor or text efficiently in VGA planar modes.

The goal is not to re-implement everything, but only what might be preempted in multitasking environments or virtualized.

I also want to point out calling setpixel 32x32x2 times to draw the cursor from INT 33h causes other problems, combined with the I/O delay emulation, that can cause demoscene or game applications to slow down or delay interrupts because of the 6 to 8 or so I/O reads and writes PER pixel in VGA 16-color mode. It was enough to delay PIC events by 5ms in emulator time every time the mouse moved!

EDIT: I want to clarify that it was a combination of the demo polling port 3DAh for vertical retrace AND iNT 33h redrawing the mouse on mouse movement that caused such uninterruptible delay. Doing this from a callback function meant that all I/O delay and memory I/O was carried out without any chance for interrupts or other events to run. If it were guest x86 code it would have a chance to operate while allowing PIC events and interrupts as intended by the DOS application. It's Gravis Ultrasound music would not slow down anymore when moving the mouse.

[hail-to-the-ryzen]

Thanks for the technical details. I noted your commit to conditionally disable i/o delay to help with the latter issue.

If instead using "guest x86 code" to solve the problem, isn't that essentially a custom made BIOS that holds video and mouse instructions?

[TheGreatCodeholio]

Thanks for the technical details. I noted your commit to conditionally disable i/o delay to help with the latter issue.

If instead using "guest x86 code" to solve the problem, isn't that essentially a custom made BIOS that holds video and mouse instructions?

Yes. It's not going to completely replace the native callback function, but it will replace the part that renders the cursor and other graphics functions in iNT 10h.

[TheGreatCodeholio]

I've created an issue listing small DOS programs (not part of DOSBox-X) to test the behavior of DOSBox-X vs real hardware.

https://github.com/joncampbell123/dosbox-x/issues/940

Programs will also be run against DOSBox SVN, Bochs, QEMU, and VirtualBox as listed to compare behavior, but less important than DOSBox-X vs real hardware.

These will not be part of DOSBox-X, they will be standalone DOS executables.

These will be written one by one over time when free time is available.

Anyone else here is free to contribute to the test program collection if interested.

[TheGreatCodeholio]

New DOSBox-X release. https://github.com/joncampbell123/dosbo ... x-v0.82.12

[LeXa2]

Hi all and a big thanks to Codeholio for working on DosBox-X all these years.

I'm in process of migrating from old DosBox-Daum builds to DosBox-X and am a bit confused regarding the proper ways to do it. Looks like documentation on DosBox-X is scarse (except for source code) so some things end up not that clear for a newcomer.
I'm a linux system engineer and devops but my main home gaming PC runs Windows 10 as that's the only way to get Steamlink and nVIDIA Shield streaming to work properly. Thus I'm forced to use windows build of DosBox-X - which there are many.
Quick looks reveals what appears to be all possible permutations between MSVC++ vs MinGW, 32bit vs 64bit and SDL1 vs SDL2 with additional "twists" to mingw builds having "lowend" and "sdldraw" flavours.

This brings us to my first set of questions:

1. Are there any major differences between 32bit and 64bit builds? I believe I’ve read somewhere that 32bit builds might be somewhat faster due to smaller memory footprint resulting in smaller active set having more chances to stay in CPU cache. Is that the case?
   
2. I’ve heard that it is impossible to use dynamic core with 64bit build for DPMI/VCPI guest programs while for 32bit build dynamic core is OK to use with DPMI or VCPI guest processes as long as they are not messing up with virtual memory and do not use paging. Is it true?
   
3. As for SDL1 vs SDL2 builds: am I correct that SDL2 build it considered to be experimental and is still under heavy development so it is not a good idea to use it unless one want to participate in beta testing? What about the general direction of DosBox-X development, is it going to move to SDL2 as a main supported backend and move SDL1 into deprecated/obsolete status?
   
4. What are “lowend” and “sdldraw” builds for? Am I correct that “lowend” build lacks mt32 emulation and Direct3D 9 output backend? As for “sdldraw” - I’ve got no idea what differs here compared to “normal” MinGW build.
   
5. Comparing MSVC builds vs MinGW I can see that a file named “FREECG98.bmp” is included with MSVC builds but is missing from MinGW builds. Is it expected? What is this file being used for?
   
6. I had compared available output backends for all available MSVC and MinGW builds. It looks like for SDL2-based builds the only options available are “surface”, “overlay” and “ddraw”. For “sdldraw” build “opengl”, “openglnb” and “openglhq” join the available club. Same list of six variants is available for all other MinGW builds and lastly in SDL1 MSVC build “direct3d” joins the club. Is it an expected situation when Direct3D output backend is only available in MSVC builds?

Now, to a more fun part of configuring and using DosBox-X.

1. Vsync mysteries. Looking at the generated “all options” config I can see a section named “vsync”. I presume that this section controls emulations of vertical retrace notification for the guest system. There is a remark in comments about “calibration with dosbox” - what is this about? What calibration? For what vsync mode? Then, what’s the difference between the modes? What does “force” mode do? Talking about vsync I really have got a “testing bonanza” with my setup. My main monitor is a G-SYNC enabled 144Hz flat panel and quick testing using “teartest.exe” utility reveals all kinds of weird DosBox behavior depending on the output backend (OpenGL vs D3D), G-SYNC state, active monitor refresh rate and the state of the “vertical retrace” setting in nVIDIA control panel. Testing all permutations here is a huge separate topic by itself so I would probably start up a separate thread for that. Still I’d like to know more about what’s actually happening under the DosBox-X hood depending on the “vsync” option state.
   
2. 3dfx support. From what I see I assume that “voodoo” equal to “software” enables software emulation of the SST-1 chip – one that Kekko initially had been working on. It seems to be working more or less fine (tested with DOS version of GTA1 + original glide2x.ovl from 3dfx) but compared to what was available in DosBox-Daum build it seems to be lacking “voodoomem” option which allowed to select what card to emulate – original Voodoo Graphics or Voodoo2 with 12MB VRAM and 2TMUs. Am I correct that this option hadn’t been implemented (or had been dropped) in DosBox-X?
   
3. 3dfx support – again. Setting “voodoo” to “opengl” seems to do something strange. In DosBox-Daum version “opengl” value enabled what was know as “gulikoza’s patch” allowing to pass all glide2x calls from guest to host system using special glide2x.ovl version. On host glide2x calls could be handled either by the real 3dfx hardware or by any available glide wrapper. For DosBox-X it seems to be different. Gulikoza’s glide2x.ovl does not work with DosBox-X – games fail to detect 3dfx hardware. Drive Z does not contain any glide2x.ovl to be used with the game. Providing the game with original 3dfx’s overlay binary results in game working but for GTA rendering seems to be broken a bit – parts of UI and text messages are rendered as single color outlines. What is going on? Am I correct with a speculation that “voodoo=opengl” mode in DosBox-X is essentially the same as “voodoo=software” mode with both using SST-1/2 emulator by Aaron Giles with the only difference being that for “opengl” original DosBox rendering contex is being passed to emulator to speedup rendering?

Thanks once again for working on DosBox-X and thanks in advance for answering my questions above.

[TheGreatCodeholio]

DOSBox-X maintains both SDL2 support by request and 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. It also features a hack for Windows builds where the window frame message pump is in a separate thread from DOSBox-X's main thread so that sizing & moving the window or using the menus is possible without halting emulation. Others requested SDL2 support, which I am willing to provide, while 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), and the SDL2 support is based on what the library can provide since SDL2 is under active development.

DOSBox-X can be compiled to SDL1 or SDL2, chosen at compile-time. Code specific to each is separated by #ifdefs.

My modified SDL1 code supports extra features including foreign keyboards, display DPI determination, and support for menus in Windows and Mac OS X.
The SDL2 support is happy to support surface output, touchscreen support, and resizing. OpenGL support isn't implemented yet.

I originally stated that I was to implement SDL2 and phase out SDL1, but I'm not so sure about that now.

A lot of work has been done to make 32-bit and 64-bit work nearly identically where possible, including fixes to parts of the source that originally had problems with 64-bit (such as the S3 acceleration code). It used to be the case that you had to use 32-bit for the dynamic core, but 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.

The various builds should be explained:
- The main Windows builds are compiled with VS2017 community edition. They run on Windows Vista or higher. VS2017 can target Windows XP but several key C runtime functions are broken (such as stat).
- MinGW builds can run on Windows XP or higher. They are compiled with the MinGW64 project to 32-bit and 64-bit versions. Based on Kernel32 dependencies they require Windows XP or higher but might run under Windows 2000 (not sure).
- There is a MinGW build that targets MS-DOS, HDPMI and the HX-DOS/HX-GUI environment. This version uses a reduced subset of the Windows API supported by HX-GUI and runs fullscreen at all times.
- Lowend builds are meant for lower end processors, especially those that lack SSE support. The MUNT code incorporated from the Daum branch happens to require SSE, which is why lowend builds omit it.
- SDLDRAW builds for WIndows use a custom drawn menu (drawn on the SDL surface) instead of the Windows menus, for code testing.

[TheGreatCodeholio]

To explain FREECG98.bmp, DOSBox-X added support for NEC PC-98 emulation back in November 2017 (machine=pc98). The CG bitmap from ANEX86.BMP or the FONT.ROM files normally needed by emulators is copyrighted, but a contributor to the project generated a free replacement from fonts on his system. If neither ANEX86.BMP or FONT.ROM is available, FREECG98.BMP is used.

Unlike the VGA font the PC-98 character generator holds a lot more characters since it must represent ASCII, symbols, and of course some 7000-8000 Kanji.