VOGONS


First post, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

With the help of advice from ripsaw8080 and h-a-l-9000, I've been able to add native 50-line and 66-line video modes to my project, and created internal commands to turn them on. (Details later in this post.) The one problem I haven't been able to solve is this:

If I try to switch to 66-line mode when the screen is not tall enough to display all 66 lines (this is the case in my OS X build and my MacBook Air), then DOSBox seems to lock up (though in fact, it simply doesn't display any typed characters, and I can blindly type a command to return to VGA mode.) I wonder if anyone knows any code that I can add to the command that turns on 66-line mode so it can detect the vertical dimension of the screen, and not do anything if the screen is too tall.

Here are the details.

I added these two modes to int10_modes.cpp:

/* info from ripsaw8080 - 50-line mode */
{ 0x057 ,M_TEXT ,720, 800, 80, 50, 9, 16, 1 ,0xB8000 ,0x2000, 100, 800, 80, 800, 0 },
/* info from h-a-l-9000 - 66-line mode */
{ 0x058 ,M_TEXT ,720,1056, 80, 66, 9, 16, 1 ,0xB8000 ,0x3000, 100, 1100,80,1056, 0 },

And I added these commands to dos_programs.cpp; first this:

class LINE50 : public Program {
public:
void Run(void);
};

void LINE50::Run(void) {
reg_ax=0x0057;
CALLBACK_RunRealInt(0x10);
}

static void LINE50_ProgramStart(Program * * make) {
*make=new LINE50;
}

// 66lines - needs code to block when screen too large

class LINE66 : public Program {
public:
void Run(void);
};

void LINE66::Run(void) {
reg_ax=0x0058;
CALLBACK_RunRealInt(0x10);
}

static void LINE66_ProgramStart(Program * * make) {
*make=new LINE66;
}

then this, just above the closing curly bracket at the foot of the file:

    PROGRAMS_MakeFile("50LINES.COM", LINE50_ProgramStart);
PROGRAMS_MakeFile("66LINES.COM", LINE66_ProgramStart);

The question, again, is, can I add something to the 66line that will cause it to perform no operation if the screen height is smaller than, say, 1000? (The full height of the 66-line mode is 1056, but I want to allow for at least 40 pixels for the topline menu in OS X and the title bar on a window.)

Thanks for any help with this.

EDIT: Corrected misstatement that DOSBox locks up.

Last edited by emendelson on 2013-07-21, 16:01. Edited 1 time in total.

Reply 1 of 6, by VileR

User metadata
Rank l33t
Rank
l33t

Sounds like something on the SDL side of things - the functionality to detect the desktop resolution does exist, e.g. setting "fullresolution=desktop", so that's a good place to start looking. However, DOSBox locking up probably means that something else is wrong...

Of course, another approach is to use a different character height than 16. 8 or 14 may fit more comfortably.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 2 of 6, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

You posted just as I was about to fix my original post. Under OS X, DOSBox doesn't lock up when I switch to 66 lines - but nothing that I type at the command line is visible. So all I have to do is type (blindly) the command to shift to another resolution, and everything is all right again.

But I'll definitely look in the SDL code for the solution to this. A recent commit to SVN made use of the full resolution size, if I remember correctly, and that's where to start - thank you!

Reply 3 of 6, by NY00123

User metadata
Rank Member
Rank
Member

Assuming what you're using is based on vanilla DOSBox (SVN) without a lot of unofficial modifications, maybe output=surface is the case of the lock up in some way? Basically, if the window isn't sufficiently large, then with output=surface DOSBox tries to draw to a rectangle that does not fit in the window, or something like that. This can easily lead to undefined behavior (basically a kind of buffer overflow).

Reply 4 of 6, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
NY00123 wrote:

Assuming what you're using is based on vanilla DOSBox (SVN) without a lot of unofficial modifications, maybe output=surface is the case of the lock up in some way? Basically, if the window isn't sufficiently large, then with output=surface DOSBox tries to draw to a rectangle that does not fit in the window, or something like that. This can easily lead to undefined behavior (basically a kind of buffer overflow).

You're right that I'm using output=surface, but the same behavior occurs with opengl, openglnb, and overlay: under OS X, if I switch to a mode larger than the screen size, the screen displays a C:\> prompt, but nothing that I type is visible. If I type the command to switch back to 25lines, then DOSBox returns to normal.

I'm using a heavily customized build that I post on another site, and I'd like to be able to let other users avoid this problem if possible, but of course it's not a serious problem. I'm still looking in sdlmain.cpp in the hope of figuring out an answer.

Reply 5 of 6, by NY00123

User metadata
Rank Member
Rank
Member
emendelson wrote:

You're right that I'm using output=surface, but the same behavior occurs with opengl, openglnb, and overlay: under OS X, if I switch to a mode larger than the screen size, the screen displays a C:\> prompt, but nothing that I type is visible. If I type the command to switch back to 25lines, then DOSBox returns to normal.

Does that behavior consist of a lock up?

EDIT: Oh, wait a second...

emendelson wrote:

You posted just as I was about to fix my original post. Under OS X, DOSBox doesn't lock up when I switch to 66 lines - but nothing that I type at the command line is visible. So all I have to do is type (blindly) the command to shift to another resolution, and everything is all right again.

Yeah, that seems to make sense. Still surprised it occurs with any output other than surface, though. (Thinking these should scale stuff to fit in the window.)

Reply 6 of 6, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There is a size check in the renerer code which limits the output to 1280x1024.

#define SCALER_MAXWIDTH	1280 
#define SCALER_MAXHEIGHT 1024

in render_scalers.h

1+1=10