Homebrew Computer & OS from modern MCUs

Building a retro-styled homebrew computer and operating system with modern microcontrollers.

Similar projects worth following
This started as a curiosity about operating systems and grew into a retro-styled homebrew computer made from modern microcontrollers.

I've been working on a homebrew computer using microcontrollers arranged in a custom hardware architecture and an operating system to drive it. It's been a non-linear journey that started with curiosity about how operating systems worked and took me down several Rabbit holes to end up with a piece that I'm pretty proud of. Most of all, it reminded me of how much I have left to learn :)

The utility of the computer is primarily as a display piece and a learning experience. While it meets the definition of a computer, it's not a good computer. It has a 1-bit data bus, and the display has a ~2HZ refresh rate, but it makes a great conversation piece! The process has been fun and rewarding so far - I made a video documenting context and the process.


The overall design philosophy for the Ficus architecture is based around the metaphor of its name-sake tree - with its complex, interconnected roots and branches. The reference implementation for the Ficus architecture is shown below. Each MCU represents a 'node' in the Ficus tree and performs a specific function.

The reference implementation is made up of 7 nodes and an accompanying web app.

Ficus Canopy
This is the display node for the Ficus reference implementation. It processes incoming shell commands and responses and displays them on a 3.5' TFT screen. It features an Adafruit Metro M4 Express featuring ATSAMD51 for processing and displays on a 3.5" TFT 320x480 + Touchscreen Breakout Board w/MicroSD Socket - HXD8357D. The code is developed in C in Arduino IDE and depends on Phil Hower's Arduino-Pico core and Adafruit's Display library.

Ficus Fig
Named after the fruit of the Ficus tree, this node implements user shell functions for the operating system. The reference implementation uses a Raspberry Pico, but any similar RP2040 with at least 2 UART connections would work. The node listens for incoming shell requests, looks across its designated search path (including user space programs) for a matching command, and executes it. Results are sent back to the router node for distribution to other nodes. This node is implemented in MicroPython for flexibility.

Ficus Keys
This node provides USB keyboard input and command line editing. It is built on an Adafruit Feather RP2040 with a USB Type-A Host. The node listens for incoming scan codes and converts them to ASCII. Key press events are sent to the Trunx node for processing and displayed on an LCD screen. The edited command is sent to the Trunx for processing when the user presses enter. The code is developed in C in Arduino IDE and depends on Phil Hower's Arduino-Pico core and TinyUSB.

Ficus Leaf
This node provides environmental monitoring and blinkin' lights for user feedback. It's built on a Sparkfun RP2040 Pro Micro, but any RP2040 should work fine. The software is implemented using Adafruit's CircuitPython for hardware compatibility. This node listens for activity from the keyboard module and reacts to user input via the blinkin' lights. Additionally, it monitors an Adafruit AHT20 - Temperature & Humidity Sensor Breakout and displays current and record temps and humidity on a 0.96-inch OLED I2C IIC Display Module 12864 128x64 Pixel SSD1306.

Ficus Roots
Roots reach outward, and this node provides essential networking support to the Ficus reference implementation. On startup, it connects to the Ficus Web App, requests a time update, and distributes that time across the data bus. If not online, it will read the current time from a battery-backed PCF8523 Realtime Clock breakout on an i2c connection and distribute that time. Since the PCF8523 is known to drift, the Roots node will overwrite PCF8523 time with network time when received. This node is implemented in MicroPython for flexibility.

Ficus Trunx
Ficus is built on a 1-bit data bus, and most nodes are restricted to two UART connections at a time. This node is a primary routing node that is responsible for routing messages to the correct destination. In most...

Read more »

  • Quick Update on the New Video System Boards

    Shane C Mason01/11/2024 at 06:40 0 comments

    Right now, it feels and looks a little messy, but the new video system is coming together. I am replacing the large M4 Metro Express board with a tiny Waveshare RP2040 Zero and adding the Adafruit Feather DVI (see previous log) on a single board. I've also built a new connector board for the TFT screen that will be 'pluggable' - It's all mostly working now, so the next steps are to build the new connectors and mount the new cards on the board. I'll update when its all back together. Cheers!

  • Initial DVI working with HDMI Monitor

    Shane C Mason12/28/2023 at 02:39 0 comments

    Over the past few days, I've been playing with an Adafruit Feather RP2040 DVI to test adding support for external HDMI monitors. Yesterday, I built out a newer, cleaner version of the graphical shell using Adafruit's modified picodvi library and got that working on a little 10-inch monitor. Today, I added in the vine protocol logic so it would populate the command, response, and error widgets. I tested it with the full system by patching into the router output. I got it working after a few iterations, and it looks great and is LIGHTENING FAST compared to the built-in TFT. 

    To finish this out, here's the next tasks:

    • Replace the Metro M4 that powers the TFT with a standard pico to save space and improve the wiring in the area
      • I will reuse as much of the code from DVI version and attempt some performance improvements for the built-in TFT.
    • Add the Feather RP2040 DVI to the top of the board - using the external HDMI display will remain optional.

    I'll update once the components are integrated on the board.

  • Remote node mostly completed

    Shane C Mason12/17/2023 at 23:28 0 comments

    I've been working on a remote node that will measure temp/humidity and display 'alerts' from the main machine. It uses a Raspberry Pico WH and connects to the Ficus Webapp to sync time and temperature data currently. It has a AHT21 I2C IIC High Precision Digital Temperature and Humidity Sensor Module and a 0.96 Inch OLED I2C IIC Display Module 12864 128x64 Pixel SSD1306 Mini Self-Luminous OLED Screen for local display. I added a piezo buzzer for audible notifications. I intend to eventually extend the software to let it display notifications from the main computer.

View all 3 project logs

Enjoy this project?



Dario Greggio wrote 12/24/2023 at 11:38 point

Nice idea Shane!
And I did something similar using 4 PIC32:

  Are you sure? yes | no

Rick Ruggiero wrote 12/20/2023 at 23:22 point


  Are you sure? yes | no

Barkfin wrote 12/20/2023 at 19:13 point

Extremely nice! I think I guessed how it worked just from the photo, but then again look at any 8-bit computer and they all have separate devices (keyboard controller, i/o, display, sound generator, UART, etc) communicating with each other over buses. Believe it or not, I'm using almost exactly the same board as a motor mount for my cyclekart project.

  Are you sure? yes | no

Shane C Mason wrote 12/22/2023 at 19:21 point

That is an amazing cyclekart project - very cool!

  Are you sure? yes | no

matt venn wrote 12/20/2023 at 18:50 point

love the wiring!

  Are you sure? yes | no

Shane C Mason wrote 12/22/2023 at 19:22 point

Thank you - I obsessed over it a bit :)

  Are you sure? yes | no

allexoK wrote 12/14/2023 at 14:34 point

Great project, I love it! I wonder if it is possible to use wireless connection for nodes, like WIFI mesh or BLE mesh?

  Are you sure? yes | no

Shane C Mason wrote 12/15/2023 at 03:10 point

I have built a remote node with a temp/humidity sensor, a buzzer and a tiny display - I will be updating on that soon. It still connects through the web app - I should consider the 'mesh' approach...

  Are you sure? yes | no

Ale o co chodzi wrote 12/13/2023 at 19:40 point

why still using 8bit? not 10 or 9 or 12?

  Are you sure? yes | no

Ken Yap wrote 12/13/2023 at 20:57 point

That was all done in the early days of computing. I think a more interesting challenge would be a non-integral number of bits, say 9¾. 😉🤣

  Are you sure? yes | no

nerdu wrote 12/14/2023 at 08:37 point

8bit cpu but adress is 16bit because is too small

if computer have 12 bit  adress is biger

( Laugh at those who are ignorant )

  Are you sure? yes | no

Ken Yap wrote 12/14/2023 at 08:57 point

Aha, somebody who gets it; change the number base. Ternary is the closest to the best digit economy which is when the base is e.

  Are you sure? yes | no

Shane C Mason wrote 12/15/2023 at 03:38 point

My motivation was simplicity - ASCII only takes up the first 7 bits, leaving me 127 values to use in the protocol. Its not extendable, but its simple.

  Are you sure? yes | no

Ale o co chodzi wrote 12/17/2023 at 10:35 point

write hangul or unicode

You MUST use 2 word to write text, If You use 12bits You can to do this in one word

  Are you sure? yes | no

Shane C Mason wrote 12/22/2023 at 19:20 point

Correct, but I didn't set the protocol up to support Unicode - it supports ASCII for simplicity. Thanks!

  Are you sure? yes | no

Ale o co chodzi wrote 12/30/2023 at 15:54 point

I 'm not write about unicode

trucated UTF16 is ok ;) or UTF32

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates