Polling for VSYNC doesn't work (0x3DA port)

[bloodline]

It appears that there is absolutely no VBlank interrupt,

Correct. Most hardware has the capability, but VBE doesn't expose it.

Seems like a massive oversight... But then again, we weren’t privy to the design meetings.

and no VBL hardware flag accessible once grub has set a VBE mode...

It depends on the hardware. GRUB can report VBE information, which will tell you if the current mode has register-level compatibility with VGA (including vblank), but it won't help you when the current mode lacks VGA register compatibility, and it won't help you when the "compatibility" isn't actually attached to vblank.

Ok, that’s good advice! I can at least check and take advantage is available.

It seems the only solution is to run updates every 16ms (~60Hz), which won’t allow display syncing, but will at least offer the regularity required for GFX display tasks.

VBE offers double-buffering functions that are supposed to wait for vblank before switching buffers. Whether or not they work is a mystery, and it doesn't help you on modern PCs without VBE.

They might work, but that would mean building the display from scratch each frame... and given the lack of hardware blitter functions, I’m just updating the parts of the display which have changed... Otherwise performance is dreadful, especially when there are lots of windows open and each could have 10s of cliprects!

If you're not limited to VBE, though, a native driver solves this problem easily. (For certain definitions of "easily".)

I’m not writing a native graphics driver any time soon, any offers? No?

[ivanzinhoa]

first of all, the timing of your game should not rely on vsync.

Hi! I'm also an 8086 assembly beginner and I'm wondering, what should I use instead? I'm really interested in learning specifically about timers and counters since it looks like a very secretive topic (I mean, since the infamous Appendix H).

Thank you.

[Octocontrabass]

I'm also an 8086 assembly beginner and I'm wondering, what should I use instead?

That depends on where you want your program to run.

If you want it to run inside an OS, you should use the timer functions provided by the OS, and let the OS worry about which hardware timer to use.

If you want it to run on bare metal, there's a list of timers available in x86 PCs on the wiki. Of course, not every PC will support all of these timers, so you'll have to choose an appropriate timer according to which PCs you want to run your code.

[orcapet3910YT]

Currently emulation is always poorer than expected. It's more productive to use real hardware and then see how the rest of things behave, like emulators.

Yet, when I test my framebuffer text scroll, it's FAST. Real hardware is much slower at my framebuffer scroll than QEMU... yet how does a real kernel like Linux scroll so fast?

[nullplan]

Yet, when I test my framebuffer text scroll, it's FAST. Real hardware is much slower at my framebuffer scroll than QEMU... yet how does a real kernel like Linux scroll so fast?

Most important optimization: Setting the cache type of the frame buffer to Write Combining. Otherwise just a better memmove(), I suppose.