Is there an NTSC video switch parameter?

[metallic77]

I am using this core on a Miyoo A30 and always runs at 60hz, is there a parameter like "uae4arm_ntsc" or something? Audio is garbled so i am trying to fix it running in 50hz..

[Chips-fr]

This core is hardcoded for 50Hz:

uae4arm-rpi/libretro/core/libretro-core.cpp

Line 1102 in 177c2f0

struct retro_system_timing timing = { 50.0, 44100.0 };

Since majority of amiga stuff works in 50hz i never bothered to implement 60 Hz.
Why you want 60 Hz ? Does your device support only 60 Hz ?

puae seems to used core parameters/variable to handle PAL or NTSC.

[metallic77]

No i am fine. I just used the core on a linux miyoo a30 (cortex a7 32bit) and behaving strangely. Speed was at 25fps, when i switched audio sync off it jumped to 60fps and when i switch sync to exact content frame rate in video sync options it went back to normal 50fps. Also sound works good there in alsa driver only. All in all performance is way better than puae on weak hw like that, even risky woods runs rock solid 50fps. There is crackling in other drivers for some reason. But i believe retroarch uses a different fork than this? And another question, isn't it possible to make this core available for android 32bit arm? That would open Amiga on many older 32bit phones.

[Chips-fr]

There is two version of uae4arm core:

• An old one which you can find in libretro repo and in a branch here. It should advertise as version 0.3 in retroarch menu of your device. It still exist because it support PSP.
• The second one is the master of my repo, more updated. It should advertise as version 0.5 in retroarch menu.

It could be interesting to know which version exactly you're using.
Does your problem appens in every amiga games ? And not in others platform for 50Hz content ?
What is your distribution ?

[metallic77]

It's 0.3 and it happened in all Amiga games until i changed audio sync etc. That's a linux gaming handheld, cortex a7 32 bit, cpu is allwinner a33. Retroarch 1.16

[metallic77]

[Chips-fr]

Version 0.3 is based on the old source code available in the libretro branch of my repository and the libretro repository:

https://github.com/Chips-fr/uae4arm-rpi/tree/libretro
https://github.com/libretro/uae4arm-libretro/
My master branch uses a more updated UAE core with better compatibility.

I also pushed an update regarding audio in my master branch:
751c8bd
The purpose of this update was to ensure a constant number of audio samples each frame by flushing the remaining audio samples at the end of each frame. The old code you're using does not include this update. It could be interesting to merge this commit into the old branch and test it on your device.

[metallic77]

the sd-retro directory doesn't even exist in the libretro repository

edit: the files exist in osdep

[metallic77]

copied the files to osdep and failed

https://pastebin.com/NuGwwkhF

Changed the platform to classic_arm_v7_a7 and again

https://pastebin.com/brjsAHq6

[Chips-fr]

Can you explain what you've done ? copied some files from my master to the libretro old source code ?
Can you anyway compile without any modification and test the generated .so ?

What is the distribution used on your device and the compilation environment you're using ?

[metallic77]

Copied the commit files to osdep folder of old libretro and got those errors. Without any modification yes i can compile it. I am using a docker for armhf from here ,on an MX Linux laptop with i7-7700hq

https://github.com/zoltanvb/retroarch-cross-compile

The distribution i don't really know, it's a Miyoo a30 handheld that runs some squashfs file system and cores etc are on sd card

[metallic77]

Right now (without modifications,)

export JOBS=4
export platform=linux-armv7-neon
./libretro-fetch.sh uae4arm
./libretro-build.sh uae4arm

[Chips-fr]

If you're able to compile and test the binary, can you try this branch:

https://github.com/Chips-fr/uae4arm-rpi/tree/libretro_audio_test

It's very close to the existing libretro branch (version 0.3) but:

• I just found that the number of samples indicated to retroarch was two times bigger than the correct value (dunno how it was anyways working on some setup ^^ )
• The audio buffer has been reduce to 256 (unsure if it's usefull but reducing could lower buffering on retroarch side)
• audio is now flushed at each frame.

I checked and now 882 audio samples (for both left & right ) is send to retroarch for each video frame. This is in line for an audio frequency of 44100Hz on a PAL amiga at 50 Hz (44100 / 50 = 882)