cliffhanger@cup.portal.com (Cliff C Heyer) (01/12/90)
I'm trying to figure out why there is this division between text and graphics modes with PCs. It seems logical that it should be possible to write directly to the same video memory being used for text display and place graphics with the text. But when you try it the graphics are "forced" into different memory if you don't change to a combination text & graphics mode. I can't change modes because other object-code only libraries are locking me into text mode. Also when you change modes, you loose all that you had in the previous mode until you switch back. I'm assuming that each screen pixel is represented by a bit in memory (or several bits) even in text mode - but in text mode the bits are written with bit maps from the BIOS. Why lock people out of this memory just because the BIOS is writing there? Is this only a convention that I can bypass by using the right library? Please post, Cliff
Ralf.Brown@B.GP.CS.CMU.EDU (01/12/90)
In article <25820@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) wrote: }I'm assuming that each screen pixel is represented }by a bit in memory (or several bits) even in text }mode - but in text mode the bits are written with }bit maps from the BIOS. You assume incorrectly. In text mode, each *character* on the screen is represented by two bytes--the character and the attribute. The display hardware converts this (on the fly) to the appropriate set of pixels using a bitmap stored on the video controller. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 14. proof by importance: A large body of useful consequences all follow from the proposition in question.
bcw@rti.UUCP (Bruce Wright) (01/13/90)
In article <25820@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes: > I'm trying to figure out why there is this division > between text and graphics modes with PCs. > > It seems logical that it should be possible to write > directly to the same video memory being used for > text display and place graphics with the text. It would be logical to be able to do this, but the problem is that when the original PC came out, graphics cards were expensive, especially if they had enough resolution (=memory) so that the characters could be displayed on the screen in a reasonable font. The solution was to have the characters stored as a character + attribute (underline, reverse, etc) byte in video memory (so there was 1 word / character on the screen, or about 4000 bytes of video memory) and then do a table lookup on the character bitmap into a small ROM. Given the technology of the day, and the cost of video RAM, this was a reasonable approach. Those who actually wanted graphics could pay the extra for the expensive interface. (BTW, for the PC this "expensive interface" started out as the CGA ... hardly what would be considered "sophisticated graphics" nowadays). In other words, what is being stored in video memory when you are in text mode is essentially just the text ... no bitmaps. You can't bypass it by using the right library. You either have to do everything on the screen in graphics mode or text mode - no mixing. (Of course, you can mix text screens with graphics screens in a single program by changing modes, but you can't display both at once). If you were designing a system from scrach nowadays, you would probably dispense with the zillions of screen "modes" that the IBM-PC has managed to accumulate over the years (for compatibility with older text mode and graphics mode interfaces) and do things similar to the way you suggest, with a single graphics memory. You'd probably also want a bitblt circuit so that characters could be zapped onto this bitmap screen without a lot of CPU time on the part of the main machine, and also to allow scrolling to be accomplished quickly (a problem with simple bitmapped graphics displays). Unfortunately, although this would simplify things quite a bit in the long run, and make the video hardware much more elegant, it would mean a lot of incompatibility in the short run which would be very difficult to overcome in the marketplace. Consult a book on the PC video architecture (of which there are many good titles available) if you want further information - Bruce C. Wright
scjones@sdrc.UUCP (Larry Jones) (01/13/90)
In article <25820@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes: > I'm trying to figure out why there is this division > between text and graphics modes with PCs. > [...] > I'm assuming that each screen pixel is represented > by a bit in memory (or several bits) even in text > mode - but in text mode the bits are written with > bit maps from the BIOS. Bad assumption. In fact, this is exactly what happens in GRAPHIC modes -- whenever you make a BIOS call to write characters, the BIOS discovers that you're in a graphic mode and writes the appropriate bit maps into the display memory. In TEXT modes, however, the display memory actually contains the ASCII characters to be displayed and the video HARDWARE converts them into bits on the fly. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "You know how Einstein got bad grades as a kid? Well MINE are even WORSE!" -Calvin
zech@leadsv.UUCP (Bill Zech) (01/13/90)
In article <25820@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes: > I'm trying to figure out why there is this division > between text and graphics modes with PCs. [ some deleted] > > I'm assuming that each screen pixel is represented > by a bit in memory (or several bits) even in text > mode - but in text mode the bits are written with > bit maps from the BIOS. > The original PC video is built around a Motorola 6845 CRT controller chip. This chip does two distinctly different things in text mode and graphics mode. When in graphics mode, text is displayed much as you describe. The BIOS looks up bit patterns in ROM or an auxiliary table and writes them to graphics memory to form characters bit by bit. In text mode, the video memory does *not* hold bit maps. It holds ASCII. (actually, an IBM defined extension of ASCII). The 6845 does the character lookup in its associated ROM and blasts the dots up on the screen on the fly. The 6845 also implements the attributes such as blink, inverse, hi/low, underline. Note that all these attributes must be handled in software when in graphics mode. So, text mode means you write ASCII + attribute byte to the video memory and the 6845 interprets it. Graphics mode means you program the dots yourself. Of course, you can mix graphics and text all you want in graphics mode. - Bill
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (01/15/90)
In article <25820@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
$I'm trying to figure out why there is this division
$between text and graphics modes with PCs.
$I'm assuming that each screen pixel is represented
$by a bit in memory (or several bits) even in text
$mode - but in text mode the bits are written with
$bit maps from the BIOS.
Well, I think we need a little lesson on how memory usage differs between
text and graphics modes.
In text mode, each byte in memory represents one character, and the byte
holds the ASCII code of the character to be displayed. A second byte is used
to hold the attribute (colours, underlining, blinking, etc.). When the
display card displays this on the screen, the ASCII code is used as an
offset into a table stored in ROM (the character generator) which provides
the actual bitmap of the character. Do not confuse this ROM with the BIOS,
because it isn't part of it.
In graphics mode, each byte in memory holds bitmap information (the
number of pixels represented by one byte depends on the graphics mode - in
Hercules graphics mode, for example, where a bit can be either on or off,
eight pixels can be stored in one byte). If you display text on such
a screen, what actually happens is that the computer looks up the bitmap for
the character in the character generator and places that bitmap into the
display memory.
So you can see that in text mode, there is no way to store graphics,
and in graphics mode, the computer performs the character generator lookup
itself when you display the text, rather than having the display card do
this lookup every time it refreshes the screen.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
If it's true that love is only a game//Well, then I can play pretendleonard@bucket.UUCP (Leonard Erickson) (01/15/90)
You are only half right. In graphics mode a given byte of screen RAM is displayed as a bit pattern on the screen. It *is* that bit pattern. In text mode, that byte is either: 1. a character code 2. an attribute code If it is a character code, it represents an index value into a character table. But there are only 256 entires in the table, and they are all used by characters. They are also not arbitrarily placable on the screen. So they can't be used for graphics except in very odd cases of limited applicability. If it is an attribute code, it defines a "mask" to to be applied to the data before displaying it. This is handled in *hardware*. The attributes on are foreground/background colors on a color display, and things like inverse, invisible, and underline on a mono screen. Look at it another way. In text mode you only have 4k of memory for the screen data. There's no way that can contain the required info for graphics. -- 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
rob@prism.TMC.COM (01/17/90)
It's possible - difficult and hardware-specific, but possible - to put graphics on the screen in text mode by reprogramming the character set. This can be done on the EGA and VGA, though not on the CGA. The 'line drawing' characters defined in the IBM extended ASCII set allow this to a limited extent, but by defining your own characters, you can create the illusion of bit-mapped graphics in text mode. IBM put out an EGA demo program several years ago that used this technique. I believe it was called FantasyLand. A good book dealing with this is Richard Wilton's 'Programmer's Guide to the PC and PS/2 Video Systems'.
cliffhanger@cup.portal.com (Cliff C Heyer) (01/17/90)
Thanks for all your comments. I'm one of those mainframe converts who has to learn that there are things you can do to save money. I assumed that FAST video memory was used for the entire screen, rather than just for the current scan line. But this would make the adaptor cost 10 times as much. Also, the AT bus is slow enough to make writing bit maps to the video adaptor slow. On (expensive) workstation platforms the bus has 10 times the bandwidth so this is not a problem. Cliff
dougs@videovax.tv.tek.com (Doug Stevens) (01/18/90)
In article <206900161@prism>, rob@prism.TMC.COM writes: > It's possible - difficult and hardware-specific, but possible - to > put graphics on the screen in text mode by reprogramming the character set > ... Desqview can simultaneously display one window with true graphics-mode graphics, and another with text-mode text. I would REALLY like to know how to do this. (Incidentally, this is on a VGA system, 640 x 480)
Ralf.Brown@B.GP.CS.CMU.EDU (01/18/90)
In article <26036@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) wrote: }Also, the AT bus is slow enough to make writing }bit maps to the video adaptor slow. On (expensive) }workstation platforms the bus has 10 times the }bandwidth so this is not a problem. As it happens, the bottleneck is not the AT bus (which can easily handle 5 megabytes per second), but the video memory on the video board! Because systems in use today have to lock out the CPU while the video circuitry is reading the video memory, most video boards can only allow the CPU one access every 1.1 to 1.5 microseconds. On my 386/33, this translates to 47 wait states! Add to this the fact that many EGA and VGA graphics modes require bank-switching to get at all the video memory used by an image. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 14. proof by importance: A large body of useful consequences all follow from the proposition in question.