2463748a71
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.
77 lines
3.0 KiB
Markdown
77 lines
3.0 KiB
Markdown
# ✅ 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](../isl-stream-entry-points.md)) 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.
|