Drawing conventions
The rules this drawing set is produced under.
01 Own the whole stack
Why build an operating system and a bootloader and a BIOS and a Vulkan implementation and a UI library? Because the seams are where systems rot. Every boundary you don’t own is a boundary you debug through a stranger’s abstractions. microZeus draws every layer — from the first instruction after power-on to the last pixel on screen — so that when something breaks, the answer is always in a sheet we drew.
02 One build, every architecture
mzOS2 configures for i386, x86_64, ARM, and ARM64 from a single CMake tree — including cross-compiling from macOS with nothing but Homebrew LLVM. Fragmented toolchains are a choice, not a law of nature. The mz answer to “it works on my architecture” is a build system where there is no my architecture.
03 Hardware is optional
mzVolk implements Vulkan entirely on the CPU, loaded by the real Vulkan loader like any hardware driver, with mzJIT compiling SPIR-V shaders to native code at pipeline creation. A stack that only works on blessed hardware isn’t a stack — it’s a dependency. Software implementations keep every layer honest, testable, and runnable anywhere.
04 Pure C, small surfaces
Nearly every mz project is pure C — some with hand-written assembly where the machine demands it. Small APIs, freestanding-friendly libraries, no dynamic allocation in test suites, frame captures for pixel-level verification. Code you can read in an afternoon is code you can trust at 3 a.m.
05 Honest documentation
mzVolk’s README keeps a section literally titled “known limitations (honest list)”. It once read no depth test yet, no descriptor sets yet, no clipping yet — and the project burned it down in public, one change order at a time, until at v0.60 the list was empty. Every sheet in this set carries the same convention. A limitation documented is a roadmap; a limitation hidden is a landmine. We stamp drawings approved, not finished.