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

[Geri]

6502Rulez:

1. 6502 is bad
2. you can assume 60 hz, and do the screen update only ecsactly when 1/60th sec elapsed. this will resolve flickering.
3. VGA emulation mode is obsolote, including every port/interrupt function related to it. you are lucky if you even have the proper colors!
4. i suggest you to use VESA VBE (SVGA). i am not sure if it supports vsync, double buffering, or anything related to this all. you can assume 60 hz. if no vesa available, you can fallback to standard vga 320x200x8.
5. as i mentioned earlyer, the speed of your game/game engine have (should have) nothing to do with frame buffer sync. you cant just expect it running on X fps. you must create proper fps measurement.
6. you cant expect to have any behaviours you used to get in high-level operating systems through specific drivers (like the vsync itself).

[Sik]

The VirtualBox source code is online, and if I remember correctly, the V-SYNC bit is simply toggled back and forth between on and off every time you read the register. It definitely does not work as you would expect.

(ノ_<)

Seeing as this is a PC booter game, probably the best emulator would be actually DOSBox. Though if you want accuracy, I'd suggest looking at the DOSBox-X fork instead, which is focused on trying to emulate obscure hardware behavior (one of the goals is to support demoscene prods, which are like 10000x more strict about this than games are).

For context: the other day they were testing mid-screen CGA video mode changes. That's probably way more than you need (・ω・；)

[6502Rulez]

6502Rulez:

1. 6502 is bad
2. you can assume 60 hz, and do the screen update only ecsactly when 1/60th sec elapsed. this will resolve flickering.
3. VGA emulation mode is obsolote, including every port/interrupt function related to it. you are lucky if you even have the proper colors!
4. i suggest you to use VESA VBE (SVGA). i am not sure if it supports vsync, double buffering, or anything related to this all. you can assume 60 hz. if no vesa available, you can fallback to standard vga 320x200x8.
5. as i mentioned earlyer, the speed of your game/game engine have (should have) nothing to do with frame buffer sync. you cant just expect it running on X fps. you must create proper fps measurement.
6. you cant expect to have any behaviours you used to get in high-level operating systems through specific drivers (like the vsync itself).

I wanted to stay at 320x200, because then I don't have to go back to real mode to do anything with the graphics. With VBE I need to change the memory banks, right ? Why is it so hard to get a stable image on a PC ? I thought I'd make my job easier by jumping from C64 to a PC haha. Also... People here (including you) say that the vsync polling wont work on emulators, yet DOS games that use the same code for vsync seem to work fine. What's different ? Does DOS do something that I don't ?

The VirtualBox source code is online, and if I remember correctly, the V-SYNC bit is simply toggled back and forth between on and off every time you read the register. It definitely does not work as you would expect.

(ノ_<)

Seeing as this is a PC booter game, probably the best emulator would be actually DOSBox. Though if you want accuracy, I'd suggest looking at the DOSBox-X fork instead, which is focused on trying to emulate obscure hardware behavior (one of the goals is to support demoscene prods, which are like 10000x more strict about this than games are).

For context: the other day they were testing mid-screen CGA video mode changes. That's probably way more than you need (・ω・；)

I said I'm making a game, but that's only half true. I actually wanted to do some oldschool demo effects, raster bars, swinging logos etc... There's this demo I'm sure you know of called 8088 Mph and it breaks all emulators, is that "mid-screen mod change" related to that ? You can easely do stuff like that on C64 or Amiga.

[Geri]

(accidental doublepost)

[Geri]

only with very old vga-s. if you first disable A20 gate and enter to unreal mode (32-bit real mode), then basically all graphics chip and emulator will give you a linear frame buffer (vesa will give a pointer back to you). as a fallback, you still can have standard vga 320x200x8, and/or you can add the bank switching. i did both for fallback reasons, but i didnt yet seen any modern computer that actually needed it, so i were not able to fully test it.

see smallerC + vesa tutorial, compile it with -unreal flag, it can be loaded in dos, or can be booted (with bootprog) after sucking a bit.

[6502Rulez]

only with very old vga-s. if you first disable A20 gate and enter to unreal mode (32-bit real mode), then basically all graphics chip and emulator will give you a linear frame buffer (vesa will give a pointer back to you). as a fallback, you still can have standard vga 320x200x8, and/or you can add the bank switching. i did both for fallback reasons, but i didnt yet seen any modern computer that actually needed it, so i were not able to fully test it.

see smallerC + vesa tutorial, compile it with -unreal flag, it can be loaded in dos, or can be booted (with bootprog) after sucking a bit.

I wanted to find the website that explained the bank switching thing to show you and while doing that I found how to get the linear framebuffer in VBE 2.0 like you said. Wooah. That's great, I'll use that then. But what about the Vsync ? Does VBE support that ?

[Geri]

i dont think it support it. even if you find a way to support it, it will not work just like the vga method.

[6502Rulez]

i dont think it support it. even if you find a way to support it, it will not work just like the vga method.

Does that mean there's no way to get a screen without flickering ?

[Geri]

no magical way to avoid flickering. be sure not to exceed 30 fps, and there will be no flickering.

[~]

only with very old vga-s. if you first disable A20 gate and enter to unreal mode (32-bit real mode), then basically all graphics chip and emulator will give you a linear frame buffer

It's not disabling, you need to enable the A20 gate and then enter Unreal Mode.

In modern computers, the A20 gate and Unreal Mode seem to be enabled in most machines, but it's always better to test whether they are enabled, and if not, enable them. If they are already enabled, it's better to skip trying to enable them. It's better to test, detect, and then act accordingly to what needs to be done currently.

To test the A20, you need to test the first 65536-16 bytes area of the first Megabyte with the first 65536-16 bytes area of the last Megabyte, with pure 16-bit 8086-compatible code. If they are different, then the A20 gate is enabled and it lets you access even and odd Megabytes. You can access up to 1048576+65536-16 bytes with the 16-bit Segment:Offset pair memory model (For example, with FFFF:FFFF you would be addressing FFFF0+FFFF=1114096-1048576=65520-65536=16).

I don't know a way to test whether Unreal Mode is enabled or not because it would lock with the first test. What I do is testing if I'm running in an 8086, in a 286, or in a 386/386+. If it's a 386, then I just set up Unreal Mode without fearing a lockup. Otherwise, I print an error message saying that the program needs at least a 386 CPU.

[Sik]

I said I'm making a game, but that's only half true. I actually wanted to do some oldschool demo effects, raster bars, swinging logos etc... There's this demo I'm sure you know of called 8088 Mph and it breaks all emulators, is that "mid-screen mod change" related to that ? You can easely do stuff like that on C64 or Amiga.

I don't know in which state DOSBox-X's emulation is regarding 8088MPH (haven't used it in a while due to performance issues in 64-bit, maybe I should reinstall it for old games only and vanilla DOSBox for faster ones). This said, what 8088MPH does for colors is pretty simple actually so I wouldn't be surprised:
http://8088mph.blogspot.com.ar/2015/04/ ... rated.html

The CGA stuff I mentioned is a tad more advanced:
https://github.com/joncampbell123/dosbox-x/issues/256

But anyway yeah, if that's your goal then DOSBox-X is definitely the emulator to try for accuracy (and maybe get involved to help test it). And yeah, for demoscene you should try to get real hardware then if you can afford it, breaking emulators is one of the best things to do =P

For the record, emulating Windows seems to be a bigger issue thanks to all the workarounds Windows implements for buggy hardware and BIOSes (which turn out to bite back in emulation).

EDIT: OK I lied it seems the 1024 colors trick does require messing with the CRTC in the same fashion as in those tests in that GitHub link. But point stands mostly (and those tests went even further).

[halofreak1990]

i dont think it support it. even if you find a way to support it, it will not work just like the vga method.

Does that mean there's no way to get a screen without flickering ?

You could hook into the VBlank interrupt. No need to poll a register that may or may not exist.

[Sik]

The crux of the issue is that such interrupt doesn't exist.

[6502Rulez]

i dont think it support it. even if you find a way to support it, it will not work just like the vga method.

Does that mean there's no way to get a screen without flickering ?

You could hook into the VBlank interrupt. No need to poll a register that may or may not exist.

Having irq on VSYNC would be ideal, but it seems like it doesn't exist (although I've found a thread with some code to enable it, people said it's not supported anymore http://forum.osdev.org/viewtopic.php?f= ... 26&start=0). Out of all the things that were preserved over the years they couldn't do the damn vsync ? I find that hard to believe.

no magical way to avoid flickering. be sure not to exceed 30 fps, and there will be no flickering.

How would lowering FPS help in any way ? If I start updating the screen after it begun drawing there will be flickering regardless of framerate.

[halofreak1990]

The crux of the issue is that such interrupt doesn't exist.

Well, it does, but it isn't readily available in your situation, unlike the C64 and the original Xbox console.