Every launcher exports RETROBIOS_PAD: gptokeyb, muxterm, evmapy or
miyoo, so the interface can name the buttons that reach it. The wiki
lists the values, and the tests check each launcher's.
Apps such as AetherSX2 named their user data folder only in prose, so
the site could neither print it nor show only the OS tabs that apply.
data_root keys android, ios, windows, macos and linux, each with the
path the user finds and the source_ref that builds it.
The speed is bytes_network over time, the interface's own guess at local
bytes is gone. The plan says when a --from folder was read only in part
or holds another drive, and how many files on the old card could not be
read, with a list of each reason. The --from folders are only checked
before the screen opens, never indexed there.
00_example is the libretro-core-info .info template, not a core the
buildbot publishes. As type libretro, all_libretro resolved it for
RetroArch, Lakka, EmuDeck, RetroDECK and ROCKNIX. type test keeps it out,
as the site already did for that type.
Release packs now exist for six platforms only, and install.py refuses a
pack named for another. build_port.py writes packs.txt from the
registry's release_pack groups. Offline, the launcher takes only a pack
spelling the detected system, names that pack, or says no release pack
serves it and gives Wi-Fi or the computer route.
The one-liner opens the full screen, and the page walked through the
line questions. It now shows the first screen, the keys and the
controller, Install, the copy from an old card and the result titles.
Troubleshooting no longer asks to move a nested bios folder by hand.
- A handheld card mounted on a computer is found by the files its
firmware writes there: muOS, Onion, spruceOS, CrossMix, Allium and
Koriki from their device rules read below the card root, KNULLI and
ROCKNIX from the share their first boot seeds. It is a setup of its
own ("muOS SD card (E:\)") with the folder that system reads, and
--dest <card root> writes there too. --platform muos with a folder
that is no muOS card is refused with the folder to name.
- Space (X on PortMaster, Y on muxterm) opens the confirm screen from
Install and never installs, closes or quits by itself.
- Short of space, Choose another folder comes first, and the result
says the card is full in words, with no log lines and no command
naming the interface's own copy of the list.
- The plan keeps the BIOS folder second, cut in its middle, a --from
folder by its name, and the config that named the folder.
- The result says how many files came from the old card, how many
were downloaded and how many are still missing, as the line mode.
- The "other" row is named and explained, files shared by several
systems are counted apart, and a file that cannot be supplied is
named with its system, only where it matters.
- A work folder left by SIGKILL is removed by the next run, a failed
run's log after a week. A full card keeps no log.
- Smaller: the sudo advice names the folder, removing a --from folder
says so, the preview counts its files only, a proxy is named, a list
that is no JSON and the clock error read as plain sentences.
The engine counts the bytes a copy, the pack or a resumed partial copy
supplied, and those the network brought. A transfer event carries both
after each progress event and once when the downloads end, so a screen
shows a download speed without guessing.
The archives ship with the next release, and build_port.py writes them
until then. muOS points to the muxapp and to /mnt/mmc, and the quit combo
reads Select first.
Start + Select now kills a sentinel the launcher owns, and the launcher
asks the interface to stop, so a running install still writes its result.
A mapper that dies, a chvt the compositor refuses, a terminal app that
cannot open and a read-only card each end the run or hand over to the
next route instead of a console waiting for a button. muOS starts
gptokeyb2 with -X and keeps muxterm off the pad so Y opens the options.
The walk no longer enters another drive mounted below the folder (it is
named instead), /proc, /sys, /dev or a Windows junction, and the root of
the system is refused. from_folder_problem() checks a folder without
reading it. A scanned event reports each folder read, cut short or not.
A file, ZIP member or folder below a --from folder that could not be
read was taken as no match. When its size is that of a file the run
still needs, or unknown, --check, --dry-run and an install now name it
with the reason, and an unreadable event carries it.
A copy that could not be read when it was copied was reported as a
folder not writable. The source is now opened first and its errors are
its own, and a download failing after it names both reasons. A run
reading a pack falls back to the pack, never to the network.
A missing file walked every archive of the BIOS folder and every file of
its size: 3,000 ZIPs and 3,000 missing files took 186 s, now under 1 s.
--from copies and the owner of a refused file use the same lookups.
The Compatibility folder of an Xbox 360 drive is what xenia-edge mounts
as Xenia-Edge/xefu/ (libretro) and xefu/ (standalone): the collection
files it under that tail so the directory entry resolves.
Compatibility folder of an Xbox 360 hard drive and the April 2018
backward compatibility title update (FFFE07D2, v2.0.5832.0).
xbox.xex and xefu.xex (v2.0.1884.0) and dash/fonts/xbox.xtf are equal in
archive.org items backwards-compatibility-files and
xbox-360-backwards-compatibility-partition-backup. Xbox Book.xtf is equal
in backwards-compatibility-files and a second upload of the folder.
The xefu1_1 to xefu7b builds and xefutitle5 to xefutitle7b come from the
title update package tu20075c00_00000000 (backwards-compatibility-files).
Every block of the package matches its hash tables up to the header top
hash, and every XEX verifies against the retail PIRS public key. The
package's xbox.xexp and xefu.xexp name the base files above by the SHA-1
of their signatures.
mariani, nuance and pcsx2x6 move upstream_commit to their fork base,
dolphin-mmjr2, hatari and jl-mod to upstream HEAD now that their prose
reads in the right tree, boom3 and bsnes-jg record the upstream they are
read against, and groovymame's source pin follows its fork.
aps3e, emucorex, ax360e, snes9x-explus vendor an upstream tree at that
commit, nes-emu and higan_sfc_balanced synced to it, yaps2, flycast-dojo
and supermodel-dojo carry upstream up to it, and AmberELEC builds
mupen64plus's core there. Each reason is in the profile's notes.
upstream_frozen says why upstream_commit stays: the port vendors that
upstream tree, synced to that release, or merged that commit. The view
is then read at its own pin, the way pin_frozen holds source_commit, and
a bump leaves it. Outside a GitHub fork network nothing else could tell
aps3e's vendored RPCS3 1f080485 from an upstream read on a date.
The pins moved past a newer release: dice v0.4.3, geargrafx 1.8.4,
gearlynx 1.2.35, izapple2 v2.5.0, lightspark 0.10.0 (its CMake version
at the pin). The drhelius cores take their version from git describe,
dice and izapple2 carry none, so the release tag is the version.
--check-version said pcsx2x6's v0.2.22 was older than its code because
the pin holds release v0.2.20, the latest the project published. A
release that is an ancestor of the declared tag is not a later one.
A folded run rewritten whole keeps its separators (boom3, mame), a
double-quoted source_ref is matched as the loader reads it and escaped on
write (etlegacy), two files sharing a name take their build mode in the
field path (supermodel Games.xml), and a project word ending the line
before a path marks the citation external (genesis_plus_gx_expanded).
The build workflow downloads it from SourMesen/librashader's nightly
release on every build, so no shipped copy has a fixed hash: the entry
joins the recorded unidentified bundled files.
FAQ entry, the release_pack field and how to revisit it from download
counts, the get/ pages, and RetroPie 4.8 now installs from a computer with
the Pi's network folder as --dest. The start pages are back under their
word ceilings.
get/<platform>/ lists the files of the current release pack, read from
release.json, or gives the command for a setup without one. The README,
setup pages, Get your files and the release notes link it instead of
asset URLs, which die with each deleted tag. Setups without a ZIP say so
with the command beside it, and validate_site checks every get/ page.
release_pack: true in the registry is the list a release builds: RetroArch,
EmuDeck, RetroBat, Batocera, RomM and MiSTer, 83% of the downloads of
v2026.10.10. generate_pack --all, --verify-packs, the pipeline consistency
step, release_record and check_release read it. Manifests are still written
for every platform.
pak399.pk4 and pak399roe.pk4 as libretro/boom3 ships them at efe140c
(tools/vr_paks/compiled/, git blob 2f5c1ad6 and 18254709). VR builds
mount them over base/ and d3xp/.
The plan offers the folder browser, mounted cards first and ZIPs listed,
to add --from (Options adds a second one, Left takes it back), checks the
folder again and says how many files it holds and how many are left to
download. Misplaced files are counted with a Show list of their reasons,
and a local copy no longer counts in the download speed. The found event
test now holds that the interface reads it after a check and an install.
Without a network, muOS and ArkOS launchers ask to copy the BIOS files from the card the system does not read (muOS bind.sh, dArkOS roms2), then install with --from and the pack. CI checks that shellcheck is present, and the test fails under CI without it.
The interface accepted --from and its check and install runs never got it, so they downloaded what the folder holds. Pins in install.sh and install.ps1 follow install.py.
Expansion, accelerator, controller, freezer, bridgeboard and CDTV/CD32
ROMs that Amiberry and WinUAE identify by SHA-1 (rommgr.cpp). Each file
is named after its rommgr label and matches the listed SHA-1.
All 178 are in archive.org item doc_2025-08-26_04-38-36 ("Amiga
roms/bin"), compared by the item's per-file SHA-1.
Independent copies that reproduce the same bytes:
- MAME archives already in bios/Arcade (a590.zip, amiga_a590.zip,
amiga_a2091.zip, buddha.zip, amiga_ar1.zip, amiga_oktagon2008.zip,
amiga_a570.zip): 13 ROMs, 7 of them by byte-interleaving the
even/odd chip halves (A590/A2091 v4.4 to v7.0)
- TOSEC Commodore Amiga - Firmware (archive.org commodore-amiga-firmware):
Action Replay Mk I v1.0/v1.5, Action Replay 1200, Action Cartridge
Super IV Pro v4.3, CDTV A570 v2.30, Nordic Power v1.5/v2.0/v3.0,
X-Power Professional 500 v1.2/v1.3
- archive.org a2091-6_6, a2091PDMA-07, commodore-amiga-a-2286-bios-v-3.6
(even/odd halves merged), bios-a-2088 (A2088 BIOS 3.4, 3.6.1)
The files-to-source table outgrew one page and split in two. Both
parts opened on the same intro, which is the page description, and
validate_site refused the duplicate. Each part now opens on "Part n of
N.". The element-budget exception for the unsplit table is gone: the
parts hold 8,987 and 7,674 elements.
mame_hash_scraper --release rewrote the whole profile and dropped the
pin_frozen that mame0258 and mame0278 carry: libretro/mame HEAD is a
later release, so without it profile_sync compares their refs with code
the Recalbox build never had. A release profile now states it, from
built_by, and keeps the reason a reader wrote.
realign_prose stripped a path prefix, or read a path two repositories
share, in the repository whose pin moved, while the profile meant the
other. hatarib's hatari/src/tos.c became hatari/hatari's src/tos.c, and
freej2me_plus's fork citations were read in hex007/freej2me: 32 and 8
citations asked to be read again although their files were unchanged.
The path as written now decides first, and a shared path belongs to the
repository declared first, as in attribution.
test_a_frozen_build_files_its_content_with_the_build_that_follows paired
every pin_frozen profile with every live one of the same source. It now
skips platform builds (built_by), and requires the frozen systems to be
a subset: a later release can add a board (advancemame's coh1002v).
Abdessamad Derraz