VESA: Doulble-buffering and vertical refresh question

[tom1000000]

Hi,

When you do DirectX programming its possible to set up double bufffering and also ensure that the screen "flips" at the same time as the veritcal refresh.

This stops flickerring / tearing of the image.

Is it possible to do this with Vesa, specifically in protected mode with an LFB!?!!??

Is there any example code out there that I could have a look at?

The VBE standard does provide 1 way of doing it however it uses real-mode interrupts. Hopefully I can avoid that!


Tom

[Pype.Clicker]

iirc, this is possible, but i don't remember very well how it actually works. I'd say you need the pmode VBE interface for this ...

[ASHLEY4]

To set up vesa you have to use realmode or a dpmi from pmode.

\\\\||////
(@@)
ASHLEY4.

[bubach]

Did you read the question, ASHLEY4?

[Curufir]

Hmm.

I haven't actually tried this, so take it as speculation until you can figure it out for yourself.

VGA provides a byte sized input status register at 0x3DA. In this register bit 3 indicates whether or not a vertical retrace is currently taking place (Set if a trace is in progress, clear if not). This is one of the ways to do flicker-free animation in a VGA graphics mode.

Now if we assume that VESA maintains backward compatibility with VGA for the standard modes (Which compliant cards should), then there's a good chance that this vertical retrace bit is still being set/cleared even when the card is being used in a VESA framebuffer mode (A decent theory since the BIOS vertical trace wait function has to get data from somewhere). If it is being set then a simple poll of the bit will be enough to give you what you need. In this case a poll isn't going to hurt much IMO as the maximum time you'll be waiting on it is 1/60th of a second.

As I say that's speculation, so if it actually works then come back and tell us .

[Pype.Clicker]

afaik, the "vertical retrace in progress" of VGA status register cannot be assumed to work with VESA modes (unfortunately).

[Curufir]

I guess if that's the case then you have no real option but to either use the VESA function in a vm86 task, or write a driver specifically for each card you want to support. Seems like a serious oversight on the part of the VESA standard writers.

[Goudaman]

Actually if you read the VBE 3 spec there is actually a protected mode entry point which you can find by parsing the video rom. You then jump to there instead of calling the interrupt. At least thats what the spec seems to say, i havent actually tried it. Although i dont know if this particular function is supported this way but the spec implied that all functions are.

[Curufir]

It's not something you can rely on though IMHO.

There aren't that many VBE3.0 compliant cards, and some of the implementations are AFAIK woefully inadequate.

[df]

double buffering, has to be done manually. ie: just copy your own buffers. its not a hardware thing in the VESA spec that I am aware off. certainly all vesa2 cards I have ever programmed we did it all in software.

certainly if you know the mode and how much memory is on the card you can use the cards memory, since its just flat. otherwise you doublebuffer offcard.

[bakery2k]

just copy your own buffers.

But how do you know when to copy without knowing if you're in VBLANK?

[ASHLEY4]

Heres what i found, i have made a lot of game and have always put ver-retrace in, but have never found a difference when i have not called it ( i am talking vga here), the thing that makes the biggist difference, is a off screen buffer.

When look though allegro, i get the impression it does not work (ver-retrace) very well under vesa.

Here is a allegro test program,that you can test for vesa modes,speed
and what the difference double-buffering etc makes.
http://board.flatassembler.net/viewtopi ... sc&start=0

and download "VesaTest.zip"

\\\\||////
(@@)
ASHLEY4.

[df]

vertical retrace always worked fine in my vesa demos but this was under dos, which doesnt reprogram the dotclock or that. you should still have a retrace but in a multitasking envonrment your not garunteed to hit it or that you task will be running when it fires....

i think what youd need is to know the speed of the dotclock x mhz and know the speed of the machine and just swich buffers each time the dotclock rolls.

[Pype.Clicker]

according to VBE3:

Hardware triple buffering is supported in the VBE/Core specification by allowing the application to schedule a display start address change, and then providing a function that can be called to determine the status of the last scheduled display start address change. VBE Function 4F07h is used for this, along with subfunctions 02h and 04h. To implement hardware triple buffering you would use the following steps:

1. Display from the first visible buffer, and render to the second hidden buffer.

2. Schedule a display start address change for the second hidden buffer that you just finished rendering (4F07h, 02h), and start rendering immediately to the third hidden buffer. CRT controller is currently displaying from the first buffer.

3. Before scheduling the display start address change for the third hidden buffer, wait until the last scheduled change has occurred (4F07h, 04h returns not 0). Schedule display start address change for the third hidden buffer and immediately begin rendering to the first hidden buffer. CRT controller is currently displaying from the second buffer.

4. Repeat step 3 over and over cycling though each of the buffers.

So it seems to me that there's no need for wait4vert_retrace in VESA mode as the start address change is performed by the hardware *on* vertical retrace ...

[tom1000000]

Triple buffering takes up a lot of RAM doesn't it (especially on older vid cards)?

I will have to ensure there's a protected mode interface available, I don't want to call real mode interrupts.