jake/SplitBit-Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Anachronaut
2026-09-03 12:38:43 -04:00
co-authored by Claude Opus 5
parent caf5e1f99d
commit a163c670d0
8 changed files with 186 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SplitBit Test Manual.md
+13 -1
View File
@@ -9,7 +9,7 @@ believe them.
## What The Suite Claims:
The suite is not one thing. It is eleven scripts making five different kinds of claim, and
The suite is not one thing. It is twelve scripts making five different kinds of claim, and
knowing which claim you are relying on is the whole point of this document. A recorded
transcript and a byte-for-byte comparison against a second implementation both print
`[ok ]`, and they are worth wildly different amounts.
@@ -64,12 +64,24 @@ Individual scripts can be run on their own, from anywhere:
./Tests/agree.sh The two filesystems against each other.
./Tests/lint.sh SplitLint against its fixture and the corpus baseline.
./Tests/lint.sh --bless Record the corpus baseline. See below.
./Tests/replay.sh A recording of input, played back as itself.
./Tests/docs.sh The manuals against the code.
```
`Tests/makedisks.sh` is not in that list because it checks nothing. It builds the disk
images the other scripts read, and `run.sh` calls it.
`Tests/replay.sh` checks that `--record-pad` and `--pad` are the same format read two ways.
A recording is written one byte a frame and is only worth having if playing it back does what
was recorded, so the strongest form of that claim is checked: 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 by hand 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.
`Tests/break.sh` is not in it either, for the reason turned round: it checks that a check
works. Run it by hand when a check is written, not as part of `make test`.