GammaOS Next 1.4 Dev Blog: one person, one summer, and a lot of bricked bootloaders

Let me tell you how I spent a Tuesday night in June. I was staring at a menu animation, a single category sliding sideways, playing it, pausing it, playing it again, because the way it settled into place was wrong by about twenty milliseconds and it was quietly driving me out of my mind. Not wrong in a way you would ever notice. Wrong in a way that only I would notice, at 3am, with the reference footage open in another window and my nose about four inches from the screen. I redid that half second of motion more times than I have eaten a proper sit-down meal this month, and when it finally landed, when the curve breathed exactly the way the original did, I sat back in my chair like a man who had just defused a bomb. It is a menu sliding sideways. I am aware of how that sounds. But that obsession is the entire job, and honestly it is the only reason any of this exists.

Because here is the whole thesis of GammaOS: it is not allowed to be "good enough." The Nano home is a recreation of the PlayStation 3 XMB, and I did not want a tribute band doing a wobbly pub cover of it. I wanted the actual song, in the actual key, down to the silk sheen rolling across the wave and the tiny curved corners on the clock frame that not one living human will ever consciously notice. I have spent this entire cycle head-down, obsessively polishing the details that matter most to me before letting a single build out the door, chasing something in the neighbourhood of perfection like a dog chasing a car it has no plan for catching.

Let me be honest about how that went, because I am not going to lie to you in my own blog post: it is not perfect. Perfect is a horizon. You walk toward it, you make good time, and it politely keeps the exact same distance the entire way. But it is polished now, genuinely polished, to the point where I can sit and look at it for a long stretch without my eye twitching, and for a man of my temperament that is basically a ticker-tape parade.

One more confession before we go any further, because it quietly explains every single thing in this post. GammaOS is not a team. There is no office, no QA department, no build farm, no rota of testers flashing nightlies while I sleep the sleep of the well-supported. It is one person. Me. I write the code, I flash the devices, I break the bootloaders, I sit there at 1am with a serial cable reading kernel source to find out why a handheld will not wake up, and then I am also the guy who has to un-break whatever I broke to find out. When 1.4 took a while, it took a while because there was exactly one pair of hands on it, and those hands kept stubbornly insisting on getting the twenty milliseconds right.

So here is the story of 1.4: what it actually is, everything that went wrong on the way, and why I think this pace, from a project of exactly one, is a little bit unhinged in the way I have made my peace with.

No, I have not abandoned your device

Before anything else, I need to talk to the people who are worried, because I know you are out there and I know the feeling is real. You look at your handheld, you notice it has not had a fresh build in a while, and your brain helpfully fills in the worst version of events: GammaOS grew up, moved to the city, and stopped returning your calls. I completely understand why it looks like that. It is also not what is happening, and I want to walk you through why, because the truth is the good ending.

Start with the simplest proof, the one you can check yourself right now: every commit I push is public. If you ever doubt that GammaOS is alive, do not take its pulse by counting release dates, take it by reading the commit history, and that history has not gone quiet for a single day. There are hundreds and hundreds of them since the spring. That is not the heartbeat of a project in hospice. That is a project that will not sit still long enough to be measured for a coffin.

Now the part that actually matters, and it is a bit of engineering genuinely worth understanding. GammaOS is not built the way most people assume. It is not a separate, hand-carved, bespoke firmware for every device that I have to raise individually like a very demanding houseplant. It is built as a GSI, a Generic System Image. The cleanest way to picture it: think of one engine that I have built to drop into a lot of very different cars. The engine, the gearbox, all the clever parts, that is shared and it is the same everywhere. Per car, the only thing that changes is the set of mounts and the wiring loom that bolts that shared engine to that specific chassis. Modern Android draws exactly that line, between the "system" half of the OS that is the same on every device and the "vendor" half that is the driver-and-hardware glue unique to each one. Almost all of GammaOS lives in the shared half. The XMB, Nano, the media players, the network shares, the thousands of fixes, all of it rides in one single image that runs across all these wildly different handhelds.

Here is why that quietly changes everything for you. It means the hard work gets done once, at the base level, and then it flows to every device that runs the image. When I fix a sleep bug, or build an entire media player, or make the menu faster, I am not doing it for one handheld and then bracing to do it eleven more times. I am doing it for all of them at once. A device that has not seen a build in a while is not abandoned, it is standing in line for the next base cycle, and when that lands it inherits everything I have built since, all in one go, as one enormous leap instead of a nervous trickle. The quiet stretches are not neglect. They are me pouring months of quality-of-life work into the shared foundation so that when your device's number comes up, the jump is huge enough to feel like a new device.

And that is a choice I make on purpose. I run long development cycles deliberately. I would far rather hand you a build that is a genuine step change, stuffed with the things that make GammaOS worth choosing over plain AOSP or LineageOS, the actual reasons to want this on your device instead of a version number I bumped so I could look busy, than dribble out cosmetic updates on a calendar like a subscription box nobody asked for. The porting and the maintenance that used to be painful and one-off is genuinely easier now, specifically because I have spent this time making it easier. It just has to be got right at the base level first, and then the devices follow it home. That base is where I have been living, and it has never been in better shape.

So if you take one single thing from this whole post, take this: GammaOS is more alive than it has ever been. Watch the commits. I am right there in them, most nights, arguing with a menu.

The scoreboard, and what "1.4" actually means

Let me get the raw numbers out of the way, because they reframe everything that follows. Since the 1.3.2 release in early May, GammaOS Next picked up 531 commits, roughly 353,000 lines of new code across 2,555 files, in about eleven weeks. The Nano engine on its own is now around 124,000 lines of C++ and GLES2. That is not a patch. That is a native console interface, a full set of media players, a Nintendo DS front end, a network filesystem stack, and an over-the-air updater, all written from scratch and all landing in a single summer.

"1.4" sounds like a point release, the kind of thing that fixes a typo and nudges a button three pixels left. It is a point release in the way that moving to a bigger house is a spot of light redecorating. Nano now boots your handheld straight into a frame-accurate PlayStation 3 XMB, with built-in music, video and photo players, a controller-friendly web browser, IPTV and internet radio, network shares that make your NAS pretend to be an SD card, custom wallpapers, a dual-screen control center for the RG DS, and DraStic-nano, an in-process DS player with RetroAchievements and Quick Resume that genuinely runs better than stock DraStic on the RG DS. Any one of those would have been a respectable release on its own. They all showed up together, from one person, in eleven weeks. Now let me tell you why it still felt slow from where I was sitting.

The build machine that kept pretending to die

Every byte of GammaOS is compiled on one box with 22GB of RAM. The Android source tree is enormous. The build output folder alone is 207GB. Compiling it on that machine is like trying to park a bus in a bathtub, and for a long stretch the bus kept stalling exactly halfway in, for no reason I could see, while making eye contact with me.

The culprit turned out to be the build system's own appetite. The part of Android that analyzes the build is written in Go, and on any change that forced a full re-analysis its memory use would climb toward 20GB on a 22GB machine and then enter a slow, dignified death spiral: burning one quarter of a single CPU core, writing nothing to disk, and looking for all the world like it had hung. It had not hung. It was quietly suffocating with excellent posture. One line capping the memory limit at 15GB, and the same build suddenly ran at nearly twelve cores and finished 48 times faster. Forty-eight. I had spent hours babysitting a terminal that was not frozen, it was just sad, and the fix was to stop it from eating until it fainted.

Then the build system taught me its party trick: the exit code lies. It once told me, with total confidence, that a build had succeeded when the linker had actually failed. That is the software equivalent of the friend who texts "omg I'm literally pulling up now" from their own sofa. That is exactly how you flash an image, break nothing but your own evening, and then spend an hour certain your code is wrong when your code was never in the image to begin with. So now I grep the build log for the word FAILED like it owes me money, and I check the size and the symbols of the actual artifact before it goes within a mile of a device. Trust nothing. Verify the bytes. This becomes a theme. It becomes the theme.

Debugging with the lights off

Here is the detail that shaped every single day of this release. Nano renders by seizing the display controller directly and painting the panel itself, going around Android's normal compositor, because that is how you get a locked 60fps menu on a handheld with no fan and a strong opinion about heat. The price of that trick is that all the usual ways to see what a device is doing come back black. A screenshot is black. The compositor sees a beautiful nothing. So a huge amount of 1.4 was debugged by dumping raw, uncompressed frames off the device and squinting at them by hand, like it is 1995 and I am developing film in a darkroom, except the film is a menu and the darkroom is my life.

It gets funnier. Nano exclusively grabs the input devices, so a drifting stick or a temperamental d-pad can never leak a ghost press into your game. Wonderful for you. Genuinely inconvenient for me, because it means I cannot inject fake button presses down a cable to test anything. To confirm a button does the right thing, I frequently have to physically pick up the actual device and press the actual button with my actual thumb. I have, in effect, built a QA department of one, and the department is issued exactly one tool, and the tool is a thumb. A frankly heroic quantity of this operating system was validated by a grown man sitting alone in a room narrating "okay, now I press right, now I press X" to an audience of nobody and one very patient houseplant.

Breaking bootloaders, on purpose and mostly by accident

You have asked me before how it is going, and the honest answer some weeks was simply "I bricked it again." Low-level boot work is where most of the invisible time goes, and it has no sense of humour and a perfect memory. Get a UI animation wrong and it looks a bit ugly. Get a bootloader wrong and the device becomes a very expensive fridge magnet until you can talk it back to life. There are two kinds of people who do this work: those who have bricked a device, and those who are about to.

My favourite self-inflicted wound this cycle was on the TrimUI Brick, a device that takes its name seriously. I wanted verbose boot logs, so I passed a nicely quoted debug flag through the bootloader, the way you would in any sane shell. Turns out the ancient bootloader on that platform does not respect quotes the way a shell does, so the semicolons inside my quoted value got read as "new command starts here," my boot arguments were confetti-shredded into a string of broken half-commands, and the device hung stone dead right after the co-processor firmware announced itself, with no handoff to the kernel and no further comment. No adb, no recovery, no nothing. The road back is properly old-school: power it off, boot a known-good SD card (the chip prefers SD over its internal storage, which is the single mercy in this whole affair), and once you are alive from the SD, hand-write the correct boot environment back onto the internal storage byte by byte with dd. I have done that dance enough times now that I could probably do it blindfolded, which is convenient, because the screen usually is blank anyway.

The deeper down you go, the more the hardware locks the doors behind you. On the RG Rotate the bootloader flat refuses an unsigned device tree overlay even with the bootloader unlocked, which is a bit like a bank vault that stays shut even after you have been handed the key. So to change anything at that layer I had to reverse the signing chain and re-sign the overlay myself, with the right 4096-bit key and the right salt and the right rollback index, then dd it into both boot slots. On the same device the kernel refuses to load any module it did not personally sign. That normally means game over, you cannot run your own module. Except the signing key happened to be sitting right there in the on-disk kernel source, unlocked, in the glovebox. So I built a custom kernel module, signed it with the kernel's own key, transplanted the exact symbol checksums into it byte for byte so the running kernel would nod it through, and loaded it live. That is not supposed to be possible on a signature-enforcing kernel. There is a very particular joy in a device grudgingly accepting a module you built because its own key quietly ratted it out.

One image, a dozen chips, all allergic to something different

GammaOS ships as a single system image that has to run across genuinely different silicon: Allwinner on the Brick, Rockchip on the RG DS and the Vita Pro, Unisoc on the RG Rotate and the RG Vita, MediaTek on the Pocket Air Mini, Qualcomm elsewhere. Every one of these is a toddler with a different allergy. A fix that makes one board sing will make another board show a black screen and refuse to explain itself, like a witness who has decided to lawyer up.

The showpiece this cycle was a streaming-app crash on Unisoc hardware. One symptom, apps dying during video playback, turned out to be four completely separate faults stacked on top of each other like a cursed layer cake nobody ordered. The Bluetooth controller was crash-looping every few seconds over a scan feature it fumbled. Picture-in-picture was aborting because of how Nano launches apps. The graphics driver was rejecting the video decoder's private buffer format and taking the whole app down as a hostage. And then Nano's own watchdog was cascading the entire mess to a black screen, because one wedged app blocked its cleanup. You fix one, you still crash, so your brain quietly informs you that you fixed nothing, so you start doubting the fix that was actually correct. Four bugs in a trench coat pretending to be one tall bug is a very specific psychological attack, and there is no colleague across the desk to turn to and ask "am I losing it here." It is just you, the layer cake, and a slowly forming eye twitch.

The RG Rotate would not wake up, and it took four kernel modules to talk it down

If I had to point at the single thing that ate the biggest crater into this cycle, it is the RG Rotate's slide sensor. This is the twist-screen handheld, and the little magnet that senses open versus closed is wired into the system as a button. When it was closed, it would wake itself up for no reason, like a smoke alarm at 4am. When you actually wanted it awake, it would refuse, like the same smoke alarm during an actual fire. The device and I were, for about a week, in a relationship, and it was not going well.

The first job was ruling out everything it was not, which cost several full flash cycles chasing ghosts through the device tree and the vendor blobs before I could prove the real problem lived up in the software, in how the sensor's repeated signals were being handled. Fixing the everyday case was the easy 20 percent. The other 80 percent was deep sleep. To wake the thing from true suspend on a twist, I had to move the sensor onto a part of the chip that stays powered while it sleeps, which then started catching a tiny electrical hiccup at the precise instant it tried to nod off, which kept it awake, which is the exact opposite of the goal. Fixing that meant reading the actual kernel driver source line by line, building a custom module that re-reads the settled signal and throws away the hiccup while letting a real twist through, and doing it so it can never, ever swallow a genuine wake, because a false wake is a mild annoyance and a lost wake is a dead brick in your pocket.

It went four rounds. Round one: sleep became flawless, but a twist would not wake it. Round two: still would not wake. Round three, after going back and actually reading how the chip hands control back on the way out of sleep, the twist finally yanked it out of deep sleep, and then the little traitor immediately fell back asleep 100 milliseconds later because nothing was holding it awake long enough for the software to catch the ball. Round four: hold the device awake across that exact window so the wake actually sticks the landing. That was the one. Deep-sleep twist-to-wake, working consistently, end to end, on a device I had been told would never manage it without a custom kernel. It did not need a custom kernel. It needed one signed module, four evenings, and for me to be marginally more stubborn than a magnet. I have gone twelve rounds with worse opponents. Never one that fit in a pocket.

Performance per watt is the whole game, and I refuse to cheat at it

I feel strongly about this one, and it is genuinely why some of the performance work took longer than it "should" have. On a handheld, raw speed is not the trophy. Performance per watt is the trophy. Frames per joule. A device that runs 10 percent faster and dies two hours sooner is not a faster handheld, it is a more exciting paperweight. So I keep a rule I will not break: I never force the CPU governor, I never pin clocks for a cheap frame-rate bump, and I never override a power or thermal setting that you chose. That policy belongs to you. Forcing the governor would have genuinely bought a few frames in places, I measured exactly how many, and then I deleted the code, because it was your battery I would have been quietly spending behind your back.

That means every performance win has to be earned honestly, from the render side or from the silicon itself. And on the silicon side the real surprise was that undervolting is the actual prize, not overclocking. On the RG Vita I pushed the CPU up and pulled the voltage down by around 37 millivolts across the board, and the result was roughly 18 percent more CPU throughput while the chip ran nearly 3 degrees cooler than stock. More work, less heat, at the same time: the closest thing to a free lunch physics allows, and since physics does not actually do free lunches, I checked the receipt twice. I also learned, the slow way, that the hardware has voltage ceilings the software will happily ignore. You can ask the GPU rail for more voltage all day long. It will nod, politely print your number back at you in the logs, and then do absolutely nothing, like a cat you have asked to get off the counter. Weeks of experiments to map exactly where those invisible walls sit, all so the shipped settings land safely on the sane side of them.

The battery win I am proudest of, though, was a drain bug, and it is a proper little detective story. A device was quietly losing about 35 percent of its charge overnight while it was supposedly fast asleep. The catch with these handhelds is that you cannot measure sleep drain while the thing is plugged into your computer, because being plugged in stops it ever really sleeping and reports the battery as charging, so the meter you would reach for is useless. The proof had to come sideways. I watched the clock that is meant to freeze during real sleep, and across a fifteen-minute unplugged screen-off test it kept ticking one to one with the wall clock. The device had not slept for a single second. It had been lying there wide awake in the dark all night, like a raccoon that has learned how your kitchen works. The culprit was a Bluetooth chip warm-up script that grabbed a kernel-level lock at boot and never let go, because that particular lock only releases when the Bluetooth stack is properly shut down, and if you never turned Bluetooth on, there is nothing to shut down. So it sat there, invisible, holding the whole chip awake all night with the radio switched off the entire time. One symptom, "bad battery in sleep," turned into a week of forensics with nobody to bounce it off, and the fix is worth more to your actual day than any headline in the changelog.

Making a NAS pretend to be an SD card

Network Shares was equal parts elegant and cruel, so it has earned its spot here too. The dream is lovely: point GammaOS at your SMB, NFS, WebDAV or FTP share and it shows up as ordinary storage, so your emulators and file browsers just open files by path and never suspect they are talking to a box in the other room. The catch is that these handheld kernels have no built-in support for any of those network filesystems, and I cannot swap the kernel. What they do have is FUSE, the same plumbing the SD card already rides on. So the whole thing speaks all four network protocols up in userspace and pipes the result back down through FUSE, one isolated process per share, so one NAS keeling over cannot take the rest down with it in solidarity.

A fun fact I paid for with a full day: the obvious library only speaks the ancient first version of SMB, a protocol so old it should be behind glass in a museum with a little card explaining what people used before they knew better, and which no NAS built this decade will accept. That whole path went in the bin and got rewritten against a modern one. Then a real server out in the wild exposed the bug that actually mattered. My "helpful" read-ahead was, it turned out, hauling entire files across the network just to read the little tag at the front of each one, which turned scanning a 35-track album into 133 megabytes and nearly four minutes, with most of the transfers giving up in disgust halfway. Watching a real server get quietly pummelled by my own code is the single most effective code review money cannot buy. It is adaptive now, dramatically leaner, and it survives a router reboot mid-copy without needing a little reboot of its own to recover its feelings. At some point I made a deliberate call that a known-slow-but-unshakeable path beats a fast one that might occasionally wedge, because a predictable wait you can plan your day around is fine, and a frozen filesystem on the device you are actively using is a bad afternoon. Slow and honest is a shippable state. I said that out loud, to the houseplant, and shipped it.

What actually came out the other side

With all of that as the backdrop, here is what shipped anyway, and I still have to remind myself it was one summer and one person:

• A frame-accurate recreation of the PlayStation 3 XMB as the Nano home, translated from the real math and curves rather than eyeballed into a lookalike, right down to glass icons that refract the live wave behind them, an analog clock drawn in three passes, and a firmware-accurate field of glitter you will feel more than notice.

• Full built-in players for music, video and photos, plus a controller-first web browser, internet radio and live IPTV, none of which need a separate app installed to exist.

• DraStic-nano, an in-process Nintendo DS player that runs more efficiently on the RG DS than stock DraStic, with RetroAchievements, Quick Resume, an in-game cheats page and picture-in-picture.

• The RG DS dual-screen Control Center, custom still and video wallpapers, the PSP Go slide clock, network shares, a user-configurable swap file, and a genuinely large pile of boot-speed, memory, sleep and wake fixes holding the whole thing up from underneath.

That is only the highlight reel. The full changelog is long. Absurdly long. So long that reading the whole thing back, I became mildly concerned about my own wellbeing. If you want the complete, exhaustive, itemised, possibly-unreasonable list of everything that changed, it is all written up here: https://github.com/TheGammaSqueeze/GammaOSNext/wiki/GammaOS-Next-Changelog#v14-july-2026 . Bring a snack.

Thank you, and a little perspective

I owe you an apology for the wait and, much more than that, a sincere thank you for your patience, which frankly showed more restraint than mine. Every person who kept a GammaOS device on the shelf through a quiet spring, everyone who held off asking "when," everyone on Patreon keeping the lights on and the one overworked build machine in snacks: this release exists because you did not give up on it. I get the fun part, which is building the thing. Your part, waiting on faith while one person vanishes into kernel source for weeks to argue with a magnet, is honestly the harder shift.

I will leave you with the perspective I have to keep repeating to myself on the nights it feels slow. This is one person building a console-grade experience for a dozen very different devices at once, debugging half of it through raw pixel dumps because the screen point-blank refuses to be screenshotted, un-bricking bootloaders by hand, and signing custom kernel modules against kernels specifically designed to refuse them, all on a machine that occasionally tries to faint from exhaustion mid-thought. Progress at this pace, from a project of one, is not normal. It is a little bit extraordinary, and it only keeps happening because you keep showing up for it, and because I apparently cannot leave a twenty-millisecond animation alone.

1.4 is here and will be dropping for devices shortly. Go and break it when it comes, and then tell me exactly how, because right now I am the only one who can, and I would genuinely love the company. On to the next one. Another one.

TheGammaSqueeze