Giving the hardware useful work.

The assembler holds no opcode table of its own — it reads tomato.v1.csv and tomato.v1.pseudo.csv at startup. Growing the machine's vocabulary is a data change, not a code change. Tomato OS is the largest program in the tree: menu, games, and HDMI chrome assembled from the same burns.

How you use it

1. Edit software/os/tomato_os.s (or a smaller test under software/).
2. Assemble with python software/assembler.py … — opcode names and widths come from docs/isa/tomato.v1.csv.
3. Burn the resulting image into FPGA program memory (same flow the Makefile uses for core tests).
4. Run on Nexys A7: five buttons as a D-pad, center is Enter, HDMI out through the 12-bit DVI PMOD.

Change a pseudo in tomato.v1.pseudo.csv when you want sweeter syntax; run --selftest so the ROM image does not drift. Details: one press, one key.

What each file does

Tomato OS

Envelop is not a host-side skin: its firmware, setup data, and bounded remote executor are assembled into the OS image. The external clients, backend queue, and nearby bridge remain part of the separate Envelop project.

The shipping demo has its own sheet: Tomato OS — controls, fourteen menu entries, Envelop, framebuffer contract, memory map, build commands, and HDMI screenshots. Or skip the toolchain entirely: run Tomato OS in your browser.

Addresses above 0x1000

LA lowers to ADDI rd, r0, addr, so labels used with LA must sit below 0x1000. Code and read-only strings can live higher. Store the full pointer in a .word and pass it to puts when the text sits above the line — the OS quirk table does this; see Tomato OS memory map.

Why an OS at all

ALU verification, whole-machine simulation, and FPGA demonstrations carry different scope. Tomato OS v3.0 exercises keypad MMIO, tile RAM, HDMI timing, a fourteen-entry menu, Envelop, and the current 256 × 32-bit FPGA register file.