A demo recorder: --record-pad writes what --pad reads

One byte a frame, in exactly the format the player takes, so a recording
needs no conversion and there is no second format to keep in step. That
symmetry is the feature, and it makes the strongest form of the claim
testable: a recording is made OF a playback, and the bytes coming out have
to be the bytes that went in.

It exists because some inputs cannot sensibly be written by hand. Flying a
lander from one base to another is a few hundred frames of steering that
has to arrive somewhere eight cells wide, and several attempts at
authoring one got within two columns and no closer. That is a piloting
exercise rather than a test. Playing it once and keeping what happened is
the answer.

A BYTE FOR EVERY FRAME, written inside the loop that advances the
recordings rather than after it, so a machine that jumped several frames
at once still writes one for each. A recording is a timeline: one that
skipped the frames nobody looked at would play back faster than it was
flown.

What is recorded is what the DEVICE WOULD REPORT, not the live state - a
recording of a playback that wrote the live state would be a file of
noughts. And it is flushed as it goes, because a recording is usually
stopped by whoever is playing rather than by the program ending, and a
demo lost to a buffer is a demo flown twice.

Tests/replay.sh is where this and whatever follows it are checked. Twelve
scripts now.

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

Source/Emulator/pad.h

@@ -79,6 +79,18 @@ void padFromFile(int which, FILE *file);
 // underneath was reporting its buttons perfectly.
 void padSet(int which, int connected, uint8_t held);
 
+// ---- Writing one down ----
+//
+// A demo recorder. What it writes is EXACTLY WHAT --pad READS, one byte a frame, so playing a
+// recording back needs no conversion and no second format - and the round trip is a property
+// worth testing: play a file while recording it and the same bytes come out.
+//
+// It exists because some inputs cannot sensibly be written by hand. Flying a lander from one
+// base to another is a few hundred frames of steering that has to arrive somewhere four cells
+// wide, and hand-authoring one is a piloting exercise rather than a test. Playing it once and
+// keeping what happened is the whole answer.
+void padRecordTo(int which, FILE *file);
+
 void padTick(unsigned long now);
 uint8_t padRead(uint8_t port);