The pad was working; the game was told there was not one

0x64 counted only the RECORDED pads. So a controller plugged into Voyager
reported its buttons perfectly, and every game asking whether there was a
controller was told no - which is exactly what Lunar Porter asked, once,
at startup, before falling back to the console for the rest of the run.

The cause is worth naming: a front end calls padSet every frame for every
pad, so "held nothing" is the commonest thing it says and cannot also mean
"there is no pad here". Connected is said separately now. Pad nought is
always there behind a window, because the keyboard is behind it - which is
the useful answer rather than the literal one.

And Pad.asm, which is what should have existed before any of that guessing
began. It prints a line whenever a pad changes, and tells apart the three
states that look identical from inside a game that will not respond: one
nobody noticed, one mapped to nothing, and a mapping that is wrong.

WHY A PROGRAM AND NOT A PRINT IN THE FRONT END: because the question is
what the MACHINE can see. A front end reporting what it thinks it is
sending answers a different question, and the gap between those two is the
whole of this bug.

It also found that osPrintNumber takes A as the HIGH half - the same way
round as the shift register and every other pair here, and not what a byte
in A wants. Every value came out 256 times too big.

Gravity is one frame in ten rather than six. The ratio between thrust and
gravity is the feel; how often the tick comes round is how fast that feel
arrives, and one in six was still touchy. Same lander, more time to think.

And the verdict waits for a key. It printed and left immediately, taking
the screen with it - so the one thing worth seeing, the lander sitting on
the ground it had just reached, was gone before it could be looked at.

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

Source/Emulator/pad.c

@@ -9,6 +9,7 @@
 static uint8_t held[PAD_COUNT];
 static FILE *recorded[PAD_COUNT];
 static uint8_t live[PAD_COUNT];
+static int connected[PAD_COUNT];
 
 // ---- The frame the recordings advance on ----
 //
@@ -26,6 +27,7 @@ void padReset(void) {
     for (int n = 0; n < PAD_COUNT; n++) {
         held[n] = 0;
         live[n] = 0;
+        connected[n] = 0;
         // The files are NOT closed or forgotten. They were named on the command line and
         // outlive a reset, the same as a disk image does: a machine that restarted itself
         // and lost its controllers would be a strange thing to debug.
@@ -41,10 +43,11 @@ void padFromFile(int which, FILE *file) {
     recorded[which] = file;
 }
 
-void padSet(int which, uint8_t heldNow) {
+void padSet(int which, int isConnected, uint8_t heldNow) {
     if (which < 0 || which >= PAD_COUNT) {
         return;
     }
+    connected[which] = isConnected;
     live[which] = heldNow;
 }
 
@@ -76,7 +79,10 @@ uint8_t padRead(uint8_t port) {
     if (port == PAD_PRESENT) {
         uint8_t there = 0;
         for (int n = 0; n < PAD_COUNT; n++) {
-            if (recorded[n] != NULL) {
+            // A recording is a pad, and so is anything the front end says is plugged in.
+            // Counting only the recordings meant this said nought on the one machine that
+            // has real controllers, which is the only machine where the answer matters.
+            if (recorded[n] != NULL || connected[n]) {
                 there |= (uint8_t)(1u << n);
             }
         }