rajamesandClaude Opus 5.5 66b26f823c fix(v4.0.0): step 6e final review -- texts begun in order; a word no one will read lets its writer go; a cut wire wakes a wait for room; a full console wire is a refusal, not a fault
The final review of step 6e, by a fresh reviewer told to break it, and
what was ruled: fix them all, test first.  Each has a test that failed
before the mend.

- Two texts from one node could be begun in the wrong order when room
  for their answers came between the node's look at the first and at the
  second.  Texts whose answers go by the same port are begun in the order
  they came: (D-MASK), quit.v4.  102 of 700 timings were wrong before.
- A word written with PORT! to a node that speaks whole messages, or to
  a console's port, blocked its writer for ever and cut off every node
  beyond it.  It is error 18 now, whether that node is asleep, running
  or stuck: fabric.c, node.c.
- A node asleep for room on one wire is woken when another of its wires
  is cut.
- A line there was no room for on the lone node's wire was reported as a
  fault and ended the hosted program.  It is Message refused, and the
  prompt comes back: V4_BOOT_LINE_REFUSED.  hosted-check has the case;
  no bare-metal boot has typed it.
- Ruled: text behind held output for the same port is refused though it
  would fit.  MESH.md 7d.4 said otherwise and is corrected.
- The removal test also cuts and re-makes a wire, and has an exchange in
  which output is held at a full wire: 26,814 disturbances in all.
- MESH.md and v4/README.md no longer say that a stuck node holds up no
  other node, that only printing waits, or that no node is left waiting
  on one that is gone; 7d.6 lists the limits and what the products do
  that they did not before.

make -C v4 test and sanitize at both widths, hosted-check, lint.  Three
bare-metal boots: logs/20261013-194827 (amd64), -195131 (aarch64),
-195518 (riscv64).  POST 538 of 538, word_count=317,
dict_hash=0xe5a57f3eb72ff94a on all six; the three sessions are the same
character for character.  The boots were built with the working tree's
uncommitted change to kernel/Makefile that adds the ISA to the kernel's
version line.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-13 20:02:33 -04:00
2026-08-25 20:41:50 -04:00
2026-08-02 05:11:24 -04:00
2026-08-01 07:49:56 -04:00
2026-08-01 07:49:56 -04:00
2026-08-02 05:11:24 -04:00

LithosAnanke v2.0.1

UEFI-bootable FORTH microkernel. Boots from firmware, initialises memory and interrupts, then runs the StarForth VM as its sole userspace runtime. No libc. No OS. Just stone and necessity.

Lithos (foundation) + Ananke (necessity) — the kernel under StarshipOS.


Products

StarForth v4 moves the engine onto a 32-instruction core derived from Chuck Moore's F18 (docs/v4.0.0/). With it, this repository carries three products, not one:

Product What it is
Hosted StarForth F18 The v4 engine as a native Linux build, for amd64, arm64 and riscv64, on real hardware.
FPGA StarForth F18 A 32-bit build of the same engine loaded into the FPGA. It is the gateway to the rest: the foundation everything else is built up from.
StarshipOS The bare-metal product: LithosAnanke running the v4 F18 engine.

FORTH-79 is recomposed on the F18 engine and stored as a capsule; the StarshipOS-specific vocabulary gets the same treatment. The source tree will be reorganised around this split.

v3 remains the reference system until v4 meets its acceptance criteria (docs/v4.0.0/JUSTIFICATION.md §16). Everything below describes v3 as it stands today.


Status — M7.1 (Capsule System · Multi-VM Fleet)

Milestone Status
M0–M6 UEFI boot · PMM · VMM · IDT · APIC · heap · framebuffer VT100 console (v1.5.1-FINAL) ✅ Complete
M7 StarForth VM integration + parity validation ✅ Complete
M7.1 Capsule birth protocol · Mama FORTH vocabulary · Tripod multi-VM fleet (Hermes/Artemis) · Word-level ACL (Phases 1–7) 🔄 In Progress
M8 REPL — keyboard input, interactive Forth Planned
M9 Block storage — AHCI driver Planned

POST at boot: parity hash verified across amd64/aarch64/riscv64 · Mama capsule dictionary: 453 words

What's live in M7.1

  • Tripod — a named multi-VM fleet (Hera the Mama VM, Artemis, two Hermes instances) births, runs, and re-births independently, verified booting live pre-REPL on all three architectures.
  • Hermes — a 17-block inter-VM messaging/channel layer between fleet members, with async delivery and channel negotiation.
  • Artemis — a Block Allocation Map (BAM) storage subsystem with Q48.16 block-heat tracking and cooldown/reclamation (ART-COOL/ART-REAP).
  • Word-level ACL — every dictionary entry carries a TTL/allow/mode/pin access-control record. Strict, TTL, and pinned modes; two console layers (emergency ok> and superuser zuse)ok>). Phases 1–7 complete (C infrastructure, FORTH policy layer, zuse bootstrap superuser, Isabelle proof stubs, kernel parity); Phase 8 (Ed25519 PKI / thumbdrive challenge-response) is the only item remaining. Measured overhead once active on every check: +0.0054%–+0.0088%, CV = 0.000%, across a 3×3 Latin-square DoE campaign (architecture × seed × 30 replicates) — three orders of magnitude below the measurement floor.
  • VM Fleet Attractor physics — the L8 Jacquard mode selector now has a real per-VM heat channel into fleet-wide tuning, replacing hardcoded compudynamics constants with a dynamically-inferred rate.
  • Kconfig build configuration — every physics/heartbeat/pipelining/ kernel-only tuning knob (~40 total) is now a discoverable, optional Kconfig symbol shared with the hosted VM build. See Quick Start below.

Quick Start

# One boot image per physical target (output: build/boards/<board>/)
make boot_image TARGET=SER5       # Beelink SER5   -- GPT/ESP, BOOTX64.EFI
make boot_image TARGET=RASPI      # Raspberry Pi 5 -- FAT, config.txt + kernel_2712.img + DTB
make boot_image TARGET=MILKV      # Milk-V Mars    -- GPT/ESP, BOOTRISCV64.EFI (U-Boot bootefi)
make boot_image TARGET=ZYNQ7020   # Zynq-7020      -- ARMv7 port in progress
make boards                       # list boards

# The same TARGET drives all, docs and clean (make help)
make                              # every board with a kernel port + hosted v3 + the book
make TARGET=RASPI                 # one board's image + build/docs/LithosAnanke-raspi.pdf
make docs                         # build/docs/LithosAnanke.pdf (LaTeX master: docs/book/main.tex)
make clean TARGET=RASPI           # that board's outputs and build/aarch64/kernel
make clean                        # all of build/ except build/cache/

# Build kernel (requires cross-compilation toolchain, or native gcc)
make -f kernel/Makefile ARCH=amd64

# Run in QEMU with OVMF
make -f kernel/Makefile qemu

# Other architectures
make -f kernel/Makefile ARCH=aarch64 qemu
make -f kernel/Makefile ARCH=riscv64 qemu

Artifacts: build/amd64/kernel/starkernel_loader.efi · build/amd64/kernel/starkernel_kernel.elf

Tree: kernel/ (LithosAnanke: Makefile, src/, include/starkernel/, linker/), v3/ (StarForth v3 engine and hosted build: Makefile, src/, include/), v4/ (StarForth v4, see docs/v4.0.0/), boards/<board>/ (board.mk + boot files). Every makefile runs from the repo root; the root Makefile forwards any other goal to v3/Makefile (hosted build).

For the hosted VM by itself (Linux, no cross-compiler needed, no bare-metal tooling): see the separate StarForth repository — LithosAnanke used to be a branch inside that repo, now it's its own project with its own master.

Build configuration (optional)

Every kernel-only knob (STARFORTH_ENABLE_VM, PARITY_MODE, the shared physics/heartbeat family, etc.) is an optional Kconfig symbol — a plain make -f kernel/Makefile uses the same defaults it always has unless you opt in:

make -f kernel/Makefile ARCH=amd64 menuconfig
make -f kernel/Makefile ARCH=amd64 kernel_amd64_defconfig

Documentation

System Architecture Full kernel + VM design
HAL Reference Hardware abstraction layer interfaces
Capsule System — M7.1 Capsule birth protocol design
VM Fleet Attractor design log Tripod/Hermes/Artemis physics + build-system history
Getting Started / Kconfig reference Full symbol reference for both build targets
Changelog Milestone-level history
Roadmap Milestone plan through self-hosting

License

Starship License 1.0 (SL-1.0) — free for personal, research, and educational use. Commercial use requires a separate agreement. Attribution to R.A. James (Captain Bob) must be preserved in all distributions.

Patent pending. USPTO provisional filed December 2025 — physics-grounded self-adaptive runtime system. This license does not grant patent rights. Licensing inquiries: rajames440@gmail.com


Robert A. James (Captain Bob) · Systems Engineer · Hacking since 1973

S
Description
No description provided
Readme
6.8 GiB
Languages
C 72.2%
Isabelle 10.4%
TeX 5%
Shell 3.4%
R 2.7%
Other 6.3%