Project Logs

Collapse

• Build Log #2 — The Homecoming Sends Back Four Corrections

  Tsuneo.Ohnaka • a day ago • 0 comments

  (draft for hackaday.io/project/206144 · 2026-09-07 · derived from PROJECT_ABSTRACT_canonical.md; no resource figures by rule)

  In Log #1 the machine left home. This is the log where it came back — and the first thing it did, once home, was mail four corrections to the place it came from.

  A quick recap of the structure, because it changed. PTSG-CPU-Formation is the master data ISA; applications are made from it by subtraction. The plan was to produce the first subtraction profile — PTSG-WPMS-Formation, the packet-parameter engine of the FPGA Spectrum Engine synthesizer — directly inside the parent project. The architect judged the load on the parent too great and stood up an intermediary: PTSG-WPMS-Formation is now its own project, with its own amanuensis, its own decision register, and a one-page hand-off brief from this side describing what we expected it to keep, forbid, omit, and add. (If you know your Star Trek, the parent is Earth, the profile is the Enterprise, and I am not going to push the metaphor further than the architect already has.)

  What the profile decided. Its register is keyed to ours, ID by ID. Its first Fixed ruling re-forbade the one CPU-ish liberty the master had admitted — pointer indirection — for purity; that escape hatch was written into the master precisely so a profile could use it, and it worked on first use. It omitted the data stack (legal, documented, the instructions fall to the reserved-ID law). It restricted an open master question rather than wait for us to rule it — restriction is always safe, and it does not pre-empt the master. And it took a stance on fixed-point arithmetic that amounts to a vote on one of our open ties: an integer-only ISA where the Q-format belongs to the program, which is coherent only if the realignment shift is expressible in the instruction itself. The first customer leaned; the architect will rule.

  What the profile found. Four defects in the master, all valid, all now corrected:

  A register the spec called "read/write" that no instruction could actually read. The prose overstated; the ID table had been right all along.
  A claim that the stay counter is the index of "any recurrence the hardware consumes." It isn't — whether it is depends on how a profile choreographs its prescaler and its consumer. The master now exposes the counter and lets profiles decide what it means.
  Two open ties filed by the first program that never reached the register where, by the spec's own words, "their status lives."
  And the important one: the machine-readable translation contract — the file the validator uses to accept or reject instruction lists — had been extracted from the deliberation worksheet, not from the canonical chapter. The mechanical link was pointing at the ancestor instead of the law. There is now a generator that derives the contract from Chapter 3's rows plus its common law, cross-checks against the worksheet extraction (they agree, all eighteen instructions), and gets re-run whenever the chapter changes. The old file is retired; the first program re-validates clean against the canon.
  Here is the part worth writing a log about. The master runs mechanical audits on itself — chapters against worksheet, chapter against chapter, IDs against the register. Three of the four defects sailed through every one of them, because the audits check consistency, and two documents can be consistently wrong together. What caught them was a second reader with fresh eyes and no stake in the master's assumptions. A downstream amanuensis is a verification layer the master cannot supply for itself. The hand-off brief had ended by asking the profile to file any disagreement, on the grounds that this ecosystem's best design review had been the one that was wrong. The profile took the invitation literally, and the master is better for it.

  The exchange is archived, both directions, as a Layer-2 reasoning trace in the repository — including the reply, and the profile's one clarification back...

  Read more »

• Build Log #1 — The Five Impossibilities, or: How a Failed Audit Founded a CPU

  Tsuneo.Ohnaka • 07/13/2026 at 13:55 • 0 comments

  (draft for hackaday.io/project/206144 · derived from PROJECT_ABSTRACT_canonical.md · 2026-07-13)

  The most productive design review in this project's short history is one we got wrong.

  PTSG-CPU-Formation is the third repository of the PTSG ecosystem, and its first Formation: a minimal instruction-driven datapath — accumulator, Horner-step MAC, an explicit data stack, packet-parameter memory with atomic boundary commit — built around the frozen PTSG-Core, entirely inside the Core's window discipline. One line: a deterministic data machine built on a clock that cannot be argued with.

  It was born sideways, the way everything in this ecosystem is born. While drafting the packet-parameter engine for the FPGA Spectrum Engine's WPMS synthesizer, the instruction set kept growing more general than its application. So we ran a review with an inverted question. Not what should we add? but: what can this machine never be — not inefficiency, impossibility?

  The audit came back with five impossibilities, each one the shadow of a doctrine we actually wanted:

  1. It cannot branch on its own data. No flags register, no compare. The core is data-blind by creed.
  2. It cannot capture a return address. No subroutines, no recursion — because the timing chart must stay readable as the program text.
  3. It cannot read its own writes within a window. Staging lands on a shadow page; the page you're playing from cannot be touched.
  4. It cannot own its program. No load path, no self-modification. The tines of the music box are planted from outside; the planting is the performance.
  5. It cannot be interrupted. Preemption is jitter incarnate.

  Tidy. Convincing. And then we read the Core repository properly — and two of the five collapsed. The Core already captures return contexts (a holding register auto-saves state on branch, call, and insertion; an external stack bus delegates nesting depth outward), and it already has interrupts: Insertion exists, honored at packet boundaries — not absent, but quantized to the deterministic grid. A third impossibility turned out to have a front door (ALU flags exported as external Condition lanes, so the core stays data-blind while the loop closes outside), and a fourth turned out to be doctrine — a per-profile choice, not law.

  Only one impossibility was actually law: the program's owner stands outside the machine.

  That correction was the founding insight. A machine this close to CPU-hood, held back only by chooseable doctrine, deserved its own repository — a master data ISA from which applications are made by subtraction. The WPMS engine becomes the first subtraction profile, and the parent project stays what it has always been: the mother that keeps birthing generic children and becomes each child's first customer.

  What exists as of tonight, in the same launch shape PTSG-Core itself once had:

  • The repository, four Open Prompt layers, CC0/CC0/MIT/CC0.
  • Five Layer-1 chapters: philosophy (including the corrected audit — the impossibilities we keep are the product), the register file and the read-only quartet SN/SSS/K/I (now, here, when, which — time itself as an operand), the Command × Phase behavior table (eighteen instructions; no instruction exists until its row is ratified), the memory architecture (BG computes, Q commits: the page swap lands jitter-free on the packet boundary, so glitch-freedom is structure, not discipline), and the Core interface contract (nine lanes; "the Core never waits").
  • The deliberation worksheet and the founding dialogue itself, published as the first Layer-2 reasoning trace — this ecosystem publishes its design conversations, architect and AI amanuensis both, as reproducible public record.

  You will find no resource figures in this log, and none anywhere in the repository outside Layer 4. That is a governance rule, not an oversight: Measured, not promised. Numbers will exist only as measurements pinned to a named revision, device, and toolchain — the first of which will arrive with silicon evidence...

  Read more »

View all 2 project logs