Files

Sylpheed RE agent 2463748a71 re: the trailing data table is a per-phase TIMELINE of scheduled routines

Decodes the table found at the end of every phase region.  Layout:

    int  N
    N x [ int offset ; float t ; int kind ]      -- 8-byte typed records,
                                                    tag 0x19 int, 0x1A float

1 + 3N matches the record count in every phase measured (Stage 02: 76/40/55
records for N = 25/13/18).

Checks, all independent of each other:
  schedule entries disc-wide                675
  0x1A float records disc-wide              675   (counted by a different route)
  offsets landing on the instruction stream 675/675 = 100.0%
  control, random 4-aligned offsets                  33.3%

The floats are seconds -- 0, 0.5, 1, 4, 5, 30, 50, 60, 90, 120, 150, 170, 180, 210,
240, 270, 300, 330, 360, 420, 570, 1020, 1080, 1140, 1170 -- and the targets are small
one-shot coroutines that set arguments, call one built-in and end_coroutine.  kind is
0 (556) or 5 (119) and is not identified.

Runtime cross-check, recorded as consistency rather than confirmation: the closed
REMAINING OB work measured Stage 02's squadron arrivals at t = 0, 120 and 210 s over
n=5 emulator runs, and all three appear in phase 1's static schedule, with 120 and 210
each appearing TWICE.  These are round numbers and phase 1 has ~22 distinct times over
0-1170, so presence alone is not unlikely; the doubling is the sharper detail and was
not predicted in advance.

New artefacts data/isl-stage02-schedule.txt and data/isl-schedule-all.txt with a
committed generator (isl_report.py schedule).  calls, phase-ends, conditions and
phase-guards all regenerate byte-identical.

Not settled and said so: kind is unread; the consumer is unread, so the decode rests
on the structural checks above; whether the clock is per-phase or per-mission is an
inference from the layout; and this is NOT what starts the unreachable code -- 0 of
the 675 targets are unreached run-starts, so that ~15% gap stands.

2026-08-27 07:07:35 +00:00

3.0 KiB

Raw Blame History

✅ Each phase carries a TIMELINE — 675 scheduled routines across the disc

The trailing data table found at the end of every phase region (isl-stream-entry-points) is decoded. It is the mission's scripted event schedule.

Layout

After the phase's code ends — at the first value of that phase's mission-level 0x1883 record — comes a run of 8-byte typed records, tag 0x19 = int, 0x1A = IEEE float:

int   N                                     -- entry count
N x [ int offset ; float t ; int kind ]

1 + 3N matches the record count in every phase measured: Stage 02's three phases hold 76, 40 and 55 records for N = 25, 13 and 18.

✅ The checks


schedule entries disc-wide	675
`0x1A` float records disc-wide	675 — the same number, independently counted
offsets landing on the instruction stream	675 / 675 = 100.0 %
control: random 4-aligned offsets	33.3 %

The float count and the entry count are derived by different routes and agree exactly, and every single offset resolves. kind is 0 (556) or 5 (119).

✅ The floats are seconds

The distribution is unmistakable: 0, 0.5, 1, 4, 5, 30, 50, 60, 90, 120, 150, 170, 180, 210, 240, 270, 300, 330, 360, 420, 570, 1020, 1080, 1140, 1170 … mission times, not fractions.

And the targets are what a schedule would point at — small one-shot coroutines:

002C04:  set.i  local[0] = 1
002C1C:  set.i  local[4] = 1
002C34:  set.f  local[8] = 0.4
002C50:  call   builtin106(0x1, 0x1, 0.4)
002C5C:  call   end_coroutine

🟡 A runtime cross-check — consistent, and not proof

The closed REMAINING OB work measured, on the emulator over n=5 runs, that Stage 02's squadrons arrive at t = 0, 120 and 210 s. All three times are in phase 1's static schedule, and 120 and 210 each appear twice, which is what two squadrons arriving together would look like.

⚠️ Stated as consistency rather than confirmation: these are round numbers, and phase 1 has ~22 distinct times spread over 0–1170, so three specified round values all being present is not by itself unlikely. The doubling is the sharper detail, and it was not predicted in advance.

Artefacts

data/isl-stage02-schedule.txt and data/isl-schedule-all.txt (all 28 stages, 675 entries), generator isl_report.py schedule. The four earlier artefacts regenerate byte-identical.

🟡 Not settled

kind (0 or 5) is not identified. Two behaviours, no reading.
This is not what starts the unreachable code. All 675 targets are already reachable — 0 are unreached run-starts — so the ~15 % gap stands.
Whether the schedule is per-phase-clock or mission-clock is not established; each phase's table restarts at t=0, which suggests per-phase, but that is an inference from the layout, not a read of the consumer.
The consumer is unread. Nothing here shows the engine walking this table; the decode rests on the structural checks above.

3.0 KiB Raw Blame History Unescape Escape