VOGONS

Common searches


DOSBox-X branch

Topic actions

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

User metadata
Rank Member
Rank
Member

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.

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

User metadata
Rank Member
Rank
Member

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.

Reply 1384 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1387 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1388 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1390 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1391 of 2397, by tlk

User metadata
Rank Newbie
Rank
Newbie

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...

Reply 1392 of 2397, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

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"

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

User metadata
Rank Member
Rank
Member

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):

+	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.

Reply 1394 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1395 of 2397, by Shane32

User metadata
Rank Newbie
Rank
Newbie

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?

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

User metadata
Rank Member
Rank
Member

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.

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

User metadata
Rank Member
Rank
Member

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.

Reply 1399 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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
Filename
guest os_000.png
File size
272.51 KiB
Views
944 views
File license
Fair use/fair dealing exception

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