打开网易新闻 查看精彩图片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更好的未知是:提升时机相对于那个边界,精确位置在哪?

这比旧问题更锋利。

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

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

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

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

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

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

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

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