VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 680 of 2397, by SA1988

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:
SA1988 wrote:

is it possible to separate the disk swapping of imgmount (CDROMs) from the boot command (floppies)? It isn't so reliable to switch floppies and cdroms at the same time and some programs can have problems with such configuration.

Sure. What keyboard shortcut do you think it should be assigned to?

Ctrl-Alt-F5
(originally I was thinking of Ctrl-F5 but it was designed for the OPL commands).

Reply 681 of 2397, by truth_deleted

User metadata
arromdee3 wrote:

The problem happens on the command prompt screen before running a game. This screen is stuck at 640x480 in the dosbox-x build and is not affected by windowresolution. In the ykhwong build, this screen is affected properly.

Manually apply the attached patch by use of a text editor. Do not apply automatically with the patch command. It reverts the ef2000 workaround code and Codeholio posted part of this on his web site of dosbox-x updates. The attached has a couple of additional lines which may fix the issue. If it doesn't, then I can construct another difference file between the builds. I wish you could help troubleshoot your issue. (I don't have these issues on my win32 build, hence my request that you test on your build.)

Attachments

  • Filename
    ogl.diff
    File size
    1.65 KiB
    Downloads
    98 downloads
    File comment
    revert ef2000 workaround code
    File license
    Fair use/fair dealing exception

Reply 684 of 2397, by SA1988

User metadata
Rank Member
Rank
Member

TheGreatCodeholio, I think this will be quite helpful for you about NT 3.5 and higher not booting to the installer on your fork:
http://www.c-bit.org/kb/126423/EN-US/

It is worth noting that the ide disk driver included with NT 3.5 and higher, in the boot disks, is only on disk 3, and they all bsod only after putting disk 2 but before disk 3 (I've tried NT 3.5 RTM (807) on your fork and it does that bsod).

Reply 685 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
SA1988 wrote:

TheGreatCodeholio, I think this will be quite helpful for you about NT 3.5 and higher not booting to the installer on your fork:
http://www.c-bit.org/kb/126423/EN-US/

It is worth noting that the ide disk driver included with NT 3.5 and higher, in the boot disks, is only on disk 3, and they all bsod only after putting disk 2 but before disk 3 (I've tried NT 3.5 RTM (807) on your fork and it does that bsod).

So perhaps (just guessing) Windows NT won't be able to match things up properly until DOSBox-X emulates the floppy controller directly (I/O ports) rather than just through INT 13h? Makes sense.

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

Reply 686 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:
SA1988 wrote:

Ctrl-Alt-F5
(originally I was thinking of Ctrl-F5 but it was designed for the OPL commands).

That key combination is triggering Ctrl-F5, too. Is there another Ctrl-Alt-X key combination which isn't bound to a Ctrl-X function?

Anyone have any suggestions?

Also worth nothing is that CTRL+ALT+<any function key> isn't really workable under Linux, some X configurations map that to VT terminal switching.

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

Reply 688 of 2397, by arromdee3

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

Manually apply the attached patch by use of a text editor. Do not apply automatically with the patch command. It reverts the ef2000 workaround code and Codeholio posted part of this on his web site of dosbox-x updates. The attached has a couple of additional lines which may fix the issue. If it doesn't, then I can construct another difference file between the builds. I wish you could help troubleshoot your issue. (I don't have these issues on my win32 build, hence my request that you test on your build.)

Manually applying that patch fixes the problem with the screen going to 640x560, 640x640, etc. but I already knew that. It does *not* prevent the dosbox command prompt screen (and any non-Voodoo screen within the program) from being stuck at 640x480.

(Also, shouldn't the command prompt screen be at 640x400, not 640x480?)

Reply 689 of 2397, by truth_deleted

User metadata

Thanks for the IDE updates!

@arromdee3
If I ever find the time, I'll install linux and try to replicate your issue.

You may also test the effect of deleting these lines:

	glViewport( 0, 0, v->fbi.width, v->fbi.height );
last_width = v->fbi.width;
last_height = v->fbi.height;

/*glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glOrtho( 0, v->fbi.width, v->fbi.height, 0, -1, 1 );
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();*/
// END OF FIX

Reply 691 of 2397, by Zorbid

User metadata
Rank Member
Rank
Member
arromdee3 wrote:

(Also, shouldn't the command prompt screen be at 640x400, not 640x480?)

The real DOS prompt uses a 720x400 text mode with non-square pixels (on VGA systems). I believe the DOSBox authors have chosen 640x480 for its natural aspect ratio on modern screens.

EGA and CGA systems use 640x350 and 640x200, respectively.

Reply 692 of 2397, by arromdee3

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

You may also test the effect of deleting these lines:

Deleting those lines has no effect.

I was not expecting them to since voodoo=false (but output=opengl) results in every screen being 640x480 regardless of windowresolution

Reply 693 of 2397, by Gui55

User metadata
Rank Newbie
Rank
Newbie

Can someone please help me confirm that all of the Windows binaries that TheGreatCodeholio compiled both on hackipedia and github do not allow 'imgmount'-ing of more than one CD image on the same cmd line without instantly crashing? I need someone to help me confirm that this is only a bug with the Windows binaries he compiled. Thanks!

(Note: I tested Codeholio's Jan. 25th win32 binary on hackipiedia against ykhwong's Jan. 27th Windows build, same exact .conf settings, and ykhwong's worked just fine.)

IE 5.5 SP2

Reply 694 of 2397, by Gui55

User metadata
Rank Newbie
Rank
Newbie

Also, here is the generated stderr.txt file from the July 19 release on github from when after it crashes.

Attachments

  • Filename
    stderr.txt
    File size
    3.65 KiB
    Downloads
    76 downloads
    File license
    Fair use/fair dealing exception

IE 5.5 SP2

Reply 696 of 2397, by truth_deleted

User metadata

Attached a mingw32 version of dosbox-x (built from 7/19/14 git code; same version as the win32 release built by VS2008). This should mount multiple CD images; however, many lines of code were changed to port to the mingw/gcc environment. This may help isolate the cause of the multiple image mount issue.

Disabled d3d and fluidsynth to compile, although these should have no effect on the mounting of images. Also, added a block of unverified lines to menu.h to recognize the variable "_MAX_DRIVE":
# include "windows.h"
# include "Shellapi.h"
# include "shell.h"
# include "SDL_syswm.h"

Removed dependency of dos_files.cpp on dos_network2 and removed a block of code in sdl_main (?) to avoid errors generated by the newer C++ standard (also removed this parameter from configure).

The attached is only for verifying that the issue is minor and probably related to the build process or a missing header file (although this should produce an error). I'll remove the attached test binary within a day.

Edit: binary removed.

Last edited by truth_deleted on 2014-09-19, 05:16. Edited 2 times in total.

Reply 697 of 2397, by truth_deleted

User metadata
arromdee3 wrote:

It does not prevent the dosbox command prompt screen (and any non-Voodoo screen within the program) from [not scaling].

I interpret your issue as "not scaling" (is "stuck" slang for this?). Confirmed this issue in the win32 version. However, scaling works properly where setting output=ddraw and output=openglhq (unverified whether dosbox-x does not actually enter those modes and reverts to surface, however).

Edit: also, the scaling works for other output modes (first test with output=surface) while using the parameter "forced" along with the scaling method, such as normal2x. Tried this by the menu options, although the dosbox.conf has a line for setting these values. This should be verified in the linux version, or at least the linux version in question.

Last edited by truth_deleted on 2014-09-19, 05:23. Edited 1 time in total.

Reply 698 of 2397, by Gui55

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

The attached is only for verifying that the issue is minor and probably related to the build process or a missing header file (although this should produce an error). I'll remove the attached test binary within a day.

Thank-you truth5678, I've verified it now works. I don't have the knowledge for compiling my own binary like some, but maybe GreatCodeholio could fix this same thing (if he plans do make another win32 release).

IE 5.5 SP2