OSDev.org

ezome wrote:as the topic says...

is there any way to avoid flickering on vesa 2.0 using a linear framebuffer.
maybe something like double buffering ( painting to offscreen memory and flipping onscreen/offscreen memory)?

MessiahAndrw wrote:I would allocate a memory, do all my drawing in that buffer, and then to update what's on the screen I'd copy straight from my buffer to the frame buffer. That's essentially double buffering.

MessiahAndrw wrote:Do the copying inside your flip() (or similar)
function, which you call after you have finished updating everything on
the screen.

Dex wrote:You can test for Verticle Retrace, something like this:

Code: Select all

FullVertWait:

                        mov     dx,3dah
Vr:
                        in      al,dx
                        test    al,8
                        jnz     Vr                        ;wait until Verticle Retrace starts
Nvr:
                        IN      al,dx
                        test    al,8
                        jz      Nvr                        ;wait until Verticle Retrace Ends

                        ret

But i have found it make no differance for vesa or as it's for VGA,
it does not work for vesa, but by double buffering, you will get rid
of the flickering.

// assume 0xE0000000 is the VESA lfb

// double buffer
char* dbuff;

void init_vesa()
{
	// .... do your vesa mode switch .... //

	// create a second buffer big enough
	dbuff = (char*) malloc( 640 * 480 * 8 ); // 32-bit
}

void draw_things()
{
	circle( 1, 2, 4 );
	square( 5, 6, 2 );
	rect( 9, 10, 11, 12 );
}

void flip()
{
	// faster ways to do this, but for example purposes
	// you get the idea
	memcpy( (char*) 0xE0000000, dbuff, 640 * 480 * 8 );
}

void main()
{
	while( 1 )
	{
		draw_things();
		flip();
	}
}

however to implement double buffering i would need the know the
moment after an update is finished and be able to tell vesa which
memory address to use as framebuffer for the next update.

Dex wrote:When your VGA programing you call the function i posted than on return, you move you buffer to screen.
But i am not sure if this still works for vesa.

ezome wrote:however i guess i don't understand how the graphic card uses the lfb to update the screen because in my understanding even if i use memcpy i could change the buffer while the graphic card is updating the screen.

i would also like an article about vga programming including compatibility issues.

Combuster wrote: Basically, the video card is a piece of memory and a GPU. The memory is shared between the GPU and the rest of the system - both can read and write to it at about the same time. Part of the GPU is responsible for generating the video output - it reads in bytes from video memory, converts them to colors, and put those on the output, then reads a new set of bytes and repeats the process. In essence, the video card can be trying to read from memory when you are writing to it, the effects are noticeable after only a few pixels. When doublebuffering, you copy the buffer in one piece. the video card will only change once from old to new data (if your code is uninterrupted). Tearing is reduced because there is only one scanline where the bottom and top half (original and new) do not match up.

ezome wrote:we got the cpu, ram, videomemory and the gpu do you mean ram or video memory when you talk about memory?

when you say shared between gpu and the rest of the system do you mean some block of memory in ram is shared between gpu and cpu?

if thats true than how is memory transfered to the gpu?

does the gpu paint data from ram or from video memory?

if the gpu paints from video memory does it copy the lfb in one piece or in little chunks to video memory?

but i just hate coding such stuff as long as i don't understand whats
going on

      CPU
       |
 ============ system bus
 |          |
RAM     PCI controller
            |
      =============  PCI bus
      |           |
   other     +--- | ---+    
   devices   |  =====  |
             |  |   |  | <- video card
             | GPU RAM |
             +- | -----+    
                |
             Monitor

something like this Verticle Retrace Dex mentioned before just for VBE

if so how do we make sure that on frame1 bmp1 is dislayed completely
and on frame2 bmp2 is displayed completely