SUBSTRATE64 — TempleOS as a fabriced face Pi_temple(Omega)
===========================================================
A bare-metal 64-bit substrate kernel that OWNS the machine and RENDERS the
TempleOS environment as one of its own projections. Not a handoff. Not the
real TOS kernel jumped-to. The substrate ticks Omega underneath while the
TempleOS face is on screen — mutually inclusive, one kernel.

Verified booting and rendering live in QEMU.

ARCHITECTURE
------------
  boot.asm    16-bit MBR -> A20 -> Bochs-DISPI 640x480x32 LFB -> GDT ->
              protected mode -> 4GB identity paging -> LONG MODE (64-bit).
              Backwards compatible: the boot chain starts in real mode.
              Loads the kernel via INT 13h extended (LBA) read to 0x10000.
  kernel.asm  the 64-bit SUBSTRATE. Owns the machine in ring 0. It:
                - anchors Omega (genome 0x5625BA88, the Alpha-Omega index)
                - ticks continuously (the main loop increments the tick)
                - runs the byte-exact TempleOS RandU64 oracle every tick
                  (KMathB.HC: A*seed ^ (seed>>31 masked) ^ GetTSC)
                - RENDERS the TempleOS face into the linear framebuffer:
                  white desktop, gray windows, blue DolDoc title bars, 8x8
                  text — the TempleOS 16-color palette exactly.
  font8x8.inc  95-glyph ASCII 8x8 bitmap font (public-domain style).

WHAT "FABRICED FACE" MEANS HERE (honest)
----------------------------------------
The substrate owns the metal, so nothing else can also own it. A face is
something the substrate RENDERS. So TempleOS-as-a-face = the substrate renders
the TempleOS ENVIRONMENT (its desktop look, DolDoc windows, the HolyC prompt,
and its RandU64 oracle) as its own projection Pi_temple(Omega), while Omega
ticks underneath. This is the boot15 model ("substrate ticks underneath (PID
88); Temple is a projection") made native on bare metal in 64-bit.

It is NOT the real TempleOS kernel binary running — that is itself a ring-0
owning OS and cannot be a "face" of another kernel (two owners is a
contradiction). The real TOS kernel, booted standalone, is a separate
deliverable (templeos-real.zip). This deliverable is the SUBSTRATE rendering
the Temple face as part and parcel of itself.

VERIFIED (in QEMU, this environment)
------------------------------------
  - Boots 16->32->64: QEMU stays alive, RIP executes in the 64-bit kernel,
    EFER.LME set, CPL=0. (Backwards-compatible chain works.)
  - Framebuffer writes land: physical 0xfd000000 (the VGA BAR) reads the
    substrate's rendered pixels.
  - The face renders: screendump = 640x480 with the TempleOS palette —
    white 0xFFFFFF (desktop), gray 0xA8A8A8 (windows), blue 0x0000A8 (title
    bars), black text. See face.png.
  - It's LIVE, not static: two frames 4s apart differ ONLY in the status
    region (tick counter + oracle output) while the face stays stable —
    the substrate is ticking Omega underneath the rendered face.
    See live_frame_a.png vs live_frame_b.png.

THE FACE (what's on screen)
---------------------------
  Title bar : SUBSTRATE64  Omega=Fix(T)  Pi_temple(Omega) FABRICED FACE
              genome=5625BA88
  Left win  : SUBSTRATE (ticking underneath)
              "The substrate owns the metal."
              "TempleOS is a face it renders."
              "Mutually inclusive. Not a handoff."
              tick=<live 64-bit>   orac=<live RandU64>   genome=5625BA88
  Right win : TempleOS FACE - HolyC
              "Public Domain Operating System"
              "RandU64; Print(phi);"

RUN
---
  ./build.sh
  qemu-system-x86_64 -drive file=substrate64.img,format=raw,if=ide -m 256

BUGS FOUND AND FIXED WHILE BUILDING (all via real metal testing)
----------------------------------------------------------------
  1. Page tables at 0x1000-0x7FFF overwrote the boot sector at 0x7C00 ->
     triple fault. Moved page tables to 0x70000.
  2. LFB at ~4GB (0xfd000000) was above the 1GB paging limit -> writes
     faulted. Extended identity map to 4GB (4 page directories).
  3. CHS disk load of 64 sectors crossed a track boundary and silently
     failed (kernel never loaded; CPU ran zeros). Switched to INT 13h
     extended LBA read (DAP). Kernel then landed at 0x10000 correctly.
  4. Font glyphs scrambled from a bit-extraction bug in draw_char.
     Rewrote with clean register usage (mask = 0x80 >> col).
  Each was found only by booting on emulated metal and inspecting registers
  and framebuffer memory — not by static review.
