libretro/emulators/mupen64plus-ae.yml

emulator: Mupen64Plus AE
type: standalone
core_classification: community_fork
source: "https://github.com/mupen64plus-ae/mupen64plus-ae"
upstream: "https://github.com/mupen64plus-ae/mupen64plus-ae"
profiled_date: "2026-08-12"
source_commit: "25cfb7a0cf27517f796fb2baf92606f3ae9417f3"
core_version: "3.0.249 (beta)"
display_name: "Nintendo - Nintendo 64 (Mupen64Plus AE)"
cores:
  - mupen64plus-ae
  - MUPEN64PLUS-AE
  - org.mupen64plusae.v3.alpha
systems:
  - nintendo-64
  - nintendo-64dd
mode: standalone

notes: |
  Android front end under the paulscode.android.mupen64plusae namespace,
  published as org.mupen64plusae.v3.alpha (app/build.gradle:24). Everything it
  runs is vendored in tree rather than pulled as a submodule:
  mupen64plus-core, the hle, cxd4 and parallel RSP plugins, the GLideN64,
  glide64mk2, gln64, rice, angrylion-plus and parallel video plugins, its own
  audio, touchscreen and raphnet input plugins, and a miniupnp bridge for
  netplay (settings.gradle:1). ES-DE launches it for both n64 and n64dd with an
  ACTION_VIEW intent carrying a storage access uri, which the splash screen
  forwards to the gallery (AndroidManifest.xml:80-101, SplashActivity.java:134).

  Cartridge boot needs no boot ROM. The PIF boot sequence is simulated
  (device/pif/bootrom_hle.c:48, entered from device/r4300/interrupt.c:445,496
  and main/main.c:1875) and the CIC-NUS-6105 challenge is answered by an
  algorithm rather than a stored table (device/pif/n64_cic_nus_6105.c:93).
  Nothing fills the PIF ROM window from a file.

  Which 64DD IPL is used is not decided by the code. Two settings hold a path
  and both end up as the same working file dd_rom.n64: the global one, titled
  64DD IPL (J), read when the launched file is itself a disk, and a per game
  one, titled 64DD IPL, read when a cartridge is launched with a disk attached
  and only while the support64dd toggle is on (CoreService.java:606-620,
  GlobalPrefs.java:421,727, GamePrefs.java:579-599,
  CoreInterface.java:144,231,459-488). The core offers a callback that would
  name the image per disk region and the front end leaves it null
  (CoreInterface.java:223, main/main.c:1082-1086), so whichever image sits in
  the slot is the one loaded. A disk is recognised only when its system data
  header matches and carries one of three region words, 0xe848d316 for Japan,
  0x2263ee56 for the United States and 0x00000000 for development
  (RomHeader.java:180-220); the word sets a country code used for the ROM
  database and cheat lookup, never for picking the IPL. Launching a bare disk
  with the global slot empty stops before the core starts
  (CoreService.java:638-639), and since disk only games still need a cartridge
  image the application feeds the m64p_test_rom.v64 asset in its place
  (CoreService.java:643-644). Disk content inside a .zip or .7z is unpacked to
  the working directory first (CoreInterface.java:490-522).

  Transfer Pak carts come from four per player path settings copied into the
  working directory as playerN_gb_rom.gb and playerN_gb_ram.gb
  (CoreService.java:566-575, GamePrefs.java:933-960,
  CoreInterface.java:142-143,175-189,235-236,420-457). The core rejects a cart
  under 32 KiB and an unknown type byte at 0x147 (device/gb/gb_cart.c:996-1009)
  and fixes no name, size or hash, so neither the cart nor its save carries an
  entry here.

  Seven data files ship inside the package, each keyed to a version number and
  unpacked on first start into the private files directory, which is also what
  the core is told is SharedDataPath (ExtractAssetsOrCleanupTask.java:63-73,
  SplashActivity.java:90,399-402, AppData.java:391-403,
  NativeConfigFiles.java:111). mupen64plus.ini is the ROM database, read by the
  core (main/rom.c:473-490 from api/frontend.c:106) and by the gallery
  (SplashActivity.java:447). mupencheat.default is copied over
  Profiles/customCheats.txt into mupencheat.txt and parsed in Java
  (SplashActivity.java:443, CheatUtils.java:88-96, GamePrefsActivity.java:548);
  the core's own cheat.c opens no file. font.ttf is reached by GLideN64 only
  after /system/fonts/DroidSans.ttf fails, that name being what the front end
  writes as the configured font (TextDrawer.cpp:209-210,222-228,
  NativeConfigFiles.java:291); the core's OSD, the other upstream reader of
  that name (osd/osd.c:40), is absent from the Android source list
  (mupen64plus-core.mk:24-101). RiceVideoLinux.ini holds rice's per ROM
  settings (rice Config.cpp:38,933-953), Glide64mk2.ini glide64mk2's
  (glide64mk2 Main.cpp:1581-1586), and gln64.conf with gln64rom.conf gln64's
  global and per ROM settings (gln64 Config.cpp:245-252,296-302).

  Two more assets are read straight out of the package and never unpacked:
  m64p_test_rom.v64, and GLideN64.custom.ini, whose per ROM overrides the front
  end reads itself and writes into mupen64plus.cfg (AppData.java:396-397,
  ConfigFile.java:225-229, NativeConfigFiles.java:223,227). GLideN64 also asks
  the core for GLideN64.custom.ini in SharedDataPath, where it was never
  placed, so that native lookup finds nothing
  (mupenplus/Config_mupenplus.cpp:332-344). The touchscreen skins, the shader
  sources and the controller, touchscreen and emulation profile templates are
  used from the package the same way (AppData.java:392,401-403,
  GlobalPrefs.java:530, ShaderLoader.java:85).

  Optional content with no canonical artifact: hi-res texture packs under the
  user data directory, imported from a user archive (GlobalPrefs.java:469,
  ExtractTexturesFragment.java), the <ROM>_HIRESTEXTURES.htc and .hts caches
  the plugin builds from them, read back for their storage flag
  (NativeConfigFiles.java:365-376), customCheats.txt, custom touchscreen skins
  and cover art (GlobalPrefs.java:481,486-487), and alp_screen.vert with
  alp_screen.frag, which angrylion-plus opens as working directory relative
  paths before falling back to its embedded shaders
  (angrylion-plus output/vdac.c:119-127,167-174,246-247).

  Written rather than obtained: mupen64plus.cfg and the plugin sections in it,
  the mempak, eeprom, flashram and sram saves given default content when absent
  (main/main.c:1015-1078,1619-1622) and the 64DD disk save in whichever of the
  two formats SaveDiskFormat selects (main/main.c:365,1176-1235), savestates
  with the rcheevos progress file written beside them
  (CoreService.java:335,407-413), screenshots, the texture dump and cache
  directories, the GLideN64 shader cache and romInfoCache.cfg
  (GlobalPrefs.java:466-487, NativeConfigFiles.java:108-111).

  Two files in the tree this build never reads. cxd4's rsp_conf.bin: its reader
  is the zilmar variant of update_conf behind #if !defined(M64P_PLUGIN_API),
  and the build defines that macro (mupen64plus-rsp-cxd4.mk:8), so the variant
  compiled takes its settings from the core config API and ignores the filename
  it is handed (mupen64plus-rsp-cxd4 module.c:83-93,239,637-659). And
  parallel-rdp's shader directory, registered as a filesystem protocol only
  under PARALLEL_RDP_SHADER_DIR, which the Android build leaves undefined, so
  the SPIR-V compiled into the plugin is what runs
  (parallel-rdp rdp_renderer.cpp:74-78).

files:
  - name: "64DD_IPL_JP.n64"
    aliases: ["64DD_IPL_v12_JPN.bin", "64DD_IPL.bin"]
    system: nintendo-64dd
    required: true
    validation: [signature]
    description: "64DD IPL ROM (Japanese retail)"
    note: >
      The image every commercially released disk needs, and the one the global
      setting is named for. No name is fixed by the code: the path comes from a
      document picker and the file is copied to dd_rom.n64 before the core sees
      it. The core reads it whole, then byteswaps after identifying the first
      word as one of 0x80270740 (z64), 0x40072780 (n64) or 0x27804007 (v64);
      any other value logs an invalid IPL and disables 64DD. Size is not
      checked and no hash is computed.
    source_ref: "app/src/main/java/paulscode/android/mupen64plusae/jni/CoreService.java:606-620,638-639, app/src/main/java/paulscode/android/mupen64plusae/jni/CoreInterface.java:459-488, app/src/main/java/paulscode/android/mupen64plusae/persistent/GlobalPrefs.java:421,727, mupen64plus-core/upstream/src/main/main.c:1080-1145"

  - name: "64DD_IPL_US.n64"
    aliases: ["64DD_IPL_USA.bin", "IPL_USA.n64"]
    system: nintendo-64dd
    required: true
    validation: [signature]
    description: "64DD IPL ROM (American retail)"
    note: >
      Needed for a disk whose system data carries the US region word
      0x2263ee56, which the header reader accepts alongside the Japanese and
      development words. The front end holds one IPL path at a time and never
      branches on that region, so this image is loaded by putting it in the
      same setting. Same load path, format check and absence of size or hash
      validation as the Japanese image.
    source_ref: "app/src/main/java/paulscode/android/mupen64plusae/util/RomHeader.java:180-220, app/src/main/java/paulscode/android/mupen64plusae/jni/CoreInterface.java:223,459-488, mupen64plus-core/upstream/src/main/main.c:1080-1145"

  - name: "64DD_IPL_DEV.n64"
    aliases: ["64DD_IPL_DEV.bin", "IPL_DEV.n64"]
    system: nintendo-64dd
    required: true
    validation: [signature]
    description: "64DD IPL ROM (development)"
    note: >
      Needed for a disk whose system data carries the development region word
      0x00000000, the third value the header reader accepts before giving up on
      a file as a disk. Shares the single IPL setting with the other two
      images. Same load path, format check and absence of size or hash
      validation.
    source_ref: "app/src/main/java/paulscode/android/mupen64plusae/util/RomHeader.java:180-220, app/src/main/java/paulscode/android/mupen64plusae/jni/CoreInterface.java:223,459-488, mupen64plus-core/upstream/src/main/main.c:1080-1145"