sharpdroid icon
sharpdroid icon

sharpdroid

this is an android app that runs SharpEmu, a PS5 emulator for Windows and Linux on x86-64. sharpdroid focuses on low overhead, mergeability, and modularity.

Cost / License

Platforms

  • Android
0likes
0comments
0articles

Features

sharpdroid News & Activities

Highlights All activities

Recent activities

sharpdroid information

  • Developed by

    mircowuffwuff
  • Licensing

    Open Source (GPL-2.0) and Free product.
  • Alternatives

    6 alternatives listed
  • Supported Languages

    • English

AlternativeTo Category

Gaming Software

GitHub repository

  •  13 Stars
  •  2 Forks
  •  7 Open Issues
  •   Updated  
View on GitHub

Popular alternatives

View all
sharpdroid was added to AlternativeTo by Darlene Sonalder on and this page was last updated .
No comments or reviews, maybe you want to be first?

What is sharpdroid?

this is an android app that runs SharpEmu, a PS5 emulator for Windows and Linux on x86-64. sharpdroid focuses on low overhead, mergeability, and modularity.

requirements

an arm64-v8a processor, android 9 or later, and a GPU with vulkan support. thats it. how it works

tl;dr: sharpdroid ships a compatibility layer purpose-built to run SharpEmu's x64 Linux build on arm64 android.

sharpdroid +-- user interface +-- host layer +-- ELF loader +-- syscall dispatch +-- thunk dispatch ¦ +-- vulkan and aaudio +-- signal delegation +-- VMA and SMC tracking +-- FEXCore ------------x86-64-below------------ +-- SharpEmu (linux-x64) +-- the PS5 game

SharpEmu has no CPU emulator. instead, it executes x86-64 PS5 guest code natively on an x86-64 host CPU. there is simply nothing there, to port to arm64 android.

thats where FEX comes in. we use the x86-64 to arm64 translator it ships, FEXCore, to read x86-64 and emit arm64, as SharpEmu runs.

on arm64 Linux, which is FEX's intended usage environment, FEX also ships what it calls its frontend; a Linux program that loads the guest, answers its syscalls, and delivers its signals. FEX's frontend is a program. we need a library. which is why we implement an analogue that works as such: our host layer.

our host layer routes most of what SharpEmu asks for through to the Linux kernel at android's heart. files, memory, threads, and futexes are all answered by the real thing. though this does not work for all types of question; for instance, when SharpEmu asks which program it is, the host layer answers SharpEmu, instead of an android app, which is what the kernel would have said.

graphics and audio are solved without serialisation or copying, since guest and host share one address space.

a decoy libvulkan.so driver reroutes graphics API calls from SharpEmu to the host layer's vulkan thunk, and as a result of that to the system driver or a loaded mesa turnip driver, directly. each frame is drawn straight from SharpEmu into android's ANativeWindow.

similarly, a decoy libaaudio.so driver reroutes audio API calls from SharpEmu to the host layer's aaudio thunk. all audio is played straight from SharpEmu through android's AAudio.