[KurdtNervanna]

One feature, as asked in #11: Native games, programs built for the console that run without an emulator.

What it adds

A new system, Native games (roms/native). Each game is one launch script (.sh) next to its own folder. The menu runs the script with /bin/sh in the script's folder, in its own process group (host_launch_native() in host/launch.c). It hands over the display, sound and pads the same way it does for a libretro game.

The game's environment

• HOME=/data/rsos/native-home, because the root file system is read-only. XDG_CONFIG_HOME and XDG_DATA_HOME sit under it.
• SDL_VIDEODRIVER=kmsdrm and SDL_AUDIODRIVER=alsa.
• RSOS_GAME_DIR and RSOS_LANG.
• Its output goes to game.log.

What the menu does around it

• Select + Start held for one second quits the game: SIGTERM to its process group, then SIGKILL after HANG_KILL_MS.
• Sleep stops the group (SIGSTOP) and turns the backlight off.
• Power-off sends SIGTERM.
• The idle power-off waits while the game runs, since there is no save state to fall back on.
• An exit code other than 0 shows "The game ended with an error" with the code. A stop by Select+Start or the menu doesn't count as an error.

Build: SDL2 (KMS/DRM, GLES2, ALSA) is added to the two RetroStone2 configs.

Docs: docs/native-games.md covers the folder layout, the launch script and the environment.

Tests

• check-frontend steps 2a to 2c cover the launch and its environment, an error exit, and the menu stopping a running game (the whole process group goes).
• On this branch (rebased on main, 0.1.5): check-frontend, check-host, check-input, check-i18n and check-transfer pass. sysmap.c knows the new folder too (alias nativegames, deliberately not ports: RetroPie's port scripts start RetroPie's own emulators).
• po/rsos.pot is regenerated (make pot).

On hardware

Tested on a RetroStone2 Pro with a fork build based on 0.1.4.

• Two SDL2 games launch, run and come back to the menu: a Super Mario 64 port and a Star Fox 64 port (libultraship on GLES2). Neither game nor any game data is part of this PR; users build them on a PC from their own ROM.
• An error exit showed its code (127 for a missing library, 135 for a crash). A power-off during a game shut the console down normally. Sleep wasn't tried on hardware.
• Open question: on that unit, holding Select + Start for a second did not end the game. frontend.log doesn't show the "Select+Start held" line, so the menu never saw both buttons together. I couldn't find the cause in the code. The same log has a button the kernel reported held for 30 s, so it may be the lost-release problem that 0.1.5 fixes (issue with keys acting as if they are constantly being pressed #10). That still needs to be checked on 0.1.5. For now the two ports quit by themselves on Select+Start.

Next

rsos-gamepad (it merges the RetroStone2's three input devices into one virtual SDL gamepad, via uinput) will be a separate PR once this one is in.

🤖 Generated with Claude Code

[KurdtNervanna]

An update on the open question in the description (holding Select + Start didn't end a native game).

On the same RetroStone2 Pro, now on 0.1.5 (a fork build of 0.1.5 with this PR), holding Select + Start for a second did end a native game. It was a game that has no Select + Start quit of its own, so the menu's check was the only one that could have closed it. frontend.log:

[     3.328] host I: native game 304 started: /data/roms/native/Ocarina of Time.sh
[   66.471] frontend: Select+Start held: asking the native game to quit

On 0.1.4 that line never appeared, and the same logs had buttons the kernel reported held for 30 s. So the earlier failure was most likely the lost button releases that 0.1.5 fixes (#10), not this PR's code.

[PaddleStroke]

@KurdtNervanna hello! Thanks for the PR. I'm not sure to understand the point of this, I think it is actually redundant with something I made already. Have you seen the RetroStone section that is included in the image? The idea was exactly to have 'native games' writen for the retrostone2. So your PR feels like duplicating the same idea. Let me know if I'm wrong.

[KurdtNervanna]

I didn't know the best way to organize having some native ports for the retrostone2, i understood that there was the "retrostone" category which were native games, then there was a "doom" category, which is a also a native port which has its own. this is also complicated by the fact that i am only currently porting for retrostone2 hardware only. So while I did the porting process (i'm getting awesome native speeds, perfect dark and oot etc are all running with 0 lag) I figured i'd just throw the PR over to you to get your input on where the best place for these games to live. any suggestions? should I collapse Doom and restrostone and native ports into one list?

[KurdtNervanna]

After looking at your implementation a bit more closely, they are not quite the same thing, I think! The RetroStone section runs your VC games as libretro cores built into the image. #14 is the plumbing to start a standalone program from the SD card (an SDL2/GLES2 binary drawing straight to KMS/DRM): it hands over the display, puts the program in its own process group, and handles sleep and quit. PC ports of N64 games (Mario 64, Ocarina of Time, Perfect Dark…) are standalone programs, not libretro cores, and they need data built from the user’s own ROM, so they can’t go into the read-only image or into the VC section.

To keep the menu tidy, I’d rename it “Ports” and keep it next to Doom and Cave Story, which already carry the “Ports” subtitle in systems.c. Merging those two in would mix libretro and standalone launches, but I’m happy to do it if you prefer one list. I’ll also close #16: the game build scripts belong in my separate RetroStone-Ports repo rather than in RetroStoneOS. That leaves #14 (the launcher) and #15 (rsos-gamepad, the built-in controls as one SDL gamepad). But please advise as to what you think makes the most sense to do...

[PaddleStroke]

Yes I suggest adding these games to Ports even if it means mixing core and standalone exécutables. Rather than having 2 ports sections. For users it would be easier to understand.

…

On Fri, Nov 6, 2026, 16:14 KurdtNervanna ***@***.***> wrote: *KurdtNervanna* left a comment (PaddleStroke/RetroStoneOS#14) <#14 (comment)> After looking at your implementation a bit more closely, they are not quite the same thing, I think! The RetroStone section runs your VC games as libretro cores built into the image. #14 <#14> is the plumbing to start a standalone program from the SD card (an SDL2/GLES2 binary drawing straight to KMS/DRM): it hands over the display, puts the program in its own process group, and handles sleep and quit. PC ports of N64 games (Mario 64, Ocarina of Time, Perfect Dark…) are standalone programs, not libretro cores, and they need data built from the user’s own ROM, so they can’t go into the read-only image or into the VC section. To keep the menu tidy, I’d rename it “Ports” and keep it next to Doom and Cave Story, which already carry the “Ports” subtitle in systems.c. Merging those two in would mix libretro and standalone launches, but I’m happy to do it if you prefer one list. I’ll also close #16 <#16>: the game build scripts belong in my separate RetroStone-Ports repo rather than in RetroStoneOS. That leaves #14 <#14> (the launcher) and #15 <#15> (rsos-gamepad, the built-in controls as one SDL gamepad). — Reply to this email directly, view it on GitHub <#14?email_source=notifications&email_token=AEYO6MKECM3FH7W5XWOJNGT5XXTFTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNRYHAYTQMZRHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6688183190>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYO6MLN6P5QFU5BBZ6D4HL5XXTFTAVCNFSNUABGKJSXA33TNF2G64TZHMYTGOJRGI3DOOBVHE5US43TOVSTWNRQG4ZTGMJQGAZDJILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AEYO6MI5UBJEBWEPHDS7P5D5XXTFTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNRYHAYTQMZRHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AEYO6MK2BFSMVL3YA4OW6W35XXTFTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNRYHAYTQMZRHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>