In the months leading up to Fab Academy, words from one of my first meetings with my mentor Jorge at ESAN kept playing back in my head. He said to me that the best way to be successful in the course is to have a final project idea for the first week of classes. This tormented me for weeks, I had such a hard time coming to terms with the commitment. I quite literally had dozens of projects and things I wanted to explore, how could I pick just one?

What I'm sharing with you today ultimately comes back to the object that got me into tech in the first place: an original purple Game Boy Advance, my first personal device. I've always been fascinated by consumer electronics and the design language of the big names in the industry: Braun, Nintendo, Sony, Teenage Engineering.

I'm also drawn to the aesthetics of the early 2000s (having a strong sense of nostalgia for that world), and would be interested in designing devices that call upon the "blobject" and "frutiger aero" design language of this idyllic world that we have all left behind for less green pastures.

I've tried creating my own very simple 3D-printed electronics enclosures and have created simple circuits by repurposing existing logic boards and utilizing commercial boards, but the Fab Academy is going to give me an opportunity to push this understanding and learn more.

I also wanted to center my project around a problem, as any good designer does. Look for a problem, not a solution. As a high school teacher, I am no stranger to the impact that cell phones have had on attention spans, focus, and our abilities to be comfortable being bored. Using the internet and a cellphone is a near requirement for participation in society these days, and the creators of these devices and the software that powers them do not have our wellbeing in mind when their design prioritizes increasing engagement and data collection above all else.

Enter, my final project idea:

FINAL PROJECT IDEA, JANUARY 2026

This is a handheld device meant to replace your smartphone but still give you access to important features needed for modern life. The catch is that each of the features exists on it's own dedicated cartridge, much like a single game can only occupy one Game Boy Advance cartridge. Swapping "apps" is a deliberate action the user must take. The intended user is someone who wishes to "unplug" from the modern world of electronics and return to a time that humans used technology with intention, not compulsion.

Your first impression may be that this sounds overly ambitious, and I agree. But the development of the device and the added cartridges are meant to be spiralled into bits and pieces that be developed independently, and I can have a minimum viable product with many stretch goals. My primary goal with this device is to create a simple handheld computer that I have created the enclosure, custom PCB and software for, with one cartridge that runs a simple program.

Towards the end of my sketching, I started playing with the idea of a third design language that I've been interested in, and one that ultimately was the inspiration for the stylesheet for this website.

There are not a lot of words to describe this aesthetic. I tend to default to the Consumer Aesthetics Research Institute (CARI) when it comes to vocab. The site describes this look as: Vectorheart, characterized by "futuristic forms" and "high-contrast typography that borrows from both Swiss modernism and utilitarian industrial design".

I had an idea to run my sketches through Gemini's Nano Banana image generator to see what it could create.

and for fun, I asked it to try out the same render in clear plastic, a la Y2K.

I knew that for my first iteration of my device (which is still unnamed) I would want to start with a simple enclosure, without trying to over-complicate things to start. I knew roughly that I wanted the device to fit nicely in a pocket, and comfortably in one hand (hence why all of the controls are on one side). The user is meant to hold the device like a point and shoot camera, not a game console (despite the appearance haha).

1

2

3

SLIDESHOW ⇲

I started out with a simple rectangular shell (dimensions can be found above), and carved out the space for the screen. I added a simple chamfer to the edges of the device and a bevel to the screen.

1

2

3

4

SLIDESHOW ⇲

Using additional sketches on top of the top face of the main body, I started playing with shapes for the buttons and added electronics. Since I don't know what my final design will incorporate, I just used dimensions that felt right for placeholders. The beauty of parametric design is that I can easily come back and edit the numbers to fit different parts.

Since I also needed to revisit what the final cartridge design would be later, I decided to just import the Game Boy cartridge I modelled earlier as a placeholder. I intend to iterate on the design of the cartridge and make it something that better fits the aesthetic, form and function of the device. I was telling my mentor, Jorge, that I think one of the most important parts of the cartridge and device is getting the tolerance spot on for that perfect insertion feel.

1

2

SLIDESHOW ⇲

Once I had a good starting place with the shell, I decided to try adding some surface motifs, like small vent holes, detailing lines, additional fillets to the corners for comfort. All things I want to iterate with once I'm able to start 3D printing prototypes.

I even went so far as creating placeholder internal components, like PCBs, a LiPo battery and screen. Obviously all TBD, but it allowed me to render out this terrific expanded view, and the animation that can be see as the (header for week 02)[./assignments/week02.html].

This was also a great opportunity to create some "promotional" material using my Illustrator skills. I created this image using some of the vector motifs I designed - which, unfortunately does not stand the test of my photo compression script. Perhaps I can use some kind of hybrid .svg and raster format for presenting my work. I would like to preserve that super clean minimalist high-contrast look.

I wanted to take the opportunity this week to explore my options for the PAK's architecture. After doing a bit of reading and testing, I determined that the RP2350 would be the best fit for the PAK's main driver.

My main focus this week was to become a bit more familiar with developing for the RP2350 and slowly start to develop the actual development process for creating future PAK cartridges on the chip. I decided that, in place of a traditional app launcher (reminder that the PAK has no built in apps), I wanted a little character to be shown on the screen, and it could react to the user's inputs, animating when the user presses buttons or even inserts a PAK into the system!

Since I didn't have the full screen I wanted to use yet, I figured I would start develop a placeholder, or at least something that I could scale up to other device sizes.

This week I wanted to start actually fleshing out the design and shape of both the PAK itself and the cartridges that would interface with it. After some earlier thinking, I decided that the best interface for the cartridges to the main unit would be through the use of spring loaded POGO pins, so I placed an order at the end of last week for a pack of 100. In the meantime, I could start thinking about how they would interface with the plastics. This would be design consideration #1.

1

2

SLIDESHOW ⇲

Luckily - I have all the dimensions to work with from the product page.

I could at the very least create a placeholder for the pins to be placed - and even update these values parametrically if needed later on.

Design consideration #2 would be to determine how I want the cartridges themselves to interface with the unit. I could opt for a friction fit akin to the Game Boy or home consoles like the SNES or N64, or I could opt for a push-push latch mechanism that feels a bit more luxurious and secure akin to a microSD card or Nintendo DS/3DS cartridge.

I found this 3D printable spring push-push mechanism on Makerworld that I thought would be a good start. It utilizes a heart shaped track/cam that allows a pin to travel in one direction around the path, preventing the spring from debouncing once pressed in.

The spring mechanism is one thing but I would also need to envision away to "latch" the cartridge in place. There's a great video by Engineezy that shows how the mechanism for microSD cards works that I took inspiration from.

After some failed prints and further frustration with trying to wrap my head around how this mechanism would work, I attended the Global Open Time on Saturday and Saheen recommended to me a part I could order that would make my life much easier rather than trying to 3D print micro compliant mechanisms.

IMAGE CAPTION ⇲

This is a push-push mechanism that is commonly found in cabinetry and enclosures like garbage cans. I placed an order for about a dozen and got to work incorporating it into my CAD file

IMG_FILE: Pasted image 20260223090551.jpg

TYPE: JPG

XYZ: 123

Design consideration #3 was to engineer a way that restricts the user from inserting the cartridge the wrong way (and thus shorting or messing with the pogo pin wiring). To do this I would take a page out of Nintendo's book with their Game Boy cartridge design. It has a chamfer on two edges of the same face that is complimented by a guiding "rail" inside the slot. Try to put it in the other way and you'll find the cartridge doesn't fit.

1

2

3

4

SLIDESHOW ⇲

The idea is that the cartridge contains the "male" parts of the mechanism and it interfaces with the "female" part of the mechanism in the main body.

Gave myself some time to be a bit creative here and envision different looks for the cartridge too. ./images/cartridgetests1and2.png

Here's the design I used for v2. I extruded the bottom part of the bottom half of the cartridge and subtracted it from the top half - and then added a chamfer to each so that there would be a little bit of empty space. Much better!

Here's the small detail that makes sure the user only slots the cartridge in one way (to avoid the POGO pins from being wired incorrectly) - there's a small chamfer on the cartridge and complimentary guide rail in the slot that only works if you slot it in the correct orientation.

This was a great start to developing the actual shell to the device. I finally have one constraint to work around (although, the cartridge itself could still change sizes), so I can at least start with dimensioning out a PCB for the cartridge and perhaps the main unit next week and then continue iterating on the full shape of the case. I will say that I think the final unit itself needs to be fabricated with something a bit more fancy that PLA or ABS. I did like the way the resin print came out, so it's something to consider, but at least I have a good tool for rapid prototyping.

A key design decision made this week was the implementation of a dual-protocol bus for the cartridge, instead of picking either SPI or I2C, I chose to develop a system that could accommodate both as a future proofing method. The W25Q16 Flash IC that will store each cartridges software will communicate with the PAK via SPI (Clock, MOSI, MISO, CS) using a 7-pin configuration. I also chose to include an integrated I2C (SDA, SCL) line on pins 8 and 9 to allow for future "Hardware Apps." Once I've created the first simple cartridge (likely the Pomodoro app), I want to develop cartridges with more I/O functionality that isn't present on the main board. A single cartridge could house a camera module, a DAC for high-fidelity audio, or environmental sensors, all sharing the same two I2C pins.

The PAK will also feature a D-PAD and 4 face buttons (A, B, START, and a fourth button I'm calling the "P" button for now). I want to be able to open the possibility to low latency gaming on the device, so I didn't want to pick a communication between the buttons and the microprocessor that would introduce any extra processing time, so I'm taking a page out of Nintendo's books and using an old school shift register (shown in the bottom right of my drawn schematic).

1

2

3

SLIDESHOW ⇲

Hand drawn schematic

Translated into KiCAD schematic

and translated into the PCB editor!

As I've explored in previous weeks, I'm exploring the use of Pogo Pins as the interface for the PAK, which means each cartridge would need a complimentary set of pads to connect with. Using the KiCAD Footprint Editor, I designed a custom 9-pin staggered layout in KiCAD's Footprint Editor.

1

2

SLIDESHOW ⇲

Creating a custom sized pad in the Footprint Editor

The staggered row layout - like a VGA port.

Under the guidance of my mentor, Jorge, I opted to design a two-layer board rather than a simpler single-sided milled board. This was specifically chosen to increase the technical challenge and improve the device's performance. The entire bottom layer is a dedicated GND plane. This provides the shortest possible return path for high-speed signals, significantly reducing the electromagnetic noise generated by the display and flash memory clocks. Implementing this required the use of vias (small holes connecting the front and back layers).

The goal this week was to create a "development board", not something that I can easily slide into the PAK's case right away. Just something that will help me quickly test and prototype the software and electrical connections. The board is using the XIAO, which is technically a daughterboard. I would like to eventually create this board with my own power regulation and and a baremetal RP2350, but I'm going with the XIAO for convenience for now as I continue to learn. The next version will also need precise M2.5 or M3 screw holes for mounting inside the 3D-printed case. The buttons and screen are currently placed for routing ease and debugging, and as
I mentioned in the weekly documentation, D-PADs aren't typically done with push buttons, but this is something to iterate on in the future once we have full access to the PCB milling machine!

If you read the full article from this week, you'll know that I had a tough ride, but I did manage to prototype and test more aspects of the PAK this week.

My goal for this week was to develop a circuit board for a PAK "dev kit", that is, a less "put together" version of the PAK that I can focus entirely on development with, rather than aesthetics. I wasn't able to mill the board out in a functional state, but I was at least able to test layout and practice my PCB design skills more.

After what I learned this week, I'll be redesigning the dev kit for a single side board, with more surface mounted components wherever possible.

The thing I did get closer to figuring out though was the cartridge mechanism, including the interface for where the pogo pins on the dev kit/main machine will slide into the cartridge.

1

2

3

4

SLIDESHOW ⇲

and coupled with the push push mechanisms that my wife brought with her last week when she came to visit me, I was able to get the first functional prototype of the cartridge interface, with this SUPER satisfying click!

I really wanted this week to be the turning point for the PAK, where I start developing my Fab Academy assignments in the actual PAK architecture. The goal for the start of this week was to create a working prototype of the cartridge and slot mechanism, and then just run all of the Input Devices (and similarly: next week's output devices) through some breakout pins that I could clean up later.

That was the plan of course.

1

2

SLIDESHOW ⇲

The many tests of the slot mechanism

The many iterations of the cartrdige itself and it's embedded PCB meant to interface with the slot via pogo pins

As you can read in this week's assignment page, I managed to get a working prototype but it only cost me my sanity and a little bit of burnout.

1

2

3

SLIDESHOW ⇲

Inserted

Not inserted

and the idea - which actually worked (required a bit of a bodge in the form of a binder clip to keep the pressure held on the pins) but it taught me that this is not the way I want to move forward here...

The pogo pins are a neat thing to incorporate. My original plan was to have them run parallel to the push-push latches, but they simply do not have enough spring distance to match the latch spring. It would have also been harder to create two PCBs that would have run perpendicular to the main components inside of both the main device and the cartridge. So I tried running the pins perpendicular to the direction the cart would travel. My thinking was that the pogo pins would be supported by a 3D printed bracket, and I would position them at the right height to juuuuust miss rubbing against the plastic and introducing the lateral motion that would sheer any soldering job. I managed to get it working in principle, but it was delicate. It was not the kind of sturdy I would want for a final polished project.

So I'm making the decision here to abandon the pogo pins and switch to a more typical edge connector solution. I still really want to use the push-push mechanisms because the click is super satisfying, so I'll need to figure out a way to reduce the friction on the receiving end while still having enough tension to make contact with the cartridge pin pads.

The PAK has two main output devices that are built into the main unit: the 3.5" TFT display and an RGB indicator LED that communicates the current state of the device to the user. My goal for this week was to try integrating more of the output device-based cartridges I had in mind for the final device directly into the cartridge prototype, but if you've read the progress I made in Week 9 (just above) on this, you'll know that I had a lot of trouble getting the cartridge PCB to play nice with the Pogo pins and I spent the next few weeks researching and determining an alternative plan for the pins. That left prototyping to be relatively simple for this week, and was really just an excuse to get the 3.5" screen up breathing for the first time. You can read about all of the bits and pieces on the page for Week 10.

TFT SCREEN

I managed to get the screen powered on through SPI and ran some stress tests to see what data load it could handle.

INDICATOR LEDs

You can again, read more about the process of creating the light pipe tests on the assignment page for this week. The idea of the light pipe is to funnel the light out to the edge of the case and diffuse it so it appears more attractive and easier on the eyes!

The first step to getting the DEV KIT assembled was getting the motherboard, where all of the other companion boards and components would link up to, designed and milled. So I used what I learned from my existing schematics and pieced together a MUCH better wiring.

1

2

3

4

SLIDESHOW ⇲

I think the number one thing I learned is to LOOK AHEAD at your pinouts so you're not stuck placing a million 0 ohm resistors trying to bridge a connection that could have easily been avoided if you just chose closer pins

This layout was SO much easier to work with - broke out the remaining pins on to pinheaders for easy access

And getting much better at soldering these kinds of things! Used a bit of reflow to help me with the ESP

and even printed a little case to protect my hard work!

Breaking up the DEV KIT into several boards means I can test all of the individual components without having to worry about the whole thing breaking. One by one I was able to test:

THE SCREEN

THE FLASH MEMORY CHIP

THE RGB LED

and then I was able to design and mill out a secondary board that would have the shift register and buttons on it. Here you'll see a custom footprint I designed to test out membrane style buttons, which I plan on creating in the molding and casting week.

1

2

3

SLIDESHOW ⇲

Which brings us to our first fully functional prototype of the PAK. Everything is here! Even if it looks like a bowl of spaghetti, we're officially through our first spiral of development!

I knew that I wanted a more premium feel for the PAK, and to avoid just simple tactile buttons for the finished product. A lot of consumer electronics that I am modelling the PAK after utilize silicone/rubber membrane pads with conductive carbon pills to bridge the connection between two pads. The silicone/rubber acts like a spring that decompresses the plastic button on top after each press. Normally these molds are made with a specific kind of rubber that best handles the wear and tear and desired feedback, so I knew I would need to iterate and try out lots of different ideas if I wanted to use the silicone product we have in house. I found some great sites with lots of information that lead me to testing a few different kinds of button profiles.

1

2

SLIDESHOW ⇲

Credits to Better Silicone (linked above) for these profiles - which I loaded into Fusion and directly traced

The traced profiles in Fusion

I talk in depth about the process of how to create these buttons over on the assignment page for Week 14 if you'd like to read more about the process. For the next iterations, I actually decided to go with a 3D printed mold (with the lowest possible layer height) as I found the surface finish to be indistinguishable from the milled molds and it was exponentially faster.

The next step was to try out some D-PAD designs, which require a little post/rocker in the middle to prevent multiple directions from being pressed at once.

1

2

3

SLIDESHOW ⇲

The process is the same as before - create your negatives in the mold - this can then be milled or printed

Here's the full block that I milled in wax AND printed to test different results

Milled block of wax - use the vaccuum to get all of the reusable wax!

I also found these cheap insertable conductive carbon pills I could add or glue into the moulds.

1

2

SLIDESHOW ⇲

A bag of ~100 for ~$10 - a good investment

They are a little large for the DPAD buttons - but I can just trim them with some scissors

After some initial tests, I was ready to cast the actual silicone rubber. I 3D printed the mold instead of wax milling it because I actually had better success.

1

2

SLIDESHOW ⇲

The big difference to note is that you need to print these molds on the highest resolution possible - which in my case is 0.08mm layer height.

and here's the result! I made a few different kinds with different wall thicknesses to test the springiness and responsiveness.

It was time to start developing the foundation to continue building apps/cartridges for the PAK. In Week 15, I dive deep into the choices I made to create the development stack for the PAK, including the many different scripts that are layered and run concurrently on the ESP32. You can read the full dive on the assignment page for this week..

This week, I created two test applications using the above dev stack, the Pomodoro Timer v2 and a Weather Application.

After having the Spiral 2 Dev Kit break on me pretty much immediately after getting into a completed state, I knew it was time to get the final boards (or at least the next iteration) shipped off to a board house so I could stop worrying about being too rough with the system.

1

2

3

SLIDESHOW ⇲

The motherboard schematic is quite complex - but here I'm using net classes to avoid a spaghetti plate of crossing wires

The resulting PCB - I opted to add some chamfers to the corners for aesthetics and to save some space

I also took the opportunity to include some silkscreened easter eggs since this board would have a proper silk screen and solder mask layer - I did this by using KiCAD's built in Image Converter

1

2

3

4

SLIDESHOW ⇲

The schematic for the control board is a lot simplier

I create these custom footprints for the membrane buttons - just out of trapezoids - modelled after some other designs I saw on Google Images

Getting the layout required deciding on a final placement for the buttons and then carrying over those positions to the case design

The resulting board

and here's what they looked like upon arrival and assembly!

1

2

3

SLIDESHOW ⇲

Controls board backside

Controls board frontside

and the main motherboard!

Now that things were starting to come together for the board and I had committed to a placement of the buttons, I figured I would start casting and testing more button designs to get closer to the final iteration. I modelled the D-PAD after a Wii Remote design but altered some of the measurements to have it better fit my board.

1

2

3

4

SLIDESHOW ⇲

It's nice to have an actual DPAD design finally!

Placing the buttons and DPAD into a draft layout - I wanted a staggered button layout like a Game Boy

Adding the measurements taken from the PCB ordered earlier

And loading it in to the model to see if everything fits nicely and my screw holes line up (spoiler: they did not)

I cast the buttons for the PAK out of plastic using silicone molds which were cast from 3D prints.

1

2

3

4

SLIDESHOW ⇲

The top half slots into the bottom half of the mold with cylindrical keys for alignment

The silicone molds to cast with

The resulting buttons! The detail on the lettering came out great!

and then plugging them into the actual case with the membrane backing going on top.

The case of the PAK, believe it or not, is actually the lowest prority design item. I made all of my system integration decisions above based on the fact that I can rapid iterate on cases, so if something doesn't fit, I can just move things around in CAD and reprint. The top priority were the PCBs, which take the most time (even if I was doing those 2 in house). My process for developing the case for the PAK is better described in depth on the assignment page for Week 16.

However, I spent a crazy long amount of time iterating on the case design. Printing 5 different prototypes this week, refining the shape and aesthetic (and function - making sure it all fits) each time.

I was mostly concerned with the fit and screw bosses of the PCBs, and then ran into some issues with how my JST connectors were fitting, so I had to revise the edges so I could actually unplug and plug in the the connectors, since I had them pretty flush to the walls.

but then I became totally sucked into how I would actually assemble and disassmble the device. I really wanted to be able to have it come apart really easily so I could show people what was inside, but that's actually a really tough thing to do, especially when you're already deep into other priorities. I ended up going for 3 screw holes on the bottom to seal the whole thing shut and some ribs around the inner edges to help with the gap, something you find in other electronics enclosures.

After a full week of just printing prototypes and testing what works and what doesn't, I decided to bite the bullet and call it (I really could work on this alone for weeks to get it just right) and I decided to order some resin prints from JLCPCB (since there is no SLA printer here at Fab Lab Kannai). Here's an image of the FDM printed case that I did in house, and what I'm likely going to be presenting with since the JLCPCB parts might not make it in time!

I knew that I would need to redesign the cartridge at some point to fit to the new motherboard and daughterboard combo, so I took the opportunity to see if I could come out of this with a slightly smaller footprint - something that would afford me better system integration.

I knew that my pogo pin design from earlier just wasn't going to cut it. The latch mechanism was just too large to accomodate pins in the same direction, and I wouldn't be able to run pins perpendicular to the board since there would be a lot of shear force from insertion. I thought for a while, and considered doing an edge connector board, but I would lose the amazing click mechanism that I spent so much time researching and planning for, so I kept looking. I found these excellent sized spring loaded connectors on DigiKey that I thought would be a good substitute.

I designed a new footprint for the PCB in KiCAD. I made it shaped a bit like an "A" to help with the force of inserting and removing the cartridge. The gap in between the pins would have a plastic shelf that could help with a bit of that force.

However, at this point, I hadn't actually got the final PCBs in my hands, so I was really concerned with alignment. While I was designing the final motherboard, I added extra long solder pads for where I could attach an extension daughter board, which you can see in the image above, in case my springs didn't line up nicely with the cartridge (and so I could correct an error I made - swapping MISO and MOSI by accident). In hindsight, this was a really stupid decision as it just made things difficult to design around, rather than just coming up with a design and tolerance for error in the beginning - but hey, I learned a great lesson here and it's not one I'd be happy to repeat!

Once the parts arrived, I was able to solder them on, but I had a new problem. Getting the exact height for the circuit board to sit to make the right amount of contact with the spring loaded pins! I thought I had calculated this properly Fusion, my initial tests were either too loose and not making enough contact or too tight and I risked ripping the spring pins right off the board.

I unfortunately was limited by the height of cartridge's soldered components in the end. If I was just a millimeter closer to the board, I would have had to settle for this ugly bodge, but you live and learn.

IMAGE CAPTION ⇲

The problem? Yeah it's the flash memory SOIC (the black thing in the center of the board). It's literally standing 1mm too tall for me to put a lid on this thing.

IMG_FILE: thinnercart4.png

TYPE: PNG

XYZ: 123

The fix is: three seperate "boards", two of them at the height where the pins would interface naturally, and the main board with all of the components isolated and positioned off to the side, and then connected with soldered wires. It's certainly not graceful, but I was anxious about getting the rest of the work done. Without redesigning the rest of the main unit, the next logical fix would be using a double-sided board and just having the cartridge mount upside down with the components facing the other way and the pins interfacing on the other side. I tried to give this ago, but then I was reminded about just how difficult it was to do.

I spent the first half of my last week before my presentation nailing down the user interface and reconfiguring the ui_core.py that I explain earlier in spiral 2. Since I was running low on time, and I had already coded a lot of what I needed to do myself, my workflow for this involved drafting out designs in Illustrator and then asking Gemini to take my graphics and apply them to my existing code base, updating the classes I defined earlier with the new looks. The behaviours all pretty much stayed the same.

I would ultimately need to scale things down, even with the minimal approach to the UI above, as the SPI TFT display coupled with the ESP32 really couldn't handle a lot of the really fluid user experience I was aiming for. I bought these screens all the way back in week 4, and I didn't know enough back then to realize how difficult and slow they would be to work with without adequate memory on board. I found some bodges though and I got it working.

The big tricks were creating bitmap versions of the fonts I wanted to use and saving them in an assets.bin file on the device. I asked Gemini to create me a script that could take a .ttf file and output a literal pixel-by-pixel array of what each letter looked like. The downside is that you lose any anti-aliasing in this approach, so I made sure to find fonts that looked good at the sizes I needed them at. The original .bin file I configured was actually way too big to load into memory all at once, so I had to create a second asset_index.py script that my applications could consult to find the byte offset to use to pull out the correct character.

The full code base, that builds off of my work from the section above (week 15), can be accessed here:

Before I could get any of the apps actually running off cartridges, I would need a way to actually initalize the cartridge as a file system, which thankfully, already exists. This handy script from Peter Hinch allows me to create a littlefs filesystem on the W25Q128JVSIQ flash memory chips on each cartridge, and then essentially just read from them as though they were part of the ESP32/micropython's own file system. The first app I would actually need to code would be a cartridge manager that could format and push the scripts to the device.

Using the FLASH method from flash_spi, I was able to create a script that was able to do just that! I used a lot of the same code I had already tested back in week 08 ran into a lot of the same errors as I did back in week 08 and week 09 as well, but with a bit of debugging support from Gemini, I was able to get an app that I could launch from os_menu.py and push other scripts to the cartridge's flash memory.

APP_DESC = "Cartridge Data Manager"

import os
import time
import sys
import machine
from flash_spi import FLASH
from hal import hw, QuitToMenuException
import ui_core
import config

class CartManagerApp:
    def __init__(self):
        self.current_sel = 0
        self.carousel = ui_core.NavCarousel(
            0, 54, 240, 
            ui_core.sys_font_16_act, 
            ui_core.sys_font_16_gry, 
            ui_core.sys_spr_arrow, 
            ui_core.sys_spr_app_icon
        )
        self.refresh_menu()

    def refresh_menu(self):
        self.staging_apps = self._get_local_apps()

        self.menu_items = []
        self.file_map = {}
        self.descriptions = []

        for app in self.staging_apps:
            if app == "NO LOCAL APPS":
                self.menu_items.append("NO LOCAL APPS")
                self.descriptions.append("NO VALID APPS IN /APPLOAD")
                continue

            display_name = app[:-3].upper() if app.endswith('.py') else app.upper()

            self.menu_items.append(display_name)
            self.file_map[display_name] = app
            self.descriptions.append(f"PUSH {display_name} TO /CART")

        self.menu_items.extend(["FORMAT CART", "RETURN"])
        self.descriptions.append("ERASE AND FORMAT CARTRIDGE AS LITTLEFS")
        self.descriptions.append("RETURN TO OS MENU")

        #cursor fix
        if self.current_sel >= len(self.menu_items):
            self.current_sel = max(0, len(self.menu_items) - 1)

    def _get_local_apps(self):
        apps = []
        path = '/appload' if sys.implementation.name == 'micropython' else 'appload'
        try:
            for file in os.listdir(path):
                if file.endswith('.py') and file not in ['__init__.py', 'main.py']:
                    apps.append(file)
        except OSError:
            pass
        return apps if apps else ["NO LOCAL APPS"]

    def copy_file(self, display_name):
        actual_filename = self.file_map.get(display_name, display_name)
        src = f"/appload/{actual_filename}"
        dest = f"/cart/{actual_filename}"

        ui_core.sys_context.draw(f"COPYING {display_name}...")

        try:
            if os.statvfs('/') == os.statvfs('/cart'):
                raise Exception("NO CART DETECTED")

            src_size = os.stat(src)[6]

            with open(src, 'rb') as f_src:
                with open(dest, 'wb') as f_dest:
                    while True:
                        chunk = f_src.read(512)
                        if not chunk:
                            break
                        f_dest.write(chunk)

            try:
                dest_size = os.stat(dest)[6]
                if src_size != dest_size:
                    raise Exception("VERIFY FAILED")
            except OSError:
                raise Exception("WRITE FAILED")

            ui_core.sys_context.draw("TRANSFER COMPLETE")

        except Exception as e:
            err_msg = str(e)[:15].upper()
            ui_core.sys_context.draw(f"ERROR: {err_msg}")

    def get_controls(self):
        if self.carousel.is_open:
            sel = self.menu_items[self.current_sel]
            #dont delete these buttons haha
            if sel not in ["FORMAT CART", "RETURN", "NO LOCAL APPS"]:
                return {"UD": "NAVIGATE", "A": "EXECUTE", "B": "DELETE", "START": "HIDE"}
            return {"UD": "NAVIGATE", "A": "EXECUTE", "START": "HIDE"}
        else:
            return {"START": "MENU"}

    def run(self):
        hw.display.fill(hw.c_wht)

        self.carousel.draw_header()
        self.carousel.draw(self.menu_items, self.current_sel)

        ui_core.sys_controls.draw(self.get_controls())
        ui_core.sys_context.draw(self.descriptions[self.current_sel])

        prev_btn = 0

        while True:
            btn = hw.read_buttons()
            pressed = btn & ~prev_btn
            prev_btn = btn

            if pressed:
                if pressed & config.BTN_START:
                    self.carousel.toggle(self.menu_items, self.current_sel, hw.c_wht)
                    ui_core.sys_controls.draw(self.get_controls())
                    ui_core.sys_context.draw(self.descriptions[self.current_sel] if self.carousel.is_open else "")

                elif self.carousel.is_open:
                    if pressed & config.BTN_DOWN:
                        self.current_sel = (self.current_sel + 1) % len(self.menu_items)
                        self.carousel.draw(self.menu_items, self.current_sel)
                        ui_core.sys_controls.draw(self.get_controls())
                        ui_core.sys_context.draw(self.descriptions[self.current_sel])

                    elif pressed & config.BTN_UP:
                        self.current_sel = (self.current_sel - 1 + len(self.menu_items)) % len(self.menu_items)
                        self.carousel.draw(self.menu_items, self.current_sel)
                        ui_core.sys_controls.draw(self.get_controls())
                        ui_core.sys_context.draw(self.descriptions[self.current_sel])

                    elif pressed & config.BTN_B:
                        sel = self.menu_items[self.current_sel]
                        if sel not in ["FORMAT CART", "RETURN", "NO LOCAL APPS"]:
                            actual_filename = self.file_map.get(sel, sel)
                            try:
                                os.remove(f"/appload/{actual_filename}")
                                ui_core.sys_context.draw(f"DELETED {sel}")
                                time.sleep(0.5) 

                                self.refresh_menu()

                                hw.display.fill(hw.c_wht)
                                self.carousel.draw_header()
                                self.carousel.draw(self.menu_items, self.current_sel)
                                ui_core.sys_controls.draw(self.get_controls())
                                ui_core.sys_context.draw(self.descriptions[self.current_sel])
                            except OSError:
                                ui_core.sys_context.draw("ERROR: CANNOT DELETE")

                    elif pressed & config.BTN_A:
                        sel = self.menu_items[self.current_sel]

                        if sel == "RETURN":
                            raise QuitToMenuException()

                        elif sel == "FORMAT CART":
                            ui_core.sys_context.draw("FORMATTING... PLEASE WAIT")
                            try:
                                try:
                                    os.umount('/cart')
                                except OSError:
                                    pass

                                tft_cs = machine.Pin(config.PIN_TFT_CS, machine.Pin.OUT)
                                tft_cs.value(1)

                                hw.spi.init(baudrate=5_000_000)

                                cs = machine.Pin(config.PIN_FLASH_CS, machine.Pin.OUT)
                                cs.value(1)
                                time.sleep_ms(1)

                                cs.value(0)
                                hw.spi.write(bytearray([0xFF]))
                                cs.value(1)
                                time.sleep_ms(10)

                                cs.value(0)
                                hw.spi.write(bytearray([0x66]))
                                cs.value(1)
                                time.sleep_ms(1)

                                cs.value(0)
                                hw.spi.write(bytearray([0x99]))
                                cs.value(1)
                                time.sleep_ms(30)

                                flash_dev = FLASH(hw.spi, (cs,))
                                os.VfsLfs2.mkfs(flash_dev)
                                os.mount(flash_dev, '/cart')
                                ui_core.sys_context.draw("FORMAT COMPLETE")

                            except Exception as e:
                                err_msg = str(e)[:15].upper()
                                ui_core.sys_context.draw(f"FMT ERROR: {err_msg}")

                            finally:
                                hw.spi.init(baudrate=40_000_000) 

                        elif sel != "NO LOCAL APPS":
                            self.copy_file(sel)

            time.sleep(0.01)

def main():
    app = CartManagerApp()
    app.run()

The next step would be to start porting over some of the scripts I had already written in previous weeks on other hardware (sometimes simulated) onto the current iteration of the PAK with all the updated pinouts and hardware changes. The first app I coded all the way back in Week 04, the pomodoro timer, was the first cartridge I had in mind. Since I had all of the basics of my operating system and UI elements in simple classes, really all I had to do was bring over the logic of the timer and countdown and make it function on the larger display - which was farily simple to do. I asked Gemini with some help on fixing the screen tearing issues, as I've mentioned - the SPI screen really isn't as fast as I thought it was going to be originally, so I need to allocate some memory to a frame buffer for elements that are going to change often on screen. Gemini provided me with some code that reserves portions of the memory for the exact size of block to be drawn and then does some garbage cleanup with gc.collect() when we transition to different states that won't reuse assets.

Developing applications for the PAK is relatively straightforward. The software stack, described earlier, essentially just looks for python scripts in a few different directories (including the file system stored on the cartridge) and then populates a list on the home menu. My next demo app, since at the time I was having some trouble, would be a simple input tester - showing button presses on screen. This one was super straightforward to put together.

After that, I added a little "my profile" page reminiscent of early PDAs and gaming devices. Needed a bit of charm. These values are read and saved to a .json file stored locally on the ESP so in theory, other applications could be set up to read from them!

Next up I worked on a Date/Time app that could show the time in the three locales I've been studying in the last 5 months. The ESP32 does have an onboard clock but it loses persistance without power, so I would need to take advantage of my specific ESP32's onboard WiFi antenna to poll internet time. I added the SSID and security info of my router to the root of the ESP's filesystem in a .json folder and then a python script could poll for internet time and display it in EST/EDT, PET and JST! I did the same with the weather application I wanted to create, that could use an onboard DHT11 sensor to read the ambient temperature in the room as well as show you the forecast!

With my code base now easy to iterate on, I uploaded my entire code base to Gemini and asked it to help code some simple games to serve as proof of concepts for the PAK. I think the lowest hanging fruit for a simple device (that I've been struggling with memory and screen buffering on) was Flappy Bird, Doodle Jump and Snake, all shown below.

At this point, I only really had 3 physical cartridges fabricated, but it was possible to load multiple scripts on to a single cart (they are 16MB after all)... but I figured that would kind of defeat the purpose of the device haha! All of the scripts for the apps I coded (and vibe coded) can be found here:

On the Thursday right before my Monday presentation, the polished resin prints from JLCPCB arrived! I was so nervous they were going to arrive late but incredibly relieved that they came early! They looked absolutely incredible, especially the transparent resin case I ordered as a backup. It felt like all the hard work was finally crystalizing into a real, physical product.

IMAGE CAPTION ⇲

All the components laid out and ready for the final assembly.

IMG_FILE: disassemblywithallcomponents.jpg

TYPE: PNG

XYZ: 123

The first step was using my soldering iron to carefully press-fit the metal nuts into the top case to hold the screen in place. It's a delicate process where you have to heat the nut just enough so it melts perfectly into the plastic without warping the surrounding area or leaving burn marks.

Getting all of the components into the case and aligned to their stand-offs and screwholes was incredibly satisfying. However, I spent a surprisingly long time just adjusting the screw tightness. If the screws were too tight, the rubber membranes would stay compressed and the buttons would stick. If they were too loose, the controls felt mushy and unresponsive.

IMAGE CAPTION ⇲

The final two units side by side. I couldn't be happier with how the transparent resin turned out!

IMG_FILE: twoofthemcases.jpg

TYPE: PNG

XYZ: 123

With the physical devices finally assembled, I spent the next two entire days locked in the photobooth. I needed to collect a mountain of pictures and videos for my final presentation. I took video demonstrations, hero shots, and some stop-motion animations. Finally, I took all of that footage, along with my exploded render view from Fusion, and edited my final project slide in Illustrator and my presentation video in CapCut. You can find a link to the finished thing at the top of this page!

With 1-2 days left before my presentation, I really wanted something fun to end on. You know the meme: "Can it run DOOM?" I decided to lean into it and see if I could actually get DOOM installed on the PAK.

Since I was already using MicroPython on my main ESP32, getting a native C application like DOOM running would mean destroying my partition and reformatting all of my hard work, ultimately losing the functionality of what I built in the first place, so my compromise here is that Doom isn't actually going to run on a cartridge, it pretty much needs to occupy the full 4MiB of flash storage on the chip to make this work. I transferred all of my working PAK components and software over to the new clear model so I could get Doom running exlcusively on the white model.

IMAGE CAPTION ⇲

The slightly longer WROVER chip soldered onto the board with Kapton tape protecting the extra pins.

IMG_FILE: wroversolderedwithkaptan.jpg

TYPE: PNG

XYZ: 123

For the original case, I ended up soldering a new ESP32-WROVER to a spare motherboard. I realized pretty quickly that the WROOM chip I was using just would not be able to hold the game in the flash memory and run it on it's own memory. I needed more firepower so I ordered a devboard on Amazon that came the next morning. The WROVER is slightly longer than the ESP-WROOM-32 I designed the board for, but thankfully, the pinout for the overlapping footprint is practically identical. I just put some Kapton tape down over the extra pins to prevent any shorts and managed to get it in!

IMAGE CAPTION ⇲

The ESP32's internal RAM simply wasn't enough.

IMG_FILE: memorysystempanic.jpg

TYPE: PNG

XYZ: 123

To actually get the game running, I started with an old 2017 repo (espressif/esp32-doom). Because of how old the codebase was, I had massive issues compiling it. I knew I would need to completely swap out the screen logic and button logic to make it work with my ST7796 TFT and the 74HC165 shift register, but most of the problems I encountered were way above my expertise. I had Gemini help me rewrite the C code to match my specific hardware, and we came across some major hurdles along the way: The modern framework deprecated and moved almost all core APIs that the 2017 Doom port relied on. We had to manually re-link drivers for SPI, Partitioning, GPIO, and Flash, and update dozens of header paths (e.g., swapping esp_spi_flash.h for spi_flash_mmap.h). The compiler encountered code written in older C standards that were no longer valid. We had to fix "multiple definition" errors where the 2017 port used custom functions (like access) that conflicted with the modern ESP-IDF Virtual File System, and update outdated macro names (e.g., changing portTICK_RATE_MS to portTICK_PERIOD_MS). This was the most critical issue. The original code attempted to allocate massive video buffers in the ESP32's tiny internal memory, which immediately triggered memory allocation panics. We fixed this by forcing the engine to allocate the frame buffer in the 8MB PSRAM and utilizing a permanent, tiny 640-byte internal "bounce buffer" to stream the display. Because the Doom engine is so demanding, it was essentially "hogging" the CPU and failing to yield to background tasks, triggering the Task Watchdog Timer to reset the board. We resolved this by injecting vTaskDelay hooks to feed the Watchdog without impacting game performance.

1

2

SLIDESHOW ⇲

DOOM is technically running, but the screen initialization is completely botched (the cyan tint!).

Frame buffer alignment issues causing severe graphical tearing.

We had to manually perform the hardware-level initialization of the ST7796 panel, resolve the inverted color output (the infamous "cyan tint" issue), and implement a manual coordinate offset to center the 320x240 frame inside the PAK's 480x320 physical screen, all while painting a hardware-level black border. The audio engine was trying to write to an uninitialized memory queue. Since my project didn't require onboard audio, we performed an "audio lobotomy" by stubbing out those functions to ensure they would return "success" to the Doom engine without trying to access hardware memory that didn't exist.

IMAGE CAPTION ⇲

The terminal finally showing a successful boot sequence!

IMG_FILE: doomrunninginterminal.jpg

TYPE: PNG

XYZ: 123

After banging my head against the wall with C code for hours, seeing the terminal finally spit out a successful boot sequence was massive. I immediately texted all my friends to tell them my project could run Doom.