Video Pages

[dncprogrammer]

Dumb question: Whats the story with video pages. I realize that there are more than one available under most of the INT10h functions in the top of BX but I have been told that using more than one page wasn't used much. How, why?
jon

[Tedd]

If we say that the available memory for video in character modes is 64k..

if one page (a full screen) is only 80*25*2 = 4000 bytes, that means you've got space for 16 whole screens - such that, writing to one, wouldn't interfere with the others. Though you can only actually see one at a particular time.
However in practice, it just wasn't used much. Namely it was DOS doing everything on a single screen. Linux consoles use many pages though, although without the aid of bios, but it's the same idea.

[Mark Jones]

Curious, is that how this was developed?

http://video.google.com/videoplay?docid=-5885351342753379583&q=8088

[MichaelW]

Jon,

Assuming you are asking about the VGA, for the normal alpanumeric display modes the hardware supports 8 display pages. I don't know how detailed of a story you actually want here, so I'll just hit the high spots. In order to maintain compatibility with the CGA, for the VGA alpanumeric display modes the display buffer is mapped into the host address space starting at B8000h and extending to BFFFFh, for a total size of 32KB. Each character code byte is paired with an attribute byte that controls the color of the character, so each character cell requires 2 bytes of storage. With an 80x25 resolution there are 2000 character cells, requiring a total of 4000 bytes of storage. With 4096 bytes actually allotted for each display page, a total of 8 pages will fit within the display buffer. IIRC at higher resolutions, 80x43 or 80x50, only 4 display pages are supported. The VGA BIOS allows you to select the active (visible) page, or write to any page, whether visible or not. The VGA BIOS also maintains a cursor position and state for each of the pages.

AFAIK mainstream applications made little use of multiple display pages. Most applications that had a need to save and restore areas of the screen would use memory buffers. For a text mode user interface that I once developed I used display page switching, and it worked out very well. Page switching is very fast, and because the switch is synchronized with vertical retrace there is no visible tearing.

[dncprogrammer]

Ok, I have written directly to vid memory before but  I can't see why that video paging ability couldn't be really useful, especially if each page could be in a different mode. Plus thats a bunch of memory area, even if you didn't intend to use the extra pages. Coulnd't that be managed for use as something else, temporary maybe.
jon

[dncprogrammer]

Hi guys, I was hoping for an opinion on this last one too..
thanks,
jon

[raymond]

jon

That "extra" memory can certainly be used for anything else. However, even in the old days when total available memory was only 1Mb, you would have been terribly stuck if you really needed that relatively small amount of extra memory.

Raymond

[MichaelW]

The VGA supports only one mode at a time, so all of the pages must necessarily be the same mode. I have actually used the display buffer to store the code for a memory test app where I wanted to test all of the memory in a single pass, without having to move the test app or not test the memory it occupied. The VGA supported 256KB of memory, but only 64-96 KB of it was directly accessible at any one time.

[Gustav]

reading video memory is very slow. I estimate running code in the vga memory with current cpus will slow down execution time by factor 10-100. So this memory usability is really limited.

[MichaelW]

Gustav,

I think it would depend on whether or not the video memory was cached. I recall doing some crude access time tests where I could detect no difference between the video memory and the main memory.

[dncprogrammer]

On the issue of writing directly to video memory, what does this line mean:

mov     CS:Screen+100h, 0B800h
.
.
.
Screen    dw  0B000h

If Screen was substituted then CS:0B000h, 0B800h so what the heck kind of addressing is that?
Is it something like:   mov   CS:[Screen+100h], 0B800h   ?
                             mov   Byte Ptr CS:[Screen+100h], 0B800h ?

jon

[dncprogrammer]

Oh wait,
That snippit sets the CodeSegment effective address to 0B800h. Ah. And I meant Word Ptr not Byte Ptr.

jon

[Gustav]

it does not affect the code segment (CS) itself. it just stores a word value (B800) in a variable located in the code segment.

[dncprogrammer]

does this mean that MASM doesn't require any type of focus delimiters for the operand that is being read or modified? i am used to something like the following:

mov    ax,  es:[bx]
dec     WORD [bx+100h]

where the brackets show the operand or operand combination that is being read or modified.

jon

[MichaelW]

The MASM syntax would be:

mov ax, es:[bx]
dec WORD PTR[bx+100h]

For MASM the brackets are the "index" operator (singular), used in this context to specify an indirect memory operand. For indirect memory operands in 16-bit code the operand can specify one base register, or one index register, or one of each.

MASM, unlike NASM, FASM, GoAsm, etc, ignores the brackets for direct memory operands, so for example these two statements are equivalent:

mov bx, var1
mov bx, [var1]