Robert Allan JamesandClaude Opus 5
f81e9c92bc
fb_scroll_rows() hardcoded the pixel distance it physically shifts the framebuffer by as char_rows * 16 * scale -- the bitmap-font (font_8x16.c) cell height -- regardless of which glyph mode vt100.c actually had active. In TTF mode (the REPL's default, cell height 24px via VT100_TTF_CELL_H_PX) this meant every scroll_up(1) call physically shifted the framebuffer by only 16px while the text model (g_vt.rows, py_of()) placed each row 24px apart. That 8px-per-scroll shortfall compounds with every subsequent scroll: a few scrolls barely show it, but enough scrolls -- or scrolling quickly, which is just many scrolls in a short span -- accumulates into visible pixel overlap between rows, with newer lines drawn on top of the tail end of older ones. fb_scroll_rect() (the box-confined scroll added later for 4.4t) already carried a doc comment calling this out explicitly, describing its own explicit pixel_rows parameter as the fix for fb_scroll_rows()'s "fixed 16px-row assumption" -- fb_scroll_rows() itself was just never updated to match. Fixed by changing fb_scroll_rows()'s parameter from an implicit char_rows count to an explicit pixel_rows count (matching fb_scroll_rect()'s existing convention), and having its one caller (vt100.c's scroll_up()) pass lines * cell_h() -- the real active cell height -- instead of a raw line count for the callee to guess at. Verified: booted amd64 to the REPL (TTF mode active per sk_repl()'s own console_fb_enable_ttf() call), let boot chatter + WORDS output scroll the screen through thousands of accumulated scroll_up() calls, then measured every visible line's y-position via a QMP screendump. Spacing held at a perfectly consistent 24px (TTF cell height) top to bottom with zero drift -- the old hardcoded-16px bug could not have produced that after this many scrolls. Re-verified boot to ok> on all three architectures (amd64/aarch64/riscv64) per repo acceptance policy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
capsules/
FORTH personality files loaded by the VM at boot. A capsule is an immutable, content-addressed payload; its XXHash64 hash is its identity. Any mutation changes the hash and the birth protocol rejects the image.
Key files
| File | Type | Purpose |
|---|---|---|
init.4th |
(m) MAMA_INIT |
Default Mama VM personality — loaded at LBN 2048 |
ACL.4th |
user | Word-level ACL system; self-activating at boot |
zuse.4th |
user | Bootstrap superuser; loaded by ACL.4th |
doe.4th |
user | DoE workload words (EXEC-DOE) — opt-in |
init-0.4th … init-9.4th |
(p) |
Numbered personality variants |
init-l8-*.4th |
(p) |
L8 Jacquard mode variants (stable/volatile/diverse/temporal/transition/omni) |
hermes/init.4th |
(p) |
Hermes baby VM personality |
artemis/init.4th |
(p) |
Artemis baby VM personality |
Block namespace
Block ranges are shared across all loaded capsules — collisions cause silent word-definition overwrites.
| Range | Owner |
|---|---|
| 2048–2099 | init.4th |
| 2100–2199 | doe.4th |
| 3000–3999 | workload capsules |
| 4000+ | user-defined (ACL.4th, zuse.4th, …) |
Each block is limited to 1024 bytes. Verify with wc -c before committing.
See also
experiments/bare_metal/README.md— DoE protocols and block namespace rulesdocs/03-architecture/word-acl/DESIGN.md— ACL system designtools/mkcapsule.c— assembles capsules intocapsule_generated.c- Project root