https://gitlab.synchro.net/main/sbbs/-/commit/486ce37018886b960029d771
Added Files:
src/doors/syncretro/LAUNCHER.md
Modified Files:
src/doors/syncretro/DESIGN.md M4_AUDIO.md README.md
Log Message:
syncretro: record the launcher design and the Windows seams

The launcher replaces one xtrn.ini entry per cartridge with a JS
lobby that discovers ROMs and keeps a play-activity board. Write down
what it does and, more usefully, what it deliberately does not: no
in-game scores, because no libretro core reports one and reading them
means a per-ROM RAM-address table that generalizes to nothing; and no multiplayer, because game_lobby.js's registry and muster exist for a
network play this console does not have.

Also record the Windows seams while they are fresh. The door is POSIX
only by decision, and the work is bounded: a dlopen shim xpdev already provides, the socket I/O in two files, the frame pacer's absolute
deadlines, and a vcpkg libsndfile for the audio encoder. Neither the
keypad work nor the audio work made any of it harder.

Corrects three claims the audio spec made that the code does not: the
unit test is test_chunk.c, Ctrl-R now really does flush the channel,
and a terminal that never confirmed libsndfile now really does hear
nothing -- the exit flush is skipped for it. The exit flush carries no
fade, and the spec now says why.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e7eac973b40bc35007814c69
Modified Files:
src/doors/syncretro/LAUNCHER.md
Log Message:
syncretro: correct the launcher spec's stale claims

Section 10 pointed at a SyncDuke lib test that does not exist, in the
checkout or the install. The only stock JS test convention is a directory-walking runner for the core API, which a door's lib cannot
use; say instead what the launcher actually does: one self-contained
script, ok/FAIL lines, non-zero exit -- the shape the door's C tests
use. Also record that lobby.js itself is now driven headless by test_lobby_headless.js, and say precisely what that test covers and
does not: the launch command line, the play log, and search -- not a
single rendered character of the screen, so "the screen cannot be
tested" overstated it.

Section 7's mock screen and section 3's reuse list both still named live_nodes(), which nothing calls: it needs a Terminal Server context
no test can reach, and it is decoration on a screen whose job is
picking a game. Drop it from both places and record it in section 11
(Deferred) with that reasoning.

This also folds in section 6 edits that were already sitting in the
working tree, unrelated to this task, keeping the discovery-rule prose
in sync with two already-merged code changes: full-file-hash dedupe
replacing a 4 KB prefix, and dump-quality-variant collapsing.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1dedf345333f639e21abbdc9
Modified Files:
src/doors/syncretro/LAUNCHER.md
Log Message:
syncretro: bring the launcher spec's status and counts up to date

The spec still called itself unimplemented and pointed its test table
at a SyncDuke file that does not exist. Say what shipped, and name the
headless test that drives lobby.js by stubbing console, bbs and user
-- the screen is not verified, but the file is executed, and every
call it makes into the model layer is checked.

Numbers are the measured ones: 222 candidate cartridges, 12 collapsed
as dump-quality variants, 210 offered, seven pages at eighty columns.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/9a2e13855f0495f55bb2ea0f
Modified Files:
src/doors/syncretro/LAUNCHER.md README.md syncretro_io.c xtrn/syncarcade/README.md install-xtrn.ini syncretro.example.ini xtrn/syncivision/install-xtrn.ini xtrn/syncnes/install-xtrn.ini
Log Message:
syncretro: document where a *nix door's diagnostics actually go

The arcade README told a sysop to read data/syncretro/syncretro_n<node>.log
for the reason a romset was refused. That file only exists on Windows, or
for a -stdio door: those are the two cases where the door redirects its own stderr, because a console-less Windows launch has nowhere for it to go and
a stdio door's stderr is painted over the player's screen. A *nix socket
door -- what the lobby spawns by default -- leaves stderr inherited, and xtrn.cpp's wait loop drains it a line at a time into the server log. So on Linux there is no door log to find. The sysop-facing docs now say so, and
name the "[MAME 2003+]" / "Opening ROM file:" lines that identify which
file the core wanted.

Also corrects the opposite error in the dirty_log comment, which claimed a native door's stderr is eaten outright under EX_BIN. That applies only to
the EX_STDOUT (stdio) path; a socket door's stderr is relayed and does
reach the server log. dirty_log keeps its own file regardless -- a
per-frame trace has no business flooding the server log at a syscall per
line inside the frame loop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net