Skip to content

simple64 - RetroBIOS
Type standalone
Classification Community forks
Source https://github.com/simple64/simple64
Version v2024.12.1
Profiled 2026-08-08
Cores simple64, simple64-gui, io.github.simple64.simple64
Systems nintendo-64
Technical notes

Qt front end by Logan McNaughton over a vendored fork of mupen64plus-core, with parallel-rsp and parallel-rdp as the only RSP and video plugins (wiki, simple64-FAQ.md). The monorepo holds the core, the GUI, the SDL2 audio plugin, the Qt and raphnetraw input plugins and both parallel components as squashed subtrees (pull_repos.sh). The core is compiled with M64P_PARALLEL, M64P_NETPLAY and NO_ASM, and its source list leaves out src/osd and every dynarec (mupen64plus-core/CMakeLists.txt:26,28-104). ES-DE runs the release binary as --nogui <rom>; the GUI registers only verbose, nogui and test (simple64-gui/main.cpp:14-24). Development stopped and the repository was archived in February 2025, five commits past v2024.12.1, touching only the README, the build script and a netplay dialog.

Boot runs the real PIF ROM when one is present, which is where this fork parts company with mupen64plus upstream: upstream keeps open_pif behind the M64CMD_PIF_OPEN command with a caller supplied length and ships no such image in data/, while simple64 opens the file itself at a fixed length and ships both images. get_pif_path names pif.pal.rom for SYSTEM_PAL and pif.ntsc.rom for SYSTEM_NTSC and SYSTEM_MPAL, then resolves it against the shared data path (mupen64plus-core/src/main/main.c:1565-1580; mupen64plus-core/src/api/config.c:1610-1625; mupen64plus-core/src/osal/files_unix.c:150-170). The GUI passes the directory holding the executable as that path (simple64-gui/mainwindow.cpp:986-988, mupen64plus-core/src/api/frontend.c:59,90), and build.sh copies both images there (build.sh:26), so a release install always carries them.

Absence is not fatal. The lookup returns NULL when the file is not found and the result reaches fopen unchecked; on a failed open, open_pif is never called and g_start_address keeps its initialiser 0xa4000040 (mupen64plus-core/src/main/main.c:112,1624-1633). A digest that matches none of the four accepted values returns M64ERR_INPUT_INVALID, which main_run discards, leaving the same address. pif_bootrom_hle_execute returns immediately when the address is 0xbfc00000 and otherwise simulates IPL1 and IPL2 in full, quiescing the RSP, PI, VI and AI, deriving s3 to s7 from pif24, copying IPL3 into DMEM and planting the stub CIC x105 needs (mupen64plus-core/src/device/pif/bootrom_hle.c:48-151). It runs on cold boot and on both reset paths (mupen64plus-core/src/main/main.c:1977; mupen64plus-core/src/device/r4300/interrupt.c:445,496). The CIC challenge reads no file either: process_cic_challenge answers with the CIC-NUS-6105 algorithm (mupen64plus-core/src/device/pif/pif.c:252-260, mupen64plus-core/src/device/pif/n64_cic_nus_6105.c).

64DD is not reachable. The GUI's media loader supplies only the two Game Boy cartridge callbacks and leaves set_dd_rom_region, get_dd_rom and get_dd_disk null, the two functions that would have answered being commented out (simple64-gui/interface/common.cpp:129-163,240; mupen64plus-core/src/api/m64p_types.h:186-221). load_dd_rom is only reached after load_dd_disk succeeds, and load_dd_disk bails on a null callback, so the IPL image the core can otherwise load and byteswap is never requested (mupen64plus-core/src/main/main.c:1175-1247,1722-1736). No IPL entry follows from that, and the system list carries no 64DD line.

Transfer Pak carts come from Player1GBROM and Player1GBRAM through Player4GBROM and Player4GBRAM, filled by a file dialog (simple64-gui/mainwindow.cpp:84-117, simple64-gui/interface/common.cpp:87-127). The pair is a Game Boy cartridge and its save, supplied by the player, and the code fixes no name, size or hash for either, so neither carries an entry here.

The Voice Recognition Unit is the one asset the user has to go and get. The core's VRU controller forwards every word command to the input plugin (mupen64plus-core/src/device/controllers/vru_controller.c:147-235), and setupVosk loads libvosk from beside the executable, then hands vosk-model-small-en-us-0.15 under the user data directory to vosk_model_new once conf/mfcc.conf is found inside it (simple64-input-qt/main.cpp:769-813). Choosing "Emulate VRU" for controller 4 tests that same file and, when it is missing, downloads https://alphacephei.com/vosk/models/vosk-model-small-en-us-0.15.zip and unpacks it there with 7za (simple64-input-qt/configdialog.cpp:22-62,93-115). build.sh fetches only the Vosk library, never the model (build.sh:89-101, 158-160), so no release carries it.

Data the build places beside the executable: mupen64plus.ini, parsed as the ROM database and keyed on MD5 then CRC pair, which supplies save type, player count, rumble, Transfer Pak, Controller Pak, bio pak and expansion memory per title (mupen64plus-core/src/main/rom.c:190-235,674-691; build.sh:25); and cheats.json, pulled from simple64/cheat-parser at build time and read by header CRC pair and country code (simple64-gui/cheats.cpp:230-239; build.sh:106-111). Neither is hashed or version checked, romdatabase_open logs and returns when the file is absent, and loadCheatData yields an empty object, so both degrade rather than fail.

Two data files in the tree this build never reads: data/font.ttf, whose only consumer is src/osd/osd.c, absent from the source list, leaving osd_new_message as the inline no-op behind M64P_OSD (mupen64plus-core/src/osd/osd.h:93,104,118-121); and data/mupencheat.txt, referenced nowhere under src/ since cheats come from the GUI's own JSON. The parallel-rdp shaders are compiled in through shaders/slangmosh.hpp rather than loaded (parallel-rdp-standalone/parallel-rdp/rdp_renderer.cpp:36), and the file reads in parallel-rsp/main.cpp belong to a test harness that sits outside that plugin's CMake target.

Written rather than obtained: mupen64plus.cfg in the config directory and simple64-gui.ini beside the executable (simple64-gui/mainwindow.cpp:249), the Controller Pak, EEPROM, FlashRAM and SRAM saves opened with default content when absent (mupen64plus-core/src/main/main.c:1160-1173,1717-1720), the per ROM save metadata (mupen64plus-core/src/main/rom.c:263,347), savestates and screenshots (mupen64plus-core/src/main/screenshot.c:174), and the Discord game SDK and Vosk shared libraries, which are resolved by name at runtime and are code rather than data (simple64-gui/mainwindow.cpp:356, simple64-input-qt/main.cpp:773).

2 files | 0 required, 2 optional | 2 in repo, 0 missing | 2 with HLE fallback

pif.ntsc.rom optional in repo HLE fallback world
PIF boot ROM (NTSC)

  • System: nintendo-64
  • Size: 1.9 KB
  • MD5: ['5c124e7948ada85da603a522782940d0', '4921d5f2165dee6e2496f4388c4c81da']...
  • Validation: md5
  • Source: mupen64plus-core/src/main/main.c:1565-1580, mupen64plus-core/src/main/main.c:1624-1633, mupen64plus-core/src/main/main.c:2097-2135, mupen64plus-core/src/main/rom.c:502-525, mupen64plus-core/src/device/pif/pif.h:36
  • Chosen for SYSTEM_NTSC and SYSTEM_MPAL. rom_country_code_to_system_type returns SYSTEM_PAL only for country codes 0x44, 0x46, 0x49, 0x50, 0x53, 0x55, 0x58 and 0x59 and falls through to SYSTEM_NTSC for 0x37, 0x41, 0x45, 0x4a and, on its default arm, every other code, which is why the region is recorded as world rather than an enumeration. main_run reads 1984 bytes, the size of the PIF ROM window, and open_pif digests exactly that span, so the size given here is the length consumed rather than a check the code performs. Two digests are accepted: the current one, which is the image shipped in data/ and the No-Intro entry "[BIOS] Nintendo 64 - PIF (Japan, USA).bin" at 1984 bytes, and the digest of the earlier dump kept for compatibility. On a match the image is byteswapped into PIF memory and the reset vector moves to 0xbfc00000; on a mismatch the core logs "Invalid PIF ROM" and boots through the HLE bootrom instead.

pif.pal.rom optional in repo HLE fallback europe, australia
PIF boot ROM (PAL)

Generated on 2026-08-23T16:12:06Z