Built in Emulation

Built-in Emulation

Argosy bundles its own emulator powered by the Libretro core specification, so many systems play without installing a separate emulator app. It is a fork of LibretroDroid tightly integrated with Argosy's save sync, RetroAchievements, cheats, and netplay.

Built-in emulation is separate from RetroArch. Settings, saves, and hotkeys for built-in do not transfer to RetroArch and vice versa. External emulators (including RetroArch) are covered in Emulator Compatibility; the pages linked below are only about the built-in experience.

Feature pages

• Save States -- quick slot, numbered slots, sync behavior
• Rewind -- defaults, per-platform behavior, restrictions
• Hotkeys -- default bindings, configuration, Player 1 limit
• Video -- shaders, filters, aspect ratio, rotation, audio toggles
• Custom Shader Chain -- the chain editor and shader catalog
• Cheats -- CheatDB, variants, memory scanner
• Speedrun Mode -- split tracking, timer panel, hotkeys
• BIOS -- RomM firmware sync and distribution

Core Downloads

Cores are not bundled with the APK. Argosy downloads the appropriate core from the Libretro buildbot the first time you need it:

https://buildbot.libretro.com/nightly/android/latest/<abi>/

If you launch a game for a platform that has no core installed yet, Argosy downloads the default core for that platform automatically before the game starts. You can also opt into bulk core downloads during first-run setup, or fetch cores ahead of time from Settings > Built-in Emulator > Manage Cores.

In Manage Cores, each core shows:

• Install status (installed vs. available)
• Whether an update is available
• Netplay support

From here you can download a core on demand (e.g. to swap from FCEUmm to Nestopia for NES) or update an installed core to the latest nightly.

If a launch fails because the device is offline and the core hasn't been downloaded yet, Argosy surfaces the error and lets you retry once you're back online.

If a core crashes, Argosy notices on the next launch and offers to roll back to a previously installed version of that core. It keeps the recent core builds it has downloaded so a known-good binary is available to restore, and verifies a core's integrity when checking for updates.

For some cores, Argosy also downloads supporting assets the first time you launch the platform. PPSSPP (PSP) pulls a small bundle of fonts and helper files so in-game menu text renders. These happen automatically and silently — you'll just notice the first PSP launch takes a little longer.

ARM Architecture (ARMv7 vs ARMv8)

Argosy is built for modern 64-bit Android devices. ARMv7 (32-bit) support is experimental and currently unreliable -- see the note below before installing the 32-bit APK.

ARMv8 (arm64-v8a) -- supported

This is the default for every modern emulation handheld and the only ABI Argosy is actively tested against. Grab argosy-vX.Y.Z-arm64.apk from the release page, or the universal APK if you are unsure.

When Argosy needs a core, it downloads the matching ARMv8 build from the Libretro buildbot:

https://buildbot.libretro.com/nightly/android/latest/arm64-v8a/

ARMv7 (armeabi-v7a) -- experimental

A 32-bit APK (argosy-vX.Y.Z-arm32.apk) is published alongside each release. Core availability is broader than the wiki previously suggested: every Libretro core Argosy ships works for ARMv7 on the upstream buildbot except Dolphin (GameCube / Wii) and Azahar (3DS), which are 64-bit only. Launching a GameCube, Wii, or 3DS game on a 32-bit device will fail with "Core is not published for armeabi-v7a."

Caveats that keep this experimental:

• Performance on 32-bit hardware is the main risk. Cores like PPSSPP, Parallel N64, Beetle PSX HW, Beetle Saturn, melonDS, and Flycast build and download fine for ARMv7, but target systems that may not run at full speed on older 32-bit devices.
• Recent testing on a real 32-bit device was unsuccessful for reasons beyond core availability. Until a 32-bit device is re-validated end to end, treat ARMv7 as experimental.
• When a core download does fail on a 32-bit device, the error now includes the ABI (e.g. "Core is not published for armeabi-v7a") so you can distinguish an ABI mismatch from a network failure.

If you are on a 32-bit device and want to help test, install the arm32 APK and report issues at GitHub Issues. For now, 64-bit devices are the supported path.

Architecture override (advanced)

Settings > Built-in Emulator > Architecture lets you force Argosy to request 32-bit or 64-bit cores regardless of the auto-detected ABI. This is intended for development and testing; changing it deletes already-downloaded cores and forces a re-download. Most users should leave it on the auto-detected value.

Per-Platform Cores

Most systems have a default core chosen for broad compatibility. Some platforms offer alternatives -- for example, NES has FCEUmm (default) and Nestopia, SNES has Snes9x (default) and bsnes, N64 has Mupen64Plus-Next in GLES3 and GLES2 variants plus Parallel N64, and PS1 has PCSX ReARMed (default) and Beetle PSX HW.

To switch cores:

• For a whole platform -- Settings > Platforms > [Platform] > Core. Affects every game on that platform that doesn't have a per-game override.
• For a single game -- open the game's details, select Per-Game Settings from the left-hand menu, and change the Core row. Overrides the platform default for that game only.

If you switch to a core that isn't installed yet, Argosy downloads it on the next launch.

Some systems have no alternative in the built-in emulator (e.g. GameCube uses Dolphin, PSP uses PPSSPP). In those cases the platform setting only exposes the one option.

Core Options

Some cores expose their own settings -- renderer, screen layout, BIOS behavior, and the like. Argosy ships curated options for the cores that support them, saved per core and persisted across launches. You can reach them in three places:

• Settings > Built-in Emulator > Core Options -- pick a platform and core, then adjust its options.
• Settings > Platforms > [Platform] > Core Options -- the same options for that platform's core.
• In-game -- open the in-game settings overlay and switch to the Core Options tab to change the running core's options without leaving the game.

Most options apply immediately; a few only take effect after the game is relaunched, and those say so in their description. The in-game tab is greyed out for cores that have no configurable options.

Play! (PS2) and Retro-8 (PICO-8) shipped as built-in options in v1.3.0. Like every newly added libretro core, both are considered unstable until they've gone through real-device testing — expect rough edges, and report crashes or rendering issues at GitHub Issues.

PC-FX (Mednafen PC-FX), Philips CD-i (SAME CDi) and Atari Jaguar (Virtual Jaguar) were added in v2.8.0. As with every newly added libretro core, treat them as unstable until they have been through real-device testing, and report crashes or rendering issues at GitHub Issues.

In-Game Status Bar

A small status bar can sit over the game while you play. It is off by default and configured at the root of Settings > Built-in Emulator:

• In-Game Status Bar -- the master toggle. The rows below only appear while it is on.
• Status Bar Corner -- Top Left, Top Right, Bottom Left, or Bottom Right.
• Show Battery
• Show Clock
• Show Session Time -- time since this session started.
• Show FPS -- presented frames per second, hidden while fast-forwarding.
• Show Last Save State -- how long ago a save state was written.

New in v2.6.0 and untested on hardware, so report it if the bar overlaps game content or does not appear at all.

Per-Game Settings

Core options and controller mappings can be overridden for a single game, leaving your global defaults untouched. The two are independent: a game can use custom controls with global core settings, or custom core settings with global controls -- neither implies the other.

• Core options -- in the in-game settings overlay, open the Core Options tab and turn on Game-specific settings. Changing an option then forks it to this game only; options you leave alone keep inheriting your global defaults.
• Controller mapping -- open the Controls tab and turn on Game-specific controls, then use Input Mapping to remap buttons for this game only. The same toggle also scopes the per-port controller type below.

Per-game overrides are stored against the game and persist across relaunches. Turn the toggle off to fall back to your global settings.

Controller Type per Port

Some cores let a single port accept more than one kind of controller -- a PlayStation core offering standard pad, analog, or Multitap, or an N64 core offering controller vs. mouse. Where a port has more than one option, the in-game settings overlay's Controls tab shows a Player N Controller row for it. The choices and their labels come straight from that core's own advertised device list, so they vary by core, and the row does not appear at all for a port where the running core only advertises one device.

Changing a port's controller type is stored the same way as the rest of your emulator settings: globally by default, or per-game when Game-specific controls is on (see Per-Game Settings above). It persists across launches now instead of resetting each session. Reassigning a running core's input device can hang some cores, so a change made in-game is saved but shows Applies next time you launch -- it takes effect on the next launch rather than immediately.

Platform Restrictions

Not every feature is available on every system -- cheats are disabled on dynamic-memory platforms, rewind is disabled on heavy platforms, netplay is only supported for some cores. See the relevant feature pages above and Platform Limitations for the cross-emulator view.