[comp.sys.ibm.pc] i/o routines and non-standard video modes

nn86302@tut.fi (Neuvo Niilo Anselmi) (11/16/89)

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

CMH117@PSUVM.BITNET (Charles Hannum) (11/17/89)

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.

TEITTINEN@cc.helsinki.fi (Marko) (12/04/89)

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

CMH117@PSUVM.BITNET (Charles Hannum) (12/04/89)

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

prc@erbe.se (Robert Claeson) (12/05/89)

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

teittinen@cc.helsinki.fi (12/05/89)

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

dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (12/05/89)

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.

rogers@SRC.Honeywell.COM (Brynn Rogers) (12/06/89)

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  

joefritz@pawl.rpi.edu (Jochen M. Fritz) (12/06/89)

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

toma@tekgvs.LABS.TEK.COM (Tom Almy) (12/10/89)

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

leonard@bucket.UUCP (Leonard Erickson) (12/10/89)

>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

doerschu@rex.cs.tulane.edu (David Doerschuk) (12/14/89)

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