thanks for such a great addon. One thing about the remote share mount scripts, i think this is meant for NFS only rgiht. The script does not have -t cifs option, even if there is, i think busybox in latest coreelec does not support samba share anyways.
Here is the relevant part:
UPDATE: Nevermind it was my bad, busybox version does not require -t cifs argument, simply use mount //ip.add.re.ss/sharename /storage/roms -o username=user,password=pass would work, even for anonymous logins. Therefore script works fine.
Snes9x, mupen64, Famicom, sega genesis/masterdrive stuff, pcsx rearmed, flycast work perfect.
Especially flycast is impressive with Naomi Roms, easily emulates Guilty Gear XX Accent at 60fps, 640x480 in full anisotropic filter. Quite good for such a crap device.
I would like to also test Dolphin emulator without much expectation. Is the hook for running aarch64 in armhf working? I can understand the idea of replacing the elf interpreter with aarch64, and run with a staged ld_library_path, but curious how to overcome 32bit libgles.so (libmali.so) to my knowledge libmali is 32bit only, and if the binary dynamically loads it, it would seg fault since the binary would be in aarch64??
Yes the hook aarch64_to_arm_userspace is working, and not only the interpreter is changed but the entire package of libraries needed are included in the addon in aarch64 version (including libmali), based on dependencies automatically retrieved by the build script.
Hence as long as the library to be loaded in RA is available in the addon package in the aarch64 version, there will be no issue.
It’s quite a dirty and bug prone approach, mainly to try dolphin (which has low performance with this kind of hw anyways), so it’s not worth to waste too much time in that direction from development/maintenance point of view.
If you are going to build and try it, note that installed addon path will be different from arm version (will include aarch64 instead of arm in the addon folder name), so better to remove existing arm version retroarch.cfg, if any, and start with a clean one (or fix paths by hand).
I think my confusion comes from me using S905X chipset which carries Mali-utguard (Mali450) range GPU, the libmali.so blobs for those GPUs dont have aarch64 variants for the reason Amlogic being Amlogic. But for S905X3, they are equipped with Mali-BitFrost (Mali-G31) which have a aarch64 based blobs (libmali.so). Therefore, it think that would work with S905X3 but not with S905X. Afaik that should be the reason why CE still uses armhf user space.
May be i could try Librelec Test Build or EmuELEC where they use, panfrost/lima reverse engineered open source Mali GPu driver. I have no idea about the maturity but would be afun weekend hobby.
UPDATE: I see that Lakka is also using Lima OSS driver, thats the way the HOOK gets all the Libmali stuff in aarch64, thanks now i got it :), was a bit slow but i think i got it now.
To run with this hack, aarch64 libmali version must be exactly what CoreELEC kernel driver expects, otherwise it won’t work.
That is why this hook patches Lakka to use opengl-meson-coreelec.
Now the patch above is using davlin as it was only to test with Mali-G31: to try with Mali450 you are supposed to modify the patch above here copying from here, and adjust the following two symlinks accordingly. Based on what I see in opengl-meson-coreelec repo, a Mali 450 arm64 userspace driver exists.
Let me know if it works, adding a condition to select the correct libmali file based on the script configuration it’s easy.
If you managed to install the addon and to launch RetroArch without issues, it’s just a matter of learning how to use RetroArch itself. You can probably start here and explore their documentation:
You can also google “how to use retroarch” I guess, you will find a lot of stuff…
Additional info regarding folder locations of the addon can also be useful to set-up the things for the first time.
I am planning to do some testing over the weekend but experience from past emulators in general is that they tend to require input from a controller to navigate the menus and make config changes where I would much rather initially navigate using a mouse.
All input devices available in the system (including mouse) are recognized by retroarch and used in cores as needed (e.g. mouse can be used in ScummVM), but I don’t see a mouse cursor in the menu, even if mouse buttons are working. This is same behaviour as Lakka, so I guess complete menu navigation with mouse is not covered by retroarch (though I did not perform a deep investigation…).
That’s not related to this addon however, but retroarch menu driver itself.
Most convenient way for first setup of the system is a keyboard, a gamepad preconfigured in retroarch (e.g. xbox360) or a remote controller if your systems have CEC.
Of course retroarch.cfg can also be modified by hand through SSH (when retroarch is closed, otherwise changes will be overwritten on exit)…
