The Box: How Pisces Moon OS Got Started
A box arrived from Shenzhen on a Tuesday in late March. Inside was a LilyGO T-Deck Plus — $96, from AliExpress, two weeks in transit. ESP32-S3 dual-core. 8MB PSRAM. WiFi, Bluetooth LE, LoRa long-range radio, GPS. A 320×240 IPS color touchscreen. Most importantly: a physical QWERTY keyboard with backlit keys, and a trackball that clicked when you pressed it.
I plugged it in. It booted to a default firmware that did a few isolated demos. WiFi scanner. LoRa ping test. GPS readout. Each demo was its own thing. Press a button, see a thing. Done.
I closed the demo and stared at the device.
It looked exactly like a BlackBerry. A little chubbier. The trackball where the BlackBerry had its own. The keyboard layout was the same. The screen was a little smaller. If you squinted, it could have been a Palm Pilot from 2003 — same general silhouette, same handheld pocket-computer instinct in the design.
Everyone in the maker community who bought one of these — and there are thousands — looked at it and saw a field tool. A wardriving gadget. A mesh radio terminal. A security toy. The community built single-function firmware projects for it, each one impressive in its narrow domain. Bruce. Meshtastic. Tactility. Each project did one thing, did it well, and called it a day.
I looked at the same device and could not stop seeing the BlackBerry.
The Question
What if you put a real OS on this thing?
Not a single-purpose firmware. An actual operating system. With a launcher. With apps. With multitasking. The way a BlackBerry had email and a calendar and a browser and games, all running on a device with way less computing power than this $50 microcontroller from 2024.
The hardware was already there. Two cores at 240MHz. 8MB of PSRAM. Hardware crypto. A working filesystem on the SD card. Wireless radios in three different bands. The device had everything a Palm Pilot had in 2003, plus things a Palm Pilot would have killed for — wireless internet, GPS, encrypted storage, dual-core processing.
Why was nobody treating it like a pocket computer?
I think the answer is that the maker community had been culturally trained to see microcontrollers as single-purpose devices. You build a thing that does one thing. You don't build an OS, because microcontrollers don't run operating systems — that's what Linux is for, and Linux runs on Raspberry Pis.
Except this microcontroller, the ESP32-S3, has more capability than most computers from the year 2010. The cultural assumption that microcontrollers are single-purpose was about ten years out of date. Nobody had updated it because nobody had needed to update it. The available firmware projects matched the available cultural template — single function, focused implementation, narrow scope.
The hardware was waiting for someone to ask a different question.
The Insight
Once I framed the device as a BlackBerry instead of a security tool, every architectural decision flipped.
A BlackBerry runs apps. Not one app — many apps. You launch them from a launcher. They have icons. They share a filesystem. They have settings. The OS handles input routing, screen rendering, and persistent state.
A BlackBerry does things in the background. Email syncs while you read calendar entries. The radio listens for incoming messages while you write a note. The system clock keeps time while you play Brick Breaker. Background tasks were not optional in the BlackBerry era — they were the entire point of having a smartphone instead of a feature phone.
A BlackBerry has security. The Ghost Partition concept came from thinking about what a 2026 BlackBerry would do — not encrypt files (which was the 2003 answer), but architecturally hide that there were any files to encrypt (which is the 2026 answer when you assume your adversary has access to the hardware).
Every feature I built into Pisces Moon OS came from asking: "What would a BlackBerry from now do, if BlackBerry had survived and been built by people who took adversarial threat models seriously?"
The Ghost Engine — wardriving running on Core 0 in the background while the operator does anything else on Core 1 — is the BlackBerry email-sync answer applied to RF intelligence. It runs because that is what background tasks are for. The user is not interrupted because that is what good operating systems do.
The 47 applications across 7 categories — each launching from a categorized grid, each persisting state, each working with the others — is the BlackBerry app drawer applied to a security-research handheld.
The trackball-and-keyboard input model — where the trackball navigates the launcher and the keyboard types in apps — is exactly the BlackBerry input model. The hardware was already laid out this way. The default firmware just wasn't using it.
What Got Built
Once I started actually building, I hit problems that did not exist in any documentation. The MicroSD card and the LoRa radio share the SPI bus on this hardware. When the Ghost Engine writes wardrive data to the SD card and the LoRa radio fires at the same time, the device crashes. Not occasionally. Reliably, but with non-deterministic timing — the crash address changes every time, making it look like memory corruption or random bugs.
This had no documented solution because no previous ESP32-S3 project ran the SD card and the LoRa radio under sustained simultaneous load. Every previous project did one thing. The conflict was invisible until you needed both at once.
The solution turned out to be a formal protocol. Not a patch. A protocol — four rules every component in the OS must obey. Hit and run on bus access. No extended holds. Radio traffic flag. Metadata-only destructive operations. I ended up calling it the SPI Bus Treaty because that's what it is — a behavioral contract between competing subsystems sharing a hardware resource.
The historical precedent was right there once I named it. Unix filesystem locking conventions in the 1970s. The Apollo Guidance Computer's priority scheduler in 1969. Nintendo's N64 RSP time budget in 1996. In each case, the answer to "competing subsystems sharing a critical hardware resource" was not a clever patch — it was a named protocol that everyone agreed to follow. The SPI Bus Treaty is the same kind of solution applied to ESP32-S3 hardware. It's now the first documented instance of this solution class for this platform.
That's one of six engineering problems I had to solve to build the OS. None of them existed in prior documentation. None of them had been encountered by previous projects because no previous project had been complex enough to trigger them.
The Reframe
Looking back at the box on the table, the thing that should bother every maker who bought one of these and built single-function firmware on it is not that they didn't think of the SPI Bus Treaty. The Treaty came from the engineering — it solved a problem that only emerged because of the architecture choice. You would not invent the Treaty without first deciding to build the OS that needs it.
What should bother them is that they all looked at the same hardware and didn't think "this is a BlackBerry."
The reframe was free. It cost zero dollars and took five minutes of staring at the device. The device was already a pocket computer with a keyboard, a screen, a trackball, three radios, GPS, and 8MB of RAM. Treating it like a single-purpose tool was a choice — and once you made that choice, every subsequent architectural decision was constrained by it. No multitasking. No app launcher. No background tasks. No platform.
The whole maker community made that choice without knowing they were making it. The cultural template was so strong that nobody questioned it.
I questioned it on a Tuesday in late March, because a BlackBerry sat on my desk in a box from Shenzhen and I refused to pretend I was looking at something else.
What's Next
Pisces Moon OS shipped v1.0.0 "The Arsenal" on April 16, 2026 — six weeks after the box arrived. v1.0.1 followed two weeks later with the SPI Bus Treaty refinements and a few bug fixes. Both are public on GitHub under AGPL-3.0. The full source compiles with PlatformIO. The white paper documents the architecture. The Defcon 34 talk submission is in.
The platform now extends to five deployment targets — T-Deck Plus, Pisces Moon Linux on obsolete x86/ARM hardware, Android APK, Luckfox Pico 86 Panel, M5Stack Cardputer. The original box from Shenzhen turned out to be the proof of concept for something much bigger than the device itself.
The total cost of building all of this from scratch was $144 — $96 for the device, $8 for an SD card, $40 in cloud AI to help debug the harder problems. Six weeks. One person. The receipt is on the internet.
The Ghost Engine never stops. The SPI Bus Treaty is why. The receipt is $144.
The box is still on my desk.
Eric Becker / Fluid Fortune The Court Jester of Vibe Coding fluidfortune.com