I've been doing some additional testing with the floating point frequency support in the latest beta (2.3.2 beta 5). Since this topic is deviating from the original topic (whether or not WinUAE is optimized for lowest possible input lag, see http://eab.abime.net/showthread.php?t=58495), I'm posting this as a seperate topic.

Given my findings and some new ideas I hope that we can possibly take the floating point frequency support one step further. The goal would be to make the feature robust enough for users to enjoy the "no buffering" display mode (fastest mouse/joypad input response) in combination with zero screen tearing. With robust I mean that it would take a one time calibration by the user and after that no "tricks" or anything to get screen-tearing to zero.

I need to explain my findings a bit to hopefully make it clear where my suggestion comes from and why it could be a step forward in making this a robust and unique feature (not to forget the Dream of every Amiga purists action gamer! ). To be honest, if this is going to work, then I'll keep my real Amiga A1200/060 for reference, but WinUAE will take over in all aspects.

Below is a short guide which I'll write as a guide to anyone interested. Why might it be of interest? The benefit of the chipset_refreshrate option is that it makes it possible to very closely match your monitor's refresh rate with the screen refresh rate of WinUAE, thus minimizing screen tearing in the no-buffering mode (which gives the fastest input response / lowest input delay on your mouse and joystick.) An additional benefit is that it makes it possible to match the WinUAE refresh exactly with PC screenmodes that line up exactly with the Amiga Agnus PAL display specifications (for example created with soft15khz).

To be very clear about it, this guide is meant for experienced users. If you never worried about input lag, smooth scrolling and/or screen-tearing, then you're already fine. For others, who did worry at one time or another about these topics, then you might want to explore this.

Short 'how to' guide: calibrating the chipset_refreshrate variable
Assumption: your monitor is capable of running a screenmode that has a refresh of approximately 50hz (100hz most probably also applies).

Step 1: get to know the exact refresh rate of your monitor.
You can do this by running the tool FrequencyTest, which you can get here: http://www..com/?lycrjcm55j37n

For this example let's say the tool returned an average of 49,918221. Now only take the number with the first two decimals (so 49,91) and take this as the starting value for the 'chipset_refreshrate' in the config file.

Step 2: set your WinUAE configuration:

CPU&Chipset
o configure it such that it closely matches A500 specs: 68000, OCS/ECS and chipset set to cycle exact.

sound
o disable 'automatic switching' (my guess is this resets the synchronization buffer, which in turn shifts the position of the screen tearing. We don't want that in this case).

filter setting
o for now do not use any filter setting.

Step 3: find out at which sound buffer setting the buffer is most stable.
You can do this by enabling 'native on-screen display' in the miscellaneous options. The game to use is Jim Power, as its title screen has lots of sideway scrolling parts and it continuously loops (this will come in handy later). So load up the title screen and change the sound buffer setting until it's most stable with the average around zero. For me this is a buffer setting of 3.

Step 4: find the right 'chipset_refreshrate' by iteration
For this you'll need some time and patience, be prepared. It will take time because you'll be going through an iterative process where you 1) start winuae and load up the game, 2) do testing , 3) close winuae, 4) adjust the chipset_refreshrate in the config file, 5) go back to 1), just as long until the screen-tearing is stabilized/fixed to a few horizontal lines that do not roll-up or down the screen, but instead stay in the same place 'jittering' back and forth a little bit.
Doing the actual refreshrate calibration.
Start by loading up the title screen of Jim Power. You'll see a big logo 'Jim Power' and lots of background horizontal scrolling looping continually. Watch the screen, you'll notice screen-tearing because of the no-buffering option. Run through the following just as long until the line tearing doesnt roll-up or down the screen anymore.

An example
As an example: your whole iterative process could be such that it starts with a value of 49,91 --> screen tear rolls down --> raise value to 49,92 --> screen tear rolls up --> lower value to 49,915 --> tear still rolls up --> lower value to 49,912 --> tear rolls (slowly) downward --> raise value to 49, 9125 --> tear still rolls slowly downward --> raise value slightly to 49,9127 --> tear still rolls slowly downward --> raise value slightly to 49,9130 --> tear moves very slowy upward --> lower value to 49,9129 --> etc... until you've gotten to 5 decimals at least. Getting to the last digit iteration, takes time (!), as you'll have to leave the title screen running for half an hour to see whether the tear is moving upward or downward... Finally you might come up for example with a value of 49.912920.

DO NOTE: various settings in WINUAE can/probably influence how stable you're going to get the tearing. for example the priority settings, how powerful your PC is and whether your using Direct3D or DirectDraw. Do experiment with some of the settings to see if they deteriorate or improve the minimization of screen tearing.

DO NOTE 2: In WinUAE 2.3.2 beta 5 there's a small bug, where the chipset_refreshrate setting is reset back to the default 50.00hz if you bring up the Setting window (F12) during emulation and click on 'Display' panel and OK. So if you experience rolling screen tearing again all of a sudden, then probably you've gone through that menu, which made the refreshrate being reset to the default value again.
If you've done things right:
Then you've probably ended up with minimal screen tearing: in this case only about 2-3 lines shift back and forth, but most importantly these 'jittery' lines stay in the same place on the screen.

Now for the interesting part. If you load up a game with these settings then you have a certain chance that the screen tearing isn't visible at all. That is when the tearing lines end up in the border and blanking area of the screen. My guess is that there's approximately an 8% chance of this happening. Simply because there are 287 lines displayed out of a total of 313. So you have 26 lines of border+blanking on 313 total, which makes it about an 8% chance of having no screen tearing at all!

The other way round is that you have a 92% chance that the jittery lines WILL be visible... But, another interesting finding leads to a way to mitigate this. If you press F12 and OK, somehow the draw position from the display buffer gets shifted a number of lines, which also makes the jittery lines shift position and then again stay put. If you try this a few times, you have about a 1 in 10 chance that the jittery lines get shifted to the border area, where you'll not see them anymore. This makes it possible to enjoy ZERO screen tearing in no-buffering mode and thus enjoy the best of all worlds: no screen tearing AND very fast input response.

As an indication, with my current calibrated settings if I press F12 and OK a few times at the start of a game, until there's no visible tearing/jittering anymore, I've been playing a long way through Jim Power (wel until level three until I get killed ) with NO screen tearing at all. The same holds for games as Hybris and Pinball Dreams. It's simply *bliss* for the Amiga purist with a love for action games, as it's so remarkably close to the real thing.

Toni, now for the suggestion

Calibrating the chipset_refreshrate value leads to a stable positioning of a few jittery lines on the screen. Already a major advancement from the 'rolling' screen tearing that default no-buffering modes lead to. There's still a drawback unfortunately, as these jittery lines may still be in sight and distract from the real smooth Amiga experience. (And unfortunately chances of these lines being invisible in the border area by itself are small.)

Now instead of pressing F12 and returning to the screen a number of times until the jittery lines are positioned in the border (which as said is a bit of a game of chance), it would be much more sensible if we could have WinUAE create the correct alignment. I do have an idea, which I hope is feasible (and works).

What if WinUAE would do a vertical sync only on the first frame after the display buffer is activated, and then return the display back to the chipset_refreshrate timing. Would filling and displaying the buffer then not be aligned correctly, thus having the jittery lines per configuration out of the visible screen area? WinUAE would probably also have to do this alignment after a user returns from the settings menu (F12) to the screen, as currenly that shifts the position of the 'jittery lines'.

It would be awesome if such an option would work, as we could enjoy a calibrated fullscreen no-buffering mode (with blazing fast input response) AND have zero screen tearing by default! It would also be robust enough for use by general users as it would only take a one-time calibration of the chipset_refreshrate by the user. A small effort, especially when in return you're getting a (very close to) real hardware response back for it...

If something like this might work then it would preferably be an additional separate option in the config file, at least for now, so that we could test it with and without this "vsync on first frame" option.

I possibly have omitted some things here and there, but hopefully the findings and story are complete enough for you to think about this suggestion and possibly add this (or something similar?) to a future beta release?

I would appreciate to hear your thoughts on this.

Thanks again. I'm off to playing a few rounds of Hybris and Pinball Dreams!