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