将《测试驾驶II》从超级任天堂移植到个人电脑，第一部分：从第0天到可度量的ROM

在2026年2月26日至3月19日期间，asmdump代码仓库经历了45次提交。它最初只是一个原始的逆向工程转储，到这一阶段结束时，已发展出一个基于C语言和SDL的运行时环境、确定性模拟器探针、图块地图来源分析工具以及回归测试关卡。

本篇第一部分涵盖最初两天的工作：第0天仓库中包含哪些内容，为何项目没有从游戏逻辑代码开始，以及最初的提取与验证工具链如何改变了问题的形态。

第0天：仓库是一个逆向工程基础

2026年2月26日的提交a683c61是真正的起点。该提交导入了以下内容：

• bank0.asm至bank31.asm
• game.smc和game.sym
• ROM构建文件，例如Makefile、linkfile、main.s、snes.asm和spc700.asm

这些内容足以重新构建并检查ROM，但还不足以进行移植。

当时尚无资产提取流水线，也没有确定性捕获框架，更没有可供个人电脑运行时加载的稳定资产格式。该仓库对内存地址了解颇多，但对模块间的契约却知之甚少。

缺乏直接的反编译路径在此至关重要。bank0.asm已经暴露出可识别的复位、垂直消隐中断（NMI）、中断请求（IRQ）及回调调度逻辑，但面向游戏玩法的代码段尚未达到适合直接进行汇编到C语言转换的状态，原因如下：

• bank10.asm和bank11.asm仍严重混合了代码与数据
• bank30.asm看起来更像是结构化的表格和分发器数据，而非清晰的可调用函数列表
• game.sym仅暴露了标签和覆盖范围信息，而非行为逻辑

因此，早期计划并非“先翻译bank 0，再bank 1，然后bank 10”。早期计划是：

1. 使原始ROM变得可度量。
2. 从中提取类型化的数据。
3. 在个人电脑端根据这些度量结果重建系统。

这一决策至今仍是正确的。可靠的移植工作在需要更多C语言文件之前，首先需要一个参考验证框架。

首批工具的集中开发

2月27日共有九次提交。这一天实际上构成了第1天的移植工作。

其中重要的提交包括：

• c867efd - 超级任天堂资产提取工具链的脚手架
• fcc30b5 - 场景、精灵和道路可视化工具
• f8785b9 - 完全集成的Qt资产查看器用户界面
• 2bc9dc2 - 初始脚本、精灵转换、捕获数据以及首个运行时骨架

仓库不再将ROM视为单一整体，而是开始将其转化为可检查的输出：

• 调色板以JSON格式导出
• 显存（VRAM）重建与启动画面清单
• 解压缩后的数据块输出
• 图块表渲染为中立图像格式
• 基于Mesen模拟器的截图与状态捕获
• 可在模拟器外部驱动的场景可视化工具

该阶段的代表性命令至今仍很好地体现了这一方法：

./validation/run_mesen_capture.sh

python3 tools/extract_bank3_palettes.py game.smc tools/out/bank3_palettes.json
python3 tools/extract_boot_screen_manifest.py game.smc tools/out/bank1_boot_screen.json
python3 tools/build_boot_vram.py game.smc tools/out/bank1_boot_screen.json tools/out/bank1_boot_vram_variant0.bin --json-out tools/out/bank1_boot_vram_variant0.json
python3 tools/decompress_td2_chunk.py gam