🚀 go-pugleaf

In article <2090@calvin.EE.CORNELL.EDU> richard@calvin.EE.CORNELL.EDU (Richard Brittain) writes:
>I have already established that the gettextinfo() routine does not return
>the correct screen size but I think I can fix that.

Alright then, how do you do this.  I want a routine which will tell me
whether I'm in 25,43, or 50 line mode.


-- 
Eric A. Raymond  (raymond@ptolemy.arc.nasa.gov)
G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James

In article <2980@einstein.ptolemy.arc.nasa.gov> raymond@einstein.arc.nasa.gov.UUCP (Eric A. Raymond) writes:
>In article <2090@calvin.EE.CORNELL.EDU> richard@calvin.EE.CORNELL.EDU (Richard Brittain) writes:
>>I have already established that the gettextinfo() routine does not return
>>the correct screen size but I think I can fix that.
>
>Alright then, how do you do this.  I want a routine which will tell me
>whether I'm in 25,43, or 50 line mode.

	Well, I hate it when people post replies that are not true, but working from
my manual (like I said, I don't have the hardware to actually test this)
BIOS data area:
0040:004a	# characters per line 16 bit int
0040:004c	# bytes required for 1 screenful of data - 16 bit int 
0040:0084	# rows-1 - 1 byte
0040:0085	# scan lines per character (i.e. height of cell) - 16 bit int
If these are set correctly (The last two only for EGA/VGA/MCGA) then that
should be all you need.
Alternatively:
BIOS INT 10H
function AH=0F  Get mode - should return characters/line as well as mode.
Hopefully the 'non-standard' modes also return this correctly
function AX=1130 Get character generator info (EGA/VGA/MCGA) returns #rows-1
and bytes/character in the 'alternate' font table.

The gettextinfo() routine does a function 0F (Get mode) call, which doesn't
return enough information by itself, and it apparently doesn't read the bios
data area parameters directly.  I used the intercep program to trap all of
its bios calls.

Richard Brittain,                   School of Elect. Eng.,  Upson Hall   
                                    Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.spp.cornell.edu	
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard

In article <2092@calvin.EE.CORNELL.EDU> richard@calvin.spp.cornell.edu.UUCP (Richard Brittain) writes:
>
>Well, I hate it when people post replies that are not true, but working from
>my manual (like I said, I don't have the hardware to actually test this)
>BIOS data area:
>0040:004a	# characters per line 16 bit int
>0040:004c	# bytes required for 1 screenful of data - 16 bit int 
>0040:0084	# rows-1 - 1 byte
>0040:0085	# scan lines per character (i.e. height of cell) - 16 bit int
>If these are set correctly (The last two only for EGA/VGA/MCGA) then that
>should be all you need.
>Alternatively:
>BIOS INT 10H
>function AH=0F  Get mode - should return characters/line as well as mode.
>Hopefully the 'non-standard' modes also return this correctly
>function AX=1130 Get character generator info (EGA/VGA/MCGA) returns #rows-1
>and bytes/character in the 'alternate' font table.
>
Well I've got the hardware (IBM PS/60, normal colorVGA). After some
inetnsive hacking I was able to come up with a 80*50 color mode (with
Turbo Pascal 4.0). I set the bios data area, got the correct font,
used function AX=1130 to crosscheck that I had done everything
correctly, and changed the required VGA ports (not in that order).
The screen looked fine and bios *knew* that I used 80*50, but bios
won't use the bottom half (ie lines 26-50) of the screen. So here
I am with a fifty line screen, but the bios is so stupid that it
won't scroll more than 25 lines. If I set the number of chars per
line (0040:004a) to 160, bios writes to every other line (as it
should) allowing me to write on the bottom half of the screen, but
it won't scroll the bottom half. I tested this with bios commands
not Turbo's own write commands. Can someone help me with this?
I don't want to rewrite the bios. I sort of like the idea of
having DOS and 50 lines (now it's 50 lines, but dos uses only the
first 25).


-- 
      NN   NN  NN   NN  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
    NNNN    N  NN    N  NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
  NNNNNN  N    NN  N    NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNN  NN   NN  NN   NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

The problem is that while Turbo's own screen package will take advantage of
whatever size screen you are using, DOS (not necessarily BIOS) is hard-coded
to work with only the first 25 lines of the screen.  The problem here is that
to do anything else, DOS would have to automagically sense the current screen
size, which, since it uses BIOS calls, would tremendously slow down screen
I/O.  OS/2 can solve this problem easily, because it *always* knows what size
the screen is.

In article <2090@calvin.EE.CORNELL.EDU> richard@calvin.EE.CORNELL.EDU (Richard Brittain) writes:
>1)  Whether Borlands console i/o routines will work (cputs, cprintf etc.) in
>    a window larger than 25x80
>2)  Whether the standard i/o routines will work, assuming the display is
>    already in the required mode, or can be set using something nnansi.sys
>
>I have already established that the gettextinfo() routine does not return
>the correct screen size but I think I can fix that.  

I have used cputs, cprintf etc., in text windows of 135x43 on an EGA and 135x50
on a VGA with no problems.  I am not sure why you claim gettextinfo() doesn't 
work.  I have used it to get the info for the windows I mentioned above.  If it
wasn't working that is news to me.

I don't know if you are talking about standard DOS i/o routines or Borland's
standard i/o routines in paragraph two.  I also don't know what a nnansi.sys
is.  I can guess that nnansi.sys is a replacement ansi.sys supplied by some
VGA card maker but that is only a guess.  It would be nice to have a little 
more info.

The above statements are only my opinions.  They in no way reflect the official
opinions of IBM or of IBM AWD Development.



Eric S. Clarke                                   UUCP: uunet!ibmsupt!eclarke
1510 Page Mill Road                              COM:  415-855-4458
Palo Alto, CA 94304                              TIE:  465-4458

In article <89320.130954CMH117@PSUVM.BITNET>, CMH117@PSUVM.BITNET (Charles Hannum) writes:
> DOS (not necessarily BIOS) is hard-coded
> to work with only the first 25 lines of the screen.  The problem here is that
> to do anything else, DOS would have to automagically sense the current screen
> size, which, since it uses BIOS calls, would tremendously slow down screen
> I/O.

I don't think screen handling is terribly slow in DOS 4.0, but it knows
whether the screen is in 80*25 or 80*50 line mode. Easy to use (command
is "mode ,50", but too few programs check whether they are running on
80*25 or 80*50 line screen. Of course, all DOS programs do it,
especially more.

-- 
E-Mail: teittinen@finuh.bitnet               ! "Studying is the only way
        teittinen@cc.helsinki.fi             !  to do nothing without
Marko Teittinen, student of computer science !  anyone blaming you" -me

In article <1494@cc.helsinki.fi>, TEITTINEN@cc.helsinki.fi (Marko) says:
>
>In article <89320.130954CMH117@PSUVM.BITNET>, CMH117@PSUVM.BITNET (Charles
>Hannum) writes:
>> DOS (not necessarily BIOS) is hard-coded
>> to work with only the first 25 lines of the screen.  The problem here is that
>> to do anything else, DOS would have to automagically sense the current screen
>> size, which, since it uses BIOS calls, would tremendously slow down screen
>> I/O.
>
>I don't think screen handling is terribly slow in DOS 4.0, but it knows
>whether the screen is in 80*25 or 80*50 line mode. Easy to use (command
>is "mode ,50", but too few programs check whether they are running on
>80*25 or 80*50 line screen. Of course, all DOS programs do it,
>especially more.

You are naive.  DOS only *thinks* it knows what size the screen is.  In
reality, if you set the screen size without using MODE, DOS won't know a
damned thing about it.  How about using "MODE ,50" and having a program set
the screen back to 25 line mode.  What will DOS do?  Heh, heh ...
-------

--
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  cmh117@psuvm.{bitnet,psu.edu}  "No noozzzz izzz netzzzsnoozzzzz..."
  c9h@psuecl.{bitnet,psu.edu}    "Mem'ry, all alone in the moonlight ..."

Pardon my ignorance, but...

In article <1494@cc.helsinki.fi>, TEITTINEN@cc.helsinki.fi (Marko) writes:

> I don't think screen handling is terribly slow in DOS 4.0, but it knows
> whether the screen is in 80*25 or 80*50 line mode. Easy to use (command
> is "mode ,50", but too few programs check whether they are running on
> 80*25 or 80*50 line screen. Of course, all DOS programs do it,
> especially more.

How do I inquire the current screen geometrics? Is there a BIOS call that
I can use to get the number of lines and columns on the screen (mind you,
the number of lines is not the only thing that can be changed)? At least,
it isn't mentioned in my (old, pre-AT) PC Technical Reference.

-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

In article <89338.051609CMH117@PSUVM.BITNET>, CMH117@PSUVM.BITNET 
(Charles Hannum) writes:
> In article <1494@cc.helsinki.fi>, TEITTINEN@cc.helsinki.fi (Marko) says:
>>
>>I don't think screen handling is terribly slow in DOS 4.0, but it knows
>>whether the screen is in 80*25 or 80*50 line mode. Easy to use (command
>>is "mode ,50", but too few programs check whether they are running on
>>80*25 or 80*50 line screen. Of course, all DOS programs do it,
>>especially more.
> 
> You are naive.  DOS only *thinks* it knows what size the screen is.  In
> reality, if you set the screen size without using MODE, DOS won't know a
> damned thing about it.  How about using "MODE ,50" and having a program set
> the screen back to 25 line mode.  What will DOS do?  Heh, heh ...

I use "MODE ,50" quite a lot and many programs change the screen back to
80*25. But still DOS has no problems of knowing what is the screen size.

Have you ever used DOS 4.01?

-- 
E-Mail: teittinen@finuh.bitnet               ! "Studying is the only way
        teittinen@cc.helsinki.fi             !  to do nothing without
Marko Teittinen, student of computer science !  anyone blaming you" -me

In article <89338.051609CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET (Charles Hannum) writes:
>>especially more.
>
>You are naive.  DOS only *thinks* it knows what size the screen is.  In
>reality, if you set the screen size without using MODE, DOS won't know a
>damned thing about it.  How about using "MODE ,50" and having a program set
>the screen back to 25 line mode.  What will DOS do?  Heh, heh ...

Any program that changed the screen size without updating the screen size
bytes in the BIOS data area (40:4A = number of columns, 40:4C = number
of bytes in the full screen) is buggy and should be thrown out.  If DOS
can't read those values and use them, then it's buggy and should be thrown
out.  (This is the recommended action for ANSI.SYS, by the way.  It contains
the hard coded screen length in earlier versions of DOS.  Plain DOS can
handle a 50 line screen with no trouble.) 

Duncan Murdoch

P.S. If there are any errors in the information above, then please
throw it out.

In article <966@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:

>Any program that changed the screen size without updating the screen size
>bytes in the BIOS data area (40:4A = number of columns, 40:4C = number
>of bytes in the full screen) is buggy and should be thrown out.  If DOS
>can't read those values and use them, then it's buggy and should be thrown
>out.  (This is the recommended action for ANSI.SYS, by the way.  It contains
>the hard coded screen length in earlier versions of DOS.  Plain DOS can
>handle a 50 line screen with no trouble.) 

>Duncan Murdoch

>P.S. If there are any errors in the information above, then please
>throw it out.


The Bytes relevant to changing screen sizes are:  (as far as I know)

40:49  Video mode (notes below)
40:4A  number of columns
40:4C  first time I heard of this one. 
       Must be a word giving number of bytes in the screen if Duncan is right.
40:84  Rows - 1   (probably a leftover EGA BIOS bug that keeps it 1 smaller)
40:85  Character Height.   The number of pixels vertical in a character cell.

  Notes:
Ansi.sys and most of the nansi,fansi,zansi,nnansi   drivers expect to see a
3 in 40:49.  If they don't, you get flashing underbars at the begining and
end of each line.  Most Video BIOSes (some anyway) put the actual video mode
number in 40:49 when you change to an extended text mode (like 640x480 or
800x600).  Unless you pump a '3' back into 40:49 after changing to one of
these modes, the various ansi drivers will think you are in graphics mode.

nnansi.sys will soon be able to handle the 40:49 byte right, if what I heard
is right.   (I recommend it.  It is the best ansi driver I have seen)


  I agree that any program that doesn't read those values (especially
rows and columns) or handle arbitrary ones should be thrown out.

  I have written a font loader that will load any font into any EGA or better
video board, and it knows about the extended modes that various super VGAs
offer.  Right now I am using an 800x600 text mode with a 8x12 character cell.
This gives me 50x100 screens.  I am using a font that I adapted from Xwindows.
  Fortunatly Kermit, Epsilon and the more program I use (browse.com from 
PC magazine) all can handle any size you throw at it.
  (I do believe kermit may screw up with more than 60 lines of 100, though).

The program is in the beta testing stage right now, and will be posted to 
c.b.i.p. when finished.

Brynn


 Brynn Rogers    Honeywell S&RC        rogers@src.honeywell.com
 home 612 874-7737  

In article <41644@srcsip.UUCP> rogers@src.honeywell.com (Brynn Rogers) writes:
>In article <966@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:
>
>The Bytes relevant to changing screen sizes are:  (as far as I know)
>
>40:84  Rows - 1   (probably a leftover EGA BIOS bug that keeps it 1 smaller)

It may also not be a bug, and merely start at the zeroth line.

Jochen Fritz
joefritz@pawl.rpi.edu

If all else fails, be more general.  Failing that, say "42".

In article <41644@srcsip.UUCP> rogers@src.honeywell.com (Brynn Rogers) writes:
>In article <966@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:
>
>>Any program [...]
>>is buggy and should be thrown out.  If DOS
>>can't read those values and use them, then it's buggy and should be thrown
>>out.  (This is the recommended action for ANSI.SYS, by the way.  It contains
>>the hard coded screen length in earlier versions of DOS.  Plain DOS can
>>handle a 50 line screen with no trouble.) 

But DOS 4.0's MODE ,50 command to set 50 line mode doesn't work unless 
plain ANSI.SYS (which now works, BTW) is installed!

>The Bytes relevant to changing screen sizes are:  (as far as I know)
>
>40:49  Video mode (notes below)
>40:4A  number of columns
>40:4C  first time I heard of this one. 
>       Must be a word giving number of bytes in the screen if Duncan is right.
YEP.
>40:84  Rows - 1   (probably a leftover EGA BIOS bug that keeps it 1 smaller)
THIS ISN'T USED IN CGA/Mono/Herc, causing serious compatibility problems,
which is why NNANSI.SYS is EGA/VGA only
>40:85  Character Height.   The number of pixels vertical in a character cell.
ALSO NOT USED IN CGA/Mono/Herc

I'd also add to the list:
40:4E Display start address. Programs that assume the value here won't work
    properly with NNANSI or Fansi-Console

>Ansi.sys and most of the nansi,fansi,zansi,nnansi   drivers expect to see a
>3 in 40:49.  If they don't, you get flashing underbars at the begining and
>end of each line.  Most Video BIOSes (some anyway) put the actual video mode
>number in 40:49 when you change to an extended text mode (like 640x480 or
>800x600).  Unless you pump a '3' back into 40:49 after changing to one of
>these modes, the various ansi drivers will think you are in graphics mode.

>nnansi.sys will soon be able to handle the 40:49 byte right, if what I heard
>is right.   (I recommend it.  It is the best ansi driver I have seen)

Thank you! Since I am the author of the modifications that differentiate
it from nansi.sys. Yes it will handle it "right". There are conditional
compilation options for a number of different cards. My feeling is that the
video BIOSes that leave the 40:49 value at "3" are the ones doing it correctly.
That way obviously involves the least "damage". I'd feel differently if there
was an industry wide standard for extended mode numbers.

The new NNANSI.SYS should appear in comp.binaries.ibm.pc "real soon now" --
I submitted it about a month ago.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply

>In article <89320.130954CMH117@PSUVM.BITNET>, CMH117@PSUVM.BITNET (Charles Hannum) writes:
>> DOS (not necessarily BIOS) is hard-coded
>> to work with only the first 25 lines of the screen.  The problem here is that
>> to do anything else, DOS would have to automagically sense the current screen
>> size, which, since it uses BIOS calls, would tremendously slow down screen
>> I/O.

DOS isn't hardwired to 25 lines. COMMAND.COM is. Grab a copy of 4DOS 
and you can use funny sized screens without those hassles. Just be
careful if you use ANSI.SYS as not all versions of it will support
the funny sizes. 4DOS does enough other good stuff to be worth buying
anyway.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short

In article <1805@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes:
>>In article <89320.130954CMH117@PSUVM.BITNET>, CMH117@PSUVM.BITNET (Charles Hannum) writes:
>>> DOS (not necessarily BIOS) is hard-coded
>>> to work with only the first 25 lines of the screen.  The problem here is that
>>> to do anything else, DOS would have to automagically sense the current screen
>>> size, which, since it uses BIOS calls, would tremendously slow down screen
>>> I/O.
>DOS isn't hardwired to 25 lines. COMMAND.COM is. Grab a copy of 4DOS
>and you can use funny sized screens without those hassles. Just be
>careful if you use ANSI.SYS as not all versions of it will support
>the funny sizes. 4DOS does enough other good stuff to be worth buying
>anyway.

You can "try-before-you-buy", its shareware!  Definitely worth the 50 bucks
they want from you to register, but its legal to try out first (for about
30 days, I think.)

ftp over to site:  wuarchive.wustl.edu

and then:

cd  /mirrors/msdos/sysutl       <----- changes to appropriate directory
type binary                     <----- sets transfer mode to binary files
recv  4dos22.arc                <----- get the archived 4DOS system & docs
recv  4dostip.arc               <----- handy start-up tips, also archived.

On your pc, most of the "ARC"-type programs should work to unarchive it:
PKXARC, ARCE, etc.

Good Luck!

Dave

doerschu@rex.cs.tulane.edu