chipset_refreshrate improvement

[Dr.Venom]

Thanks for the update.

A small bug report relating to both b5 and b6.

I'm experiencing some timing problems with Eagle Player when playing modules from the RTG Workbench, displayed on my 60hz LED monitor. When the chipset_refreshrate is set to ~49,92, modules seem to play too slow. If I disable the custom chipset_refreshrate then the problem is not there.

Background:
I'm using EaglePlayer with the EmpyGUI24 on a RTG workbench with display on my 60hz LED screen. I'm noticing that when I set the chipset_refreshrate to ~49,92hz then the modules played by EaglePlayer are played more slowly.

The display window in the bottom right corner shows "CPU: ~10%" and "60 [~49,9]". If I set Eagle Player's 'timing' (in preferences) to either 'CIA timing' (the default I've always been using) or 'Timer Device', then the music plays too slow; if I set timing to 'VBlank timing' than most modules sound OK, but also some play to quickly.

If I disable the custom chipset_refreshrate alltogether than all modules sound fine with CIA timing (as they used to before b5). In the bottom right corner of the WinUAE window it then shows "CPU: ~10%" and "60 [~60]".

[Toni Wilen]

Originally Posted by Dr.Venom

A small bug report relating to both b5 and b6.

I don't think this is a bug. You have NTSC (60Hz) configuration but want to see it is a ~50Hz setup.

This can get confusing for everyone (including me!) because there are 2 "refresh" rates.

You could say chipset refresh accelerates or slows down time between emulated and real world.

Emulated hardware still runs at original real rate (so that running programs think they are running on normal hardware) but what you actually see is something else

Note that chipset refresh is ignored if it is equal to PAL or NTSC rate to allow proper PAL/NTSC switching because it is what everyone expects.

Chipset refresh would conflict with this if it is always enabled. Not sure if there are better solutions to this problem. (Remember that "normal" usage always takes priority so don't expect complex solutions)

[Dr.Venom]

Originally Posted by Toni Wilen

I don't think this is a bug. You have NTSC (60Hz) configuration but want to see it is a ~50Hz setup.

I don't necessarily want to see it as exclusively a NTSC (60Hz) or exlusively a ~50hz setup. The proper switching behaviour between 50/60hz should absolutely be part of it.

My analogy would more be one of a PAL Amiga with a GFX card attached, where the RTG screenmode runs in 60hz. A friend of mine has such a real hardware setup, where he has both a VGA monitor attached for his Workbench stuff, but when he for example loads up a WHDLoad game, the display switches to the built-in video-out and his attached Philips CRT/15Khz monitor (thus running games with 313/312 lines at ~49,92hz and ~50,08hz).

I currently have WinUAE setup in the same way, with two monitors attached, one for the RTG side (60Hz LED) and one for native modes (the 15khz monitor through soft15khz).

This can get confusing for everyone (including me!) because there are 2 "refresh" rates.

You could say chipset refresh accelerates or slows down time between emulated and real world.

Emulated hardware still runs at original real rate (so that running programs think they are running on normal hardware) but what you actually see is something else

I can see that it's indeed easy to get caught in a sort of Twilight Zone between the emulated and real world

Note that chipset refresh is ignored if it is equal to PAL or NTSC rate to allow proper PAL/NTSC switching because it is what everyone expects.

Understood. That's probably also the way it works best. There's only one other possibility (super deluxe) I can think of. That would be to create a screenmode settings panel where users can configure all possible native Amiga screenmodes on the PC side, including the possibility of a custom chipset_refreshrate per screenmode, and have proper switching between all of them, almost as if a real Agnus was behind the wheel. That would be pretty cool actually . The super expert display configuration panel (hidden somewhere not to scare a lot of users away).

Chipset refresh would conflict with this if it is always enabled. Not sure if there are better solutions to this problem. (Remember that "normal" usage always takes priority so don't expect complex solutions)

OK, just thinking out loud. I don't know how complex or how much work this would be. Would it work if we used the 'refresh rate' of the RTG Graphics card (as set in the Hardware -> Expansions panel) as being dominant over the chipset_refreshrate. So only if the 'refresh rate' of the RTG Graphics card is set to either exactly 50 or 60hz and a RTG mode is displayed, then WinUAE overides the chipset_refreshrate and sets it to 50.000000 or 60.000000 to allow for proper PAL/NTSC switching. But as soon as the RTG screenmode is closed and a native display opened, the refresh rate is set back to the (custom) chipset_refreshrate. That way it would probably also mimick real world behaviour? Closest thing that comes to mind is the behaviour of say an Amiga 1200/3000/4000 with a PCI graphics card attached through an Elbox mediator board (http://www.elbox.com/products.html).

[Dr.Venom]

Originally Posted by Toni Wilen

Note that chipset refresh is ignored if it is equal to PAL or NTSC rate to allow proper PAL/NTSC switching because it is what everyone expects.

Chipset refresh would conflict with this if it is always enabled. Not sure if there are better solutions to this problem. (Remember that "normal" usage always takes priority so don't expect complex solutions)

Hi Toni,

Coming back to the earlier "problem" of the eagleplayer playing modules to slow when having chipset_refresh set to something different than 50.00000 and playing them from RTG workbench. This issue is still there in Beta 7. I now better understand your answer with the proper 50/60hz switching behaviour. If this switching behaviour is enabled (chipset_refresh set to 50.0000) then modules play at the right speed (upon booting and going from native screenmode to opening the RTG workbench, it switches speed to 60hz) . But, if the switching behaviour is disabled by setting a custom chipset_refresh (at ~50hz), than the modules play about 20% to slowly. This is apparently because the normal switching behaviour can't/doesn't occur.

I was thinking of the following possible solution to have the best of both worlds, i.e. being able to set custom chipset refresh AND have proper switching behaviour still enabled.

In addition to the chipset refresh being ignored when equal to pal or ntsc rate, would it be a solution to have a custom chipset refresh automatically toggle between ignored and enabled when the emulation is internally doing the PAL/NTSC switch?

As an illustration how this would work:
1. Default config of user = RTG workbench at 60hz (full-window on 60hz windows desktop) & native fullscreen mode set at ~50hz with chipset_refresh enabled (at e.g. 49,92hz or 50.0002hz) -> running native PAL applications gives user desired behaviour;
2. When emulated machine switches timing to 60hz (for example caused by booting up Workbench in this setup) -> custom chipset_refresh gets disabled for proper PAL/NTSC switching -> state is now 60hz;
3. When emulated machine switches timing back to 50hz (by starting a WHDLoad game from Workbench for example)-> custom chipset_refresh gets enabled again -> user desired PAL behaviour follows (chipset refresh at e.g. 49,92hz or 50.0002Hz);
4. Toggle between two and three.

Would this be a workable (and implementable) solution?

[Toni Wilen]

Moved from beta thread because this isn't going to happen in 2.3.2.

First, any player that uses vblank timing works as designed, playback changes depending on chipset refreshrate (RTG refresh may not be same as chipset refresh on real Amigas either). This is not good enough reason for change

Whole chipset_refresh needs better implementation. Main problem is that it forces all refresh rates to selected value.

Remember that originally it was only meant to slow down or speed up games

Perhaps some kind of multiplier or base unit (clock rate?) is better than direct vertical refresh rate value.

Note that 2 values, one for PAL and one for NTSC is not enough. There are 6 "standard" rates, 312 line PAL, 313 line PAL, interlaced PAL and same for NTSC. (not counting programmed rates but fortunately those aren't used by games or demos that need smooth scrolling)

[Dr.Venom]

Originally Posted by Toni Wilen

Whole chipset_refresh needs better implementation. Main problem is that it forces all refresh rates to selected value.

Remember that originally it was only meant to slow down or speed up games

Yeah I know...

Perhaps some kind of multiplier or base unit (clock rate?) is better than direct vertical refresh rate value.

Note that 2 values, one for PAL and one for NTSC is not enough. There are 6 "standard" rates, 312 line PAL, 313 line PAL, interlaced PAL and same for NTSC. (not counting programmed rates but fortunately those aren't used by games or demos that need smooth scrolling)

I don't think a multiplier or base unit/clock rate will work, mainly for the reason below.

I see the chipset refresh serving the following two purposes. It creates the possibility to:

1. Set WinUAE's output/refresh rate identical or very close to real hardware line mode refresh rates, i.e. recreate almost exact Agnus display refresh behaviour.
2. Match WinUAE's refresh rate to the real world monitor output rate, for the purpose of minimizing screen tearing in the no-buffering mode.

Having one clock rate or multiplier would conflict with 2.

An improved implementation of the chipset refresh would preferably achieve both 1 and 2. Given these goals (you might differ on them?), would it be an idea to create an "Advanced Chipset Refresh Rates" configuration section, where users can configure screenmodes and custom chipset refresh rates for all 6 "standard" rates? Thus effectively configuring WinUAE's display output to behave like a real Agnus. Possibly the seventh "standard" would be the screenmode and refresh for everything else (as most users probably will not use more than one programmed mode).

This additional configuration section would preferably be flexible enough to accommodate users that prefer a setup with one monitor (LCD/LED/VGA) attached and let's say two refresh rates (e.g. 50 and 60hz), to the more "advanced/purist" users who would like to go all the way through the means of adding seperate screen-/refresh modes through Powerstrip or Soft15khz for all of the Agnus standard rates.

For the purpose of illustration, the extra configuration section/panel could be like the one below:

Advanced Chipset Refresh Rate Panel-----------------------------
LINE MODE | REAL AMIGA  | UAE CHIPSET REFRESH | SCREENMODE     |
 ----------------------------------------------------------------
 P   625      50               user input       user selection |    
 A   312      50.08            user input       user selection |
 L   313      49.92            user input       user selection |
-----------------------------------------------------------------
 N   525      59.94            user input       user selection |
 T   262      60.05            user input       user selection |
 S   263      59.83            user input       user selection |
 C                                                             |
----------------------------------------------------------------
RTG  any      any              user input       user selection |
----------------------------------------------------------------

As further illustration, the following would be example configurations for both a "simple" user and a more advanced/purist user.

SIMPLE: user has two default screenmodes, one for PAL and one for NTSC

Advanced Chipset Refresh Rate Panel-----------------------------
LINE MODE | REAL AMIGA  | UAE CHIPSET REFRESH | SCREENMODE     |
----------------------------------------------------------------
 P   625      50              50.0021           1080p/50.0021  |    
 A   312      50.08           50.0021           1080p/50.0021  |
 L   313      49.92           50.0021           1080p/50.0021  |
-----------------------------------------------------------------
 N   525      59.94           60.0014           1080p/60.0014  |
 T   262      60.05           60.0014           1080p/60.0014  |
 S   263      59.83           60.0014           1080p/60.0014  |
 C                                                             |
----------------------------------------------------------------
RTG  1080     "60"           60.0014            1080p/60.0014  |
----------------------------------------------------------------

ADVANCED: User has created 6 custom screen-/refresh modes (through Powerstrip or Soft15khz) to match as closely as possible the Agnus linemodes.

Advanced Chipset Refresh Rate Panel-----------------------------
LINE MODE | REAL AMIGA  | UAE CHIPSET REFRESH | SCREENMODE     |
----------------------------------------------------------------
 P   625      50              50.0021           576i /50.0021  |    
 A   312      50.08           50.0790           287p /50.0790  |
 L   313      49.92           49.9180           287p /49.9180  |
-----------------------------------------------------------------
 N   525      59.94           60.0010           480i /60.0010  |
 T   262      60.05           60.0520           240p /60.0520  |
 S   263      59.83           59.8510           240p /59.8510  |
 C                                                             |
----------------------------------------------------------------
RTG  1080     "60"           60.0014            1080p/60.0014  |
----------------------------------------------------------------

To create full support for users with dual monitor setups, a last column could be added to select the correct adapter/monitor for running the specific screenmode on. Or at least a configuration option for the monitor to use for RTG mode and the one to use for the native modes would be welcome.

Pheeww.... it has indeed became somewhat more complex (or interesting) then we started out with . What's your idea on the above, would this be an implementable solution?

EDIT: For people interested, this feature has been implemented by Toni through settings in the config file. More info can be found here: http://eab.abime.net/showthread.php?t=58900