Skip to content

fix: correct supafaust PPU thread affinity for tg5050#784

Closed
carroarmato0 wants to merge 1 commit into
LoveRetro:mainfrom
carroarmato0:fix/tg5050-supa-ppu-affinity
Closed

fix: correct supafaust PPU thread affinity for tg5050#784
carroarmato0 wants to merge 1 commit into
LoveRetro:mainfrom
carroarmato0:fix/tg5050-supa-ppu-affinity

Conversation

@carroarmato0

@carroarmato0 carroarmato0 commented Jul 18, 2026

Copy link
Copy Markdown
Collaborator

SNES games crash immediately on launch on the Smart Pro S (tg5050). The emulator exits with terminate called after throwing an instance of 'Mednafen::MDFN_Error' before the game loop starts.

On tg5050 (sun55iw3 / Allwinner T527), only CPUs 0, 1, and 4 are online at game launch time:

/sys/devices/system/cpu/online: 0-1,4

The SUPA pak default.cfg was copied from the tg5040 config when tg5050 support was added (89158fe), using the same affinity values tuned for tg5040's quad-core layout:

-supafaust_thread_affinity_emu = 0x3   # CPUs 0+1 — online on both platforms
-supafaust_thread_affinity_ppu = 0xc   # CPUs 2+3 — online on tg5040 , OFFLINE on tg5050

supafaust's Thread_SetAffinity calls pthread_setaffinity_np with the requested mask. When any CPU in the mask is offline, EINVAL is returned and the core throws Mednafen::MDFN_Error from inside retro_load_game, which propagates up and crashes the emulator before the game starts.

Changed the tg5050 PPU thread affinity to 0x10 (CPU 4), which is reliably online on tg5050:

-supafaust_thread_affinity_ppu = 0x10  # CPU 4 — online on tg5050

This preserves the same principle as tg5040 (emulation and PPU threads on separate CPUs) while using the correct CPU for the tg5050 topology.

Tested on physical Smart Pro S hardware. SNES games that previously crashed immediately now launch and run correctly.

On tg5050 (Smart Pro S), only CPUs 0, 1, and 4 are online at game
launch time. The SUPA pak default.cfg was copied from the tg5040
config which sets supafaust_thread_affinity_ppu to 0xc (CPUs 2+3),
but those CPUs are offline on tg5050.

supafaust's Thread_SetAffinity calls pthread_setaffinity_np with the
requested mask. When any CPU in the mask is offline, the call fails
and the core throws Mednafen::MDFN_Error during retro_load_game,
crashing the emulator before the game can start.

Fix by setting the PPU thread affinity to 0x10 (CPU 4), which is
online on tg5050. The emulation thread stays on 0x3 (CPUs 0+1),
preserving the same emu/PPU separation as on tg5040.

The bug was introduced in 89158fe when tg5050 support was added and
the tg5040 affinity values were used verbatim without accounting for
the different CPU topology.
@carroarmato0
carroarmato0 deleted the fix/tg5050-supa-ppu-affinity branch July 18, 2026 01:12

@carroarmato0 carroarmato0 left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized this might require some more thinking through as the governor might dynamically disable the CPU we just added, not solving the core problem. Created an issue instead to discuss

carroarmato0 added a commit to carroarmato0/NextUI that referenced this pull request Jul 26, 2026
Two related fixes:

1. skeleton/EXTRAS/Emus/tg5050/SUPA.pak/default.cfg: change
   supafaust_thread_affinity_ppu from 0xc (CPUs 2+3, offline on tg5050)
   to 0x10 (CPU 4, online). Mirrors the upstream fix in PR LoveRetro#784.

2. workspace/all/minarch/ma_core.cpp: wrap retro_load_game in try/catch
   in Core_load(). A core that throws during load now logs the exception
   and exits cleanly instead of hitting std::terminate with no context.
   (C++ only; upstream's ma_core.c has no equivalent guard available.)
carroarmato0 added a commit to carroarmato0/NextUI that referenced this pull request Jul 26, 2026
The C++20 migration PR must not change behavior. Commit 8f873ec had slipped
in a tg5050-specific crash workaround (supafaust_thread_affinity_ppu 0xc->0x10,
the LoveRetro#785/LoveRetro#784 fix) that belongs in its own change, not this migration. Restore
it to upstream's 0xc so the PR stays behavior-neutral.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant