Thanks for your interest in UnoDOS! This document explains how to get started.
- Linux (Ubuntu/Debian recommended)
- NASM assembler
- QEMU (for testing)
- Python 3
- Make
sudo apt install nasm qemu-system-x86 make python3# Build everything
make clean && make floppy144 && make apps && make build/launcher-floppy.img
# Run in QEMU
make run144
# Build HD image too
make hd-image
make run-hdkernel/kernel.asm— The entire kernel (one large assembly file)apps/*.asm— Each application is a standalone NASM source fileboot/*.asm— Boot chain (MBR, VBR, stage2 loaders)tools/*.py— Build tools (image creation, filesystem)docs/— Technical documentation
The kernel communicates with apps through INT 0x80 system calls (similar in concept to Linux, but with a completely different API). Apps are flat .BIN binaries that each run in their own 64KB segment. The App Development Guide covers everything you need to write an app.
- New applications — Write a new app using the existing API. See docs/APP_DEVELOPMENT.md for the full guide and docs/API_REFERENCE.md for available system calls.
- Icon artwork — Apps use 16x16 2bpp CGA icons. The existing ones are functional but could be improved.
- Documentation — Corrections, clarifications, or tutorials.
- Screenshots — The README needs screenshots from real hardware or QEMU.
- Bug fixes in the kernel or existing apps
- New kernel APIs (coordinate with maintainer first)
- Hardware testing on machines not yet listed
- x86 assembly uses Intel syntax (NASM)
- Comments explain why, not what —
; Skip headernot; Jump past 80 bytes - Labels use
snake_case - Constants use
UPPER_CASE - Local labels start with
.(e.g.,.loop:,.exit:) - Keep lines under 100 characters where practical
Always test changes in QEMU before submitting:
make run144 # Test floppy boot
make run-hd # Test HD bootIf you have real vintage hardware, testing there is even better. Report the hardware model and results.
- Fork the repository
- Create a feature branch
- Make your changes
- Test in QEMU (both floppy and HD boot if applicable)
- Submit a pull request with a clear description
The BUILD_NUMBER file tracks sequential builds. Don't increment it in your PR — the maintainer handles build numbering.
By contributing, you agree that your contributions will be licensed under the project's CC BY-NC 4.0 license.