Hi,

There is one of the functions I have used with Watcom C/C++ to wait for vsync, it is very similar, but there might be some difference in the way it is actually compiled as it uses the inline assembler syntax instead of the header pragma assembler syntax:

1void wait_for_vsync()
2{
3    _asm
4    {
5        push ax
6        push dx
7        mov dx, 0x3DAh
8wait_vsync_1:
9        in al, dx
10        test al, 0x08h
11        jne wait_vsync_1
12wait_vsync_2:
13        in al, dx
14        test al, 0x08h
15        je wait_vsync_2
16        pop dx
17        pop ax
18    }
19}

Also note that the VGA refresh frequency for the standard 320x200 256 colour mode is 70Hz not 75Hz.

EDIT:

hornet1990 wrote on Yesterday, 16:30:

The only way I can get it animating at a sensible speed is to massively drop the cpu cycles. I initially picked the "emulate P100" setting to match my machine of the day, but 53k cycles is way too high, 12k is better although arguably still a bit too quick, but then that drops it to 30fps, 6k drops it to 15fps. The vsync option under the video menu seems to make absolutely zero difference.

If it drops to exactly 30 and 15 fps then it means that it vsyncs to half or quarter of 60Hz instead of the 70Hz that the original VGA has, but Dosbox might emulate the VGA mode running the actual display of the computer you are using with a 60Hz refresh mode, and dropping down to 30 and 15 fps is a behaviour very possible when the CPU is too overloaded to get to the vsync loop with enough cycles to spare, so it syncs to half or quarter of the actual vsync frequency instead.

MagefromAntares wrote on Yesterday, 16:42:

There is one of the functions I have used with Watcom C/C++ to wait for vsync, it is very similar, but there might be some difference in the way it is actually compiled as it uses the inline assembler syntax instead of the header pragma assembler syntax:

Thanks Mage, that did it. Curious though that the only difference is you explicitly save the state of ax and dx then restore it, which is what the modify of the pragma is supposed to tell the compiler to do. Must admit I didn't think to check the compiled code to see if it actually had or not.

Although why it worked at the time with exactly the same compiler install is strange (literally, I had it zipped up with my batch files for setting up the environment and everything). IIRC the inline asm syntax didn't come until Watcom 11, and even then I think they still recommended using the pragma method... <shrugs>

MagefromAntares wrote on Yesterday, 16:42:

EDIT:
If it drops to exactly 30 and 15 fps then it means that it vsyncs to half or quarter of 60Hz instead of the 70Hz that the original VGA has, but Dosbox might emulate the VGA mode running the actual display of the computer you are using with a 60Hz refresh mode, and dropping down to 30 and 15 fps is a behaviour very possible when the CPU is too overloaded to get to the vsync loop with enough cycles to spare, so it syncs to half or quarter of the actual vsync frequency instead.

Yeah, it was one of my first efforts so isn't in the slightest bit optimal - I cringed when I first looked at what the code was doing! I apparently also tried making a mode-x version of it and looking at that code and re-reading Abrash's black book it was very obvious I had little real understanding of the advantages of that mode at the time.

Thanks again!

hornet1990 wrote on Yesterday, 19:11:

Although why it worked at the time with exactly the same compiler install is strange (literally, I had it zipped up with my batch files for setting up the environment and everything). IIRC the inline asm syntax didn't come until Watcom 11, and even then I think they still recommended using the pragma method... <shrugs>

This is exactly why I sent one of my non pragma version of vsync to check 😀, while the pragma method is the preferred one for inline assembly in Watcom C, it also opens up the assembly code for compiler optimization, the modified register list at the end of pragma is to tell the compiler that which registers after the call is in a modified state, it is possible in the case of your code the optimizer made a mistake of what registers were required to push and pop.

hornet1990 wrote on Yesterday, 19:11:

Yeah, it was one of my first efforts so isn't in the slightest bit optimal - I cringed when I first looked at what the code was doing! I apparently also tried making a mode-x version of it and looking at that code and re-reading Abrash's black book it was very obvious I had little real understanding of the advantages of that mode at the time.

If you cannot vsync to the exact 70hz VGA frequency don't worry about it, even John Carmack with Doom decided to go with 35 FPS for the original DOS Doom because keeping a stable 70 FPS was considered even by John Carmack himself to be unstable. Mostly only non-interactive demos syncs to 70hz, for interactive applications syncing to half the refresh rate of VGA is enough.