移植24：他花3个月破译1张8字节表

8字节。30年前写进卡带的数据。3个月前还只是一团十六进制噪音。

现在它是一张地图——指向《Test Drive II》SNES版前端菜单的底层骨架。

这个项目的第24个checkpoint，没有宣布胜利。但把两个"大概知道"变成了"可以验证"。

01:8000那张表，终于开口说话

地址01:8000到01:8008之间，藏着游戏用来驱动菜单行数和行基址的小型查找表。

之前$1C7C这个内存地址被当成"某种四状态开关"——可能是难度，可能是视角，可能是别的什么UI装饰。

解码之后，它是四组描述符的选择器。不是UI层的皮肤切换，是内容边界的硬开关。

这没有最终证明人类标签是"赛道"还是"风景"。但干掉了另一种更弱的解读：$1C7C曾经可能只是个没后端支撑的界面拨杆。

现在你知道它选的是整组描述符。行从哪开始、有多少行，由这张8字节表说了算。

预览路径的"双重证据"陷阱

$0202到$1C78的预览数据流，之前只有代码层面的孤证。

现在辅助表让它看起来像个真正的内容域，而非单一的视觉把戏。

三个预览包索引解析为三个不同的辅助三元组。旁边还有一个未标注的前端UI辅助，通过1E80文本缓冲区消费数据——这个缓冲区在菜单流程的其他地方也在用。

组合起来，$0202/$1C78作为"车辆选择器"的候选强度，比之前高了一个量级。特别是当你把已验证的"CUSTOMIZE CAR"表面放在一起看的时候。

但作者试着把当前辅助场景构建器塞进这些预览包索引时，撞墙了。

L00A9CB的批量路径（辅助索引9到11）报出26FB长度不匹配。这不是失败，是信号——三选一预览不是"已经解决的简单辅助场景"的另一个实例。

正确的下一步是专用预览提取器，而不是继续盲目复用更简单的构建器。

B1F9交接窗口：从"是否发生"到"何时发生"

两个bank-1兄弟回调的强制探测，结果干净得反常。

两条强制通道都只做一件我们关心的事。栈返回字仍然干净地分离两个兄弟。状态分裂也存活下来。

但同一个狭窄跟踪窗口仍然看不到关键问题：回调提升（callback promotion）相对于bank-1分支边界，到底发生在什么时候？

更宽的静态走廊已经预置了$1C8A/$1C8C的bank-1进入点。所以缺失的证明不再是"这个分支真的进入交接代码了吗？"

更好的未知是：提升时机相对于那个边界，精确位置在哪？

这比旧问题更锋利。

下一个转向：从"菜单猜测"到"两份具体工作"

这个checkpoint没有解决前端。但让下一步探测的模糊性大幅降低。

作者列出的待办只剩两项：专用预览提取器，以及B1F9时序探针。

30年前的二进制，正在以每月一两个约束条件的速度，交出它的结构秘密。

如果这张8字节表当初被设计成可读格式，整个移植可能只需要几周。但它不是——它是为1989年的卡带容量和读取速度优化的。现在有人用2025年的静态分析工具，把它翻译成可维护的约束条件。

这种工作没有"完成"的庆祝时刻。只有"下一个未知比上一个更清晰"的累积。

当专用预览提取器跑通时，$0202/$1C78能否被正式标记为"车辆选择器"？还是会有第三个身份跳出来？