Over the last month or so, I have been managing Claude AI in building an Operating System (OS). Over the course of the next few days (weeks?) I am going to go into the process of how I went from 0 to 1 in 6 weeks or less. (Who am I kidding, I will never write a follow up to this)
Where this actually started was a thread on the PicoCalc forums, where a guy wanted to write an OS for the PicoCalc. He was obviously young, and rubbed people the wrong way, so it did not go well. During the conversation though, he did ask two questions that I thought were important.
The first question was, what should this operating system look like. My suggestion was an MS-DOS workalike. Any meaningful GUI would be impossible with 520 KB of memory, and since the Raspberry Pi (RPi) Pico is a microcontroller, it should be easy to write drivers and provide hardware access. As I recall, absolutely no one liked this idea.
The second questions was, will anyone write programs for my OS? My answer was, yes, give me an OS with a toolchain and an API and I will at least give it a shot. This is where I knew this was going no where, because he honestly thought we could just write C code and have it work.
Anyway, I put this whole idea on the back burner for a long time, thinking about it occasionally, but not really doing anything about it. Then recently a couple of other interesting threads came up, one was a guy who had built an x86 emulator, so you could actually run MS-DOS on a PicoCalc, that was pretty cool. During this conversation it came up whether or not Linux could be made to run on a RPi Pico. With a bit of Googling, I found that yes you could. I spent a day or two building an interface for the PicoCalc, I even patched in the PSRAM. Unfortunately, it was useless, even with the PSRAM, you could not run a small text editor like Nano or Vi. This kind of brought me back to the question of an MS-DOS like OS running on bare metal instead of an emulator.
The big problem I had is I am not a great programmer, writing an OS, even for a microcontroller, is very much beyond my skill level. This is when the second thread came up, where a fellow was presenting a program for the PicoCalc, that had obviously been written by an AI. He didn't deny it, nor was he even trying to cover it up. He got torched on the forum, because there are very deep anti AI feelings almost everywhere these days. I supported him, it was his idea, he guided the AI through the process, he had a vision and executed on it, even if he did not write a single line of code. My only issue was he copyrighted the code under his own name, which I did object to. I think anything written by an AI should be public domain, but that is just me.
This got me off my butt, and I seriously started to work on it. I knew Claude Code was going to have to do all the heavy lifting here, but I had to tell Claude Code what I needed. I knew I wanted a general purpose OS about on the level of MS-DOS 4.0. It needed to have a development toolchain, and it had to come with some basic productivity tools. I would start with a C compiler and a Basic interpreter, giving a user a couple of ways to write programs. The productivity tools had to be useful, but simple, and this is what I came up with; Text Editor, E-mail Client, Web Browser, File Manager, and a Calendar/To-Do list. Of course the E-mail client and Web Browser meant there also needed to be a network stack.
The first step was to get a kernel and a command shell running on a bare bones RPi Pico through a serial console, so I started with that, so I had a conversation with the Gemini AI about what I wanted, it generated the prompt that started it all.
Project: PicoDOS — a minimal DOS-inspired OS for the Raspberry Pi Pico
Goal
Build a small, single-tasking operating system for the Raspberry Pi Pico in the
spirit of an MS-DOS boot disk (kernel + shell + a few utilities), but NOT DOS
binary-compatible — it's its own thing. Primary target is the RP2350 (Pico 2W);
keep code RP2040-compatible where that's cheap. The ultimate hardware target is
the ClockworkPi PicoCalc, but early development runs entirely over a SERIAL
console so OS logic stays decoupled from display/keyboard drivers.
Language: C, using the Raspberry Pi Pico SDK and CMake.
Architecture (please follow this)
- Layered, DOS-style split:
- Hardware-dependent layer ("hal", analogous to IO.SYS): clock init, serial,
and later the SD/SPI, LCD, and I2C keyboard drivers. - Hardware-independent kernel ("kernel", analogous to MSDOS.SYS): filesystem,
memory, program model, syscall surface. Never touches hardware directly —
it only calls the HAL.
- Hardware-dependent layer ("hal", analogous to IO.SYS): clock init, serial,
- The console abstraction is the key seam. Define a small Console interface
(putc, getc, getc_timeout, erase, newline, clear). The kernel and shell talk
ONLY to this interface — never call printf/getchar or emit ANSI escapes
directly from shell/utility code. v1 ships a serial backend; a PicoCalc
LCD+keyboard backend drops in later behind the same interface. - Filesystem: FatFs (ELM-ChaN) over an SD card on SPI. The FAT-formatted SD card
is the "boot disk." - Shell (COMMAND.COM equivalent): compiled INTO the kernel image for v1, no
external program loading yet. Internal commands only to start. - Syscall model (for later, when external programs land): pass programs a struct
of function pointers (a syscall table), NOT an SVC/exception trap — this design
runs with no MMU and no memory protection. Single address space,
single-tasking, DOS in spirit.
v1 scope — build this first
- Pico SDK C project with CMake, targeting RP2350 (note where RP2040 differs).
- Boot: init stdio over UART at 115200, print a banner/version line.
- Console interface + serial backend.
- A small shell line editor: treat Enter as CR (\r), Backspace as both DEL
(0x7f) and BS (0x08), and echo typed characters (assume no terminal echo). - Shell loop with a prompt and internal commands: VER, CLS, ECHO, DIR, TYPE, CD.
- FatFs mounting the SD card. If the SD/SPI wiring is unknown right now, stub
the block device so DIR/TYPE can be built against a fake in-RAM volume, with a
clear TODO for the real SPI SD driver.
Explicitly DEFER (do not build yet)
ILI9488 LCD driver, I2C keyboard driver, external program loader (fixed-address,
then ELF later), PSRAM use, any multitasking.
Hardware facts (for accuracy)
- RP2350 / Pico 2W: dual Cortex-M33 (or RISC-V Hazard3), 520 KB SRAM.
RP2040: Cortex-M0+, 264 KB SRAM. - PicoCalc (later target): ILI9488 320x320 display over SPI; keyboard is an
STM32F103 co-processor on I2C at address 0x1F exposing a keycode FIFO (also
battery telemetry via an AXP2101 PMU); SD card slot; 8 MB PSRAM via PIO-SPI.
Keep the keyboard I2C bus slow (~10 kHz).
How to start
- First, ask me any clarifying questions — especially: is the Pico SDK installed
and can you build in this environment, or should you produce source + build
files only for me to compile? SDK version / board? Project name (I used
"PicoDOS" as a placeholder)? - Then propose a directory layout and a phased plan before generating a lot of code.
- Create a CLAUDE.md capturing this architecture, the console-seam rule, the v1
scope, and the deferred list, so future sessions stay on-architecture. - Keep the layering strict and leave TODOs where the PicoCalc backends plug in.
Within an hour, I booted PicoDOS on an RPi Pico 2W for the first time, it didn't do much, but there is was, the project was alive. Version 0.1.0 was born.