Teach the console the sequences the corpus already speaks, and let the status port see the window

Three things Snake found the moment somebody ran it in a window, and all three are the same
kind of mistake: the console grew a screen and kept asking the terminal.

IT COULD NOT CLEAR THE SCREEN. Every program here that moves a cursor does it with ANSI
escapes, because until there was a screen the thing on the other end was somebody's
terminal. The controller drew "[2J" as three letters and left the board underneath. It now
parses them, which is what a video terminal did - a VT100 is exactly this. The whole corpus
uses two, ESC[2J and ESC[H, and the general shape is recognised so anything else is
swallowed rather than drawn: a sequence nobody implemented should leave no marks. Cursor
positioning is in too, since it is the same parse and one line more.

IT DID NOT SEE KEYS FROM THE WINDOW, but did when the terminal behind it was focused, which
is the whole diagnosis in one sentence. Snake polls the READY bit and never blocks, and
consoleFetch - what the status port asks - was polling standard input regardless of whether
a front end had installed a hook. So a window's keys were invisible to every program that
looks before it reads, and a keystroke aimed at the terminal would be picked up instead.

The hook now takes a question. Zero is the status port looking, and must not present or
sleep: a program polling in a loop would otherwise be charged a frame for every glance. One
is the data port blocking, where presenting is exactly right, because a machine waiting for
a key is still a machine somebody is looking at. One value for both would have made either
polling ruinous or waiting dead.

AND IT RAN SLOWLY, which was the same bug wearing a hat: a game that never receives a
steering key is a game that only ever goes one way.

Six more checks in Tests/video.sh, to 32: that ESC[2J clears, that ESC[H goes to the corner
without disturbing what is drawn, that ESC[3;5H counts rows and columns from one, and that
an unknown sequence is swallowed and leaves nothing behind.

The hook itself is still the one thing here the suite cannot reach - it exists only when
there is a window, and this host has no display. It was found by a person playing Snake,
which is where the Test Manual says these go on being found.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Source/Emulator/voyager.c

@@ -113,12 +113,22 @@ static void presentFrame(void) {
 // What the console asks while it is waiting. Presenting from in here is what keeps the
 // window answering, and EndDrawing paces it, so waiting for a key costs a frame rather
 // than a spin.
-static int voyagerKey(void) {
-    if (!windowOpen || WindowShouldClose()) {
-        windowOpen = 0;
+static int voyagerKey(int mayWait) {
+    if (!windowOpen) {
         return CONSOLE_GONE;
     }
-    presentFrame();
+    if (mayWait) {
+        if (WindowShouldClose()) {
+            windowOpen = 0;
+            return CONSOLE_GONE;
+        }
+        // Presenting is what keeps the window answering while the machine waits, and
+        // EndDrawing paces it, so waiting for a key costs a frame rather than a spin.
+        presentFrame();
+    }
+    // Asked without waiting, this takes whatever the last frame's event poll left behind
+    // and returns at once. A program polling the status port sixty times between frames
+    // must not be charged a frame for each look.
     int character = GetCharPressed();
     if (character > 0 && character < 128) {
         return character;