Retroid Pocket Nova on ROCKNIX

I am not a fan of fiddling around with Android. Between launchers, scoped storage permissions, and every emulator front end wanting its own idea of where ROMs should live, it stops feeling like a handheld and starts feeling like a phone I have to administer. So the moment I heard ROCKNIX had support for the Nova's chipset, I was happy even though it is clearly still in an early state for this particular device.

The rough edges show up immediately. On first boot the controller identified itself as a PlayStation DualSense Edge, back paddles and all, instead of anything resembling the Nova's actual button layout. That is not really a bug: it is ROCKNIX's InputPlumber service intentionally emulating a DualSense Edge so that paddle-aware games get proper input, but it does mean the very first thing you see is a slightly wrong set of button icons. Once you know that is what is happening it is easy to look past, and for a chip this new to ROCKNIX, the fact that the rest of the system already works this well says a lot about the project.

The path that worked for me was to install ROCKNIX onto a microSD card first and boot from that. Booting from SD is the safer way to try a young port like this one, since nothing about the internal Android install is touched and a bad flash just means reformatting a card. Once I confirmed the SD boot was stable, I enabled SSH from the network settings menu and used that shell to move the install over to internal storage, which is both faster and one less card to keep track of. If you are trying this yourself, do the SD boot first, make sure your controller, WiFi, and audio all behave the way you expect, and only then commit to internal storage.

Shaders are the part I spend an unreasonable amount of time on with any new emulation device, and this section ended up growing well past the single crt-easymode setup I started with, mostly because black frame insertion turned into its own multi day detour.

All of the shaders below come from the libretro/slang-shaders repository, which ships with RetroArch and therefore with ROCKNIX. I am linking the actual files so this is reproducible rather than just a list of settings names.

shader3 = "newpixie-crt-flat.slang"
scale_type3 = "viewport"
curvature = 0.5
cornersize = 0.02
cornersmooth = 1000.0

shaders = "2"
shader0 = "vba-color.slang"
filter_linear0 = "false"
scale_type0 = "source"
scale0 = "1.0"
darken_screen = 0.400000

shader1 = "lcd1x-mix.slang"
filter_linear1 = "false"
scale_type1 = "viewport"

BRIGHTEN_SCANLINES = 32.000000
BRIGHTEN_LCD = 12.000000
GRID_STRENGTH = 0.750000

shaders = "3"
shader0 = "sharp-shimmerless.slang"
filter_linear0 = "true"
shader1 = "image-adjustment.slang"
filter_linear1 = "true"

ia_luminance = 0.750000
ia_bright_boost = -0.150000
ia_saturation = 0.900000
ia_R = 1.025000
ia_B = 0.950000

shader2 = "lcd1x-mix.slang"
filter_linear2 = "false"
scale_type2 = "viewport"

BRIGHTEN_SCANLINES = 32.000000
BRIGHTEN_LCD = 12.000000
GRID_STRENGTH = 0.500000

This is the section that grew far beyond what I originally planned, because PortMaster on ROCKNIX turned out to be a genuinely deep rabbit hole. PortMaster is the tool ROCKNIX (and most of the Batocera-family systems) use to install native Linux ports of PC and homebrew games, everything from simple SDL games to full engine reimplementations, packaged as install scripts that live right alongside your ROMs.

The bulk of what I did was getting a stack of Pokemon fan games running well. Most of these ship as Pokemon Essentials projects running on a community-maintained engine called mkxp-z, which reimplements RPG Maker's runtime for Linux. The scripts these games carry were mostly written for Windows and an old version of Ruby a decade ago, so a lot of them break in small specific ways under a modern Ruby interpreter: a stray Windows-only font installer that always reports fonts missing on Linux, byte-handling code that assumes an ancient string-indexing behavior, even a syntax pattern (an unreachable break right after a return) that older Ruby quietly accepted and newer Ruby now rejects outright. None of these are hard bugs once you find them: there are just a lot of them, spread across a dozen different games that all copy-pasted the same community scripts.

Two examples, since these are worth having on hand if you run into the same games. First, the fullscreen fix that most of these ports needed in their mkxp.json, since the default is a small windowed canvas with letterboxing on every side:

{
  "fixedAspectRatio": false,
  "fullscreen": true
}

Second, and this was the best find of the whole process: Pokemon Essentials ships two completely different ways of entering your character's name. One expects a proper on-screen keyboard from the operating system; the other is a self-contained screen that draws its own letter grid and only needs the D-pad and two buttons, exactly like naming a Pokemon on the original Game Boy games. The on-screen-keyboard path is the one that is broken on a Wayland-based handheld like this, and chasing it down through virtual keyboard protocols turned into its own multi-hour side quest. But the classic grid was sitting right there in the same script the whole time, fully working, just switched off by default in the Settings script:

# was: USEKEYBOARDTEXTENTRY = true
USEKEYBOARDTEXTENTRY = false

Flipping that one line fixed name entry across every affected game at once, no keyboard, no touch input, no extra dependencies.

The more exciting part came next: native ARM64 game ports that need no emulation at all. Projects using static recompilation, where an N64 or GameCube game's original machine code is translated once into real native code rather than interpreted at runtime, are becoming a small but active homebrew scene, and several of them now ship prebuilt ARM64 Linux binaries directly. I got a Banjo-Kazooie recompilation running completely natively, no translation layer in sight, using the Vulkan driver already on the device:

A Twilight Princess recompilation runs the same way, and I also got a Super Smash Bros. Melee PC port working, which does need a light compatibility layer (box64) since that one only ships x86-64 builds. It still renders through the same real Vulkan driver, once a couple of missing system libraries are pointed at a compatibility runtime already present on the device:

export BOX64_LD_LIBRARY_PATH="./box64-libs"
export BOX64_EMULATED_LIBS="libsqlite3.so.0"
box64 ./melee "/path/to/Super Smash Bros. Melee.rvz"

Thanks to just how good modern recompilations have gotten, we are living in a bit of a golden age for retro games right now: there is already a huge amount of native Linux gaming support on ARM, and it keeps growing. This is basically the role I wanted the Nova for in the first place: a Steam Deck addition mainly for retro games, emulation, and the occasional fan game. And with the 4:3 aspect ratio, it does that job perfectly.

These two needed the opposite fix from each other. The PSP screen is natively about 16:9, not 4:3, so left alone it renders letterboxed, black bars top and bottom, to preserve that shape. I wanted the opposite: filling the whole 4:3 panel instead, accepting the mild horizontal squish that comes with it. That lives in the [Graphics] section of PPSSPP's own ppsspp.ini. It needs two keys together, since changing SmallDisplayZoomType alone had no visible effect:

SmallDisplayZoomType = 0
DisplayStretch = True

Pico-8 is built around a fixed, square-ish 128 by 128 canvas, so there I wanted the aspect ratio preserved rather than stretched. Once installed through PortMaster, setting the display to 4:3 instead of a full stretch keeps its pixel grid clean and square the way the fantasy console was designed to look, exactly the kind of small win the Nova was supposed to deliver.

This is the part I am still poking at rather than something I have fully settled. The idea of running actual Windows games on an ARM chip through Steam, on a handheld this size, is the kind of thing that would have sounded absurd a few years ago, and the fact that it is even worth attempting now says something about how far compatibility layers have come. I am approaching this the same way I approach the 4:3 side of things: picking games that were built for or look right in a 4:3 or boxier aspect ratio rather than assuming every modern widescreen title will behave.

For actually finding games worth trying, the Does it 4:3 curator on Steam has been the most useful starting point. It is exactly what it sounds like, a running list of games that support or look right in a 4:3 aspect ratio, which pairs nicely with a small handheld screen and with the general philosophy behind the rest of this setup.

None of this replaces the Steam Deck, and it was never supposed to. What the Nova gives me is a dedicated, boxy little retro machine I do not mind handing to a kid or leaving on a shelf, running an operating system I actually enjoy configuring instead of fighting. ROCKNIX support for this chipset is young: the wrong controller identity on first boot is proof of that. But the pace of what already works, from properly tuned shaders to genuinely native ARM64 game ports through PortMaster, made the early rough edges easy to forgive. If you already have a Steam Deck and are wondering whether a small ARM handheld is worth adding next to it, the answer for me was yes, mostly because of how much of this stack simply is not stretched-widescreen software at all.