Tips, Tweaks & (ArkOS) Compatibility Introduction

SystemR36 is built to give you the most freedom to do what you want on your R36, no matter if it’s just running a simple emulator, a simple game, run one of the many ‘standard ports‘, run an insanely sick pc/[console-name]-port, develop your own games or even use it as your handheld mini-Linux-pc.

I did (and will keep doing) my best to make/’keep’ it as compatible with ArkOS (the previously ‘major OS’ on these devices) as possible, this is unfortunately just not 100% possible without for example letting SystemR36 ‘lie’ that it is ArkOS.

This is because while PortMaster has streamlined the process quite well (hats off!) in automatically detecting the correct OS to ‘adjust settings and variables’ for example, there are MANY launcher scripts (.sh files) out there which for example use something like:

.....
COMPATIBILITY_MODE=$CFW_NAME

# Custom Settings/Fixes for ArkOS
if [ "$COMPATIBILITY_MODE" == "ArkOS" ]; then
  # Doing the custom ArkOS/Ubuntu Specffic or what ever things here
fi
.....

This is either due to older scripts, a certain thing which does need to be loaded differently due to the Ubuntu base (which is/was a quite old on ArkOS), or even ‘worse’: LLMs!

NO! I’m not perse against people using LLMs to help them code, port a game etc. The problem however is that NON OFFICIAL “PortMaster Ports” (meaning that someone ported a game and then just bluntly calls it ‘A PortMaster Port‘ for ‘better search engine results’, while its only hosted on their Github), are popping up like wildfires recently. And again: that own it’s own is not a bad thing, not at all actually. The issue however is that lots of those launchers often have more hallucinations (and “problem solving” lines) baked into them than a Wallabies on poppies 🤦🏾‍♀️

And those for example AGAIN just ‘hardcoded’/baked in ‘scans’ for a certain distro, by looking for specific boot files (.dtbs), or reading the plymouth (BOOT SCREEN! files) for version numbers/OS Version (which is not the right way to do such things to start with tbh!).

And while it IS possible to make SystemR36 (partially!) pretend/lie that it is ArkOS to those games/launchers for ‘quick and easy compatibility’. it is NOT recommended to use this as go-to because SystemR36 just isn’t ArkOS. SystemR36 (to keep it simple) has a whole different base, uses different a glibc, has additional audio output options etc etc.

To make things even worse, LOTS of those LLM (“AI”) generated launchers use something as:

LOG="$GAMEDIR/logs/[GameNameHere].log"
exec > >(tee -a "$LOG") 2>&1

Which simply explained means that EVERYTHING the game outputs as logging will be CONSTANTLY written to the log file on your SD-Card. And if that’s not bad enough, lots those “AI Assisted” (let’s just be honest here: Fully de-compiled and re-generated by AI/Claude) ports also output (nearly) EVERY single call it’s doing, including things like:
– Resolution set to, memory reserved, engine initialized, loading level, level loading completed, loading zone, picked up healthpack…
– Button …. pressed down, Button ….. released
– Texture x loaded, texture x unloaded
– Object/NPC/Vehicle/Tree etc etc streamed-in/streamed out

While this might not seem too bad to the inexperienced eye, that EXTREMELY amount of verbose logging is absolutely absurd if you are not directly developing the game engine yourself. The only thing 99% of people will only ever need (especially players when just reporting an (re-occurring) bug? That is basically the first line of items in that list I’ve typed out above.

While extensive logging is not bad per se, it IS when you are running it JUST AS A GAME TO PLAY on an device like the R36S/H which runs on an RK3326 ARM Processor with “just” 1GB of ram of off SD-Cards.

This for several reasons (but again going to keep it simple here!). One of those reasons is that such extremely extensive/verbose logging WILL have a performance impact on the game you’re playing on those ‘constrained’ devices. And even worse (if you don’t care about ‘a little bit more CPU overhead’, micro-stutters and a couple FPS less: It WILL (not can, no it WILL) destroy your SD-Card faster than you can finish a Super Mario Speed run (exaggerated but you’ll get what I mean….. I hope).

Reading “millions of times” from an SD-Card is basically no issue, most decent brand cards will handle that perfectly fine for many many years (even decades). Writing to them with absurd amounts of lines (per second) while just playing a game, WILL wear them down FAST. This is even worse with cheap SD-Cards or unbranded ones, but this does also affect the better ones from for example Samsung, SanDisk etc!

Please do yourself, the performance of your games, and the lifetime of your SD-Cards a favor and optimize your games, their configuration and how you run them!

In this section/sub-menu I explain how you can optimize and/or heavily strip those launchers to run them fully optimized for your R36 on SystemR36 without wearing down your SD-Card for nonsense (like insane logging) you in 99% of the cases don’t need.

NOTE/Disclaimer:
This obviously mainly concerns ‘wild-west-ports’ out there, because like I said earlier: PortMaster has done a great job and has come VERY far in the last couple of years to make everything as streamlined as possible across devices and distributions. However do keep in mind, that the launcher scripts in some (older) PortMaster games can still have ‘ArkOS/Ubuntu speciffic’ workarounds or expectations which do NOT recognize SystemR36 (yet) or it’s Ubuntu base. And thus you might need to adapt those launcher scripts or you might need to run those in the ArkOS compatability mode via EmulationStation-XNL😊