The form factor is immediately recognisable. At 160 x 91 x 22mm it’s a near-match for the 3DS XL (156 x 93 x 22mm), similar button layout and hinge feel, two screens stacked vertically. The corners are sharper than the XL’s rounded edges though, which I noticed in my hands after longer sessions. Both screens are the same size and resolution, which wasn’t the case on the 3DS XL.

Specifications

In the box

The console, a capacitive stylus, screen protectors, a wrist loop, and a 64GB microSD. Given there are two screens to scratch, the screen protectors are at least practical. There’s no slot for the stylus, so it lives loose in a bag or you just use your fingers.

The 64GB card turns out to be the official Linux firmware, with multiple partitions, one of which is a ROMs volume pre-loaded with a starter library (160 NDS files, 206 GBA files, and various other systems). With the card inserted, the device boots straight into Linux rather than Android.

The screens

Both screens are 4 inches, matched in size and resolution. The 3DS XL ran 4.88 inches on top and 4.18 at the bottom, at different resolutions; the RG DS goes for symmetry instead. Coming from smaller devices like the Miyoo Mini or TrimUI Brick, the difference is immediately noticeable. Both panels are well-matched in brightness and colour temperature, which isn’t a given at this price. Two independent screens make room for things the original DS couldn’t do. A game guide on the top, the game on the bottom works well in practice.

The resolution is 640x480 per screen. The Nintendo DS ran at 256x192, so the scaling factor is 2.5x. That’s not a clean integer, so pixel-perfect rendering isn’t possible without borders. DraStic offers scaling filter options to take the edge off: Scale2X and HQ2X both soften things up well enough, and integer scaling with borders keeps pixels clean at the cost of black bars. Easy to stop noticing either way.

The stylus is capacitive, not resistive. The original DS’s resistive panel gave more precise single-point input; capacitive is smoother for general use but hurts games that depend on drawing or tapping.

The rest of the hardware

The RK3568 handles DS emulation and most 2D systems comfortably, but loses convincing ground past N64, Dreamcast, or anything with heavier 3D.

Two analogue sticks, recessed further than feels natural given the limited space. They work, but they’re clearly an afterthought. Anyone coming from a flat handheld will notice.

Closing the lid sleeps the device; opening it wakes cleanly. If the screens time out while it’s open, only the power button brings them back. Touching the top screen doesn’t register as activity for Android’s idle detection either, so the device can go to sleep on you even while you’re actively using it. Mildly annoying if your hands are already on the controls.

The hinge is solid, tight enough that the device stays open at whatever angle you set it, with a firm linear advance all the way to 180 degrees flat. Build quality is fine for the price. Mine is Black & Crimson Red; it also comes in Turquoise Blue and Polar White, the names nodding at that DS inspiration.

The bottom is completely plain bar four 1.5mm hex screws, which is a welcome change from Nintendo’s tri-wing. The top edge has two USB-C ports, one for power and data transfer, one for OTG. Both are labelled, but nothing physically stops you plugging into the wrong one.

At 311g and about twice as thick as a modern phone, it doesn’t fit in a front pocket but slides into a back pocket.

No camera, which is a bit odd when budget smartwatches manage to include one, but since none of the emulators need it the omission is hard to argue with.

The speakers are loud enough and clear, but thin on bass. Bluetooth works fine. I haven’t tested the 3.5mm jack; other reviewers report a fair bit of interference hum through it.

The face buttons and D-pad are clicky micro switches. The shoulder buttons are springy and clicky. Fine when gaming alone, but the noise carries (you sort of wish they were squashier if you’re playing near others).

The vibration motor is far more powerful than it needs to be. It goes off when plugging in to charge, connecting via USB, and on shutdown (a full rattling buzz each time). It’s all controllable from Android’s sound settings though; I turned it off immediately.

Battery life

The 4000mAh battery is rated at around six hours. DS emulation at reasonable brightness gets closer to three to four. Well below the marketing figure.

Charging is at 5V/1.6A, which is slow. Expect around three and a half hours from empty.

The battery indicator is unreliable, staying green well past what the charge warrants. The percentage is more reliable than the icon.

Emulation

The obvious target is DraStic for DS games. Every DS title I tried ran at full speed. Games fill both screens as they’re supposed to, no awkward hotkeys or workarounds. The stylus works, though it’s noticeably laggier than on actual DS hardware (the capacitive panel is the culprit). For most games that’s fine; for anything that depends on precise or rhythmic stylus input (Rhythm Heaven, Elite Beat Agents, Kirby Canvas Curse) it’s a problem.

Running Mario Kart DS with Scale2X on for a couple of grand prix cups does make it run warm, but it keeps going without complaint.

DSiWare is a gap. DraStic doesn’t support it, and melonDS (the only option that does) runs DSiWare titles very poorly on this hardware.

One DraStic annoyance is that the L2 and R2 buttons are bound to save and load state by default. On a clamshell, those sit where my fingers naturally rest, so I kept accidentally triggering a save or load mid-game until I remapped them. Easily fixed, but surprising it shipped that way.

GBA via GBA.emu is flawless. Zelda: The Minish Cap ran perfectly, and R2 fast-forward is handy for cutscenes. The hardware is massively overpowered for anything in the 16-bit era and below.

PPSSPP handles most PSP games well. GTA Liberty City Stories and Vice City Stories both ran fine via the standalone app. The RetroArch core was a different story, with audio stuttering in cutscenes and lag when driving fast. Standalone PPSSPP is the better choice. The heavier 3D titles (God of War: Chains of Olympus, Crisis Core) I haven’t tested, but RK3568-class hardware is generally not their friend.

PS1 via DuckStation is great. Metal Gear Solid ran without hiccups, 2x upscaling held steady. DuckStation on Android hasn’t had an update since May 2025 and the developer has stepped back. It still works, but the maintained alternative is RetroArch’s SwanStation core, a DuckStation fork. Save files transfer across directly.

N64 through Mupen64Plus FZ Pro standalone runs well; it handles compatibility better than the RetroArch core for a handful of games.

3DS via the stock Azahar build is mostly disappointing. The preinstalled version undersells what’s possible though. Swapping to AzaharPlus, a community fork with extra optimisations, is worth it. New Super Mario Bros 2 Special Edition runs at 85%+ speed, which is very playable. Getting the dual-screen layout configured wasn’t obvious, but once sorted it works nicely. Not every 3DS title will fare as well, but it’s worth trying before writing 3DS off entirely.

Stock firmware

Most early reviews got a device in a rough state. The headline problem was screen desync (top panel at 40Hz, bottom at 60Hz), which is hard to ignore. DraStic had noticeable input lag, the D-pad misfired on diagonals, sleep/wake was unreliable, and the launcher was sluggish. That coverage stuck, and the device’s reputation took a hit before most retail units shipped. V1.15 fixed the desync. V1.18 smoothed out more of the rough edges. What most buyers get now is a different device to the one those reviews described.

Firmware updates are listed on Anbernic’s update page, though the hosting is unreliable. V1.18 is on WeTransfer, V1.15 and the Linux build are on Google Drive.

The stock OS is workable but not especially clean. It’s Android 14 with custom launcher changes. The RG button earns its place: a short press switches input focus between screens, a long press opens Anbernic’s game frontend, and mid-game there’s no need to reach for the touchscreen. Standard frontends like Daijisho and ES-DE install without issue, though DraStic has to be launched directly, and the patched version that fixes the 40Hz screen bug isn’t automatically picked up by frontends.

The emulator lineup is hard to fault. DraStic for DS, Azahar for 3DS, and the .emu suite covering handheld and 16-bit systems (GBA, GBC, NES, SNES, Mega Drive, Neo Geo, Neo Geo Pocket, PC Engine, MSX). There’s DuckStation for PS1, PPSSPP for PSP, Flycast and Redream for Dreamcast (both included), Yaba Sanshiro 2 Pro for Saturn, Mupen64Plus FZ Pro for N64, RetroArch as a catch-all, and EasyRPG Player for RPG Maker games. Apollo and Limelight handle game streaming. There’s also APKPure as an alternative app store (Google Play Services removed it on my unit before I got a chance to use it), a couple of Chinese apps that don’t serve much purpose outside China, and the Play Store, which I haven’t signed into.

GammaOS is the one most people seem to land on for day-to-day use.

GammaOS Next

Most long-term owners end up on something different: GammaOS Next v1.2.2, a custom Android 14 build (based on LineageOS 21) that several reviewers frame as what should have shipped from the start. When I reviewed the Mangmi Air X last year, GammaOS was Patreon-only. It went public in April 2026, and the RG DS felt like the right device to finally try it on.

It addresses the stock OS’s main rough edges (sleep/wake reliability, input latency in DraStic, diagonal D-pad misfires, general sluggishness). The touch panels are bumped to 120Hz. DualStack mode makes apps behave as single-screen when needed, plus per-screen volume, system-wide audio EQ, and a global shader pipeline so CRT filters apply across all emulators without per-emulator config.

The bottom screen can’t be fully turned off, only dimmed. The more demanding systems (N64, Dreamcast, PSP) are not GammaOS’s strongest suit, but 3DS compatibility, full Android app support, and DraStic with shader support make up for it. DraStic runs well even in low power mode, which helps battery life considerably. Standby drain is about 3% over eight hours.

The install wipes the device (unlike Linux firmware which boots from microSD), so it’s a one-way trip until reflash. Lite is the better choice; Google Services overhead makes Full sluggish on the RG DS hardware.

Install is via fastboot. Post-install it sets up RetroArch and Daijisho, and comes with DraStic, Flycast, Mupen64Plus FZ Pro, and PPSSPP pre-installed. Launching Mario Kart DS from Daijisho feels near-instant. It feels more like a games console out of the box than Android with emulators dropped on it.

I went with Lite, which skips Google Services entirely and ships with Aurora Store and Firefox instead of the Play Store. Noticeably snappier than stock.

The RG button loses its special functions on GammaOS; it just pulls down the notification drawer.

DraStic comes pre-configured for dual screen. DS games run better than on stock.

GammaOS also ships with demo ROMs across a range of platforms and three Pico-8 games via the fake08 RetroArch core. Enough to get a feel for each system before digging into your own library.

Linux flavours

Anbernic released an official Linux firmware (v1.0, May 2026) taking a more console-like approach (games sorted by system, launched through DraStic and RetroArch, with a DS-themed UI). The included 64GB card is this firmware, with a starter ROM library and a handful of ports (Doom with nine WADs, Cave Story, VVVVVV, Sonic Robo Blast 2, C-Dogs) plus 39 Pico-8 carts running through the fake08 RetroArch core. Decent for a first boot.

The UI feels unpolished. The in-game menu has tiny unreadable text, the three included themes are fairly basic, and game cover scraping is patchy. DS games run fine, but there’s no scaling control (everything stretches to 640x480 with no pixel alignment), which looks rough versus DraStic on Android. Raw emulation performance is worse than Android, and high-res 3D mode struggles. Audio bugs, a “now playing” overlay on the bottom screen that can’t be disabled, occasional shutdown issues. Worth revisiting as it matures. It boots from microSD, so no need to wipe the internal Android install to try it.

ROCKNIX doesn’t have an official RG DS build yet. There’s an unofficial workaround using the RK3566 nightly with a config edit, and there’s already a DSi-style EmulationStation theme for it. One to watch once an official build lands.

Knulli is another community Linux build with the same basic install process as ROCKNIX, currently in alpha and Patreon-only. Not practical for most people yet.

Worth it

At $95 it does one thing better than most, playing DS games in the right form factor. The clamshell, dual screens, and a hinge that folds it pocket-sized all do the same job. Save states, fast forward, and a spare screen to pull up a guide or video while playing are things actual DS hardware can’t offer. The bundled emulator lineup covers a lot of ground, DraStic runs everything I threw at it, and GammaOS addresses the rough edges that hurt early reviews.

The caveats matter. The capacitive stylus lag rules out precision games, and DSiWare is effectively a dead end on this hardware. The RK3568 falls apart past 5th-generation 3D. Battery life is three to four hours in practice, well short of the marketing figure. The analogue sticks feel like an afterthought. The vibration motor is absurdly strong for the job. The sharp corners dig in during longer sessions.

As a DS replacement it’s probably the best DS-feeling option going.

Two counterpoints worth considering. A DS Lite plus a DS Pico flashcart comes in at around half the price, actual hardware, proper resistive touchscreen. There’s also DS wifi-play, which the RG DS can’t offer at all. Hard to ignore if DS games are the whole point.

Or a 3DS modded with custom firmware, which runs DS, DSiWare, and 3DS titles perfectly, and covers a fair few other systems besides.

The RG DS is available directly from Anbernic.

Part of the problem is how frictionless it is. I take a photo, it syncs, it’s “backed up”, and I never think about it again. That’s the appeal, but it’s also why I’d gone fifteen years without asking where, exactly, “backed up” actually meant.

Getting the download URLs

I requested a full Takeout export and it came back as 66 zip files, about 2GB each, 131GB total. My NAS has the space; my laptop does not. I didn’t fancy downloading it locally just to copy it across, so I worked out how to pull it straight to the server.

On the Google Takeout page, there’s a list of all the zip files with a download link for each. There’s no way to grab them all at once, but running this in the browser console pulls all the links and copies them to the clipboard:

copy([...document.querySelectorAll("a.WpHeLc")].map(a => a.href).join('\n'));

Google obfuscates its CSS class names, so WpHeLc will likely change at some point. If it returns nothing, inspect one of the download buttons and find the current class. Paste the result into a urls.txt file on the server.

Why cookies don’t transfer

The download links are authenticated, so the trick is carrying the Google session from the browser into the terminal. The obvious approach was to export browser cookies to a cookies.txt file (via an extension like “Get cookies.txt LOCALLY”) and pass them to curl or aria2c. This doesn’t work.

The Takeout download URLs go through a redirect chain across multiple Google domains before landing on takeout-download.usercontent.google.com. The cookies that matter (__Secure-1PSID, __Secure-3PSID, SIDCC, and a few others) don’t survive that redirect in most download tools, and some cookie export extensions miss them entirely. Every download attempt ends up at the Google login page and saves an HTML file instead of a zip. The solution is to skip the redirect entirely and go straight to the final download URL, using Chrome’s exact headers.

Pretending to be a browser

Install the CurlWget extension in Chrome. Start downloading one of the files from the Takeout page, then immediately click the CurlWget icon. It generates an equivalent curl command with all the headers and cookie data Chrome used, pointing at the actual takeout-download.usercontent.google.com URL, no redirect involved. This works where the cookie export didn’t because Chrome had already followed the redirect, so the cookies are tied to the final domain, not the Takeout one.

From that I had the Cookie: header string, a job ID shared across all files, a numeric user ID, and the base filename, which was enough to build all the download URLs directly. The files are numbered sequentially, so the whole lot can be constructed without touching the Takeout page again.

The cookies don’t last long, though. Each session got me about 7 files (~14GB) before they expired and downloads started coming back as HTML again. The cookie lives in a separate cookie.txt file so it can be refreshed without touching the script. Grab a new CurlWget capture, save it to a text file, and pipe it through a helper script that pulls out just the value:

cat curlwget.txt | bash update-cookie.sh

#!/bin/bash
# update-cookie.sh
# Usage: pbpaste | bash update-cookie.sh
#    or: cat curlwget.txt | bash update-cookie.sh
grep -oP "(?<=Cookie: )[^'\"]*" | tr -d '\n' > cookie.txt
echo "cookie.txt updated."

The resulting cookie.txt looks something like this (heavily abbreviated):

SID=g.redacted; HSID=redacted; SSID=redacted; APISID=redacted; SAPISID=redacted; __Secure-1PSID=g.redacted; __Secure-3PSID=g.redacted; SIDCC=redacted; __Secure-1PSIDTS=sidts-redacted; __Secure-3PSIDTS=sidts-redacted; NID=redacted

The download script

With those pieces, the script builds each URL directly and downloads with curl:

#!/bin/bash
set -euo pipefail

DIR=/path/to/destination
TOTAL=$(wc -l < "$DIR/urls.txt")

# From the CurlWget capture
J=your-job-id-here
USER_ID=your-numeric-user-id
BASE_NAME=takeout-YYYYMMDDTHHMMSSZ-N

COOKIE=$(cat "$DIR/cookie.txt")

# Clean up any small HTML files from previous failed attempts
find "$DIR" -name "takeout-part-*.zip" -size -1M -delete 2>/dev/null || true

for i in $(seq 0 $((TOTAL - 1))); do
    part=$(printf '%03d' $((i + 1)))
    filename="${BASE_NAME}-${part}.zip"
    output="$DIR/$filename"
    url="https://takeout-download.usercontent.google.com/download/${filename}?j=${J}&i=${i}&user=${USER_ID}&authuser=0"

    if [[ -f "$output" ]] && [[ $(stat -c%s "$output") -gt 1048576 ]]; then
        echo "[$((i+1))/$TOTAL] $filename already exists, skipping"
        continue
    fi

    echo "[$((i+1))/$TOTAL] $filename"

    curl \
        --header "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" \
        --header "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7" \
        --header "Accept-Language: en-GB,en-US;q=0.9,en;q=0.8" \
        --header "Referer: https://takeout.google.com/" \
        --header "Cookie: $COOKIE" \
        --retry 10 \
        --retry-delay 15 \
        --retry-all-errors \
        --continue-at - \
        --progress-bar \
        -o "$output" \
        "$url" && echo "done" || echo "FAILED"

done

echo "All done."

Run it inside tmux or screen so it survives disconnecting from the server:

tmux new -s takeout 'bash download.sh'

--continue-at - handles resume if a download is interrupted, and the script skips any file over 1MB that already exists, so a mid-way cookie expiry just means refreshing it and running the script again.

What’s inside

Extracted, it’s a single Takeout/Google Photos/ directory with about 28,500 files in it. Almost exactly half are small JSON files, one per photo or video, carrying the metadata that Google doesn’t embed in the image itself (taken time, location, description, view count). The actual images have none of that baked in.

The folder structure is a mix of year folders (Photos from 2011 through Photos from 2026), named albums I actually created (Iceland 2016, Menorca 2018, Jenny & Max Wedding, various project dumps), and 214 folders called Untitled, Untitled(1), and so on up to Untitled(213). Those turned out to be WhatsApp shares, recognisable from the IMG-20XXXXXX-WAXXXX.jpg filenames inside.

The JSON files are a bit annoying. The photoTakenTime field has the actual date the photo was taken, but that’s separate from creationTime, which is when it was uploaded to Google Photos, and neither of those is written into the image file itself. So if I import everything into something like Immich or Lightroom without processing these first, it all ends up timestamped wrong. Tools like gphotos-takeout and google-photos-exif can merge that data back in, but that’s a job for another day.

It worked well enough that I didn’t touch it for three years, but the rate-limit situation had been silently catching visitors out and eventually I started pulling at the thread.

The original setup fetched webmentions from webmention.io on every page load, caching the results in localStorage for 30 minutes. GitHub issue comments (my comment system) were fetched the same way. The result was a discussion section that would flicker in after a moment, or not appear at all if the API was rate-limited or slow.

The GitHub API rate limit is 60 requests per hour per IP for unauthenticated requests. That’s per visitor, so anyone browsing through a few posts in quick succession would hit it pretty fast and suddenly find comments not loading. There was also no record of what mentions existed at build time. Anyone without JavaScript saw nothing.

Fetching at build time

I run a small self-hosted service on my VPS called Morris that mirrors webmentions from webmention.io, indexing them by target URL and storing each one as a JSON file so I’ve got a local copy I control rather than depending on the API directly. (webmention.io receives and stores mentions sent to your site; brid.gy bridges social platforms like Mastodon and Twitter so their replies show up as webmentions too. Both are free and genuinely brilliant bits of IndieWeb infrastructure.)

Two scripts handle the fetching, a webmention one and a GitHub comments one, each writing results to _data/. A GitHub Actions workflow runs both at 4am daily and commits whatever’s changed.

Fetching GitHub comments via Actions rather than client-side also means the requests go out authenticated with GITHUB_TOKEN, which has a rate limit of 1,000 requests per hour per repository. That’s more than enough for a daily cron job, and since the results are committed to the repo, visitors never touch the API at all unless new comments have arrived since the last build.

With the data files in the repo, Jekyll renders the mentions at build time using standard Liquid templates. The discussion section is in the HTML before anything loads. The JS still runs to pick up anything that’s arrived since the last build, tracks which IDs were already rendered to avoid duplicates, and re-sorts the feed chronologically. The page passes the pre-rendered IDs to the JS as two Sets:

const preRenderedWmIds = new Set([{{ output at build }}]);
const preRenderedCommentIds = new Set([{{ output at build }}]);

One stream instead of three

Previously the discussion section had separate blocks for comments, replies, and mentions. I merged them into a single feed sorted by date, mixing GitHub comments and webmentions together. Archived comments (old ones I’d manually added to post front matter) slot in at the top since they’re always the oldest.

Items are colour-coded by source, GitHub comments getting one accent and webmentions another, with further tints for Reddit, Mastodon, and Twitter. My own entries flip to a reversed bubble, like a sent message.

Likes, reposts, and bookmarks are gone from the stream entirely. They used to show as a grid of avatars, which was mostly noise, and a row of ten identical silhouettes doesn’t tell you much. The counts still show up in the interactions badge at the top of the post.

Interaction counts also appear on the post listing pages now. Since the data is baked into the build, the counts render statically alongside each post title with no JS involved.

Tidying up

Webmention.io matches mentions against exact URLs, and I was losing some because people link with or without a trailing slash even though the canonical URL always has one. Webmention.io also has a .txt version of each post it can check against (I added .txt support back in January). I added both variants to the set of URLs the JS uses when looking for matches, which recovered a few mentions that had been silently missing.

I swapped the various hand-rolled inline SVGs scattered through the interactions markup for a Lucide icon sprite, one <svg> block in the page head with <use href="#icon-name"> anywhere an icon is needed. A bit less markup noise and much easier to maintain.

Webmention.io’s own blocklist doesn’t catch everything. I found a cluster of scraper sites that had all syndicated the same “budget smart home” article and sent webmentions to an old post of mine. They were easy to spot since they all had the same URL path across different junk domains. I added a BLOCKED_DOMAINS list to the fetch script and purged them from the existing data.

The discussion section now loads with the page. No flicker, no comments quietly missing because someone linked without a trailing slash.

I’ve had a DevTerm A04 since launch, modded it a bit, and mostly use it as a curiosity. It’s a small ARM-powered Linux machine in a retro terminal form factor with a built-in 58mm thermal printer. At some point it occurred to me that I could use it to emulate the whole Game Boy Camera setup, mGBA running the GB Camera ROM, a USB webcam feeding in as the camera sensor, and the DevTerm’s printer standing in for the Game Boy Printer. Tiny thermal photos. Same aesthetic, one device.

The idea on paper was simple enough. When a print is triggered in-game, mGBA saves the output as a PNG. A Python script watches for new files and converts them to 1-bit monochrome to send to the printer. Four moving parts. Should be fine.

It was not fine. Not immediately, anyway.

The OS was showing its age

My DevTerm was still running the original OS image it shipped with, Ubuntu 21.04 Hirsute. That version hit end-of-life in January 2022, so the package repos were long dead. Anything involving apt install was either broken or unreachable. The printer service also wasn’t working, which I couldn’t easily diagnose without being able to install anything.

ClockworkPi provide an updated image, DevTerm_A04_v0.2h.img.bz2, based on Ubuntu 22.04 LTS (Jammy) with Linux 5.10.75. Flashed via macOS:

bunzip2 -c DevTerm_A04_v0.2h.img.bz2 | sudo dd of=/dev/rdiskX bs=4m

It booted fine and the package repos worked. The printer still didn’t work, but at least now I could start diagnosing it.

How the printer works

The DevTerm’s printer doesn’t expose itself as a simple device node. Instead there’s a pair of services: devterm-socat.service creates a named pipe at /tmp/DEVTERM_PRINTER_IN, and devterm-printer.service reads from it and drives the hardware over SPI. To print something, you write ESC/POS commands to the pipe.

On the fresh image both services came up without issue, which was more than could be said for the old Hirsute install.

It was the ribbon cable

I tried sending a test command (\x12\x54 is DC2 T, the ESC/POS self-test sequence):

echo -ne "\x12\x54" > /tmp/DEVTERM_PRINTER_IN

The printer display showed “Error: NO PAPER”. The paper was loaded. I pulled the holder out and reinserted it. Still “NO PAPER”.

I ran strace on the printer process to check whether anything was actually happening:

sudo strace -p $(pgrep devterm_thermal) 2>&1 > /tmp/strace.log &
echo -ne "\x12\x54" > /tmp/DEVTERM_PRINTER_IN

The log showed ioctl calls against file descriptor 4. Checking /proc/$(pgrep devterm_thermal)/fd confirmed FD 4 is /dev/spidev0.0:

0 -> /dev/null
1 -> /tmp/devterm_printer.log
2 -> /tmp/devterm_printer.err.log
3 -> /dev/mem
4 -> /dev/spidev0.0
5 -> /dev/pts/0

SPI commands were going out and the daemon was doing its job. The printer hardware just wasn’t responding.

The ribbon cable (FPC) connecting the printer board to the mainboard was loose, not visibly out but not seated properly at both ends. The spec sheet notes the FPC connector should only be plugged and unplugged fewer than ten times in its entire life, which is a slightly alarming thing to read while reseating a connector for the second time. Reseated it anyway, sent the self-test command again:

echo -ne "\x12\x54" > /tmp/DEVTERM_PRINTER_IN

It printed. Logo, fonts, QR code, system info, the lot.

Hardware sorted. Time to actually do the thing.

The camera

The camera I’m using is an HBV-1313, a £7.82 USB module that’s 60mm long and 8mm wide. I didn’t want to be lugging a full webcam around or cable-tying something to the shell, and this sits neatly above the screen held on with double-sided tape, which is exactly the kind of mounting solution the GB Camera aesthetic deserves.

The module shows up as /dev/video1. I grabbed a shot with fswebcam:

fswebcam -d /dev/video1 test.jpg

Converting and sending it to the printer took a small Python snippet:

python3 -c "
from PIL import Image, ImageOps
import struct

img = Image.open('test.jpg').convert('L')
w, h = img.size
new_h = int(h * (384 / w))
img = img.resize((384, new_h), Image.NEAREST)
img = ImageOps.invert(img).convert('1')
data = img.tobytes()
header = b'\x1d\x76\x30\x00' + struct.pack('<HH', 48, new_h)
open('/tmp/DEVTERM_PRINTER_IN', 'wb').write(header + data)
"

The shot was taken blind over SSH, which explains the composition. The print has a gap in the middle where I forgot -e on the echo command and printed a literal \n\n\n\n\n. Pipeline confirmed working.

mGBA and the file watcher

With the camera already working, I launched mgba-qt with the GB Camera ROM. mGBA has a camera sensor backend that maps a V4L2 device to the cartridge’s sensor interface, so it picked up /dev/video0 without any extra configuration.

mGBA does have GB Printer emulation built in. You open it via Emulation, Game Boy Printer, and get a dialog with a live print buffer, a “hurry up” button to skip the timing delay, “tear off” to flush the buffer (useful for batching multiple prints into one image), zoom, copy, and save. It’s a perfectly good tool, but saving still means clicking through a dialog each time. My first attempt at automating around this was a file watcher: save the PNG wherever you like, and the script picks it up and sends it to the printer.

The script watches a directory for new PNG files and sends each one to the printer. The conversion is the awkward bit: GB Camera output is 160px wide, 4-shade greyscale; the DevTerm printer wants 384 dots per row, 1-bit monochrome. Image.NEAREST for the resize matters here. Bilinear would blur the pixels into mush; nearest-neighbour keeps the chunky look intact.

import sys
import time
import struct
from pathlib import Path
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
from PIL import Image, ImageOps

PRINTER_IN = '/tmp/DEVTERM_PRINTER_IN'
PRINTER_WIDTH = 384

def send_image(path):
    img = Image.open(path).convert('L')
    w, h = img.size
    new_h = int(h * (PRINTER_WIDTH / w))
    img = img.resize((PRINTER_WIDTH, new_h), Image.NEAREST)
    img = ImageOps.invert(img).convert('1')
    data = img.tobytes()

    width_bytes = PRINTER_WIDTH // 8
    header = b'\x1d\x76\x30\x00' + struct.pack('<HH', width_bytes, new_h)

    with open(PRINTER_IN, 'wb') as f:
        f.write(header + data)

class PrintHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.src_path.endswith('.png'):
            time.sleep(0.1)  # let mGBA finish writing
            send_image(event.src_path)

if __name__ == '__main__':
    watch_dir = sys.argv[1] if len(sys.argv) > 1 else '.'
    observer = Observer()
    observer.schedule(PrintHandler(), watch_dir, recursive=False)
    observer.start()
    print(f'Watching {watch_dir}')
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()

Skipping the middleman

The script worked, but the workflow was still a mess. To actually print something you’d take a photo in-game, trigger a print, open the Game Boy Printer dialog, wait for the buffer to fill, click save, choose a filename, save it to wherever the watcher was looking, and then it would send it to the printer. The whole point of the GB Printer was that print was one button. This was six.

So I forked mGBA and wired its printer emulation directly to the thermal pipe. mGBA was already capturing the printer buffer and emitting a signal when a print job came in, so the fork just catches that signal and sends the image to the pipe instead of opening a save dialog. Nothing changes in the emulator’s GB Printer handling. The image gets scaled, contrast-adjusted, dithered to 1-bit monochrome, and written as an ESC/POS bitmap command, all in one step. The printer auto-attaches when any GB game loads, so the game always sees it as connected. That includes Photo!, a homebrew alternative to the GB Camera ROM with considerably more control over the imaging side, if the original isn’t enough.

There’s a settings panel under Tools, Thermal Printer Settings:

• Auto-print: whether to actually send anything to the printer (the printer is always attached regardless)
• Pipe path: defaults to /tmp/DEVTERM_PRINTER_IN
• Density: 0–15, how hard the print head fires
• Contrast: 1.0–4.0, applied before dithering
• Dithering: threshold, ordered/Bayer, Floyd-Steinberg, or Stucki
• Scale: integer 2x centred, or stretch to full width
• Feed lines: paper advance after printing
• Instant print return: skip the print timing delay

The defaults are all DevTerm-specific, but it should work with any ESC/POS thermal printer with the pipe path changed.

The fork is at omgmog/mgba on the devterm-thermal-printer branch, with a pre-built binary for the DevTerm A04 (aarch64, Ubuntu 22.04 Jammy) for anyone who doesn’t want to build it.

Dithering

Converting from the GB Camera’s 4-shade greyscale to 1-bit monochrome is where most of the image quality lives or dies. A thermal printer can either fire a dot or not (there’s no such thing as grey), so dithering is the only way to fake tonal range. The patch offers four options, and they produce noticeably different results.

Threshold is harsh. Everything becomes either white or black, the midtones disappear, and the result looks like a photocopy left in the sun. Ordered/Bayer gives a classic halftone look, regular dot patterns standing in for greys, which is fine but reads as “printed” in a fairly obvious way. Floyd-Steinberg is where it starts to feel more photographic, the grain distributed unevenly in a way that looks almost natural. Stucki does the same thing with a bit more finesse, the dots finer, the transitions smoother. On thermal paper, where there’s no such thing as grey anyway, Stucki consistently gets the most out of the image.

So anyway, that’s a print

The thermal prints will fade in a few years and they’re too small to frame. Nobody asked for this. But it’s the same stupid aesthetic from Christmas 1998, running on hardware I had to reflash and debug and physically reseat a ribbon cable on, printing photos through an emulator I had to fork. There’s something satisfying about that chain of effort for something this pointless. If you had a GB Camera as a kid, you already understand. If you didn’t, I’m not sure I can explain it.

The setup

A scheduled action runs every hour, fetches my most recent track via the Last.fm API, and writes it to _data/now/lastfm.json. If the track changes, it commits the file and pushes, triggering a Jekyll build and redeploy.

- name: Commit changes
  run: |
    git config user.name "github-actions"
    git config user.email "actions@github.com"
    git add _data/now/lastfm.json
    if git diff --staged --quiet; then
      echo "No change"
    else
      git commit -m "Update data"
      git push
    fi

The script only writes to disk when something actually changes (track name, artist, or now-playing status), so most hourly runs are no-ops. But when I’m listening to music, each track change produced a new commit. After a few months the log looked like this:

d3e220d post about my home nas
a051ecf Update data
c2d9699 Update data
5eb6c17 Update data
9644ed6 Update data
e4dca4d Update data
b4c5fba limit the feed to 25 posts

142 Last.fm commits across 1091 total. Roughly one in eight commits was noise.

Fixing it going forward

The solution was to make the workflow amend the previous update commit, instead of creating a new commit each time. That leaves at most one Last.fm commit between real ones:

- name: Checkout repo
  uses: actions/checkout@v4
  with:
    fetch-depth: 0

- name: Commit changes
  id: commit
  run: |
    git config user.name "github-actions"
    git config user.email "actions@github.com"
    git add _data/now/lastfm.json
    if git diff --staged --quiet; then
      echo "changed=false" >> $GITHUB_OUTPUT
    else
      if [ "$(git log -1 --pretty=%s)" = "Update data" ]; then
        git commit --amend --no-edit
        git push --force-with-lease
      else
        git commit -m "Update data"
        git push
      fi
      echo "changed=true" >> $GITHUB_OUTPUT
    fi

fetch-depth: 0 is important here. actions/checkout@v4 does a shallow clone by default (depth 1), and force-pushing a shallow clone replaces the entire remote history with a single commit. I found this out the hard way.

--force-with-lease makes the push fail if something else landed on main in the meantime, rather than silently overwriting it.

Cleaning up the existing history

The workflow change stopped the bleeding, but there were still 142 commits in the log. I wanted to collapse each run of consecutive Last.fm commits into one.

git rebase -i is the usual tool for this, but editing 190 lines of a rebase todo by hand wasn’t appealing. I set GIT_SEQUENCE_EDITOR to a small Python script that rewrites the todo:

#!/usr/bin/env python3
import sys

todo_file = sys.argv[1]
with open(todo_file) as f:
    lines = f.readlines()

out = []
prev_was_lastfm = False
for line in lines:
    stripped = line.strip()
    if not stripped or stripped.startswith('#'):
        out.append(line)
        continue
    parts = stripped.split(' ', 2)
    action, sha = parts[0], parts[1]
    msg = parts[2] if len(parts) > 2 else ''
    is_update = msg == 'Update data'
    if is_update and prev_was_update:
        out.append(line.replace(action, 'fixup', 1))
    else:
        out.append(line)
    prev_was_update = is_update

with open(todo_file, 'w') as f:
    f.writelines(out)

It reads through the rebase todo in order. The first Update data commit in a consecutive run stays as pick. Every subsequent one becomes fixup, folding it into the previous commit and discarding its message. Any other commit breaks the run.

I ran it from just before the oldest Last.fm commit:

GIT_SEQUENCE_EDITOR="python3 /tmp/squash_lastfm.py" git rebase -i a1aaf39e

1091 commits became 969. 142 Last.fm commits became 20, one per cluster. Then a force push:

git push --force-with-lease

The log now looks like it should:

e35e061 Update data
b4c5fba limit the feed to 25 posts
fc050f2 also highlight the nav when viewing archive page
...
4fdfec4 Update data
adc03e8 Improve feed.xml

The hardware

The SNUNMU GK3 is one of those cheap Chinese mini-PCs from Amazon.

There’s no official website or support page for the SNUNMU GK3. The Amazon listing is about all you’ll find. That’s pretty typical for these no-name mini-PCs, but it does mean you’re on your own if anything goes wrong.

The Yottamaster FS5RU3 (£179) is a 5-bay USB 3.0 enclosure with solid aluminium construction, hot-swappable bays, and a fan that’s barely noticeable. I filled all five bays with old hard drives, 4TB x2, 2TB, 1TB, and 750GB.

It supports hardware RAID (0, 1, 3, 5, 10), but mismatched drive sizes make that awkward, and I don’t need the extra complexity. I’m running it in JBOD mode instead, roughly 11.75TB raw, each drive mounted individually over USB 3.0.

The software

I tried OMV initially and it felt limiting. The web interface is nice for basic storage management, but once I wanted Docker containers, or anything beyond simple file shares, I was fighting it to do things I could do in a terminal in seconds.

So I went with plain Debian. On top of that I’m running:

• CasaOS - a lightweight browser dashboard. It’s in maintenance mode now (the developers have moved to ZimaOS), but works fine on top of Debian. I’ve tweaked it a bit (app grouping, a sorted app store, some clutter removed).
• Jellyfin - media server for films, TV, music. Open source, no subscription nonsense.
• Portainer - web UI for managing Docker containers without dropping into the CLI every time.

Setting up the drives

CasaOS has its own auto-mounting, but it kept overriding my mount points and dumping drives into /DATA/USB_Storage1. I set up fstab entries by hand instead. All the drives are ext4. USB drives can end up as a different /dev/sdX after a reboot, so I used UUIDs.

sudo mkdir -p /mnt/media/{4tb-a,4tb-b,1tb,750g,2tb}

# /etc/fstab - Media disks (ext4)
UUID=3040769c-... /mnt/media/4tb-a  ext4 defaults,noatime 0  2
UUID=e909fd59-... /mnt/media/4tb-b  ext4 defaults,noatime 0  2
UUID=ac8bdcdc-... /mnt/media/2tb    ext4 defaults,noatime 0  2
UUID=76c68f31-... /mnt/media/1tb    ext4 defaults,noatime 0  2
UUID=815f72aa-... /mnt/media/750g   ext4 defaults,noatime 0  2

The fiddly bit was permissions. Jellyfin runs as its own user, so it can’t access files owned by my max user by default. I added it to my user group and set permissions:

sudo chown -R max:max /mnt/media
sudo chmod -R 775 /mnt/media
sudo usermod -aG max jellyfin
sudo systemctl restart jellyfin

For Samba, one share over /mnt/media covers everything. The physical layout doesn’t matter. I can browse smb://mothra/Media (mothra being the hostname, Kaiju-themed) from any machine on the network and see all the drives as subdirectories. Samba has its own password database, so I needed to add my user there too (sudo smbpasswd -a max).

[Media]
   path = /mnt/media
   browseable = yes
   read only = no
   guest ok = no
   valid users = max
   create mask = 0664
   directory mask = 0775
   force group = max

One issue that crept up after a few days was the drives disconnecting overnight due to USB power management putting the enclosure to sleep. I’d have to run mount -a each morning to get them back.

The fix is a udev rule targeting the Yottamaster’s USB controller by vendor and product ID (152d:0567), telling the kernel to leave power management alone:

sudo tee /etc/udev/rules.d/99-yottamaster-usb-power.rules >/dev/null <<'EOF'
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152d", ATTR{idProduct}=="0567", TEST=="power/control", ATTR{power/control}="on"
EOF

sudo udevadm control --reload
sudo udevadm trigger

To verify it took, check the power control state for each USB device:

for dev in /sys/bus/usb/devices/*/; do vendor=$(cat "$dev/idVendor" 2>/dev/null); product=$(cat "$dev/idProduct" 2>/dev/null); power=$(cat "$dev/power/control" 2>/dev/null); [ -n "$vendor" ] && echo "$vendor:$product $power"; done

The 152d:0567 entry should show on. If it still shows auto, replug the enclosure to force the rule to fire.

I’m organising by media type (films, series, music) rather than worrying about which physical drive things land on. I’ve got about 20 years of media to consolidate from various machines and old drives, so it’s a dump-and-sort job.

Working from anywhere

Back in 2022 I set up a Raspberry Pi as a local dev server to keep project files in one place. It worked, but the Pi was slow, storage-limited, and only ever doing one job. The NAS replaces it, same idea but with proper storage and room for Docker containers too.

The NAS is the machine; everything else is just a keyboard and screen. This post was written that way. I started drafting it at my desk, moved to the sofa, carried on from my laptop. Same files, same project, no copying or syncing. I’ve got lazygit on the server for staging and committing. VS Code’s Remote SSH forwards ports too, so Jekyll running in Docker appears as localhost:4000 on whatever machine I’m on.

The first dead drive

A couple of days after getting everything set up, I heard a loud persistent beeping from the room where the NAS lives. The Yottamaster enclosure has an alarm for drive failures, and it was not subtle. The 750GB had gone bad.

I shut down the machine, powered off the enclosure, ejected the dead drive, and booted back up. Debian dropped into recovery mode because fstab still had mount points for a drive that no longer existed. Logged in as root, commented out the 750GB entry in fstab, rebooted, and everything came back up fine.

The 750GB was a random pull from my drawer of old drives. Turns out I bought it in 2008, so no great loss. I’d already moved everything off it onto the newer 4TB drives and formatted it fresh, so nothing was lost.

I’m keeping this simple on purpose. No drive pooling, no RAID, no fancy backup setup. It’s a home NAS for media and project files, not a production server. If a drive dies, I lose whatever was on it, and for 20-year-old rips of films I already own, that’s a risk I can live with.

What it actually cost

The Yottamaster enclosure was the only thing I bought: £179. The mini-PC was already here doing nothing, the drives pulled from old machines and previous NAS attempts. Scraped together rather than purpose-built.

A Synology would have meant starting fresh, £400+ for a 4-bay, then drives on top, all tied to their OS and ecosystem. Instead, I got five bays, whatever OS I want, and full control for £179.

The vast majority of calls that trigger it aren’t real people. They’re robocalls and AI diallers, automated systems ringing numbers en masse hoping someone picks up. The calls aren’t really for me. They’re scanning for any human who’ll answer, and what they find instead is Google’s screener. It intercepts them, announces itself, asks who’s calling and why. What follows is two AI systems running through a scripted exchange while I sit there watching the transcript scroll past on my screen.

It’s oddly compelling. The caller’s AI will introduce itself (sometimes with a name, sometimes just a company) and try to pitch. Google’s screener follows its script, politely firm. The caller can’t adapt. Neither can the screener, really. They talk past each other for a few exchanges until one gives up or the call gets marked as spam.

The “press 9 to opt out” in the last two is good. The opt-out assumes a human who can comply. That branch never executes. The robocall was written for a world where a human picks up. No human did. The “Hello, how are you?” in the first clip is just the robocall trying to sound like a real person. Google’s screener doesn’t take the bait.

There’s something absurd about the whole thing. The call was never meant for a human to answer. My phone was never going to hand it off to me. The entire exchange plays out in a layer I never touch, two scripts running against each other, and I’m just an observer watching the transcript. Occasionally I’ll tap “block spam call”, which triggers Dobby to add a polite “please remove this number from your mailing and contact list” before hanging up. That’s the full extent of my involvement: a single button press.

How I transcribed these

The recordings are stereo: Google’s screener on the right channel, the caller on the left. The files are named dobby_audio_*, which is apparently Google’s internal codename for the Call Screen feature. Whisper handles the transcription. So: an AI transcribing two AIs talking to each other. It’s AIs all the way down. Every system in that chain is optimising an objective. None of them experience the exchange as anything. I’m the only one present for the joke.

A short Python script splits the channels, runs each through the model, then merges the segments back in timestamp order:

import wave, struct, whisper, tempfile, os

model = whisper.load_model("base")

def extract_channel(path, channel):
    with wave.open(path) as w:
        params = w.getparams()
        frames = w.readframes(w.getnframes())
    samples = struct.unpack(f"<{len(frames)//2}h", frames)
    mono = samples[channel::2]
    tmp = tempfile.NamedTemporaryFile(suffix=".mp3", delete=False)
    with wave.open(tmp.name, "w") as out:
        out.setnchannels(1)
        out.setsampwidth(params.sampwidth)
        out.setframerate(params.framerate)
        out.writeframes(struct.pack(f"<{len(mono)}h", *mono))
    return tmp.name

for path in sorted(os.listdir("recordings/")):
    left = extract_channel(path, 0)   # caller
    right = extract_channel(path, 1)  # Google

    segs = []
    for seg in whisper.transcribe(model, left)["segments"]:
        segs.append(("Caller", seg["start"], seg["text"].strip()))
    for seg in whisper.transcribe(model, right)["segments"]:
        segs.append(("Google", seg["start"], seg["text"].strip()))

    for speaker, _, text in sorted(segs, key=lambda x: x[1]):
        print(f"[{speaker}] {text}")

Call Screen works, but it’s quite locked down. The messaging the screener uses is fixed. There’s no way to adjust what it asks or how it phrases things. The voice is whatever Google decided on. It’s acting on my behalf, answering in my place, but the representation is entirely theirs to design. It’s a centralised proxy, built for a generalised user, standing in for me. I’d like to tweak it a bit (maybe make it sound less corporate, or change what it actually says to callers). It feels like it should be configurable, but it isn’t.

It’s a small gripe, and it still catches the AIs. I’m just entertained watching them at it. Dobby, quietly handling the world’s nonsense so I don’t have to.

Specs

Build and feel

These are chunky. They’re obviously inspired by (or a rebadged clone of) the Nyxi Hyperion, for about a third of the price, with a similar ergonomic grip that makes the Switch feel more like holding a proper controller. I’ve got big hands and the standard Joy-Cons always felt cramped, especially for longer sessions. The KS42s sorted that out - with them attached, the Switch is about the same size as a Steam Deck.

The left controller has a full-size d-pad rather than the four individual buttons on Nintendo’s Joy-Cons, which I prefer. Buttons feel soft but responsive. The Hall Effect sticks have a smooth range of motion and shouldn’t develop drift - they use magnets instead of physical contacts.

Each half has its own USB-C port for charging (they do not charge via the Switch). In the box there’s a bridging piece that clips the two halves together to form one (slightly wide) controller for wireless play. It also works with the original Joy-Cons and actually feels quite nice with them - a good option for player 2.

The vibration motors feel cheap. Instead of a continuous rumble, they do a noticeable burst of small vibrations. There’s a button on the back of each controller to adjust or disable it. There are two macro buttons on the back, reminiscent of the Steam Deck’s back paddles, but I’ve not found a use for them yet. The RGB LEDs have a few colour modes but I turned them off after about five minutes - they drain the battery and I couldn’t care less about RGB.

The controllers pair just like any other joycons. All the buttons map correctly, the gyro works, and holding the home button wakes the Switch from sleep. Slide them onto the rails and they’re recognised immediately (including the satisfying snap animation). The connecting edge is thicker than on first-party Joy-Cons, so there’s an abrupt step where the controller meets the Switch. Looks a bit odd given how thin the console is.

There’s no NFC, so no Amiibo support. They’ve got SL and SR buttons for split play, but holding a single controller sideways isn’t the most comfortable given how chunky they are. Fine for a quick round of something, not great for longer sessions.

Because of the grips, the Switch tilts back noticeably when set down on a surface or a lap. The standard Joy-Cons sit fairly flat, but with the KS42s attached the whole thing leans back at an angle. Not ideal for handheld propped against a cushion or a tray table.

One annoyance: accidentally knocking a controller while the Switch is off will wake it up, and it’ll sit there draining battery. They apparently auto-sleep after 5 minutes, but I’d rather they just stayed off.

For £18 they do the job. They’re comfortable, they work with Android without any fuss, and the build quality is fine for what they cost. I wanted functional joycons for a banned, last-gen Switch that I’m not about to spend serious money on, and that’s exactly what I got.