First day of coding

Today, I started this new project in C++ with PlatformIO to get more comfortable with it.

For now, it’s not really an OS, but we already have a Renderer class to handle rendering in an optimized way.

The goal

The goal is to create a complete desktop OS for ESP32 and various screens. Using an ESP32 allows network access, which is important on a computer in 2026.

I’d also like to run small video games on this OS, which I think would be quite an achievement.

I’m not trying to replace Windows or Linux XD, I just want to code a small retro system and have fun with it.

Rendering

So, this is what I worked on today, and I added a layer to the LovyanGFX library to have something optimized from the start.

When an object is displayed using the Renderer class, I save the intention to display a specific object with specific parameters in a list. Each object has a rectangle to detect collisions with other objects and therefore redraw the object or not.

When Renderer::render() is called, I check the areas to be displayed and only display what is necessary, which avoids flickering.

This method has several advantages, the main one being low RAM usage, which is crucial on a microcontroller like an ESP32.

The supported graphics are:

• Solid and non-solid rectangles
• Solid and non-solid rectangles with rounded corners
• Lines
• Circles
• Text
• Bitmap images or images without scaling

In my opinion, these are the essential elements for creating a good UI and complete video games (yes, really). In the videos, you can see the rendering of Mario (the NES version), even though there’s an issue with the colors, it’s definitely him. He’s present as a bitmap image in a C array.

Touchscreen

This is the second thing I implemented. The calibration isn’t perfect yet, but it’s already pretty good.

The touchscreen and stylus will allow for easy navigation of the OS without needing other peripherals, although I do plan to add joystick support to control the future mouse pointer.

What’s next?

Well, I’m not entirely sure. I’m thinking of creating UI components now, with the goal of building a window manager later on. But before that, I’ll probably code the foundations of the module that will handle inputs, to ensure an instant transition between touch and joystick. Anyway, I’ll keep doing a lot of graphics work!

Thanks so much for reading,
wilrakov, btw

Abandoning LVGL

After extensive testing aimed at achieving a smooth user experience, I unfortunately didn’t succeed.
I believe the main issue stems from the fact that LVGL relies on significant abstraction layers designed to simplify and optimize UI creation.

However, it isn’t optimized for a full-fledged graphical OS capable of handling video games.

So, I decided to change my approach.

WilUI

After much thought, I decided to create my own graphics library: WilUI (yes, I’m a megalomaniac 😂).

It uses double buffering in PSRAM (the ESP32’s external RAM, ranging from a few MBs to more, depending on the configuration).
It then renders the screen using one or two internal RAM buffers; each of these buffers holds 48 lines of the display.

Thanks to this, I managed to jump from under 10 fps to around 26 fps. I achieve this speed using full refreshes, so in theory, the actual performance should be smoother; I won’t be doing a full refresh every time, but rather partial refreshes on the areas that have changed.

The library isn’t really fully underway yet—I’ve mostly handled the framebuffer management so far, while the UI components and other features still need to be built… But I wanted to say I’d created a UI library anyway 😅

The new TODO list

• dirty rects
• basic UI components
• text rendering
• basic window manager (SOWM) -> desktops + status bar + simple windows

wilra0v, btw

A functional multitasking system!!!

I coded the micro_os base, including FreeRTOS and LVGL to handle multitasking and provide a nice display.

Everything went smoothly at first, adding LVGL and esp-idf to good tools for using a screen.

The beginning of the problems

Once the LVGL task was able to display text, I thought everything was ready to start the window manager and desktop for this OS.

But… in the end, I had synchronization issues since the tasks run in parallel. Fortunately, I found the problem fairly quickly and was able to fix it.

So, in the end, the base works without any problems.

What’s already there

For now, there’s almost nothing, just a status bar and 3 virtual workspaces with custom themes for the windows, etc. You can also switch between light and dark themes.

What I’m going to do now

I’m going to continue working on the basic display by dynamically showing and hiding the status bar.

Next, I’d like to add a small dock like on macOS.

Finally, I’d like to make the status bar dynamic so that it displays the name of the application in focus and also allows me to add and remove icons on the fly.

Thanks for reading,
wilrak0v, btw

🚀 Major Pivot: From PicoOS to micro_os

I’m officially moving away from MicroPython for my OS development. While it was a great way to prototype, it’s time to get closer to the metal.

Say hello to micro_os — a complete, lightweight, and graphical operating system built from scratch.

To kick things off, I have just initialized the project entirely in C using the ESP-IDF framework. The goal is to build a fast, minimalist, and efficient system, focusing on the ESP32 first, with plans to port it to the Raspberry Pi Pico later on.

Time to write some real firmware. Stay tuned for updates! 💻🛠️

Devlog #1: Launching AstroOS – A Lightweight, Tiling WebOS Approach

Hey everyone!

For the past few days, I was having a hard time finding the motivation to code, feeling a bit stuck with my ideas. But looking at the incredible variety of WebOS projects built for Stardance
inspired me to finally jump in and build my own.

There are amazing, feature-rich web desktops out there, but for my specific setup and workflow, I wanted to explore a different architectural path. Running a minimalist setup on a Raspberry Pi 5 under dwm, I naturally lean toward simple, hardware-friendly, and lightweight tools.

That is how AstroOS was born.

The Vision & Goals

My objective is to build a compact workspace centered around a minimalist philosophy:

• Offline-First (PWA): Designed to function entirely without an internet connection once loaded, keeping all processes local.

• Consistent Workspace: A unified environment that adapts cleanly whether I am working on a desktop PC or typing on an iPad on the go.

• Vanilla Foundations (KISS): Built using standard HTML, pure CSS (Grid/Flexbox), and Vanilla JavaScript to keep rendering overhead as low as possible.

• Tiling Window Management: While windows will start as floating elements, the long-term goal is to implement a native tiling system inspired by window managers like dwm.

• Modular Design: A simple virtual file system using IndexedDB to allow local app expanding down the road.

First Steps (The 17-Minute Spark)

To break the laziness, I forced myself to sit down and write the absolute baseline. In less than twenty minutes, the project officially started:

• Initialized the directory structure and the core files.

• Created a basic HTML with the base of the future style of windows.

Time to build. Stay tuned!

Prepare to the first ship

So I created the github repo, and I made a small test with wokwi simulator but it doesn´t work very well, I have to find a better way to run my OS on the Internet.

Devlog PicoOS #3: Colors, SDK, and an Alternative C Kernel

What is New

Application Library (SDK)

To stop rewriting core system code for every new feature, PicoOS now features a minimalist SDK. This application library standardizes how programs interface with the OS for rendering and input handling, making the codebase modular.

ANSI Color Support

PicoOS now supports standard ANSI color escape sequences. This brings color to the terminal interface without bloating the system, allowing for better visual hierarchy and cleaner error reporting.

Technical Friction: Refactoring the ls Command

Integrating older, hardcoded features into the new standardized SDK proved to be a real headache.

The biggest friction happened while adapting the ls command to the new library. Originally, the file listing system was deeply intertwined with the main loop and bypassed any formal API. Forcing it to fit into the new application structure broke the output formatting and data piping. It took a lot of tedious refactoring to abstract the file system calls into the SDK so that ls could run as a standard, isolated application while maintaining its output format.

Future Roadmap

Text Editor: poe

The next native tool will be poe (PicoOS Editor). This minimalist text editor will run directly on top of the SDK, allowing basic file editing on the go.

Parallel Track: A C Version

The MicroPython version is not going anywhere and will remain active. However, as a C developer who loves low-level programming, a parallel version of PicoOS written entirely in C will start soon. This alternative kernel will run closer to the metal, offering absolute memory control, optimal performance on the RP2350, and a pure bare-metal experience.

Storage unlocked! Added SD card memory support for PicoOS today. The craziest part? It took me barely 20 minutes. The implementation was surprisingly straightforward, and the OS now effortlessly handles multiple SD cards simultaneously without any conflicts.
Next on the roadmap: building a library to make custom command development easier, and adding a “Clippy”-style assistant right inside the terminal.

PicoOS Devlog #2: Rounding Up Essential Commands

Welcome to the second devlog!

I’ve spent the last two days expanding the shell’s toolkit to make the environment much more usable. I am happy to announce that the core lineup of indispensable Unix utilities and I/O features is now complete!

New Features & Commands Added

• echo: Prints text to the terminal—essential for verifying variables, scripting, and testing streams.
• clear: Clears the terminal screen (super satisfying when working over UART!).
• cat: Outputs the content of a file directly to the terminal.
• less: A lightweight pager to view content page by page. It dynamically handles input either directly from a specified file or piped on the fly from another command using the shell pipeline (|).
• help: Displays the description and usage of available commands.

Stream Redirections are Live!

I have successfully implemented basic I/O redirection operators into the shell parser:

• >: Redirects a command’s standard output to a file, overwriting its existing content.
• >>: Redirects standard output to a file, but appends the data to the end of the file instead of wiping it.

How help works under the hood

To keep things lightweight and modular, the help command doesn’t rely on a hardcoded dictionary. Instead, it dynamically parses an optional comment block placed right at the beginning of each command line inside /bin. Simple, effective, and completely decentralized.

What’s next?

With the fundamental CLI utilities and stream handling out of the way, I am shifting focus toward system architecture and usability:

1. Memory & Storage Integration: Setting up proper management for SPI flash memories and mapping out the memory structure of the system.
2. Developer Experience (DX): Building core Python modules to make writing custom apps for PicoOS as straightforward and clean as possible.
3. Refactoring & Expansion: Polishing and simplifying the existing codebase while adding a few more handy utilities.
4. Text Editing: Writing a lightweight, built-in text editor (a mini-clone of nano or vi) to modify files directly on the hardware.

Community request!

I feel like the most critical commands are now up and running, but a shell can always grow.

What essential CLI utility or fun tool are you missing? If there is a specific command you’d love to see running natively on a Raspberry Pi Pico 2, drop it in the comments below!

Until next time!

PicoOS Devlog #1 : Build the Shell Foundation

Welcome to this very first devlog! After setting up the project description, it’s time to div into the actual code.

Lately, I’ve been focusing on implementing the core shell environment. The goal is to build a familiar CLI experience by rewriting essential Unix/Linux commands from scratch, keeping them lightweight and stripped of bloat

Anatomy of a Command

In this OS, every command lives as a file or folder inside the /bin directory, with the exception of cd, which has to be built directly into the shell to modify the current working directory.

Here is the standard structure for a basic command (e.g., hello):

def hello(args: list) -> int:
    print("Hello World")
    return 0

• Naming convention: The main function name must perfectly match the script’s filename.
• Arguments: Just like in standard C programs on Unix/Linux, args[0] always hold the name of the program itself, followed by the actual arguments.

What’s Already Working

I have successfully implemented a solid batch of core utilities:

• ls: Lists directory contents. Supported flags: -l (long format) and -a (show hidden files).
• cd: Changes the current working directory.
• mkdir: Creates one or multiple directories.
• touch: Creates one or multiple empty files.
• rm: Removes files or directories. Supported flag: -r (recursive).
• mv: Renames or moves files/directories.
• cp: Copies files/directories. Supported flag: -r (recursive).
• picofetch: A custom, lightweight system information tool (think neofetch / fastfetch) custom-tailored for PicoOS.

What’s Next?

The shell is alive, but there is still plenty of low-level work to do. My immediate milestones are:

1. Expanding the toolbet: Implement the cat command along with a few other handy utilities.
2. I/O Streams: Add basic shell redirection mechanisms, specifically output redirection (>) and piping (|).
3. Hardware Storage: Write drivers to interface with and manage external SPI flash memories.

The Endgame

As a reminder, the final objective of this project is to build a functional mini-computer powered by a Raspberry Pi Pico 2. I’ll be handling networking, driving a graphical display purely over UART, and the ultimate test of fire: making DOOM run on it.

Stay tuned for the next updates!

🚀 Project: PicoOS (Retro CLI for RP2350)

For this Stardance marathon, I’m building a minimalist, retro-styled operating system running entirely on the new Raspberry Pi Pico 2 (RP2350) using MicroPython!

The goal is to blend the nostalgic command-line simplicity of MS-DOS with the modular design and philosophy of Unix/Linux. Everything is designed to be as close to the KISS (Keep It Simple, Stupid) and suckless principles as possible.

What I’m shipping:

• A custom, fast interactive CLI shell over serial (USB/UART).
• A modular file system structure where commands are isolated scripts (like a real /bin directory).
• Direct low-level hardware poking (GPIO, PWM, I2C) right from the prompt.
• No bloated abstractions, just clean and simple code.

Can’t wait to log hours on this and see how far I can push this little dual-core chip. Let’s build! 💻🔥

“Let’s strip away the layers of bloated complexity. Welcome to the CHIPC adventure.”

You probably have an 8-core beast of a processor in your pocket and another one on your desk. But do you really know what happens inside the silicon at every single clock cycle? Driven by a pure love for bare-metal hardware and the KISS (Keep It Simple, Stupid) philosophy, I decided to build my own minimalist computer from scratch.

Its beating heart? The legendary MOS 6502 (specifically, the Rockwell R65C02). No heavy OS, no high-level abstractions. Just pure logic, assembly, and raw silicon.

The Backstory: A One-Year Hiatus

To be completely honest, this project didn’t start yesterday. I actually designed and fully assembled the board a year ago. Back then, I was on fire: I spent hours mapping out the architecture, routing the PCB traces, and soldering the components.

But right after assembling the board, the momentum dropped. The hardware went straight into a drawer, and the project stalled. I realized I had completed the visible part of the iceberg, but I completely missed the most important phase. A custom computer without firmware is just a beautiful, expensive paperweight. The real challenge starts now.

The End Game: Running a Raycaster

I’m digging the project out of its drawer to finally give it life. No more simulations. We are talking custom EEPROM flashing, memory mapping, and low-level bare-metal programming.

But I’m not just aiming for a simple “Hello World” or a blinking LED. The ultimate, crazy goal of this project? Writing and running a 3D raycaster engine directly on this 8-bit machine. If you want to see how far we can push a 6502 processor with clever optimization and minimal resources, you’re in the right place.

Here is what’s coming up in the next devlogs:

EEPROM Programer: create a simple EEPROM programer based on a microcontroller.

The First Boot: Writing the initial bootloader and basic I/O initialization.

Memory Mapping: Figuring out how RAM, ROM, and peripherals will coexist cleanly on the bus.

The Software Stack: Building the foundations to eventually support the raycaster graphics logic.

If you love DIY electronics, retro-engineering, and optimization, stick around.

**CHIPC 2.0 is officially alive. Stay tuned for the next post where we jump straight into the assembly code! **