Recalbox 10.1.1 builds the wxWidgets-era libretro PCSX2 for x86_64 at
408e3b2 with 0003-bios-path.patch, which moves the BIOS scan from
pcsx2/bios to ps2, and lists it as the libretro core pcsx2 of the ps2
system. Since lrps2-9485a53 took the ps2 name no profile described it.
pcsx2-libretro-408e3b2 is built_by recalbox under the name pcsx2, beside
standalone PCSX2 and LRPS2. It reads <bios>.rom1, rom2, erom, nvm and
mec beside the selected image. GameIndex.yaml and the patch archives are
compiled in.
DEV9init opens eeprom.dat from the working directory and maps 64 bytes over the compiled-in image (pcsx2/DEV9/DEV9.cpp:159-176). The profile did not list it.
Batocera 43.1 builds libretro/ps2 at 416291a with 001.bios-dir.patch and
Recalbox 10.1.1 builds it at 9485a53 with 0001-recalbox-paths.patch. Both
patches move the BIOS scan from pcsx2/bios to ps2, and Recalbox also moves
the data root to system/ps2. Each build gets its own built_by profile:
lrps2-416291a under Batocera's pcsx2 name, lrps2-9485a53 under Recalbox's
ps2 name.
A platform's own build now answers for its own build mode only on a
dual_mode_cores name, so Batocera keeps standalone PCSX2 beside its
libretro build.
KNULLI builds amiberry from Batocera's package through its batocera
submodule: the reference now names knulli-linux at 20260511, the tag
platforms/knulli.yml is read at, and the package file below the
submodule. check_freshness follows a path .gitmodules declares to the
commit the tree pins, which reads AMIBERRY_VERSION = v7.1.0 there.
RetroBat pins amiberry 8.3.0.0 only in emulators/versions.xml on its
download server, read by emulatorLauncher/Installer.cs. No repository
holds it, so amiberry-8.3.0 keeps pin_frozen, which says so, and no
pin_build.
Batocera builds facaaeb, 332 commits after v7.1.1, and EmuELEC
builds 452783a, 44 commits after it. Both read 8.0.0 from
CMakeLists.txt and both displayed as 'Amiberry 8.0.0', three site
pages under one title. Each name now carries its commit and the
platform that builds it.
Upstream added 19 build profiles to src/pin.json, 252 from 3020 to
8023 on the same nine engines, and moved the core version to 0.1.85.
The two changed citations, pin.json:1-20 and obor_engines.h:6-7, still
name the version lines, read at b3557f6, which prose_written_at
records. The diff renames the core options to anybor_* and adds no
file read: the system directory still gives only AnyBOR.ini to the
packed and ZIP preparation. Five citations in libretro.cpp shift by
five lines.
main/Pak6.pk3 now goes to the demo disc's empty placeholder, listed
with the demo entries, so the pack carries Pak0 to Pak7 as the
Allied Assault single-player demo 0.05 installs them. The 1.11 patch
Pak6.pk3 stays a named and collected retail entry, not chosen: the
retail Pak0 to Pak5 are not held, and no release shipped the demo
with it.
The seven pk3 files under main/.variants/ are the Medal of Honor:
Allied Assault single-player demo 0.05, extracted from the December
2001 demo disc (archive.org ea-mohaa-sp-demo, EA_MOHAA_SP_Demo.iso,
sha1 4cba6697): Pak0 to Pak5, and Pak6 and Pak7, two identical empty
placeholders. OpenMoHAA reads the demo from main/ like the full game
(common.c:3168-3182) and mounts every .pk3 there (files.cpp:3136).
Each demo pak is now an entry with its hashes, listed before the
retail entry of its slot, so Pak0 to Pak5 resolve. The 1.11 patch
Pak6.pk3 keeps its slot. The retail entries keep unsourceable, now
naming the retail release as what the collection lacks.
xemu loads wpcap.dll with a plain LoadLibrary (winpcap-loader/loader.c),
and it works only with the Npcap driver, whose installer puts it on the
DLL search path. The schema has no marker for a file a separate system
install provides, so the entry is unsourceable with that reason. The
copy at the BIOS root of RetroBat, RetroDECK and eight other platform
lists, which no search order reaches, leaves them.
Each Cxbx build reads its data from the folder its settings.ini sits
in, which RetroBat writes beside the binary: the three profiles name
Settings::GetDataLocation, so keys.bin, EmuDisk and EmuMediaBoard go to
emulators/<folder> on RetroBat instead of the BIOS root. RetroBat writes
cxbx-reloaded's EEPROM.bin and xemu's eeprom.bin and xbox_hdd.qcow2
itself (installed_on), and mounts an .iso with its own tool, so Cxbx's
dokan2.dll is never loaded there (unread_on).
The xemu generator writes eeprom.bin and xbox_hdd.qcow2 into
saves/<system> from its own resources and passes both in xemu.toml,
copies chihiro_eeprom.bin between saves/chihiro and the emulator folder,
and points the Chihiro snapshot store at saves/chihiro. The Cxbx
generator runs each build from its emulator folder (chihiro, chihiro-ds,
cxbx-reloaded, else cxbx-r), where it writes settings.ini, writes
EEPROM.bin into cxbx-reloaded for an Xbox, and mounts an .iso with its
own xbox-iso-vfs.exe after checking the Dokan 2 runtime. Nine records,
read at emulatorLauncher ca486005.
A program the launcher runs from its own folder is no launcher read
left to collect. xemu-chihiro lists the two files it generates,
chihiro_eeprom.bin and chihiro_snapshots.qcow2, as unsourceable.
The EmuELEC paragraph cited version.txt:1, a line that moved from
1.0.11 to 1.1.18 under the same text. version_basis already says where
the version is read, and profile_sync now reads the profile clean.
At 6c51acf the engine also looks in the user config and data folders,
reads resurrection.h2d only in H2D format 3 holding the 68 files it
carries (h2d.cpp:107-145, h2d_file.cpp:39-88), and plays MIDI music with
the sound fonts of files/soundfonts and files/timidity/timidity.cfg. The
pinned 1.0.11 container, format 0 with 7 files, stops the start: the
entry now names the engine's own file. The sound font, the timidity
configuration and instruments and the translations join the profile,
all shipped with the engine. Refs re-read at the new pin, version
read from version.txt.
2048 and gong (game), radio and video_processor (utility) and the test
cores (test) are libretro builds, but their role sat in type:, which
resolve_platform_cores filters on: all_libretro left them out, so no
platform resolved them and RetroArch's manifest named none, the
--installed-cores gap of issue 87. The role moves to role:, and type
stays libretro: type keeps saying how a profile is built and run, which
the resolver reads, while teaching the resolver that three role values
mean libretro would make type a classification again. The site and
coverage leave test cores out by role. fluidsynth, a library and no
libretro core, keeps type utility. A test keeps every buildbot core
named by RetroArch's resolution.
Their pin_frozen said EmuELEC alone ships them, but they are port
engines of emuelec-ports, which no package, options file or Makefile of
a v4.8 image pulls in: no platform ships either. pin_frozen and
pin_build go, the notes say which revision EmuELEC's tree builds, and
the normal pin rules apply.
The buildbot's openmsx and linuxloader cores come from libretro's own
ports on git.libretro.com, not from the standalone projects: openMSX
21.0 reading <system>/openmsx/share, and Linux Loader v3.0.14 run as a
child process from <system>/linuxloader, which the core carries. Each
gets its own libretro profile, read at its commit: openmsx-libretro
lists the 105 system ROM contents of the twelve real machines and the
extensions its options offer, linuxloader-libretro the runtime the
core carries, the game-folder files and the libgcc DLL the buildbot's
Windows build lacks. No buildbot core name is left without a libretro
profile.
The 8.5.0 source builds a standalone Amiberry and the libretro core, so
the profile is standalone + libretro again. A standalone name a build the
platform compiles itself answers to keeps meaning that build: RetroBat's
standalone amiberry is 8.3.0, and 8.5.0 runs there as the core only.
A platform that builds Amiberry itself runs that revision under the name,
on every board it builds: RetroPie 5.7.2 and 6.3.3, Recalbox 8.2.2,
Batocera 7.1.1-332, KNULLI 7.1.1. The 8.5.0 profile is the buildbot
libretro core. It now names the ROM table's own file names and hashes
the keyboard MCU images.
EmuELEC 4.8 builds amiberry 452783a (CMakeLists.txt declares 8.0.0).
Same paths as 7.1.1, a ROM database with the PPC flash images, which
the scan hashes with their config bytes cleared, so no file hash is
declared for them. Tests check that ROCKNIX, AmberELEC and EmuELEC
resolve their own build, the other platforms the 8.5.0 profile, and
that ROCKNIX places its kickstarts at the BIOS root.
AmberELEC builds amiberry c53d6db (CMakeLists.txt declares 7.1.1). Its
ROM path is rom_path, else roms/ below the home directory
(AMIBERRY_HOME_DIR, ~/Amiberry, or the working directory in portable
mode), scanned at its root by the ROM database. The WHDLoad booter
reads whdboot/ below $XDG_DATA_HOME/amiberry. EmuELEC's 452783a adds
13 PPC board ROMs to the database and hashes flash images otherwise,
so it gets its own profile. AmberELEC reaches its Kickstarts through
the .uae kickstart_rom_file paths, the fixed_name records.
ROCKNIX builds amiberry 5c54536 (target.h declares 5.6.5). Every file
it reads lies below its start path, the working directory: the ROM
database dumps, aros-ext.bin, aros-rom.bin and rom.key in kickstarts/,
the WHDLoad booter files in whdboot/. Profiled from that revision,
pin_frozen with pin_build on ROCKNIX's package.mk.
The ROCKNIX scraper records the folder its start script enters and the
kickstarts link it carries there by copying /usr/config/amiberry, so
<cwd>/kickstarts binds to the BIOS root. A standalone + libretro profile
under a name the platform's own build answers to no longer resolves
there: ROCKNIX's amiberry is 5.6.5, not 8.5.0.
45 fonts from a PS4 firmware 11.00 dump (archive.org item
sony-ps4-system-font), checked against the item's md5 and sha1 and,
for 44 of them, byte for byte against the separate ps4font upload.
Each sits in the folder the console keeps it in: shadPS4 mounts
fonts/font and fonts/font2 as two guest folders (emulator.cpp:640-661),
so the ten font2 fonts move there and the seven font2 files the mount
also serves get entries.
The configs root place joins roms and emulator folders in the split
handed directories, and RetroBat's portable folder table keeps both
sides. Batocera, KNULLI and RetroBat records regenerated.
Sudachi.Generator.cs:28-30 creates user/ beside sudachi.exe, and
sudachi reads it as PORTABLE_DIR (path_util.cpp:92, fs_paths.h:9) in
place of %APPDATA%. Its keys now go below emulators/sudachi/user/.
Both binding sides kept: roms_place, named handles and environment
variable directories from integ run through the pool and per-system
binding of this branch. Batocera, KNULLI and RetroBat launcher records
regenerated from the merged extractors.
RetroBat's generators create user/ beside yuzu.exe and eden.exe and
portable/ beside Ryujinx.exe, which the emulators read in place of
%APPDATA% (PORTABLE_DIR, Ryujinx AppDataManager.cs:12, 60). Their keys
now go below emulators/<key>/.
The font library opens each SST font by its dumped or PS4 name in
fonts/, fonts/font/ and fonts/font2/ and falls back to the Noto fonts it
embeds, so the 38 entries are optional with an HLE fallback.
The standalone Amiberry scans rom_path, ROMs below its content root by
default, for the ROMs of its database, without descending into
folders, and reads rom.key beside the Kickstart and the MT-32 ROMs
from mt32-roms. Those entries now carry standalone_path relative to
it, the four Kickstart labels holding slashes flattened. The kick*.rom
names stay the libretro build's.
Batocera's config_directories reads its rom_path save, KNULLI reuses
it. On Batocera, KNULLI and RetroPie the ROMs move from the BIOS root
to bios/amiga.
XRoar reads a ROM by name from the directories of rompath. The entries
take their file name as path, relative to ~/.xroar/roms or
${prefix}/share/xroar/roms, and rompath and -rompath are declared as
search lists.
Batocera records its rompath line, Recalbox -rompath bios/<system>
(the placeholder its extractor already writes), RetroBat its -rompath
as two records, bios/dragon and bios/coco for coco. An entry whose
name the platform list does not declare follows the launch its
profile system is listed under: Recalbox lists mc10.rom under
trs80coco, so alice.rom is read there.
Batocera ROMs move from the BIOS root to bios/xroar, Recalbox ROMs to
bios/dragon and bios/trs80coco, RetroBat ROMs to bios/dragon and
bios/coco. RetroDECK and RetroPie keep them at the BIOS root.
openMSX reads share/systemroms below OPENMSX_HOME or ~/.openMSX and
every filepool entry by SHA1. The profile paths drop RetroBat's
openmsx/ prefix and declare those directories and the filepool.
Batocera's config_directories reads the filepool lines its generator
writes, KNULLI reuses it. RetroBat records OPENMSX_HOME, RetroPie the
moveConfigDir of ~/.openMSX that its systemroms link lies in, and the
configure --prefix of xroar that its roms link lies in.
Batocera and KNULLI system ROMs move from openmsx/share/systemroms to
openmsx/, beside the files their own lists declare, RetroPie's to
BIOS/openmsx, the folder linked as share/systemroms.
sys_modules/ is below shadPS4's user folder: user/ in the working
directory, else the XDG data folder (path_util.cpp:88-124). Batocera
and KNULLI start it from /userdata/system/configs/shadps4, so their
packs no longer carry bios/shadps4/sys_modules, which nothing read, and
name the modules instead. EmuDeck keeps its link at
bios/shadps4/sys_modules, and RetroBat places them in
emulators/shadps4/user/sys_modules.
Both profiles placed their keys in switch/, Batocera's folder. The code
reads them from KeysDir, <data>/keys, so the paths are keys/<name> and the
profiles declare the data folders, the portable user folder and the
KeysDir handle. Batocera and KNULLI keep citron's keys in bios/switch,
EmuDeck places each emulator's in its linked bios/<emulator>/keys,
RetroBat in emulators/citron/user/keys, and KNULLI's suyu, which keeps
its data in /userdata/saves/switch, names them as read outside the BIOS
folder.
lexaloffle documented two programs, so every platform naming PICO-8
received Voxatron's files: ROCKNIX, RetroDECK and RetroBat run PICO-8
only. Voxatron is its own profile, named vox_official. A platform also
runs the emulators its standalone_cores list names: Batocera and KNULLI
list lexaloffle there and nowhere else.
Read while walking the profile checklist on the profiles the
variant_group conversion touched.
- pizza-boy-sc: the core holds one Mega CD slot and one Master System
slot, filled through the document picker under any name, and tests
only the Mega CD length (libsc.so frontend/android/src/lib.rs:475,
569-648, megacd_main_machine.rs:169-178). Nothing picks by
territory, so the three images of each are a group, not a selection
slot: megacd-boot-rom required, mastersystem-boot-rom optional.
- fpse, fpse-ng: the BIOS note pointed at "the other images of the
group", a set the profile does not list. It now says any 524288-byte
PlayStation image fills the slot.
Abdessamad Derraz