DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-11 @ 03:36

When exiting Quake, and possibly other 32-bit DOS games, in a Windows 95 OSR2 dos box (video driver=9x vesa driver), then often the mouse cursor will move slowly until exiting the dos box. Since it doesn't occur every time, I wonder if a time delay between video modes would workaround the issue or verifying by a log that the mouse cursor is aware of the resolution change.
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-12 @ 09:57

The Windows 95 dos box generates page faults related to video mode and cmos in OSR2 version. Is it instead better to run the retail version of Win95 since it has write capability to the linearly mapped bios data area? Is there a plan to emulate both the reading and writing of the cmos registers?
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-12 @ 14:26

hail-to-the-ryzen wrote:The Windows 95 dos box generates page faults related to video mode and cmos in OSR2 version. Is it instead better to run the retail version of Win95 since it has write capability to the linearly mapped bios data area? Is there a plan to emulate both the reading and writing of the cmos registers?


I'm not exactly sure why Windows 95 OSR2 faults like that when changing video mode. OSR2 is a bit weird.

CMOS emulation is already there, but inherits the DOSBox SVN design limitations of faking the values on the fly without support for writing.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-12 @ 22:06

Thank you for the helpful insight. I think that the OSR2 dos box with 9x vesa driver has some dependence on timing and the audio driver where returning to a window from Quake. The minor issue is avoided by running dos box with mouse in exclusive mode or in full screen mode. It is possible that real hardware is no better.

A greater concern is that the output=opengl mode now has a long time delay where switching from window to full screen mode. I noted it today, but it occurs in my current build and one I built in March. I think it may be from the yesterday's Windows 10 update. I haven't tested for the issue in other builds yet.
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-12 @ 22:15

hail-to-the-ryzen wrote:Thank you for the helpful insight. I think that the OSR2 dos box with 9x vesa driver has some dependence on timing and the audio driver where returning to a window from Quake. The minor issue is avoided by running dos box with mouse in exclusive mode or in full screen mode. It is possible that real hardware is no better.

A greater concern is that the output=opengl mode now has a long time delay where switching from window to full screen mode. I noted it today, but it occurs in my current build and one I built in March. I think it may be from the yesterday's Windows 10 update. I haven't tested for the issue in other builds yet.


It's probably just Windows 10.

I remember sometime around April-May the latest update broke the asynchronous SDL window code. Apparently if thread 2 resizes a window while thread 1 is busy with the user resizing the window, something in Windows gets wedged and you can't move/resize the window anymore. I had to add a critical section to avoid that conflict.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-12 @ 22:41

Thank you. I just tested a HXDOS build and it shows the same issue.
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-12 @ 22:52

Confirmed the same problem in vanilla dosbox with its SDL library. The 8/11/18 Windows 10 update must have caused the delay in opengl video output where switching to fullscreen mode. It doesn't seem to happen in a custom build with opengl-hq, however.

It is possible that it only occurs in particular video hardware. Tested with an AMD HD6xxx card and driver.
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-12 @ 23:04

Reproduced the same issue in other clients, including a quake port to sdl12/opengl and a sdl2 version of dosbox running with renderer=opengl.
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-16 @ 05:56

The serial mouse doesn't seem to work in DOS (ctmouse driver). Is it still functional with serial1=serialmouse? Also, is the menu updated for the absence of "internal mouse emulation" where the mouse emulation is disabled in the configuration file?
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-16 @ 06:07

hail-to-the-ryzen wrote:The serial mouse doesn't seem to work in DOS (ctmouse driver). Is it still functional with serial1=serialmouse? Also, is the menu updated for the absence of "internal mouse emulation" where the mouse emulation is disabled in the configuration file?


serial1=serialmouse should still work. You may need to tell CTMOUSE specifically to look for the mouse on the serial port, it might be locking onto the PS/2 mouse emulation instead.

You may also want to set int33=false first before running CTMOUSE.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-8-16 @ 06:22

I had already tried both those suggestions (int33=false; ctmouse.exe /S1).
hail-to-the-ryzen
Member
 
Posts: 219
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby Danfun64 » 2018-8-17 @ 03:15

Is it possible to get either the timidity or mt32 mididevice to work with the windows builds from the Dosbox-X Releases github page? Also, is there a way to use the record function without losing FPS (I did a Doom timedemo, there's a definite difference with recording on and off)? Thanks in advance!
Danfun64
Newbie
 
Posts: 90
Joined: 2009-11-15 @ 20:33

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-17 @ 04:07

Danfun64 wrote:Is it possible to get either the timidity or mt32 mididevice to work with the windows builds from the Dosbox-X Releases github page? Also, is there a way to use the record function without losing FPS (I did a Doom timedemo, there's a definite difference with recording on and off)? Thanks in advance!


I assume you're capturing video to AVI, not to the MPEG-TS format (Windows builds lack the MPEG-TS capture mode)?

Video capture has always added to the CPU requirements, even in the code inherited from DOSBox SVN.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby awgamer » 2018-8-17 @ 18:35

I don't if you've checked out this thread but there's a cpu tester that looks like it might be able to be run on dosbox-x. viewtopic.php?f=9&t=56440&start=140#p691912
awgamer
Member
 
Posts: 444
Joined: 2014-7-26 @ 07:42

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-17 @ 18:44

awgamer wrote:I don't if you've checked out this thread but there's a cpu tester that looks like it might be able to be run on dosbox-x. viewtopic.php?f=9&t=56440&start=140#p691912


Custom code to stress test the CPU is always welcome. Just like the early demoscene and all the weird custom code and anti-debugger stuff they use :)
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-17 @ 18:50

Also if anyone is interested, I just got ahold of an old IBM PS/2 model 30 8086-based system from eBay that has MCGA graphics.

That and two old books would enable DOSLIB to test MCGA graphics and DOSBox-X to add machine=mcga.

Unlike CGA/EGA testing, I won't need a converter for the video output since MCGA uses the same 15-pin VGA connector.

From what little I've gathered, MCGA is a weird superset of CGA hardware that can also do 640x480 monochrome and 320x200 256-color graphics modes.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Scali » 2018-8-17 @ 20:02

TheGreatCodeholio wrote:From what little I've gathered, MCGA is a weird superset of CGA hardware that can also do 640x480 monochrome and 320x200 256-color graphics modes.


That's one way to look at it. The other way (the one I generally use) is that it's a dumbed-down version of VGA. It supports VGA monitors, and the 640x480 and 320x200 modes that VGA offers, and the VGA palette.
However, it lacks the 'fancy' stuff that was introduced with EGA and VGA, so it has no hardware scrolling, no ALU, etc. So it basically acts much like CGA did: little more than a dumb framebuffer. As such, it is neither EGA- nor VGA-compatible (and has only limited BIOS-level CGA compatibility, like EGA/VGA do).
Many games support 'MCGA/VGA', because MCGA is a nice 'lowest common denominator' between the two: any MCGA code also works on any VGA-compatible hardware. Most PC games from that era didn't use any fancy scrolling, ALU or other trickery.
Scali
l33t
 
Posts: 3457
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-17 @ 20:58

Scali wrote:
TheGreatCodeholio wrote:From what little I've gathered, MCGA is a weird superset of CGA hardware that can also do 640x480 monochrome and 320x200 256-color graphics modes.


That's one way to look at it. The other way (the one I generally use) is that it's a dumbed-down version of VGA. It supports VGA monitors, and the 640x480 and 320x200 modes that VGA offers, and the VGA palette.
However, it lacks the 'fancy' stuff that was introduced with EGA and VGA, so it has no hardware scrolling, no ALU, etc. So it basically acts much like CGA did: little more than a dumb framebuffer. As such, it is neither EGA- nor VGA-compatible (and has only limited BIOS-level CGA compatibility, like EGA/VGA do).
Many games support 'MCGA/VGA', because MCGA is a nice 'lowest common denominator' between the two: any MCGA code also works on any VGA-compatible hardware. Most PC games from that era didn't use any fancy scrolling, ALU or other trickery.


If it was just VGA with missing features, I'd call it that.

According to the PS/2 and VGA graphics book I have (the only one I have that even documents some of the MCGA registers!) the register set is more CGA-like than VGA. It has the VGA-like DAC registers (if fractint source code is correct), but also has CGA compatible CRTC registers with additional registers specific to the MCGA, and it has a "mode" register that is like CGA. There are also references to hardware state that suggests it counts scanlines including the top/bottom of the hardware cursor as if 200-line CGA and then it doubles the scanlines in hardware. The description implies that it only has 64KB of video RAM, and that video memory is mapped to B8000-BFFFF like CGA with B0000-B7FFF holding the character generator RAM in text modes (though in a very strange format).

Having the actual hardware on hand would verify this is true, as well as fill out all the details of MCGA since even the book has holes in it's documentation.
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: 540
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-8-17 @ 21:01

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

Re: DOSBox-X branch

Postby Danfun64 » 2018-8-18 @ 07:33

My first question wasn't answered.
Danfun64 wrote:Is it possible to get either the timidity or mt32 mididevice to work with the windows builds from the Dosbox-X Releases github page?
Danfun64
Newbie
 
Posts: 90
Joined: 2009-11-15 @ 20:33

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: Google [Bot] and 1 guest