Dragon-s-Lair-X68k

50 Commits 1 Branch 0 Tags

1 Commits

Include renames

Author	SHA1	Message	Date
prosolis	8b5f51704c	Take the climb to a real branch point, and find the cadence has a third column FINDINGS 70, and it closes ROADMAP P6. 65.6 recorded that "the slack table is here, but 51.3's refill climb with a second consumer through a real branch point is not", and 67.6 repeated it verbatim two sessions later. tools/analysis/36_branch_audio.py is that run: 51.3's surplus model, 56.3's 612 real branch points, 32's cadence arithmetic, both containers' headers and the buffer constants of the player 68 measured, in one place. No machine -- all five were already numbers. AUDIO IS 1.7% OF THE CODEC WIRE AND UP TO 3.30x OF THE CLIMB. Slack accrues out of pipe - wire, which is a small difference of two large numbers, so a second consumer is not priced by its share of the wire -- which is how every budget in this tree since FINDINGS 8 has quoted it. At 451.4 KB/s (the container's own zero-prefill pipe, 49.5) in a 256 KB ring the climb goes 6.70 s -> 22.11 s and the branch points arriving under it go 482/612 (79%) -> 603/612 (99%). At 488 it is 1.19x, at 600 it is 1.05x. Correction to 56.4: it charged audio at ratectl.AUDIO_KBPS = 7.8, which is 7,812.5 B/s in decimal kB; in binary KB the figure is 7.6294, so the placeholder was 2.24% high and every column moved in the flattering direction by less than one part in six hundred of the wire. AND ON THE PACKED BRANCH THERE IS NO CLIMB AT ALL. A record goes straight into GVRAM, so the video lookahead is zero records and 56.4's alarming column is vacuous when every frame arrives with less lookahead than the one before it. Acceptance there is a per-frame deadline, not an average, which is why B1 has to name a burst rate. The only consumer on that branch with any lookahead is the audio one: 1.833 s of sound held against 0.000 s of picture. And at 589.6 KB/s -- the acceptance figure this project quotes -- the sounded container's surplus is exactly zero: it plays and never banks a byte, while the silent one climbs its record in 6.38 s. THE COST NOBODY HAD COUNTED. A DLXP2 group is `lump k, then F records`, so lump k is at a LOWER address than every record of its group but the first, and a seek to record i finds its audio behind it. Measured on the 409 within-container seek targets of the arcade's own graph at the shipped F=11: mean 416.5 ms of silence entering a branch, median 416.7, p90 750.0, worst 833.3, and only 36 of 409 land on a group boundary. The other 203 -- the scene changes -- are free by construction, because lump 0 sits between the header and record 0. The container's own start is the one branch point the cadence costs nothing at, and it was the only one anybody had looked at. SO THE CADENCE PICK IS REOPENED, on a third column. 32_audio_wire chose F=11 on padding and RAM; F=1, the cadence it called the worst one, has no group to enter off-boundary at all, and gives back 12,288 B of RAM for +4.36 KB/s of wire (0.74% of the acceptance figure). The alternative is a second read: lump k is up to 503,808 B behind, so it is a separate command of 7,168 B -- 11.7 ms against 416, 36x cheaper in time -- and src/player/packed.s starts PG_AK/PG_AKF at lump 0 and has no audio seek path at all. Nothing here decides it; the deciding number is what one more SCSI command costs, and that is B1's. The content is not uniform mod F either: the measured mean runs 0.67x..1.23x of a uniform assumption across the sweep, and the 1.00x at F=11 is a coincidence. New check.sh stage, ~10 s, and it gates the STRUCTURE and deliberately not the milliseconds: audio never shortens a climb, the shipped cadence strands most within-container branches, F=1 strands none, and the lump read is an order of magnitude cheaper than the silence it removes. The one thing 70.3 and 70.4 rest on is a DESIGN ASSUMPTION and is printed in the tool's own output: one container per SCENE (53, 55.1, 56.3). One container per sequence makes every seek land on frame 0 and empties both sections. No encoder, player or container byte moved. Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6	2026-08-25 14:21:32 -07:00

Author

SHA1

Message

Date

prosolis

8b5f51704c

Take the climb to a real branch point, and find the cadence has a third column

FINDINGS 70, and it closes ROADMAP P6.  65.6 recorded that "the slack table is
here, but 51.3's refill climb with a second consumer through a real branch point
is not", and 67.6 repeated it verbatim two sessions later.
tools/analysis/36_branch_audio.py is that run: 51.3's surplus model, 56.3's 612
real branch points, 32's cadence arithmetic, both containers' headers and the
buffer constants of the player 68 measured, in one place.  No machine -- all
five were already numbers.

AUDIO IS 1.7% OF THE CODEC WIRE AND UP TO 3.30x OF THE CLIMB.  Slack accrues out
of pipe - wire, which is a small difference of two large numbers, so a second
consumer is not priced by its share of the wire -- which is how every budget in
this tree since FINDINGS 8 has quoted it.  At 451.4 KB/s (the container's own
zero-prefill pipe, 49.5) in a 256 KB ring the climb goes 6.70 s -> 22.11 s and
the branch points arriving under it go 482/612 (79%) -> 603/612 (99%).  At 488
it is 1.19x, at 600 it is 1.05x.  Correction to 56.4: it charged audio at
ratectl.AUDIO_KBPS = 7.8, which is 7,812.5 B/s in decimal kB; in binary KB the
figure is 7.6294, so the placeholder was 2.24% high and every column moved in
the flattering direction by less than one part in six hundred of the wire.

AND ON THE PACKED BRANCH THERE IS NO CLIMB AT ALL.  A record goes straight into
GVRAM, so the video lookahead is zero records and 56.4's alarming column is
vacuous when every frame arrives with less lookahead than the one before it.
Acceptance there is a per-frame deadline, not an average, which is why B1 has to
name a burst rate.  The only consumer on that branch with any lookahead is the
audio one: 1.833 s of sound held against 0.000 s of picture.  And at 589.6 KB/s
-- the acceptance figure this project quotes -- the sounded container's surplus
is exactly zero: it plays and never banks a byte, while the silent one climbs
its record in 6.38 s.

THE COST NOBODY HAD COUNTED.  A DLXP2 group is `lump k, then F records`, so lump
k is at a LOWER address than every record of its group but the first, and a seek
to record i finds its audio behind it.  Measured on the 409 within-container
seek targets of the arcade's own graph at the shipped F=11: mean 416.5 ms of
silence entering a branch, median 416.7, p90 750.0, worst 833.3, and only 36 of
409 land on a group boundary.  The other 203 -- the scene changes -- are free by
construction, because lump 0 sits between the header and record 0.  The
container's own start is the one branch point the cadence costs nothing at, and
it was the only one anybody had looked at.

SO THE CADENCE PICK IS REOPENED, on a third column.  32_audio_wire chose F=11 on
padding and RAM; F=1, the cadence it called the worst one, has no group to enter
off-boundary at all, and gives back 12,288 B of RAM for +4.36 KB/s of wire
(0.74% of the acceptance figure).  The alternative is a second read: lump k is
up to 503,808 B behind, so it is a separate command of 7,168 B -- 11.7 ms
against 416, 36x cheaper in time -- and src/player/packed.s starts PG_AK/PG_AKF
at lump 0 and has no audio seek path at all.  Nothing here decides it; the
deciding number is what one more SCSI command costs, and that is B1's.  The
content is not uniform mod F either: the measured mean runs 0.67x..1.23x of a
uniform assumption across the sweep, and the 1.00x at F=11 is a coincidence.

New check.sh stage, ~10 s, and it gates the STRUCTURE and deliberately not the
milliseconds: audio never shortens a climb, the shipped cadence strands most
within-container branches, F=1 strands none, and the lump read is an order of
magnitude cheaper than the silence it removes.

The one thing 70.3 and 70.4 rest on is a DESIGN ASSUMPTION and is printed in the
tool's own output: one container per SCENE (53, 55.1, 56.3).  One container per
sequence makes every seek land on frame 0 and empties both sections.

No encoder, player or container byte moved.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

2026-08-25 14:21:32 -07:00