From 0019770bea01eafd9a3fd7eebc42410069890a92 Mon Sep 17 00:00:00 2001 From: Cyd Date: Thu, 16 Jul 2026 17:16:22 -0500 Subject: [PATCH] Resolve the frame: this death-cam draw IS the object (no terrain) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit payload_scan.py scans all writes into the payload region across the draw: 14,223 writes, every recoverable screen coordinate in x[66,236] = the object's range, nothing near 0/400/832. So this death-cam frame carries no geometry beyond the object -- the ~64 triangles account for essentially all payload writes; the rest is a background clear. The "ground and sky still to render" was a wrong premise for THIS frame: the array's object render IS this frame's geometry. Wider battle scenes with terrain live in mid-mission frames (a separate capture). Readout §05 + last-mile updated. Co-Authored-By: Claude Opus 4.8 --- emulator/firmware-decomp/payload_scan.py | 68 ++++++++++++++++++++ emulator/firmware-decomp/render-readout.html | 16 +++-- 2 files changed, 77 insertions(+), 7 deletions(-) create mode 100644 emulator/firmware-decomp/payload_scan.py diff --git a/emulator/firmware-decomp/payload_scan.py b/emulator/firmware-decomp/payload_scan.py new file mode 100644 index 0000000..3d28360 --- /dev/null +++ b/emulator/firmware-decomp/payload_scan.py @@ -0,0 +1,68 @@ +"""Robustly capture the frame's geometry footprint from the compiled micro-code. +Hook EVERY write into the payload region (0x08014000..0x08019000) across the whole draw +and record two things per write: fixed-point screen coords (v<0x10000, v/256 in [10,832]) +and edge/plane slope floats. No dedup, no timing assumption -> we see every primitive's +screen constants as they're compiled. If they spread across x[0,832] there is terrain.""" +import sys, time, struct, pickle +sys.path.insert(0, r'C:\VWE\TeslaRel410\emulator\firmware-decomp') +import emu860, dis860, emu_main +emu860.Mem.log = lambda self, *a, **k: None +S = r'C:\Users\cyd\AppData\Local\Temp\claude\c--VWE-TeslaRel410\4e848c76-6e89-4034-8047-d8d491cb32d8\scratchpad' +snap = pickle.load(open(S + r'\snapv2.pkl', 'rb')) +r = emu_main.MainRunner(r'C:\VWE\TeslaRel410\dpl3-revive\patha\cap7.raw.bin', fw='capfw7', max_cmds=6000) +cpu = r.cpu +cpu.mem.pages = {k: bytearray(v) for k, v in snap['pages'].items()} +cpu.ctrl.clear(); cpu.ctrl.update(snap['ctrl']) +cpu.r = list(snap['r']); cpu.f = list(snap['f']); cpu.cr = dict(snap['cr']); cpu.pc = snap['pc'] +cpu._apipe = list(snap['apipe']); cpu._mpipe = list(snap['mpipe']); cpu._fp_pipes() +cpu._lpipe = list(snap['lpipe']); cpu._gpipe = list(snap['gpipe']) +cpu._kr, cpu._ki, cpu._t = snap['kr'], snap['ki'], snap['t'] +cpu.lcc = snap['lcc']; r.qi = snap['qi']; r.heap = list(snap['heap']) + +LO, HI = 0x08014000, 0x08019000 +coords = [] # (addr, screen_value) +slopes = [] +nwrite = 0 +orig = emu860.Mem.w32 +def asf(w): return struct.unpack('> 23) & 0xff + if 1e-4 < abs(f) < 1.0 and 1 < e < 254: + slopes.append(round(f, 5)) + return orig(self, addr, val) +emu860.Mem.w32 = w32 + +t0 = time.time(); startq = r.qi +while time.time() - t0 < 200: + if r.qi >= startq + 3 and nwrite > 0: break # finish the first draw's compile + h = r.hooks.get(cpu.pc) + if h: + if h(cpu) == 'done': break + continue + if not cpu.step(): break +emu860.Mem.w32 = orig + +cv = [c[1] for c in coords] +print("payload-region writes: %d coord-like: %d slope-like: %d (cmd %d)" % + (nwrite, len(coords), len(slopes), r.qi)) +if cv: + print("coord range: [%.0f .. %.0f] distinct: %d" % (min(cv), max(cv), len(set(cv)))) + import collections + hist = collections.Counter(int(c // 32) * 32 for c in cv) + print("\nscreen-coord spread (buckets of 32, x up to 832):") + mx = max(hist.values()) + for b in range(0, 833, 32): + n = hist.get(b, 0) + if n: print(" %3d: %s %d" % (b, '#' * min(50, int(n / mx * 50) + 1), n)) + print("\ndistinct coords:", sorted(set(cv))) +pickle.dump({'coords': coords, 'slopes': slopes}, open(S + r'\payload_scan.pkl', 'wb')) diff --git a/emulator/firmware-decomp/render-readout.html b/emulator/firmware-decomp/render-readout.html index 0224ed9..302923f 100644 --- a/emulator/firmware-decomp/render-readout.html +++ b/emulator/firmware-decomp/render-readout.html @@ -350,14 +350,15 @@

What this is not, yet: a full from-scratch run of - the compiled micro-code the DMA ships (§02) — the form the ground and sky take, since they - carry no stored vertices. But that stream is now largely decoded: the command lists read cleanly, + the compiled micro-code the DMA ships (§02) — the form the geometry takes on the wire to the + card. But that stream is now largely decoded: the command lists read cleanly, the SENDE z-sweep resolves into a regular 4-word instruction, and its coefficients are the same ones driving this depth buffer — the array's inputs are - cross-validated against the hardware's own compiled stream. The full frame, we now know, - cycles its primitives through two double-buffered coefficient blocks — 1051 SENDs, 384 - TILE ops across 105 tiles — so what remains is capturing each primitive as its SEND fires - and running them all, not reversing an opaque binary.

+ cross-validated against the hardware's own compiled stream. And scanning + all 14,223 payload writes of this draw, every screen coordinate lands in the object's own + range (x 66–236) — this death-cam frame carries no geometry beyond + the object; the rest is a background clear. So the array's render above isn't one primitive of + many: for this frame, it is the geometry.

@@ -395,7 +396,8 @@
  • The array's computational model runs and matches the reference — the piece left is executing the board's own compiled micro-code
  • The per-region DMA command lists decode cleanly (§02) — SEND / SENDE / TXDN / TILE / GOTO, tile-relative
  • The SEND payloads carry real float coefficients in a regular bit-serial sweep — recoverable, not opaque
    • -
  • What's left: pin the control-word fields, run the sweep per tile → the ground and sky that carry no stored vertices
    • +
  • Coefficients verified to 0.2% against the geometry; for this death-cam frame, the object is the geometry (§05)
    • +
  • Wider battle scenes with terrain live in mid-mission frames — a separate capture, since this death-cam view holds one object