[Question] What version of WinUAE is current Amiberry based on?

[vanfanel]

Hi there!

What WinUAE version is Amiberry based on? I'm specially interested in emulating Marbella Vice laserdisc, which is supported by latest stable WinUAE.

Also, is it possible for Amiberry to properly synchronize framerate with the host framerate? NTSC and PAL games on the Amiga use different non-exact 50/60Hz video modes, so not synchronizing to host framerate would cause micro-stuttering.

[midwan]

Amiberry v5.x is a bit of a mix: The CPU emulation is stripped down and based on older WinUAE releases (pre-4.x), the core (custom chipset, drawing, CIA, etc) is based on WinUAE 4.4.0, and some other parts around it come from the latest version.

Amiberry v6.x is based on the latest WinUAE, including the newer CPU code (and includes JIT support for x86). Some parts are not implemented, such as custom hardware emulation. Some parts are emulated but not yet exposed to the GUI.

Regarding the specific laserdisc emulation you asked about, the code is there, but I think it may be missing some parts in the GUI to activate the Arcadia platform correctly.

Regarding the framerate: Amiberry uses V-Sync always, but it does not change/control the actual refresh rate of the screen opened. That can be done from the OS itself, so if your monitor supports 50Hz and you want to emulate a PAL machine, you can set your OS to use a 50Hz mode. The VSync options that WinUAE shows are also available in Amiberry, but they only change the internal state of the emulation (not the screen mode). You can use them if you want, but they only make sense to activate if you've already set your monitor to the desired refresh rate from the OS, first.

[vanfanel]

Thanks for your answer, @midwan ! I know you have put a lot of work in Amiberry for many years now, so I really appreciate every moment you dedicate to answer my questions.

I'm interested on the 6.x series because I want the precise emulation of the chipset seen on the latest WinUAE code, and the perspective of having the Arcadia available eventually is a big plus for me, too!

I would like to get perfect screen refresh rate match, as smooth scrolls without any stutter is what made the Amiga so special for me (not on every game or demo, but in those that had smooth scroll originally).
As you know, PAL modes weren't exactly 50.0000 Hz, and NTSC modes weren't 60.0000 Hz either, so even if I can set the host computer to ANY rate I want on the fly with wlr-randr (let's call it "external" frequency), I won't be able to get the "internal" frequency from Amiberry, right?
A possible solution would be to implement a system call to wlr-randr which would re-use the in-use resolution and would only change the vertical frequency...

Another solution (which I would greatly prefer) is being able to "force" Amiberry emulation to run always at a given screen rate, like 60.0000 or 50.0000Hz, and setting it "externally" on the host system we would achieve the same perfection with a small emulation timing deviance. Is there a place in the code where vertical refresh rate of the emulated Amiga can be forced?

[midwan]

If you want accuracy, then v6.x is definitely the way to go. It will eventually become the "main" release, but keep in mind it requires more from your CPU due to the updated emulation code.

Regarding the refresh rates, both WinUAE and Amiberry round up those PAL/NTSC refresh rates to 50 and 60 respectively, so you don't have to bother with fraction numbers there. If your monitor can handle them, and your device is powerful enough to process each frame in time, you should have smooth scrolling when you set those modes.

[vanfanel]

Fantastic, just built the "preview" branch, which seems to be the one based on latest WinUAE.

[vanfanel]

@midwan I have been experimenting and there's something not right with video synchronization.
I'm emulating an NTSC Amiga.
I set a 60.0000Hz video mode, since you told me the emulation rounds the NTSC refresh rate to exact 60.0000Hz.
But there are hiccups every 2-3 seconds (repeated frames, apparently). This is typical when emulated system sync rate doesn't match the host refresh rate. This is what I feared before building Amiberry...
How does the emulator sync? Does it sync to video? Does it sync on audio?

I have been fiddling with the various vsync options to no avail, disabled threaded drawing and whatnot, but the same hiccups are always present.
They are easily observable on Lemmings 1 scrolling text on the main menu.
I know how the game looks on real hw, FPGA and PUAE LibRetro core, and that scrolling text is perfectly smooth in all cases except Amiberry.

[giantclambake]

But there are hiccups every 2-3 seconds (repeated frames, apparently).

Not seeing that here -- Lemmings_v1.5_Files_NTSC_0901.lha is a NTSC title, refresh rate of my monitor is 60Hz, I can enable Vsync (standard) in amiberry (game title and display refresh rate the same) ; scrolling text on main menu screen is smooth....

... Lemmings_v1.5_Files_2089.lha is a PAL title ...my main display won't do 50Hz refresh, so I have to use my 5:4 50Hz capable display, I enable Vsync (standard) in amiberry ; scrolling text on main menu screen is smooth....

If I run the PAL title (Lemmings_v1.5_Files_2089.lha) on my 60Hz monitor, Vsync is not applicable (game title and display refresh rate are NOT the same) ... and I see some jitter/judder wrt the scrolling text on main menu screen (which is to be expected ;)

In saying that however, the jitter/judder happens 2 to 3 times per second, not every 2 to 3 seconds as you describe.

I can only imagine this has something to do with the wlr-randr command and/or the wayland compositor (I don't use wayland nor 'compositors' as such).

Tested with amiberry Preview/x86-64 using Debian bookworm (ryzen-5600/gtx-1050/x11)

[vanfanel]

@midwan I found out that when emulating an NSTC Amiga, the Amiberry emulation produces 59.94 frames per second. It is not rounded up to 60.0000 at all.

Setting a 59.940000 Hz video mode gives a perfect match and there are zero hiccups.

So, two questions arise:

1. Where did you get the 60.000000 Hz figure from? Do you happen to know where in the code are these 59.94Hz derived from?
2. Would it be possible to have an option to sync to HOST refresh rate? SDL2 will get you the exact Hz of the mode in use easily, I believe. The hard part (for me) would be to "convince" the chipset emulation to obey the precise frequency with decimals, which is needed for perfect video synchronization.

@giantclambake With all due respect, NTSC vs PAL doesn't have anything to do with the discussion here. It's about small decimal discrepancies when both the chipset and the host are in near-60.000000Hz mode, but NOT exactly 60Hz.

[midwan]

Not sure where you got those values from.

The relevant logic is all in the custom.cpp file, and more specifically the compute_vsynctime() and compute_framesync() functions (maybe more as well). If you set the emulated device to NTSC, then depending on the Vsync option you have selected in the Display panel (default/none, Standard, Standard 50/60Hz) then the internal gfx refresh rate will be set to either the vblank_hz which comes from the host system (in my case, that was 60.0544434), or 50/60Hz if you enable the VSync option.

Remember, internally Amiberry uses Vsync to show the frames anyway, so the options above only change the internal chipset settings (in other words, it makes sense to enable Vsync there only if you have the right refresh rate already set in your host system).

There's no reference to the 59.94 Hz you mentioned above anywhere, so I'm not sure where that comes from. Could it be the actual host refresh rate, when you set it to 60Hz?

What does the logfile indicate? If enabled, it will write out the detected mode, horizontal and vertical rates etc, in the following format:
"%s mode%s%s V=%.4fHz H=%0.4fHz (%dx%d+%d) IDX=%d (%s) D=%d RTG=%d/%d\n"

[vanfanel]

Ah, I see. This is my log booting an NTSC Amiga on Amiberry:
amiberry.log
If I am right, this is where the physical host video mode is detected:
Desktop: W=1280 H=1024 B=24 HZ=60. CXVS=1280 CYVS=1024
And this is what Wayland says about the mode in use:```

~/amiga$ wlr-randr
HDMI-A-1 "JZI BEETRONICS BEE133-00001 (HDMI-A-1)"
Make: JZI
Model: BEETRONICS
Serial: BEE133-00001
Enabled: yes
Modes:
1280x1024 px, 60.020000 Hz (preferred, current)

As you can see, according to Wayland the physical host video mode is **60.020000** Hz, but Amiberry fails to detect the decimals and identifies it as **HZ=60.** , which is clearly wrong.

How is the video mode / frequency being retrieved in Amiberry?

[vanfanel]

@midwan According to Toni Wilen on this thread: https://eab.abime.net/showthread.php?t=118242
...There's a field on WinUAE where the user can type-in a static vertical refresh rate.
That field is locatted on the bottom-right area of "Display" on the WinUAE GUI.
That would somewhat solve the lack of "sync to host refresh", by being able to specify a known refresh rate matching the one used by the host computer.
Can you please display that field on Amiberry 6.x too?

[midwan]

Ah, right - sure, that can be added in Amiberry's GUI as well.

[vanfanel]

@midwan I'm trying to understand, please lend me a hand here: where do you get the host monitor refresh rate from?
I see you use SDL_GetDesktopDisplayMode() here:

amiberry/src/osdep/amiberry_gfx.cpp

Line 794 in 6c7b584

if (SDL_GetDesktopDisplayMode(0, &desktop_dm) != 0) {

But that will get you a refresh_rate that is an integer (ie: for a 60.020000 Hz mode, it will give you simply 60).

That's why it's impossible to get the precise refresh rate in the logs, because the integer is printed here:

amiberry/src/osdep/amiberry_gfx.cpp

Line 870 in 6c7b584

write_log(_T("Desktop: W=%d H=%d B=%d HZ=%d. CXVS=%d CYVS=%d\n"), w, h, b, deskhz, wv, hv);

You seem to be using that value to adjust the emulated machine vblank:

amiberry/src/osdep/amiberry_gfx.cpp

Line 805 in 6c7b584

deskhz = desktop_dm.refresh_rate;

amiberry/src/osdep/amiberry_gfx.cpp

Line 899 in 6c7b584

maxrate = deskhz;

Then I see this function:

amiberry/src/osdep/amiberry_gfx.cpp

Line 2337 in 6c7b584

float target_getcurrentvblankrate(int monid)

But that's for getting emulated refresh rate instead of host refresh rate..?

And that will get you the same integer, imprecise host refresh rate in the end because it uses SDL_GetDesktopDisplayMode() again:

amiberry/src/osdep/amiberry_gfx.cpp

Line 203 in 6c7b584

static float SDL2_getrefreshrate(int monid)

If I am right on this, that could be causing the hiccups I am seeing when emulating an NTSC Amiga on a near-60Hz physical display mode.

[midwan]

You're probably right there, I'm using SDL2's function to get the host's current screen mode, including the refresh rate.
Most of the logic here was ported from WinUAE, but since it uses DirectX on Windows, I had to adapt the functionality to use what SDL2 offers, instead.

We'll see if the custom rate option will help with this, it should be ready to test in the next few days.

[midwan]

@vanfanel this is now merged, but I didn't have time to do some real-life tests. It loads and saves correctly to the config files, and I compared the functionality with that of WinUAE, to ensure they are identical. Even with the rounding glitches when parsing the string to a double and eventually to a float value (if you enter 59.940000 it will be changed to 59.93999999).

Let me know if it helps or not.

[vanfanel]

@midwan Yes, it helps immensely, as it's now possible to specify precise video refresh rates that match the physical video mode in use, thus getting perfect scrolls as in a real Amiga.

However, this brings a new issue: if the video refresh is adjusted, since audio rate isn't adjusted, too many/too few samples are produced and the audio "skips" occasionally.

RetroArch for example resamples audio to compensate, acknowledging for this exact same problem (that's why the UAE libretro core has perfect audio and video sync at the same time, which Amiberry lacks).

Internal audio rate adjustment to compensate is needed. I will ask Toni if that is present on WinUAE's code (I can't see it).