admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC.md: item 4.4k -- live SGR color verification, all three architectures

Browse Source 
No code changes -- investigation/verification only. Injected a raw SGR
escape sequence over the serial socket at the ok> prompt (composed from
EMIT + ." since no FORTH word emits a literal ESC byte + text
directly): 27 EMIT ." [95mCOLOR-TEST" 27 EMIT ." [39m", bright magenta
(the p>=90&&p<=97 branch in apply_sgr()), a third SGR code path
distinct from 4.4h's already-verified truecolor prompt.

Screendump on all three architectures confirms COLOR-TEST renders in
bright magenta via the 4.4j-retargeted TTF draw call, proving the SGR
parser and the new glyph backend work together end-to-end, not just
independently. First screendump evidence ever captured for
aarch64/riscv64 in this document -- every prior screendump item was
amd64-only with that gap explicitly accepted; incidentally closed here
via the QEMU monitor screendump command against each arch's own
display device (ramfb for aarch64/riscv64). Both confirmed booting at
800x600.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-11 20:10:12 -04:00
co-authored by Claude Sonnet 5
parent f729b91a09
commit 418f040997
14 changed files with 54888 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC.md
+27 -1
View File
@@ -5398,7 +5398,7 @@ document and committing that amendment as its own item.*
> it once it exists, not building the box itself. No box exists yet, so this is deferred by
> construction, not skipped.
- [ ] **4.4k — Live-verify ANSI color end-to-end.** Depends on 4.4j. Inject an SGR color
- [x] **4.4k — Live-verify ANSI color end-to-end.** Depends on 4.4j. Inject an SGR color
escape sequence (`ESC[3xm`/`ESC[9xm`/256-color) over serial and confirm it visibly changes
`TTF-TEXT`-rendered glyph color in a screendump — the parser and the retargeted draw call
working together, not just each existing independently.
@@ -5406,6 +5406,32 @@ document and committing that amendment as its own item.*
three architectures; three-arch QEMU boot + logs per CLAUDE.md.
*Refs:* §27.8.
> **Done 2026-08-11.** No FORTH word exists to emit a literal `ESC` byte plus arbitrary text
> directly, so composed one from existing primitives and injected it over the serial socket
> at the `ok>` prompt (same `socat`-to-chardev-socket technique the `qemu` Makefile target
> already uses for `EXEC-DOE` injection): `27 EMIT ." [95mCOLOR-TEST" 27 EMIT ." [39m"` —
> `EMIT` for the raw `ESC` (27) bytes, `."` for the literal `[95m`/`[39m` text between them.
> Chose SGR 95 (bright magenta, the `p >= 90 && p <= 97` branch in `apply_sgr()`) specifically
> because it's a third, previously-unexercised code path — 4.4h already covered `38;2;r;g;b`
> truecolor (the prompt colors), this covers the bright-palette branch, distinct from both.
>
> Three-arch screendump evidence, each showing `COLOR-TEST` rendered in bright magenta via
> the TTF path, immediately after the still-orange `[Hera]`/cyan `ok>` prompt and the
> echoed input line in default gray — confirming the SGR parser and the 4.4j-retargeted draw
> call work together, not just independently:
> [evidence/amd64/qemu-screenshot-20260811-200123-4.4k-sgr-color-injection.png](evidence/amd64/qemu-screenshot-20260811-200123-4.4k-sgr-color-injection.png),
> [evidence/aarch64/qemu-screenshot-20260811-200459-4.4k-sgr-color-injection.png](evidence/aarch64/qemu-screenshot-20260811-200459-4.4k-sgr-color-injection.png),
> [evidence/riscv64/qemu-screenshot-20260811-200719-4.4k-sgr-color-injection.png](evidence/riscv64/qemu-screenshot-20260811-200719-4.4k-sgr-color-injection.png)
> — first screendump evidence ever captured for aarch64/riscv64 in this document (every
> prior screendump item, e.g. 4.4c/4.4h, was amd64-only with that gap explicitly accepted;
> this item closes it incidentally, not by its own design). aarch64/riscv64 both confirmed
> booting at 800×600 (`-device ramfb`'s default) in the process — a data point 4.4l will
> want.
>
> Standard three-arch boot+log basis (unmodified from 4.4j — this item made no code changes):
> amd64 (`logs/20260811-200017/amd64/`), aarch64 (`logs/20260811-200250/aarch64/`), riscv64
> (`logs/20260811-200834/riscv64/`) — `Failed: 0`, identical dict-hashes, all three.
- [ ] **4.4l — Confirm actual booted framebuffer resolution, all three architectures.**
Investigation only. amd64 already confirmed this session: 1280×800 (QEMU/OVMF GOP default,
read directly off the 2026-08-11 verification screendump). aarch64/riscv64 unconfirmed.