spolsky-joel@CS.Yale.EDU (Joel Spolsky) (12/19/88)
A while ago I asked what the politically correct way is to do fast (text) video. Several people were kind enough to reply. The following procedure should work for any display: -Find out the video mode as follows: set AH to 0x0F call interrupt 0x10 (Video Services) look in AL for the video mode -If the video mode is 7, screen memory starts at B000:0000 -otherwise, screen memory starts at B800:0000 -if the user wants snow suppression, wait for port 0x3DA to become odd before poking to the screen. Beware that if the video mode is 7, you could wait forever which is unaesthetic (Alt-Ctrl-Del time!). Some people suggested letting the BIOS output one character and then checking whether it shows up in B000 or B800. This seemed quite kludgy to me. +----------------+----------------------------------------------------------+ | Joel Spolsky | bitnet: spolsky@yalecs.bitnet uucp: ...!yale!spolsky | | | internet: spolsky@cs.yale.edu voicenet: 203-436-1483 | +----------------+----------------------------------------------------------+ #include <disclaimer.h>
Ralf.Brown@B.GP.CS.CMU.EDU (12/19/88)
In article <46013@yale-celray.yale.UUCP>, spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes: }A while ago I asked what the politically correct way is to do fast }(text) video. Several people were kind enough to reply. The following }procedure should work for any display: } }-Find out the video mode as follows: } set AH to 0x0F } call interrupt 0x10 (Video Services) } look in AL for the video mode }-If the video mode is 7, screen memory starts at B000:0000 }-otherwise, screen memory starts at B800:0000 Please add: put assumed screen address in ES:DI set AH to 0xFE call interrupt 0x10 store returned ES:DI as actual screen address to let the program run in a small window under any of TopView, TaskView, OmniView, DESQview, ALL ChargeCard with 960K DOS, and probably MS Windows. vvv and the address is B800:0000 }-if the user wants snow suppression, wait for port 0x3DA to become }odd before poking to the screen. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I claimed something? You cannot achieve the impossible without attempting the absurd.
chasm@killer.DALLAS.TX.US (Charles Marslett) (12/19/88)
In article <46013@yale-celray.yale.UUCP>, spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes: > A while ago I asked what the politically correct way is to do fast > (text) video. Several people were kind enough to reply. The following > procedure should work for any display: > > -Find out the video mode as follows: > set AH to 0x0F > call interrupt 0x10 (Video Services) > look in AL for the video mode > -If the video mode is 7, screen memory starts at B000:0000 On some video cards (non-AT, non-VGA or EGA) this BIOS call does not work, and on others (older enhanced EGAs, and EGA/VGA products that are "well designed" in my opinion) the return value is the current video mode even for monochrome displays. And in these cases, the value is sometimes 7 and is sometimes not (non-80 column modes are particular culprits). > -otherwise, screen memory starts at B800:0000 Except for graphics modes (and you really ought to check for these). > -if the user wants snow suppression, wait for port 0x3DA to become > odd before poking to the screen. Beware that if the video mode is 7, > you could wait forever which is unaesthetic (Alt-Ctrl-Del time!). Very good point, for user friendly displays usually don't go to sleep for a long time (;-). I might add that puting a wait counter in to escape if you do not see it go odd might be a good failsafe feature. > Some people suggested letting the BIOS output one character and then > checking whether it shows up in B000 or B800. This seemed quite kludgy > to me. Actually this bypasses most of the possible variations of BIOSes, and is almost certain to be the most accurate -- it would even let you tell the line length by writing to (0,0) and (1,0), then measuring the distance between the two words. Another advantage is that if the character does not appear in either buffer area, the mode is most likely a graphics one, and you can then adapt to that. Even if the mode is a text one, it does not work properly with your code, so you can then fall back to BIOS writes. In fact (though I have never used this method) I really like it! > +----------------+----------------------------------------------------------+ > | Joel Spolsky | bitnet: spolsky@yalecs.bitnet uucp: ...!yale!spolsky | > | | internet: spolsky@cs.yale.edu voicenet: 203-436-1483 | > +----------------+----------------------------------------------------------+ > #include <disclaimer.h> Charles Marslett chasm@killer.dallas.tx.us
ralf@b.gp.cs.cmu.edu (Ralf Brown) (12/20/88)
In article <6490@killer.DALLAS.TX.US> chasm@killer.DALLAS.TX.US (Charles Marslett) writes: }> Some people suggested letting the BIOS output one character and then }> checking whether it shows up in B000 or B800. This seemed quite kludgy }> to me. } }Actually this bypasses most of the possible variations of BIOSes, and is }almost certain to be the most accurate -- it would even let you tell the }line length by writing to (0,0) and (1,0), then measuring the distance }between the two words. Another advantage is that if the character does not }appear in either buffer area, the mode is most likely a graphics one, and And it breaks horribly under any multitasking windowing environment. The character could appear anywhere on the screen, and in fact need not appear on the screen at all. Your code should at least try the TopView "get video address" call before resorting to the above kludge (see a previous post of mine). -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something? --