Skip to content

RustyNES v2.2.4 — "Cartridge" (libretro core builds/installs for RetroArch)

Latest

Choose a tag to compare

@github-actions github-actions released this 24 Jul 02:27
a1df7b9

RustyNES v2.2.4 — "Cartridge" (libretro core builds/installs for RetroArch)

A libretro / RetroArch distribution cut. Its single purpose is that the RustyNES core builds and installs cleanly through the Libretro buildbot (git.libretro.com/libretro/RustyNES), so RetroArch users can pull it straight from the in-app Online Updater → Core Downloader.

A cartridge is the thing you slot in to play. That is what this release is about: getting the RustyNES core packaged and advertised correctly so it drops into RetroArch and runs.

Zero emulation-core changes. The deterministic #![no_std] chip stack, the save-state / TAS / netplay formats, and every golden vector are byte-identical to v2.2.3, so AccuracyCoin holds 141/141 (100.00%) and nestest is 0-diff by construction.


The libretro core is complete, current, and builds for the buildbot

crates/rustynes-libretro is a thin wrapper over rustynes-core, so it inherits every recent change automatically — it needed no code change to carry the v2.2.3 work:

  • The fast PPU dot path is the core default now, so the libretro core gets the ~11% rendering-heavy win for free (it constructs Nes with the current defaults).
  • The PPU_SNAPSHOT_VERSION 8 / APU v4 save-state schema is transparent to the wrapper: get_serialize_size and on_serialize size and emit the current snapshot via Nes::snapshot_core_into / VsDualSystem::snapshot, not a hardcoded layout. RetroArch save states, run-ahead, and rollback netplay therefore carry the v8 sprite-evaluation FSM + OAM data-bus state with no wrapper change — and because libretro save states are session-local, the ADR-0028 epoch never enters the picture.
  • The Mapper::mix_audio i32 widening, the Zapper model, and the mNNN_ mapper rename are all below the crate's public dependency surface.

Both buildbot cross-ABIs the GitHub early-warning gate models build clean, verified with the exact CI command:

cargo check --release -p rustynes-libretro --target x86_64-pc-windows-gnu     Finished
cargo check --release -p rustynes-libretro --target aarch64-linux-android     Finished

(The full ten-job buildbot recipe went green in v2.2.2; the Apple ABIs are excluded from the Linux-runner gate because bindgen needs a real per-target Apple sysroot.)

rustynes_libretro.info metadata corrected

rustynes_libretro.info is the file RetroArch's core downloader reads to learn a core's capabilities. Three entries were stale or wrong:

  • disk_control falsetrue — the real fix. The FDS multi-side Disk Control interface (enable_disk_control_interface() plus the on_set_eject_state / on_get_image_index / on_get_num_images / on_replace_image_index callback trampolines) has been wired since the buildbot recipe landed — but the .info advertised it as absent, so RetroArch's Quick Menu → Disk Control never surfaced multi-disk FDS swapping. Now a Famicom Disk System game with more than one disk side is swappable from the RetroArch UI as intended.
  • display_version v1.0.0v2.2.4 — stale since the v1.0.0 era (the runtime library_version the core reports has always tracked CARGO_PKG_VERSION; this is the static metadata string RetroArch shows).
  • Description mapper count 168172, with a note that FDS multi-disk swapping runs through the Disk Control interface.

Documented follow-up: libretro core options

Libretro core options (region NTSC/PAL/Dendy, overscan crop, palette selection, the opt-in accuracy toggles) remain unexposed. core_options = "false" in the .info is accurate, not stale — the CoreOptions impl is deliberately empty. This is a genuine future enhancement, not a v2.2.4 gap: it is a new capability that deserves its own focused work and testing (each option wired to the core config API and verified against the determinism / save-state contract), rather than being rushed into a distribution cut.

Tooling: the Antigravity reviewer standardized onto the shared template

scripts/agy-review.sh and .github/workflows/antigravity-review.yml are now byte-identical to the canonical antigravity-pr-review template installed across RustyNES / RustySNES / RustyN64, so future reviewer improvements apply uniformly. It carries the large-diff-to-file handling, the 20,000-line gh pr diff API-limit local-git diff fallback (fetches PR objects but never checks them out), the isCrossRepository fork gate, fail-closed metadata, a default-branch checkout with persist-credentials: false, and the synchronize auto-re-review trigger.


Upgrade notes

  • Nothing breaks. There are no core, save-state, movie, or netplay changes. .rns save states and .rnm movies from v2.2.3 load and play identically.
  • RetroArch users: once the buildbot mirrors this tag, the RustyNES core appears in Online Updater → Core Downloader; FDS multi-disk games gain working Disk Control.
  • No API changes; Mapper::mix_audio stays i32 (unchanged from v2.2.3).

Verification

cargo check --release -p rustynes-libretro                          clean
cargo check --release -p rustynes-libretro --target x86_64-pc-windows-gnu    clean
cargo check --release -p rustynes-libretro --target aarch64-linux-android    clean
cargo test --workspace --features test-roms                         AccuracyCoin 141/141, nestest 0-diff
cargo fmt --all --check · clippy --workspace --all-targets -D warnings · retroachievements combo   clean
no_std build (thumbv7em-none-eabihf) · markdownlint · actionlint    clean

Mobile versions stay frozen at their v2.0.x host-only release points; the joint store launch remains v2.3.0.