• src/doors/syncretro/retro

    From Rob Swindell (on Windows@VERT to Git commit to main/sbbs/m on Tue Jul 21 01:41:00 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/5acdd27b543affbd6863576f
    Modified Files:
    src/doors/syncretro/retro_env.c
    Log Message:
    syncretro: don't forward the core's DEBUG log to the door log

    env_log() ignored the retro_log_level it was handed ((void)level) and
    forwarded every message the core produced. FreeIntv and FCEUmm say almost nothing at debug level, so this cost nothing and looked harmless.

    MAME 2003-Plus logs a line every time the emulated game pokes an unmapped address -- and Pac-Man hammers its watchdog register during play, so one session produced ~1900 copies of a single message (85% of the log). Each
    became a vfprintf to the door's stderr, which the BBS redirects to data/syncretro/syncretro_n<node>.log -- a file that on a multi-host install lives on an SMB share. A synchronous network write several times a frame
    blows the frame budget: the game visibly ran slow and the audio FIFO
    starved, stalling the sound about twice a second.

    The core's own speed was never the problem -- measured at ~1100 fps, 18x real-time. The frame budget was going into logging.

    Drop RETRO_LOG_DEBUG; keep INFO and above, which are bounded (paths, the matched driver) and are what makes a failed load diagnosable. Set SYNCRETRO_CORE_DEBUG=1 to get the firehose back when diagnosing a core.

    Introduced in 5d08adc15a (cycle-3-decreased), which wrote the callback.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows@VERT to Git commit to main/sbbs/m on Tue Jul 21 01:41:00 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/75b6cedd181ccf74603e7c05
    Modified Files:
    src/doors/syncretro/retro_core.c
    Log Message:
    syncretro: name the content, not the core, when a ROM is refused

    rc_core_load_game() logged a rejected ROM with a bare fprintf and returned
    -1 without setting rc_err, so main.c's sr_fatal(rc_core_error()) fell back
    to the default string and told the PLAYER "the libretro core could not be loaded" -- blaming the core for what is virtually always the content.

    That is exactly the contract retro_core.c's own header sets out: every
    fatal reason has to be recoverable as a string, because a door's stderr
    reaches nobody. It mattered little while a console either had its cartridge
    or did not; it matters a lot for an arcade core, where a romset built for a different MAME version is the commonest failure and looks nothing like a
    broken core.

    Introduced in 5d08adc15a (cycle-3-decreased).
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows@VERT to Git commit to main/sbbs/m on Tue Jul 21 01:41:00 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/305d224115e459dcea6fa0a7
    Added Files:
    src/doors/syncretro/retro_options.c retro_options.h
    Modified Files:
    src/doors/syncretro/CMakeLists.txt main.c retro_env.c syncretro.h syncretro_config.c syncretro_door.c
    Log Message:
    syncretro: answer the core's option queries, and pin them in syncretro.ini

    The door answered false to every GET_VARIABLE, on the documented assumption that a core then falls back to its own defaults. That assumption is not reliable. Measured with probe_core against MAME 2003-Plus: answering false leaves av_info.sample_rate at 0.0 and the core emits ZERO audio samples --
    a silent door -- while answering each query with the value the core itself advertised yields 48000 Hz and exactly 792.0 audio frames per video frame.
    It reads all 23 options it advertises. "Answer nothing" and "answer the default" are not the same thing.

    New retro_options.c/.h keeps what a core advertises (SET_VARIABLES, and defensively SET_CORE_OPTIONS[_V2][_INTL]) and hands it back on GET_VARIABLE, overridden by whatever the console pinned. GET_VARIABLE_UPDATE now gets a definite "no" rather than an unanswered call -- MAME 2003-Plus polls it
    every frame.

    Pins come from syncretro.ini's [options], NOT the command line, and that is forced rather than chosen: the BBS assembles a door's command line into xtrn.cpp's fullcmdline[MAX_PATH + 1] and truncates it there silently at 260 characters. The lobby's line for one arcade game already runs to ~240, so
    two pinned options took it to 334 and the ROM argument -- the last thing on
    the line -- was cut off, giving a door that reported "(no ROM)" for content whose full path the BBS had just logged (it logs the untruncated string and passes the truncated one). A -option flag remains for a door run by hand.

    Note the ini section is read with iniGetNamedStringList(), not
    iniGetSection(): the latter returns the section's raw lines, comments and
    all, untrimmed around the '='.

    sr_options_report() logs "N advertised, N pinned, N read" and WARNS about a pinned key the core does not advertise -- a typo is otherwise perfectly
    silent, leaving the core on a default nobody chose.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net