Guest HID Controllers support vibration as they have LRAs integrated into the controller bodies. We can try to emulate this vibration on the host device to provide further force feedback to the user.

Applications require storage for persistent data that they can create and modify to store state that is carried over from run to run. We need to implement interfaces which are used by the application to do so as it is used by essentially all commercial games.

The UI currently only has a light theme and doesn't support a dark theme, this restricts the ability of the user to pick what they prefer and doesn't match up with Android 9's Dark Mode.

Currently, the FPS and frametime is logged rather than displayed clearly when something is being played. This is suboptimal as the values can only be seen in realtime using adb logcat. So, adding the FPS + Frametime value on the screen itself will be fairly useful as then they can be viewed directly during runtime.

mine does not run a rom why is it? 🤔🤔🤔

We initially made the project's license GPLv3 due to it's popularity but at the time we had no hindsight of what we might want to do in the future and how that might be restricted. We decided internally that our main plan for monetization will be optional ads but due to GPL limitations of being unable to link proprietary (nonfree) libraries without adding an exception* we decided on Mozilla Public License 2.0.

* We refrained from adding an exception as that'd make our licensing a lot more complicated. In addition, we wouldn't be able to use SPDX and would have to include a lot more in the file headers.

The current memory system depends almost purely on KPrivateMemory for proper segmentation. This system didn't work out that well when implementing all memory related SVCs due to having an address as the parameter. So, a system where memory attributes are stored as blocks that can be found with their address would be far better. In addition, if all memory on the guest is shared with the host and works with the previously mentioned memory block system then most memory accesses won't need to use a kernel call rather can directly access the underlying pages.

Audio currently is somewhat slow due to the usage of queues rather than a circular buffer where copies can be performed as a block rather than one-by-one like it is right now. In addition, device disconnection isn't handled by the oboe callback class at the moment, this should be implemented as well.

As above, thank you

HI weird question maybe, but clicking on download latest build brings me to this project, however how can I install it onto my Android device?

Many thanks

The deswizzling implementation currently writes linearly and reads non-linearly, this is non optimal as the MMU cannot read ahead. This can be optimized a lot by reading linearly and writing non-linearly.

Android 10 has moved to SAF (Storage Access Framework) as the primary way to grant access to specific directories or files and it'll become mandatory in Android 11. It's the best to move to it as fast as possible.

A large variety of commercial games use ADPCM audio to compress the audio data with minimal quality degradation. We need to add in support to decompress the data so it can be consumed by our audio backend (oboe).

There is currently no display output in the emulator, this is a critical part of emulation. At least a basic framebuffer implementation should be present so software rendered homebrew can run.

NPDMs hold critical metadata which is required for us to emulate the following SVCs more accurately:

• GetInfo:
• • AllowedCpuIdBitmask
• • AllowedThreadPriorityMask
• • TotalSystemResourceAvailable
• • ProgramId
• • TotalMemoryAvailableWithoutSystemResource
• CreateThread
• SetThreadCoreMask
• SetThreadPriority

It also provides other useful attributes such as the address space type of a title which allows us to check if titles are compatible with Skyline as it only supports 39-bit titles at the moment.

In addition to implementing NPDM, the memory information provided via GetInfo is extremely inaccurate, this needs to be rectified as it leads to games breaking.

A lot of the FOSS libraries we use require the license being present in binary versions of the application, while we don't have this we're not following the licenses and so it's the best to fix this as soon as possible to be compliant with the licenses.

A HID implementation is required for games to read input from host HID devices, a translation layer needs to be created that can convert input from the host to the guest interface as provided by HID Services.

Accessing ROMs directly from the launcher allows quick access and convenient access to them.

An NSO file is the primary executable/linkable file used by the Switch and is contained within NCA files. Which are within NSPs/XCIs. Supporting NSOs is a step towards supporting all ROM files.

[Édit]
If you would like to participate in the translation that will be done later, please let us know here;

You will be contacted by the developers when the time comes.
thank you.

List of proposals and volunteers for translation: (thanks for their kindness)

@V6ser - Italian [IT] and maybe Brazilian Portuguese [PT-BR]

@kegri - Turkish [TR]

@Jatoxo - German [DE]

@Afk-82 - Simplified Chinese [zh-CN] and maybe Traditional Chinese [zh-Hant]

@FAROK000 - Arabic [AR] and Japanese [JA]

@ImCaillou - Brazilian Portuguese [PT-BR]

@resendex - European Portuguese [PT-EU]

@bugthug - Hebrew [HE]

@NotAWeeb69 & @Gocodeyrself & @ClearStaff (As a backup translator) - Polish [pl-PL]

@FranklinBartholomewHill - Finnish [FI]

@denys767 (Discord: Denis767#1070) - Russian [ru-RU] and Ukrainian [uk-UA]

@Ilithy - French [FR]

Hello;
Is it too early in development to start translating?
I would like to volunteer to translate the
Skyline interface into French.

Hoping not to disturb by posting here rather than on discord
(if so, please delete my request without hesitation)

Good day and good luck.

A basic audio implementation only implements audout services, these only allow limited control over playback and are not used by a vast amount of games, instead of them audren is used instead. Audio rendering services allow far more fine grained control over playback and gives almost direct access to the DSP.

The ability to map the buttons/axes of host HID devices to guest controllers is required for a good user experience. We cannot rely on Android's labelling of axes/buttons due to them being extremely inaccurate and inconsistent from device to device. A system for configuration and then translating mappings at runtime is required to be implemented.

The containers currently use ListView which is fairly inflexible in it's layout and we use a hacky approach to avoid doing a costly Context::findViewById for every item.
RecyclerView on the other hand streamlines this by integrating a viewholder into the view itself. In addition, it also addresses the problem with the layout as it can be programatically set to use a list layout or a grid layout.

The current kernel is heavily handicapped in areas due to it needing to be single threaded, this is suboptimal as it prevents certain design flows like being able to interrupt the control flow of a certain thread due to sleeping while letting the other threads fully function. In addition, there might be a viable boost in performance from this due to the multiple cores in today's processors which would go unused if we stuck to a single-threaded design.

GPFIFO is a FIFO queue of GPFIFO entries which point to a pushbuffer that are a list of commands and inline data that is used to dispatch data to a specific GPU Engine. GPFIFO also has synchronization in the form of syncpoints to ensure proper ordering of push buffers.

The codebase is somewhat lacking formal conventions at the moment with the lack of uniformity in a lot of places, this especially applies to the Kotlin codebase.
Introducing an explicit contributing guidelines to ensure uniformity everywhere will lead to a substantially better codebase and an easier way for contributors in the future to find out what mistakes to not make.
The guidelines should be rigorous but not so pedantic that the productivity of the contributors is greatly harmed by such guidelines being in place.

There's no proper way to exit the emulator at a moment's notice with proper resource cleanup, to tackle this issue we should use implicit resource cleanup via stack unwinding which C++ provides in the form of exceptions alongside signals being used to deliver a notification to enact the exception. This'll allow us to gracefully exit in nearly every case as signals will propagate as exceptions and won't result in a crash which would be significantly worse UX-wise.

First I have to thank you for the amazing Idea.
It's not possible to add .nsp yet right?
I have roms on the /sdcard then I tap the refresh button and nothing happens.

We need a structure which allows us to efficiently queue on work for the GPFIFO thread and let it process submissions asynchronously while sleeping when there is no work queued on as to save on resources which leads to higher performance alongside longer battery life.

The current system using ptrace is fairly slow due to the amount of cycles ptrace requires to pass on a syscall to the kernel process, this is primarily due to requiring the kernel as an intermediary for it. Junction branching on the other hand does runs completely in userspace and gives us far more control over everything.

The current system improperly implements mutexes, which leads undefined behavior in most cases. Fixing this is required for essentially all multithreaded applications to work correctly. In addition, conditional variables are currently not implemented and are required by a significant amount of multithreaded applications.

A lot of games pack a blob of data inside their ROM file that they access during execution, this is done so that they can stream in data from persistent storage. We need to provide an interface to access this data from the ROM file to the underlying applications.

There is an issue with synchronization overhead from using multi-process approaches to NCE, kernel calls end up being very expensive and polling leads to high CPU usage and by extension poor battery life and thermals. Moving NCE inside the same process allows directly jumping into SVC code with the only downside being the inability to support 36-bit games due to it's address being mapped by ART.

The guest has a touch-screen which is used for input in handheld mode, a translation layer is required which converts host Android touches into guest touch data which is present in HID Shared Memory.

The current loading mechanism only scans for ROMs while blocking on the UI thread, this is extremely bad design as the UI should remain interactable at all times. This was somewhat acceptable pre-SAF but due to the significant slowdown in searching post-SAF, we need to implement this.

Just tried build and run, but .nsp(mariobrosU) always throw "Incomplete NSP file",and xci file is not supported. Is it still in progress or just my wrong steps?

There are multiple issues that I have come across:

• Services & The kernel should be separated. Services do not live in the kernel, they live in sysmodules/builtins.
• Various interfaces are not handled correctly(see am & hid interfaces). A global reference to an interface that are not named breaks multi-calls to the creation of interfaces and multi-processes.
• You should not be allowed to register services with the same name without unregistering the first one
• Service names NEED to be > 0 and < 9
• Threading/Scheduling does not match nintendos kernel
• KEvent doesn't implement KReadableEvent & KWritableEvent
• Various enums are unscoped
• All of fatals cmds are not the same. ThrowFatal only throws a error code, ThrowFatalWithPolicy throws an error code and a fatal type, lastly ThrowFatalWithCpuContext throws an error code, a fatal type and the current cpu context.
• Fatals error codes return a ResultCode which can be unpacked.
• JoyConSide has no field known as "Unset"
• JoyConOrientation has no field known as "Unset"
• JoyConAssignment has no field known as "Unset"
• SetNpadJoyAssignmentModeSingleByDefault should set the orientation for one controller, not all of them
• JoyConDevices should not be considered as system controllers by default
• Various cmds which are supposed to have result codes written do not write them
• Thread yielding isn't accurate
• Memory permissions are not accurate
• Kernel doesn't do checks to ensure that only virtual addresses can be used for objects passed to the kernel
• Missing resource limits
• WaitSynchronization is incomplete
• Addresses are not checked for alignment in the kernel
• Mutex locks & Mutex unlocks always succeed when they shouldn't
• SignalProcessWideKey is incomplete
• SendSyncRequest can fail
• OutputDebugString shouldn't write to a register, only read
• GetInfo inaccuracies
• KSharedMemory inherits from KAutoObject, not KObject

There's more issues however this is just a general guideline to start with. Note, this list doesn't contain the number of code issues in the repo which should be addressed in the future

There is a limited branch range (+/-128MiB) available for jumping to the SVC handlers. While this provides no challenge on homebrew, it is a major issue on commercial games where the NSO .rodata, .data and .bss sections are extremely large and result in an inability to perform SVCs. To fix this, we need to move the .patch section prior to the .text section which puts all SVCs in the branch range.

The codebase has several issues with code style and with functionality in certain areas, RF2 is a catch-all for all these changes, similar to the first refactor. We want to cover the following points in RF2:

• RTTI for Service Class Name
• Service Constexpr Map for Function Resolution
• IPC Buffers to Span
• Eliminate Service enum
• NvDevice Constexpr Map
• IOCTL revamp (Buffer -> Span & All buffers as arguments & Return -> NvStatus)
• IOCTL Device Name + Function Name Printing
• IOCTL2 & IOCTL3
• Eliminate NvDevice enum
• SurfaceFlinger/IHOSBinder Rework
• Remove redundant comments
• Equal to brace initializers
• Check 0-inits for if they're required
• Review all unordered_map usage
• Fix FDSAN issues

The GPU's core synchronization primitive are syncpoints, which are simply just counters which are incremented when a task queued on them has been completed or are manually incremented using an IOCTL.
Fences are implemented atop syncpoints where operations wait until the syncpoints reaches a specific number to run, ensuring proper ordering.
Events are how fences are exposed to the userspace driver. They can be waited on using an IOCTL or be converted into a native HOS KEvent object that can be waited on just like any other KEvent on the guest.

The guest GPU's Maxwell 3D engine has the ability to execute "macros" which are lists of commands with corresponding arguments which are used in situations where commands need to be repeated significantly and potentially in a loop such as instanced rendering. We need to implement an interpreter that can interpret the custom ISA of the macro instructions and execute the correct commands.

Any ROM file should directly open the emulator and run the ROM for convenience's sake.

The GPU has it's own 40-bit virtual address space into which applications map GPU-sided data such as textures, storage buffers, etc. We need to implement a VMM (Virtual Memory Manager) which can handle address translation and region tracking for the GPU.

The current logger's UI takes up a fair amount of space per log. An option in settings for a compact logger which takes far less space per log would be fairly useful.

The emulator currently doesn't output any sort of audio. Most basic Switch games use audout (https://switchbrew.org/wiki/Audio_services#audout:u) for audio. So, this should be implemented.

When I was trying install the skyline is alawys say parce error