The CyberDeck hypetrain got to me. I succumbed to it. I never stood a chance.
For readers who don’t know what CyberDecks are, they’re custom-built computers in funky cases. I’ve seen people cram Raspberry Pis into small tin cans, oyster shells, and makeup palettes, and it’s just made me so, so happy. Here are some pictures:
My guess as to why CyberDecks have become so big recently is that people have gotten a little disillusioned with where technology is headed. Opaque metal boxes with not a lot of whimsy.
I think I found myself going down this path a bit too, even before my Pinterest got flooded with CyberDecks. I got myself an iPod and replaced its battery a month or so ago, and was looking up ways to fit a microcontroller into it. I’ve had a tiny camera project on the back burner for a bit now. I think I now appreciate writing that’s a little bad, or art that is a bit less polished, or shows more of the work that goes into it as part of the art; think junk journals, patchwork, and linocuts.
With the semester having ended, and two weeks at home, I FINALLY had the time to get to making a CyberDeck of my own! I’m changing up the format of how I do these posts too; I want these to be more a high-level description of my build. Technical details, instructions and schematics can be found on my Github. So if you’d prefer to just skip to that, go for it here!
Since I’m at home, I didn’t have access to lab equipment like multimeters, powertools, fancy soldering irons, and more.
I’ve gotten very used to just walking up to my lab manager and asking him for any possible electronics component I could ever want (thank you, Radd!). I haven’t utilised it as much as I should for my own projects; mostly club and class stuff. I did make a couple of cool bugs last semester though 🙂
I spent my last day on campus trying to build my camera out, but ran into GPIO conflicts. I have a solution to those now, which will follow in an upcoming post if I do finish the build.
A lab at school had an electronics giveaway this year where I actually mooched a bunch of stuff, including:
- An iPod
- A bunch of batteries (I only kept a few because I had to air travel)
- Buttons
- A REALLY nice pair of wire cutters
- A GPS module
In my personal collection, I had a FireBeetle ESP32 that I mooched from my research lab a semester ago, and a TFT screen Radd let me keep.
I couldn’t find a good replacement for a multimeter which made debugging an absolute horror, but I did come up with a pretty imprecise but good enough methodology. When using GPIOs, I would toggle them high, and then add an LED between a GPIO’s wire and GND to see if continuity was maintained. For 5V logic sensing, I did the same, but tried to see if my LED burnt out. So, my rule was:
- LED on: continuity, close to 3.3V
- LED off: no continuity
- LED burns out: continuity, close to 5V
Combining this with an ethernet cable my dad gave me for single-core wire (we cut open multiple wires till we found a single-core one!), and a soldering iron we keep around for home repairs, I had everything I needed for an initial version of this project. The wire I have isn’t quite right; it is a bit too rigid, causing it to snap in cases of medium to extreme wear, and its insulation melts off way too quickly. My soldering iron also doesn’t have temperature control and gets way too hot, causing the flux in my solder to blacken instantly. Soldering was an absolute nightmare for this reason, but hey, it got the job done. I do intend to resolder this once I’m back on campus.
I worked off of esp32_ILI9328_Pacman by Mhage, a Pacman port for the ESP32, itself based on Dr. NCX’s Pacman-Arduino-Due (whose original repo seems to be 404 now). I adapted the pin definitions for my board, replaced the ILI9328 driver with a custom ST7789 driver for my display, shrunk the pixels down to fit the different dimensions of my display, and added support for physical buttons.
On the software side, I changed the Pac-Man AI behaviour. The original codebase used a simpler proxy for the ghost AI, but in actual Pac-Man the ghosts, Blinky, Pinky, Inky and Clyde, have distinct targeting rules. Blinky targets Pac-Man’s current tile. Pinky targets the tile four spaces ahead of Pac-Man. Clyde targets Pac-Man when he is more than eight tiles away, but targets his scatter corner once he gets within eight tiles. Inky’s target is calculated using a vector: the game takes the tile two spaces in front of Pac-Man, forms a vector from Blinky’s position to that tile, doubles it, and uses the resulting endpoint as Inky’s target.
I also implemented the Pinky bug! In the original arcade code, the offset for Pinky’s target is stored as two 8-bit values packed into a 16-bit register: one byte for horizontal movement and one byte for vertical movement. When Pac-Man faces up, the intended offset is four tiles upward. However, the calculation is done using 16-bit arithmetic instead of treating the two bytes separately, so the carry from the vertical byte spills into the horizontal byte. This makes Pinky target four tiles up and four tiles left instead of just four tiles up. So SO cool!!!!
I wanted the whole thing to feel more arcade-style, with multiple games, so I added a home screen and a Flappy Bird option as well.
I used Claude to help write a lot of this code; does that defeat the purpose of making this? I want to believe it doesn’t, because I got out of this exactly what I hoped to: learning how TFTs work, setting up a portable power system, soldering things together, adapting code to very constrained hardware, and ending up with a cute little thingamabob. I hope that counts. But I digress!
As a reminder, the Github is here!
The Build Log 
Leave a comment