UnoDOS is a complete graphical OS on its own code: its own drivers, its own TCP/IP stack with TLS, a web browser, an office suite that reads the real Microsoft formats, and a C compiler that builds UnoDOS apps on UnoDOS. No Linux underneath. The same source tree ships for 22 machines in all, from a Commodore 64 to a SNES, and every one of them is a download below.
On a modern x86-64 PC, UnoDOS boots bare-metal on its own storage, input, network and audio drivers, its own TCP/IP stack, a web browser, an office suite that reads and writes the real Microsoft formats, and a C compiler that runs on the operating system it compiles for. The system image behind the Boot button above is about 19 megabytes compressed, and about half of that is Duum's game data.
It is also one member of a family: one codebase, built fresh for each machine rather than ported through a compatibility layer. The same desktop, window manager and applications appear on an 8-bit console with 2 KB of RAM and on a modern 64-bit PC, because everything above the hardware is generated from or checked against a single machine-readable contract.
The full source is on GitHub under the Mozilla Public License 2.0. Per-port status, including what has been verified on real hardware and what has not, is in PLATFORMS.md.
One of the applications is a Doom engine written entirely in Python, running on the operating system's own Python runtime. It loads a real Doom game file, streams it a piece at a time, and draws a textured, first-person view of the level you can walk through and fight in.
The level geometry and the game logic are Python; only the per-pixel drawing drops into C. Every other port of UnoDOS rebuilds the system's own applications in each machine's native language. This is the reverse: a whole outside game engine, brought to the platform in nothing but Python.
Duum is its own project now, and it has a browser build: the same engine file, on a WebAssembly build of the runtime it uses here. Play it - or bring a WAD of your own, which is read in your browser and not uploaded anywhere.
Release v3.34.0. Every file below is built from the same source tree. Pick a machine, load the file in the emulator named beside it, and you are running UnoDOS in about a minute.
Putting it on a real PC: the USB flasher. The easiest path on Windows is UnoDosFlasher.exe: no install, pick your USB stick, click Install. It does not clone a fixed-size image; it builds the volume on the stick (GPT, one FAT32 partition spanning the whole drive), so a 32 GB stick becomes a 32 GB UnoDOS drive with room left for your documents. Windows asks for administrator rights, because raw disk writes need them, and everything on the stick is erased.
Then boot the target PC from the stick: enter the firmware menu, turn Secure Boot off, and pick the USB device. On macOS or Linux, write unodos-pc64-hybrid.img.gz with balenaEtcher or dd instead; it does the same job without the convenience. The manual walks through booting real hardware in detail.
| Machine | File | Size |
|---|---|---|
| Modern PC (x86-64 / UEFI) | unodos-pc64.isohybrid UEFI ISO · Attach to a VM's CD-ROM: QEMU with OVMF, VirtualBox, VMware | 92.3 MB |
| Modern PC (BIOS or UEFI) | unodos-pc64-hybrid.img.gz96 MiB disk image, gzipped · Decompress and write to USB with dd or Rufus. Boots legacy BIOS and UEFI alike, on any PC from roughly 2007 on | 18.7 MB |
| Modern PC: USB flasher | UnoDosFlasher.exeWindows app, no install · Run it, pick your USB stick, click Install. Builds a whole-stick FAT32 UnoDOS drive; asks for admin; erases the stick | 34.4 MB |
| IBM PC / XT (8088) | unodos-144.img1.44 MB floppy image · QEMU, 86Box, PCem, or a real PC with a floppy drive | 1.4 MB |
| Commodore 64 | unodos_c64.d64D64 disk image · VICE (x64sc), or write to a real disk / SD2IEC | 171 KB |
| Commodore VIC-20 | unodos_vic20.prgPRG program · VICE (xvic) | 5 KB |
| Nintendo NES / Famicom | unodos.nesiNES ROM (NROM-256) · Mesen, FCEUX, or a real console via EverDriveHardware run covered the base apps plus Dostris; the four later parity apps are emulator-verified only. | 40 KB |
| Super Nintendo | unodos.sfcSFC ROM (LoROM) · Snes9x, bsnes, or an SD2SNES / FXPakOn real hardware, tested only on a SupaBoy clone with an FXPak Pro: boots and is navigable, but icons render text-only and there is no audio. | 32 KB |
| Game Boy / Game Boy Color | unodos.gbGB ROM (CGB-compatible) · SameBoy, BGB, mGBA, or an EverDrive GB | 32 KB |
| Game Boy Advance | unodos.gbaGBA ROM · mGBA, or an EZ-Flash / EverDrive GBA | 20 KB |
| Sega Master System | unodos.smsSMS ROM · Emulicious, MAME, or an Everdrive MD/SMS | 32 KB |
| Sega Game Gear | unodos.ggGG ROM · Emulicious, MAME | 32 KB |
| Sega Genesis / Mega Drive | unodos.genGenesis ROM · BlastEm, Kega Fusion, or a Mega EverDriveBoots from a flashcart. The PS/2, tape and Sega CD adapters are emulator-only. | 64 KB |
| Sega Dreamcast | unodos-dc-uui.isoselfboot CD image · Flycast, redream, or burn to CD-R for real hardware | 658 KB |
| NEC PC Engine / TurboGrafx-16 | unodos.pcePCE ROM · Mednafen, Ootake, or a Turbo EverDriveBoots on a Turbo EverDrive v2.5 under TEOS only; the stock Krikzz v2 OS rejects the ROM. | 48 KB |
| Bandai WonderSwan | unodos.wsWS ROM · Mednafen | 64 KB |
| Sony PlayStation 2 | unodos-ps2.elfEE ELF executable · PCSX2, or a real PS2 via uLaunchELF | 2.1 MB |
| Commodore Amiga (68K) | unodos68k.adfADF disk image · WinUAE or FS-UAE. Attach unodos-data.adf as DF1 for the app disk | 880 KB |
| Apple II | unodos_apple2.dskDSK disk image (.woz also provided) · AppleWin, MAME, or a real II via a Floppy Emu | 140 KB |
| Apple IIgs | unodos_iigs.poProDOS 800K image · GSplus, MAME | 800 KB |
| Macintosh Plus | unodos_macplus.dsk800K disk image · Mini vMac | 800 KB |
| PowerPC Macintosh | unodos_ppcmac.binOpen Firmware binary · QEMU (qemu-system-ppc) | 23 KB |
| Raspberry Pi (AArch64) | kernel8.imgbare-metal kernel image · Copy to the boot partition of an SD card, or QEMU (qemu-system-aarch64)Boots to the desktop on a real Pi 3, with two known faults: the background renders brown (pixel-order swap) and input is serial-only, no USB HID. | 27 KB |
| PinePhone (Allwinner A64) | unodos_pinephone.binbare-metal image · Emulator and instruction-level harness onlyEmulator-verified only. Confirmed NOT to boot on a real PinePhone; treat the hardware path as untested. | 26 KB |
Wi-Fi firmware is not included. The x86-64 build drives Intel wireless adapters, but that firmware belongs to Intel and is not ours to redistribute, so published images ship without it. Everything else, including wired Ethernet, works out of the box.
You only need this on real hardware: a virtual machine's emulated network card works without it. Write the image to a USB stick, then run unodos-wifi-firmware-tool.zip, which fetches the blob for your card and puts it on the stick under the name the driver expects. It double-clicks on Windows and macOS and needs nothing installed beyond Python.
Macintosh (System 1-7) is not in this release. The Retro68 cross-toolchain on the build machine is incomplete, so this port has no current binary. The source is in the repository and builds once Retro68 is installed.
Nothing here needs a special environment. Clone the repository, pick a port, run its build script.
git clone https://github.com/hmofet/unodos
cd unodos/c64 && ./build.sh # -> build/unodos_c64.d64Each port's build script names the assembler or cross-compiler it needs and stops with a clear message if it is missing. The per-port audit documents in the repository root record what has been tested and where.
Counted at release v3.34.0 with one command over every
.c .h .asm .s .py .js .ps1 .sh file in the tree, so the
figures can be re-run by anyone with a checkout. The total, the part that
is vendored, and the part written here are stated together on purpose:
the total alone overstates the work, the in-repo number alone hides the
vendoring.
767,041 lines of tracked source in 2,214 files. 375,802 of that is vendored and inventoried in THIRD-PARTY.md; the remaining ~391,000 were written in this repository, over 73 active development days.
| Component | What it does here | Licence | Lines |
|---|---|---|---|
| MicroPython | the Python runtime, and what Duum runs on | MIT | 104,154 |
| QuickJS-ng | the browser's optional second JavaScript engine | MIT | 84,217 |
| BearSSL | TLS under the network stack | MIT | 76,970 |
| NetSurf libcss stack | the browser's optional second CSS cascade (libcss, libparserutils, libwapcaplet) | MIT | 72,099 |
| uACPI | ACPI/AML interpreter core | MIT | 32,783 |
| stb_truetype | TrueType rasteriser | public domain / MIT | 5,079 |
| Codec tables | AAC and MP3 constant tables (OpenCORE, PDMP3) | Apache-2.0 / public domain | 500 |
Everything else, from the bootloader and the drivers through the TCP/IP stack, the window manager, the primary JavaScript engine, the compiler and the applications, is in-repo code.
| Part | What it is | Lines |
|---|---|---|
| UnoOffice | UnoWord, UnoCalc and UnoShow (9,384) on the unodoc format library (10,383 plus 3,749 of tests): binary .doc/.xls/.ppt and OOXML .docx/.xlsx/.pptx, read and write, with its own zip, XML and formula code. Nothing vendored. | 23,516 |
| UnoCode | the code editor as shipped in v3.34.0. It has since moved to its own public repository, unocode-desktop (31,140 lines, 22,330 of them the editor core), which the OS now vendors. | 11,526 |
| Duum | the Doom engine in Python, its own repository: 13,590 lines of Python plus the C and JavaScript of the host and browser builds. Counted at its own commit, not the OS release. | 16,114 |
All from git log at v3.34.0. The work was done by AI
coding agents, directed and reviewed by one person; the agents appear in
the commit messages, not in the author field.
| Measure | Value |
|---|---|
| First commit | 22 January 2026 |
| Release v3.34.0 | 21 August 2026, 212 days later |
| Active development days | 73 |
| Longest pause | 87 days (16 March to 11 June) |
| Commits | 2,209, about 30 per active day |
| Busiest day | 106 commits, 7 August |
| Commits on weekends | 409 (18.5%) |
| Merges / reverts | 42 / 8 |
| Commit subjects containing "fix" | 349 |
| Releases tagged | 7 |
| Numbered builds | 425 |
| Syscalls in the machine-readable contract | 106 |
| Machines the tree builds for | 22 |
| Applications on the x86-64 build | 23 |
| Conformance checks driven on real hardware before release | 86, on two machines |
| Kernel binary | 4,035,034 bytes |
| Developers | 1 |
The whole story, written up with the failures left in: the architecture that lets one codebase target machines forty years apart, the evening a font bug ate fourteen numbered debug builds, and what it takes to get trustworthy work out of AI coding agents. Every claim traces to a commit.
I am Arin Bakht. I built UnoDOS on my own, with AI coding agents, across 22 machines. The part that made it possible is not the operating system: it is the machinery around the agents. Explicit contracts, conformance tests, and verification harnesses that catch an agent being wrong about its own work before a human ever reads it.
That machinery is what I install in other teams' codebases, and it works on messy legacy code rather than greenfield like this. There is a 90-minute repository teardown to find out whether it would help you, and a four-week fixed-scope audit if it would.