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.
Abdessamad Derraz