Developer Forum

I have an old DOS program that runs in a cmd.exe window which can be made to
use the full screen with Alt-Enter. This works properly on another win200
machine, but on a Toshiba laptop the full screen mode fills the width but
NOT the height of the screen.

I've made sure that the Properties and the Console Windows Properties of the
C:\winnt\system32\cmd.exe window are the same on both machines, using Raster
Fonts 8x12 and the same Layout, Screen Buffer 80x420 and Window Size 80x25.

Still, the fullscreen mode on the laptop doesn't fill the vertical of the
screen for any cmd.exe application, even just a command prompt.

What am I mssing here, please?

In the dark ages I had one at wotk which had a FN key
function to toggle just that "DOS" screen property.
So check out your function keys.

Most likely, you are missing the fact that the digital display has fixed
numbers of pixels vertical and horizontal (and therefore a fixed aspect
ratio), and that only video modes that evenly divide those numbers and
have the same aspect mode can be displayed properly - anything else will
have to be underscanned in one direction or another, and many modes have
to be dithered as well to get them to display at all. Sometimes the
mismatch is so severe that the display can't show a stable picture at all.

The only solutions are to accept that digital reality is quantitised or
to use an analog monitor.

--

T.E.D. ( XXXX@XXXXX.COM ) MST (Missouri University of Science and Technology)
used to be UMR (University of Missouri - Rolla).

Ted Davis < XXXX@XXXXX.COM > typed:


No, I'm not missing that fact. The aspect ratio on the working display is
1152/864 = 4/3 = 1.3333..., the same as on the 800/600 laptop display.

The working DOS full screen is 640 x 480. 640 does not evenly divide 1152,
nor does 480 evenly divide 864 - the attempt to display 640 x 480 on 1152
x 864 necessarily results in siginificant compromises and approximations.

--

T.E.D. ( XXXX@XXXXX.COM ) MST (Missouri University of Science and Technology)
used to be UMR (University of Missouri - Rolla).

Sjouke Burry < XXXX@XXXXX.COM > typed:


Thank you, that seems to make the most sense, but trying all the various FN
keys doesn't resolve the problem. I'll try to find the user's manual online
somewhere and refer to that. The manufacturer's web site seems terribly
convoluted.

Am Sun, 8 Jun 2008 09:41:27 -0700 schrieb ynotssor:



But the grid of character cells scales not properly in this higher
resolution?

Dirk

On Sun, 08 Jun 2008 11:05:07 -0500, Ted Davis < XXXX@XXXXX.COM > put
finger to keyboard and composed:




I just tried full screen DOS mode on a Win98 socket 7 desktop PC with
a 15" 1024x768 LCD monitor (with an analogue interface).

For 80 cols x 25 rows, my LCD reports that my graphics card resolution
is 720x400. This would equate to a cell size of 9Hx16V. Allowing for a
single pixel between characters (have I got this right?), that would
mean a font size of 8Hx15V.

Doing the same for 80Cx50R, we get 720x400 resolution, a cell size of
9Hx8V, and a font size of 8Hx7V.

Again for 80Cx43R (mode co80,43), we get 640x350 resolution, 8x8 cell
size (with 6 pixels left over in the vertical direction), and a font
size of 7x7.

I obtained identical results on a 486 Win95 box when booted in real
DOS mode (different graphics chipset). I presume the fonts (and font
sizes) are hard coded into the video ROM BIOS of the graphics card.

Would it be possible to experiment with an external monitor that could
detect the resolution being output by the laptop's graphic subsystem?
Would that reflect the resolution being used by the internal display?

BTW, in Win98SE, the font size selected in a windowed DOS box (eg the
OP's 8x14) is ignored when switching to full screen mode. I have no
idea whether Win2K behaves the same way.

I suggest that the OP takes accurate measurements of the width and
height of a DOS text screen in full screen mode. Maybe the measured
aspect ratio will give a clue as to what is going on.

Could the OP's issue be addressed by means of a .cpi file?
http://www.yqcomputer.com/

Would command.com and cmd.exe produce different results?

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

Am Fri, 13 Jun 2008 16:08:50 +1000 schrieb Franc Zabkar:

Yes, here is an example to find the 8x8 font on my ATI x800 pro:
Pointer 1Fh shows C000:72D4
0000:007C D4 72 00 C0

The same location i get with:
mov ax, 1130h
xor bh, bh
int 10h
Results:
ES = C000
BP = 72D4

RBIL->inter61a.zip->Interrup.a
--------V-101130-----------------------------
INT 10 - VIDEO - GET FONT INFORMATION (EGA, MCGA, VGA)
AX = 1130h
BH = pointer specifier
00h INT 1Fh pointer
01h INT 43h pointer
02h ROM 8x14 character font pointer
03h ROM 8x8 double dot font pointer
04h ROM 8x8 double dot font (high 128 characters)
05h ROM alpha alternate (9 by 14) pointer (EGA,VGA)
06h ROM 8x16 font (MCGA, VGA)
07h ROM alternate 9x16 font (VGA only) (see #00021)
11h (UltraVision v2+) 8x20 font (VGA) or 8x19 font (autosync EGA)
12h (UltraVision v2+) 8x10 font (VGA) or 8x11 font (autosync EGA)
Return: ES:BP = specified pointer
CX = bytes/character of on-screen font (not the requested font!)
DL = highest character row on screen
Note: for UltraVision v2+, the 9xN alternate fonts follow the corresponding
8xN font at ES:BP+256N
BUG: the IBM EGA and some other EGA cards return in DL the number of rows
on
screen rather than the highest row number (which is one less).
SeeAlso: AX=1100h,AX=1103h,AX=1120h,INT 1F"SYSTEM DATA",INT 43"VIDEO DATA"

Format of alternate font table [array]:
Offset Size Description (Table 00021)
00h BYTE character to be replaced (00h = end of table)
01h N BYTEs graphics data for character, one byte per scan line
--------------------------------------------------------------------

C000:72D4
3C ..xxxx..
66 .xx..xx.
C0 xx......
66 .xx..xx.
3C ..xxxx..
18 ...xx...
CC xx..xx..
78 .xxxx...

00 ........
C6 xx...xx.
00 ........
C6 xx...xx.
C6 xx...xx.
CE xx..xxx.
76 .xxx.xx.
00 ........

0E ....xxx.
00 ........
7C .xxxxx..
C6 xx...xx.
FE xxxxxxx.
C0 xx......
7C .xxxxx..
00 ........

Dirk

On Fri, 13 Jun 2008 16:08:50 +1000, Franc Zabkar
< XXXX@XXXXX.COM > put finger to keyboard and composed:


Sorry, I got it wrong. It seems that any single-pixel character
separation is accounted for in the font. So font size = cell size.

Furthermore, after switching between 25/43/50 row screen modes (in
real DOS mode), I eventually achieved a font/cell size of 8x14 at a
resolution of 640x350 for "mode c080,25". At other times the same mode
setting resulted in a 720x400 resolution and a 9x16 font.

The following sequence illustrates what happens:

mode co80,50 -> 720x400, 9x8 font
mode co80,25 -> 720x400, 9x16 font
mode co80,43 -> 640x350, 8x8 font
mode co80,25 -> 640x350, 8x14 font

For my testing I found that filling two consecutive lines with ASCII
character 177 best illustrated the above.

Maybe the OP could try a "mode co80,43" command followed immediately
by "mode co80,25" ???

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.