Hello all! Hope you and your loved ones are doing well in these difficult times.

We recently discovered an annoying bug in Amiberry, which has been there for quite a while (v3.3 also had it).

It seems that if you set your monitor refresh rate at 50Hz (which allows PAL games and demos to have perfect sync, so scrolling is smooth etc.), causes issues when using audio playback under RTG modes.

This is noticeable in all RTG resolutions, but only under RTG. If you load up a game or a demo from within your RTG Workbench, it will work just fine. But if you open up an audio player (like Deliplayer, EaglePlayer, Songplayer) and try to play back a MOD or an mp3, the audio has small gaps in the playback.

I managed to track this down to the RTG vblank rate, which by default was always set to the Chipset refresh rate up till now. For some reason, if that was not set at 60, the audio under RTG would suffer. And since we use VSync with our monitor always, it is depending on what the monitor's selected refresh rate is.

To fix this, I started an experiment which was in the Todo list anyway: rewrite the whole gfx code from scratch, to get it closer to WinUAE (and hopefully fix this problem along the way). It took more than a week, but it's finally at a stage where it compiles and the first tests can be made.

This rewrite brings along several features from WinUAE, some of which are already implemented and some will probably come in the future. These include support for Borderless windows, various RTG board options and future support for multiple screens/monitors. That last bit is not implemented fully yet, but the basis for it is there now.

To handle the new options, I added a new Panel in the GUI: RTG Board

The new Borderless option can be found in the Display Panel, and only makes sense in combination with Windowed screen modes of course (full screen and full-window don't have borders anyway).

The next steps are to clean up after the rewrite, fix the new bugs that came along (you can't avoid that, unfortunately) and finally tune the performance as much as possible. Then it's testing time, for all the different scenarios and supported platforms (SDL2, Dispmanx, X11, KMSDRM).

If all goes well, we're looking at a release after that.

One more thing: This next version will be bumped to v4.0, to better reflect the amount of changes since v3.3. :-)

In the meantime, take care and stay safe everyone!