DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby Shane32 » 2018-2-25 @ 06:49

The Direct3D option? What's wrong with it? That's what I always use.
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-25 @ 06:54

And disable the menu item (core =) Dynamic where paging is enabled. Also, the user should receive a warning message if pressing the keys to switch to the dynamic core while paging is enabled.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-26 @ 05:14

The Alpha Centauri demo with sound on results in a page fault in Windows 95. This occurs in other versions and is also independent of the dosbox-x settings. If its sound routines are not sensitive to cpu cycles, then it may be related to the dosbox-x page fault handling system.

The above issue has infrequently occurred in real hardware, but early versions of PCem do not have the issue.

The workaround is to disable audio by renaming sound.dll in the game directory.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-27 @ 02:26

Did the COMMDLG.DLL debug log to screen occur in both W31 enhanced and standard mode? Also, while booting a W31 image or from a local directory?
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-27 @ 02:28

Apparently it happens in both 286 standard and 386 enhanced modes. This is running Windows 3.1 from a local directory, under the DOSBox-X DOS kernel.
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-27 @ 03:09

I haven't yet been able to reproduce the issue in the latest win32 dosbox-x. Using xms=ems=umb=true and sb2 sound.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-27 @ 03:12

COMMDLG.DLL is 89248 bytes and last modified on 3/10/92.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-27 @ 03:25

It only seems to happen with that specific version of Windows 3.1. Windows 3.0 and Windows 3.11 don't display the message. I'll finish up the changes from Windows and then boot back into Linux to check the COMMDLG.DLL version on my end.
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-27 @ 17:35

COMMDLG.DLL in my Windows 3.1 setup is also 89248 bytes. I don't have the last modified date on my system.
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby tlk » 2018-2-28 @ 16:51

Hi TheGreatCodeholio and thank you for your efforts on d-x.
Have a small q: why do you have to disable fullscreen (or any scaling at all?) with OGL Voodoo emulation?
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-28 @ 18:14

The OGL voodoo emulation is very delicate from it's design. It seems to take the OpenGL context DOSBox-X would normally use itself and set it up to become the state the DOS game uses through the hardware, including video resolution.

The problem is that any change of window size or any resize event destroys this delicate setup and messes up the graphics.

The proper fix for the issue would be two major changes.

One, the OGL voodoo emulation needs to allocate it's own OpenGL context and leave DOSBox-X's GFX context alone. Then they won't conflict and a lot of the delicate balancing act could be eliminated in sdlmain.cpp.

Two, resizing of the window could be re-enabled if the 3Dfx OGL code rendered to a texture instead (if the client area of the window did not match the resolution), and the GFX code then drew the texture to the window. You could then resize the window as you see fit while the DOS game within continued to see the 640x480 or whatever video framebuffer it expects to draw to.
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby tlk » 2018-2-28 @ 18:35

Thanks.
Also there's the issue of corruption/flickering of static elements (like hud/cockpit) I see in both Archimedean Dynasty and Carma... Actually for me Carma won't render any menus at all (have to push enter blindly), and in AD the screen with the mission briefing is likewise totally black. Could be related to (1) tho?
Anyway, still hoping to play AD w/glide one day on Linux... The reason I became interested in this Voodoo on Dosbox stuff in the first place)) Seems that it's possible with nGlide on windowz...
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: DOSBox-X branch

Postby Myloch » 2018-2-28 @ 18:48

This project really regained new life recently and I really appreciate the fact beta version binary builds are easy to find now (Did I say emucr?)

However I see some weird bugs with opengl output rendering (the standard one, not opengl voodoo) still here (you can see stills of old screens when changing graphic mode or when the whole screen image changes). I know it's hard to understand from my words what the bug is about, I'll try to document the thing with some video captures.
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
User avatar
Myloch
Member
 
Posts: 425
Joined: 2007-4-18 @ 22:13

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-2-28 @ 22:49

For the memory-backed disk image code, it may be worthwhile to bypass the capability to produce DOS 1.X floppy images (fatDrive::fatDriveInit in drive_fat.cpp):
Code: Select all
+   if ((bootbuffer.mediadescriptor & 0xf0) != 0xf0 && filesize <= 360) {
+      LOG_MSG("DOS 1.x format floppy not supported in this code path for memory-based disk images");
+      created_successfully = false;
+             return;
+   }

If this is considered, then the above also requires an additional condition on whether the image is memory-based or not, so that non-memory-based images can create that kind of floppy.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-2-28 @ 23:00

Thanks for the suggestion, that would be Shane32's work: https://github.com/joncampbell123/dosbox-x/pull/565
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Shane32 » 2018-2-28 @ 23:33

As it is now, the memory-backed disk code simply emulates a hard drive attached to the emulator, regardless of the type of formatting it has - just the same as mounting a vhd file would. It is automatically formatted so it is immediately available for use by the system. I'm not sure I understand what benefit it would have to place additional limitations on memory-backed disks, assuming the file structure was supported by the rest of DosBox. Am I missing something?
User avatar
Shane32
Newbie
 
Posts: 12
Joined: 2018-1-01 @ 15:28

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-3-01 @ 01:40

That's fine.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-3-01 @ 05:04

The MS-DOS 6.22 Supplemental package (SUP622.EXE) has Accessibility programs. However, FAKEMOUS doesn't detect the PS/2 port even though it is active in DOSBox-X, and the ADOS.COM menu item "mousekeys" is not available. This is a function where the mouse motion and buttons are controlled from the keyboard number pad.

However, the Windows 3.1 Accessibility Pack (ACCP.EXE) for 16-bit and its mousekeys function do work in DOSBox-X: http://www.mdgx.com/w31toy.htm.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2018-3-02 @ 07:24

With latest DOSBox-X, Alpha Centauri with sound exits with an error type 13 in cpu.cpp:
E_Exit("CALL:Descriptor type %x unsupported",(int)call.Type())

Cpu.h shows the definitions of these (descriptor) types, for example:
#define DESC_386_CALL_GATE 0x0c
#define DESC_386_INT_GATE 0x0e
#define DESC_386_TRAP_GATE 0x0f

Noted that the code comments about "this code isn't very easy to make interruptible".

I think PCem has similar code in loadcscall(), and it is appears interruptible. The alternative is that the above error is an after effect of the true issue.
hail-to-the-ryzen
Member
 
Posts: 245
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-3-02 @ 19:48

I found a Windows version of Alpha Centauri (a demo).

Seems to be working fine so far.

Are you using dynamic core?

guest os_000.png
You do not have the required permissions to view the files attached to this post.
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: 564
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests