DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby Hadden » 2018-9-21 @ 18:39

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).
Hadden
Newbie
 
Posts: 1
Joined: 2015-11-29 @ 22:54

Re: DOSBox-X branch

Postby stamasd » 2018-9-22 @ 12:36

Still interested in finding a solution to my LPT problem, see description in my post on the previous page in the thread.
I/O, I/O,
It's off to disk I go,
With a bit and a byte
And a read and a write,
I/O, I/O
stamasd
Oldbie
 
Posts: 1657
Joined: 2014-8-31 @ 19:59
Location: Connecticut

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-04 @ 05:15

stamasd wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-04 @ 05:18

Hadden wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Timbi » 2018-11-07 @ 00:18

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.
User avatar
Timbi
Newbie
 
Posts: 10
Joined: 2016-4-11 @ 09:07

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-07 @ 01:16

Timbi wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Timbi » 2018-11-14 @ 15:39

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?
User avatar
Timbi
Newbie
 
Posts: 10
Joined: 2016-4-11 @ 09:07

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-14 @ 15:42

Timbi wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Timbi » 2018-11-15 @ 02:02

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
User avatar
Timbi
Newbie
 
Posts: 10
Joined: 2016-4-11 @ 09:07

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-11-15 @ 05:57

"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
Member
 
Posts: 248
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-11-18 @ 22:01

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?
hail-to-the-ryzen
Member
 
Posts: 248
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-19 @ 00:16

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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-19 @ 00:24

TheGreatCodeholio wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-11-19 @ 05:13

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?
hail-to-the-ryzen
Member
 
Posts: 248
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-11-19 @ 05:31

hail-to-the-ryzen wrote: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.
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: 571
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest