VOGONS

Common searches


DOSBox-X branch

Topic actions

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

User metadata
Rank Member
Rank
Member

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.

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

User metadata
Rank Member
Rank
Member

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?

Reply 1522 of 2397, by TheGreatCodeholio

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

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

User metadata
Rank Member
Rank
Member

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.

Reply 1524 of 2397, by TheGreatCodeholio

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

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

User metadata
Rank Member
Rank
Member

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.

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

User metadata
Rank Member
Rank
Member

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?

Reply 1529 of 2397, by TheGreatCodeholio

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

Reply 1531 of 2397, by Danfun64

User metadata
Rank Member
Rank
Member

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!

Reply 1532 of 2397, by TheGreatCodeholio

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

Reply 1534 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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. test386.asm CPU tester

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.

Reply 1535 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1536 of 2397, by Scali

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

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1537 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:
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 […]
Show full quote
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.

Reply 1538 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I took notes from the book as well:

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

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

Reply 1539 of 2397, by Danfun64

User metadata
Rank Member
Rank
Member

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?