diff --git a/dwt/notes/VISUAL_INJECTION.md b/dwt/notes/VISUAL_INJECTION.md index b097541..06d4418 100644 --- a/dwt/notes/VISUAL_INJECTION.md +++ b/dwt/notes/VISUAL_INJECTION.md @@ -162,3 +162,30 @@ at idle the handler never takes the trampoline (counter 0), so it does not help. | `dwt/visual/inject.py` | challenge-solving client with `--jump-wait`, liveness, peek | | `dwt/visual/*.lua` | frame clock / interrupt probe / PC and hook probes | | `dwt/evidence/visual/` | frames, crops, client and MAME logs, `summary.txt` | + +## Orchestrator verification (2026-10-18) + +**Confirmed: visual injection works.** `posthandler_persist_3600.png` shows a +black 64x64 box on the live Terminal Manager's Memory bar while the OS is +running — root weave rendered, "TCP/IP is now up.", the Messages pane logging +"Debug connection from IP host 192.168.99.1" twice, memory figure 3099 KB. +That is injected code drawing into a live OS, not a frozen frame. + +**Not confirmed: the blink.** The 3450/3480/3500 on/off/on frames cannot be the +programmed toggle: + +* `blink.asm` toggles state every `0600h` = 1536 display interrupts. +* the counter at `0186F000` advances about once per emulated frame + (10 -> 793 over frames 3524 -> 4227 in `blink_resident_client.log`), so the + toggle period is ~1536 frames (~21 s), not the 30 frames between the crops. +* the run the summary attributes to the blink used `blink.bin` (172 B), whose + counter kept incrementing — the hook ran every interrupt, and the stock + handler repaints after it, so frame-to-frame on/off is a repaint race. +* the payload meant to draw *after* the handler (`blinkev.bin`) draws once and + then loses the TCP stack (`blink_repeat_client.log`: challenge, timeout, + "No route to host"). + +So the durable result is a **persistent box**, and the hook demonstrably runs +every frame, but a **controlled blink is not established**. Settling it needs a +time series spanning >1536 frames around a known counter value, or hooking the +display work path (`3F579880`) rather than the vector.