Zeal 8-bit OS runs a Unix-shaped system on a Z80 with a memory under 8KB of ROM

An OS designed around what a hobby Z80 machine actually has

Zeal 8-bit OS is described in the README as a simple and portable operating system for Z80-based computers, written entirely in Z80 assembly. The word portable here means portable across Z80 machines, not across processor families, and the whole design follows from that.

The origin story in the README explains the motivation. The project is part of a larger effort, the Zeal 8-bit Computer, an entirely newly designed 8-bit machine built around a Z80 CPU. When the author began writing software, demos and drivers for it, the code turned out to be tied to that specific hardware implementation, which made it incompatible with other Z80 computers even when the required features were basic, a UART for instance. The operating system is the answer to that problem, a hardware abstraction layer that lets the same software target different machines.

The design goals are stated without inflation: not multithreaded, ROM-able, modular and configurable, with a small and concise ABI that lets software talk to hardware with the fewest hardcoded behaviours. The author notes that Linux was a source of inspiration for the syscall names and the way opened files and drivers are handled, but that only the APIs and interfaces were borrowed, since Linux is a 32-bit system written in C. If you are comfortable with Linux system programming, the README says, Zeal 8-bit OS will sound familiar.

That resemblance is the practical hook. A developer who knows how processes, file descriptors and device drivers fit together on Linux will find the concepts legible here even though the implementation is 8-bit assembly.

The size budget: under 8KB of ROM and under 1KB of RAM

The headline constraint is that once compiled, the kernel takes less than 8KB of ROM for code and less than 1KB of RAM for data. The README is careful that this depends heavily on the configuration, and it explains which knobs move the numbers. Raising the maximum number of opened files or the maximum path length increases the data space, and the size grows as more features arrive, for example more file systems.

What is striking is the stated priority behind those numbers. The author says that while writing the code, speed was more important than code size, because read-only memories are available in huge sizes at a fair price, and that the OS can still be optimised in both speed and size later even though that is not the current priority.

This is a deliberate inversion of the usual retro operating system trade-off, where every byte of ROM is fought over. It means the design is not built around a size ceiling, and it also means the footprint numbers will move as the feature set grows, so anyone planning a board with a fixed ROM should measure their own configuration rather than quote the headline figure.

Drivers add to the picture. The kernel size has to be combined with the size of the driver implementations and the RAM they use, which depends on the target machine, the features implemented and the number of drivers. A configuration with a lot of hardware support is a different system from the kernel alone.

Memory mapping, an MMU, and the no-MMU path

The OS is designed to work with an MMU, and the README states the requirement plainly: the target must have 4 swappable virtual pages of 16KB each, and the pages must be interchangeable. The memory mapping section of the documentation covers the kernel configured with an MMU and the kernel configured as no-MMU, so the alternative path is part of the design rather than an afterthought.

Four pages of 16KB is a very small address space, and it explains the shape of the rest of the system. A process address space is not a flat range of memory; it is a handful of windows that the kernel swaps. That is why the ABI is described as small and concise, and why the syscall table exists at all.

The user space section of the documentation describes the entry point and the program parameters, and the syscall section documents the table, the parameters, the parameter constraints, the exec syscall in detail and the rest of the syscall set separately. The Linux-like naming is most visible here, since the README mentions the exec syscall explicitly, which is the same name Linux uses for replacing the current program image.

For anyone porting the OS to new hardware, the memory mapping and reset vector sections are the two that decide feasibility. The kernel section documents the used registers and the reset vectors, which is exactly the information a porting effort needs before anything else.

Drivers, disks and a virtual file system

The distinguishing concept is that Zeal 8-bit OS has drivers and disks while still being ROM-able, which is an unusual combination for a system of this size. The documentation has a drivers section, a disks section, and a virtual file system section with its own architecture subsection, plus a file systems section underneath.

The virtual file system is the layer that makes drivers and disks composable. Rather than a program talking to a disk controller directly, a path resolves through the VFS to a file system, and a file system resolves to a driver, and the driver owns the hardware. That separation is what allows the same filesystem and the same application to run on a machine with a different storage device, which is the portability goal the author started from.

The supported targets section shows this in practice, listing the Zeal 8-bit Computer, the TRS-80 Model-I and the Agon Light, and it includes a subsection on the relation between the kernel and the target plus a subsection on porting to another machine. A TRS-80 Model-I and an Agon Light have very different hardware, and supporting both from one kernel is the argument for the driver and VFS design in a single sentence.

File systems being listed as a separate concept from disks also implies that multiple file systems can be mounted over different devices, which is where the file systems section earns its place in the documentation.

Building it: CMake, menuconfig and a z88dk assembler

The build is CMake driven with a Kconfig-style configuration step, and the dependency list is short enough to install in a minute. The README says the project has only been assembled on Linux, on Ubuntu 20.04 and 22.04, and that it should be compatible with MacOS and Windows as long as you have bash, git, cmake 3.16 or later, python3 with pip3 for the menuconfig, and z88dk v2.2 or later.

On Ubuntu the README gives the install commands, and it notes that they must be run as a user rather than as root:

sudo apt update
sudo apt install git python3 python3-pip cmake
pip3 install --ignore-installed --user kconfiglib

The z88dk requirement has a sharp edge. Only the assembler, z80asm, is strictly required, but the latest version must be used, because earlier versions do not support the MACRO directive. That is the kind of detail that stops a build with a confusing error, and it is worth checking before anything else if the build fails.

Configuration is two steps, first the CMake configure and then the menuconfig target:

cmake -B build

cmake --build build --target menuconfig

The menuconfig screens configure the kernel and also the target computer's options, for example where the romdisk lives for the Zeal 8-bit Computer. The repository layout backs this up with a Kconfig file at the root, a configs directory holding per-target configuration, a cmake directory, a kernel directory, a target directory with per-machine code, a romdisk directory, an include directory, an sdk directory, tools and tests, and a pytest.ini, so the test suite runs under pytest.

On MacOS the README lists brew install cmake and brew install binutils, and there is a tip about setting the PYTHON_BIN environment variable to the bin directory if you need to point the build at a particular python3. Z88DK itself is installed from the project's own GitHub checkout.

Writing user programs and the SDK

The public API and languages section is the part a user-space developer cares about, and the examples directory shows three toolchain paths: gnu-as, sdcc and z88dk-z80asm. That range tells you the system is not tied to one assembler, even though the kernel itself is built with z88dk.

The example directories are named for their role rather than their content, and they sit next to the SDK directory in the repository. The kernel and the userland are separated by a syscall boundary with a documented table and documented parameter constraints, and the syscall documentation is written to be read, not just to be used as a header.

The consequences of that separation are worth being concrete about. A program cannot touch a hardware register directly; it goes through a driver, and the driver goes through the VFS and the disk layer. That is slower than a bare-metal demo and it is the entire point, because the same binary then works on a different Z80 machine with a different device behind the same driver interface.

The README also has a flashing section, split between the Zeal 8-bit Computer and generic targets, so the deployment path differs depending on whether you are writing to your own board or to something more standard. And the version history and contributing sections close the document, with the licence named as Apache-2.0.

Why not the alternatives, and where this is the wrong tool

The README names the existing alternatives and says why it is not one of them. There are several good operating systems for the Z80 already, and it names SymbOS, Fuzix and CP/M. The reason for writing another one was to have something less sophisticated: not multithreaded, ROM-able, modular and configurable, with a small ABI.

That comparison is instructive because the axes are explicit. Fuzix and CP/M, in the author's framing, are richer systems. If your requirement is a multitasking operating system with a large application base, this is the wrong project, and no amount of configuration will change that. If your requirement is a small, predictable system with a documented syscall ABI and a hardware abstraction layer you can port by writing a driver, the trade works the other way.

The real risk for an adopter is not the OS but the porting effort. Supporting a machine means writing its drivers and mapping its memory layout, and the README's own supported target list, three machines, is small. A project that needs a Z80 target not on that list is looking at real work, and the memory mapping section shows how much detail has to be right before a single driver runs.

On the project itself, the repository is not archived and the last push was on 2026-09-19, so work is continuing. The release history is slower: v0.7.0 is dated 2026-03-24, v0.6.0 dates from 2025-07-05 and v0.5.0 from 2024-11-20. Those are the tagged points to build from, and they are well behind the head of the branch, so a feature you want may exist in the repository without being in a release.

Editorial conclusion

Adopt Zeal 8-bit OS if you are writing software or drivers for a Z80 machine and want a Unix-shaped interface with a documented ABI, a small ROM footprint and a configuration system that lets you pick the target hardware, and if you are prepared to work in assembly and to read the implementation details documentation rather than a tutorial. Do not adopt it if you need a general purpose Z80 system with multitasking and a rich userland, since the author explicitly wanted something less sophisticated than the existing alternatives, and do not expect it to run on a machine without an MMU unless you take the no-MMU configuration path. Verify first that your target has four swappable 16KB pages if you use the MMU configuration, that z88dk v2.2 or later with a recent z80asm is installed, since earlier assemblers lack MACRO support, and that the release you build from matches the v0.7.0 tag, whose release date is 2026-03-24.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. Zeal8bit/Zeal-8-bit-OS on GitHub