1. 从“阿波罗”这个名字说起一个被低估的导航计算机项目第一次看到“Apollo-11”这个标题很多人脑子里蹦出来的可能是上世纪的登月计划。但如果你是在某个代码仓库、某个硬件复刻社区或者某个复古计算论坛里刷到它那它大概率指向的是另一件事——阿波罗导航计算机Apollo Guidance Computer简称AGC的复刻与仿真项目。这类项目在开源硬件和复古计算圈子里一直有相当的热度而“Apollo-11”通常就是某个具体复刻版本的代号。我接触这类项目大概是在几年前当时想找一个能真正跑起来、能交互、能理解底层逻辑的AGC仿真环境。市面上有不少零散的文档和论文但真正把“怎么从零搭起来”讲清楚的材料并不多。大部分资料要么停留在历史介绍层面要么直接甩给你一堆汇编代码和原理图中间的操作路径是断的。这个项目标题之所以值得单独拿出来讲是因为它代表了一类非常典型的工程实践用现代工具链去复现一套几十年前的嵌入式系统并且让它真正跑起来。这件事的价值不在于“怀旧”而在于它逼着你去理解很多现代开发中被封装掉的东西。比如指令周期怎么算、内存怎么分页、中断怎么响应、外设怎么通过离散逻辑跟CPU通信。这些东西在今天的高级语言和框架里几乎被完全隐藏了但在这个项目里你必须一层一层把它剥开。适合谁来参考我觉得有三类人一是对嵌入式底层感兴趣但一直没找到合适切入点的开发者二是做复古计算复刻、想找一个完整参考案例的爱好者三是教计算机组成原理或系统结构的老师想找一个比教科书更生动的教学载体。下面我会围绕这个项目的核心环节把我在实际搭建和调试过程中积累的东西拆开来讲。不会只给步骤每个关键选择我都会解释为什么这么做以及我踩过哪些坑。2. 核心架构拆解AGC到底特殊在哪里2.1 为什么AGC不是一台“普通”的老计算机AGC最特殊的地方在于它的内存字长和指令结构。它用的是15位字长不是我们今天熟悉的8位、16位或32位。15位这个数字不是随便选的它跟当时的内存工艺、功耗预算和指令编码需求直接相关。每个内存字15位其中14位是数据1位是奇偶校验。指令字也是15位但编码方式非常紧凑3位操作码、12位地址码。这意味着它最多只能直接寻址4096个内存字所以必须用分页机制来扩展寻址范围。这个设计带来的直接后果是你写任何一段逻辑都要时刻关注当前在哪个存储体bank、目标地址在哪个存储体、需不需要切换。现代开发里你几乎不用想这些但在AGC上这是每一条指令都要考虑的事。我在第一次写仿真器的时候就是因为忽略了bank切换的时序导致程序跑着跑着就跳到了完全无关的地址上排查了很久才发现是分页寄存器更新和指令预取之间的竞争关系没处理好。另一个特殊点是它的指令周期。AGC的主频大约是2.048 MHz但一条指令不是固定周期完成的。简单指令可能只要一个周期涉及内存访问或分支的指令可能要多个周期。更麻烦的是AGC有一套复杂的时序脉冲系统把每个周期分成多个时间段不同时间段做不同的事。如果你只是用一个简单的“取指-译码-执行”循环去仿真很多依赖精确时序的外设交互就会出错。2.2 内存布局与分页机制的实际影响AGC的内存分为固定内存Fixed Memory和可擦写内存Erasable Memory。固定内存就是只读的里面存的是核心程序比如阿波罗制导程序。可擦写内存相当于RAM用来存变量和临时数据。固定内存有36个bank每个bank 1024个字可擦写内存有8个bank每个bank 256个字。这个布局对仿真的影响非常大。你不能简单地用一个一维数组去模拟整个内存空间因为bank切换是有副作用的。比如切换到某个固定内存bank时需要设置对应的bank寄存器而这个寄存器的值会影响后续所有取指操作。我在早期版本里用了一个简单的地址映射表结果发现某些跳转指令在跨bank时行为不对后来改成显式的bank寄存器模型才解决。还有一个容易忽略的点可擦写内存的地址空间是重叠的。也就是说同一个地址在不同的bank选择下可能指向不同的物理位置。这在处理子程序调用和返回时特别容易出问题。我的做法是在仿真器里维护一个“当前bank状态”每次内存访问都先根据这个状态计算出物理地址再做读写。虽然性能上会慢一点但正确性有保障。2.3 指令集的核心子集与仿真优先级AGC的指令集不算特别大但也不是全部都需要在第一时间实现。根据我的经验可以按下面的优先级来推进优先级指令类型典型指令说明P0基本传送与算术TC, CCS, INDEX, XCH没有这些程序根本跑不起来P0分支与跳转BZF, BZMF, TCF控制流的基础P1内存访问CA, CS, AD, MASK数据处理常用P1移位与逻辑EXTEND, MP, DV复杂运算需要P2输入输出IN, OUT, RAND, WAND外设交互时才需要P3中断与计数器RESUME, RELINT, INHINT完整系统才涉及我建议先把P0和P1做扎实用一个简单的测试程序验证基本逻辑再逐步往上加。不要一上来就追求全指令集那样调试成本会非常高。我当初就是贪多结果一个中断处理没写好导致整个仿真器在跑复杂程序时随机崩溃回头查了很久才发现是INHINT和RELINT的配对逻辑有问题。3. 从零搭建仿真环境工具链选型与实操路径3.1 语言与框架的选择逻辑做AGC仿真语言选择其实没有绝对的对错但有几个实际因素要考虑。C或C是最常见的选择因为可以直接操作位、控制内存布局、做精确的周期计数。Python上手快适合做原型验证但性能上跑完整程序会比较吃力。Rust是近几年比较热门的选择内存安全加上不错的性能但学习曲线陡一些。我自己的路径是先用Python写了一个简化版把指令译码和基本执行流程跑通确认逻辑没问题之后再用C重写了一遍。这样做的好处是Python阶段可以快速试错不用太在意性能C阶段则专注于优化和精确时序。如果你时间有限直接上C也可以但一定要先把指令编码表整理清楚不然后面改起来很痛苦。工具链方面你需要一个汇编器来把AGC汇编代码转成机器码。网上有一些开源的AGC汇编器但质量参差不齐。我的建议是先用一个经过验证的版本不要自己从头写。另外反汇编器也很重要调试的时候你需要把内存里的机器码还原成可读的指令否则面对一堆十六进制数字根本无从下手。3.2 内存模型的具体实现细节前面提到AGC的内存是分bank的具体实现时我建议用这样的结构typedef struct { uint16_t fixed[36][1024]; // 固定内存36个bank uint16_t erasable[8][256]; // 可擦写内存8个bank uint8_t fixed_bank; // 当前固定内存bank uint8_t erasable_bank; // 当前可擦写内存bank } AGC_Memory;注意每个字用uint16_t来存虽然AGC是15位但用16位容器更方便处理最高位可以忽略或者用来做奇偶校验。读写函数要处理bank切换的逻辑uint16_t read_memory(AGC_Memory *mem, uint16_t addr) { if (addr 0x0800) { // 可擦写内存区域 uint16_t bank (addr 0x0400) ? mem-erasable_bank : (mem-erasable_bank | 1); return mem-erasable[bank][addr 0xFF]; } else { // 固定内存区域 return mem-fixed[mem-fixed_bank][addr 0x3FF]; } }这段代码看起来简单但里面的bank选择逻辑是有讲究的。可擦写内存的低地址和高地址区域对应不同的bank选择方式如果搞错了变量读写就会串位。我当初就是在这里栽了跟头一个计数器的值莫名其妙被改成了完全无关的数据查了两天才发现是bank计算错了。3.3 时序仿真周期精确到底有多重要如果你只是想让程序“跑起来”那周期不精确可能也能凑合。但如果你想接外设、想跑真实的阿波罗程序、想看到正确的显示输出那周期精确是绕不过去的。AGC的时序系统基于一组时序脉冲每个主周期被分成若干个时间段。不同指令在不同时间段做不同的事。比如取指通常在前几个时间段完成执行在后几个时间段。如果你用一个简单的循环去模拟很多依赖精确时序的逻辑就会错位。我的做法是在仿真器里维护一个周期计数器每条指令执行时根据指令类型增加相应的周期数。同时外设的更新也挂在这个周期计数器上比如每多少个周期刷新一次显示、每多少个周期采样一次输入。这样虽然不能做到100%精确但对于大多数应用场景已经足够了。注意如果你要跑原始的AGC汇编程序周期精度要求会更高。有些程序会利用指令执行的精确周期来做延时或同步这时候差几个周期就可能导致行为完全不同。3.4 汇编器与加载器的配合有了仿真器核心之后你需要一个方式把程序加载进去。最直接的做法是写一个加载器读取汇编器输出的二进制文件按地址写入内存。这里有几个细节要注意地址格式AGC的地址是15位的但汇编器输出的可能是各种格式要确认清楚。bank信息如果程序跨多个bank加载器需要知道每个段应该放到哪个bank。校验和有些程序会自带校验和加载后要验证一下确保没有加载错误。我一般会先用一个很小的测试程序比如只做几个加法然后停机确认加载和执行都正常再逐步换更大的程序。这个“小步验证”的习惯帮我省了很多时间因为一旦大程序跑不起来你很难判断是加载问题、指令实现问题还是程序本身的问题。4. 调试过程中最容易卡住的几个地方4.1 分支指令的边界条件AGC的分支指令有几个容易搞错的地方。比如BZFBranch Zero to Fixed在累加器为零时跳转但“为零”的判断是看累加器的所有位还是只看某些位答案是看全部15位。如果你只检查低8位就会在某些情况下错误跳转。另一个坑是溢出处理。AGC的算术运算有溢出标志分支指令可能会依赖这个标志。如果你在实现加法时没有正确设置溢出位后续的分支就会走错方向。我当初写加法的时候只关注了结果忽略了溢出标志结果一个循环程序死活跳不出去查了很久才发现是溢出位没更新。4.2 中断与RESUME指令的配对AGC的中断机制比较特殊它用INHINT和RELINT来禁止和允许中断用RESUME来从中断返回。关键点是RESUME不是简单的跳转它会把中断前保存的地址和状态恢复回来。如果你把RESUME当成普通跳转来实现中断嵌套时就会出问题。我的建议是在仿真器里维护一个中断栈每次进入中断时把当前PC和关键寄存器压栈RESUME时弹栈恢复。同时要注意INHINT和RELINT的配对如果程序在禁止中断的状态下试图执行RESUME行为是不确定的。我在调试一个多中断程序时就是因为没有正确处理嵌套导致返回地址被覆盖程序跑飞了。4.3 外设接口的仿真顺序AGC的外设包括显示键盘、IMU惯性测量单元、雷达等。如果你要仿真这些更新顺序很重要。比如显示刷新和键盘扫描如果顺序反了可能会出现按键丢失或显示闪烁。我的做法是定义一个固定的外设更新周期在每个周期里按固定顺序调用各个外设的更新函数。这个顺序要参考原始硬件的时序设计不能随便定。另外外设的输入输出通常是通过通道来进行的通道的读写有特定的指令如IN、OUT这些指令的实现要跟外设仿真紧密配合。4.4 性能瓶颈与优化取舍当你的仿真器能跑起来之后可能会发现性能是个问题。尤其是用Python写的原型跑复杂程序时可能会慢到无法接受。这时候有几个优化方向指令译码缓存把常用的指令译码结果缓存起来避免每次都重新解析。内存访问优化减少不必要的bank计算比如在同一个bank内连续访问时可以复用计算结果。周期计数简化如果不需要精确周期可以用近似值代替减少计算量。但要注意优化不能牺牲正确性。我一般会先保证逻辑正确再逐步优化每做一次优化都跑一遍回归测试确保没有引入新的bug。5. 实测验证怎么判断你的仿真器是真的“对”了5.1 用已知程序做基准测试最直接的验证方法是找一段已知正确输出的AGC程序在你的仿真器上跑看结果是否一致。比如一些简单的数学运算程序、排序程序、或者经典的“Hello World”级别的测试。如果输出对不上就逐步缩小范围定位是哪条指令或哪个环节出了问题。我一般会准备一组测试用例从最简单的单条指令开始到几条指令的组合再到完整的小程序。每通过一个测试就打个勾这样心里有底。5.2 对比原始硬件的时序数据如果你有原始AGC的时序文档可以拿你的仿真器周期计数跟文档对比。比如某条指令在文档里是3个周期你的仿真器跑出来是2个或4个那就说明时序实现有问题。这种对比不需要跑完整程序单独测一条指令就行。5.3 交叉验证多个仿真器对比如果条件允许可以找另一个独立的AGC仿真器跑同样的程序对比输出。如果两个仿真器结果一致那可信度就高很多。如果结果不一致那就需要进一步分析是哪个环节的差异导致的。这个方法虽然麻烦但对于追求高可信度的项目来说很值得。5.4 实际运行中的异常处理即使通过了所有测试实际运行中还是可能遇到异常。比如程序跑着跑着突然跳到一个非法地址或者某个变量的值莫名其妙变了。这时候日志就非常重要。我建议在仿真器里加一个可配置的日志系统可以按需输出指令执行轨迹、内存访问记录、外设状态变化等。出问题的时候把日志打开往往能很快定位到异常发生的位置。提示日志不要一直开着否则性能会受很大影响。我一般是先用正常模式跑出问题了再开日志重跑这样效率最高。6. 这个项目还能怎么玩扩展方向与个人体会把基本的仿真器跑通之后其实还有很多可以扩展的方向。比如接入图形化界面把AGC的显示输出用现代屏幕渲染出来这样看起来更直观。或者做一个调试器支持断点、单步、内存查看这样调试起来会方便很多。再进一步可以接入真实的传感器或控制器让仿真器跟物理世界互动这就有点数字孪生的意思了。我自己在这个项目上花了不少时间最大的体会是不要怕底层。很多人觉得这些老硬件的东西太偏、太杂但正是这些“偏”和“杂”逼着你去理解计算机到底是怎么工作的。现代开发里你写一行代码背后可能有几十层抽象你不需要知道下面发生了什么。但在AGC仿真里每一层你都要自己搭搭完之后你对整个系统的理解会完全不一样。另一个体会是测试要趁早验证要频繁。我早期有几次想一口气写很多功能再一起测结果bug堆在一起排查起来非常痛苦。后来改成每加一个小功能就测一次虽然看起来慢但总体效率反而更高。最后分享一个小技巧如果你在实现某条指令时不确定它的行为去找原始的AGC手册或者经过验证的汇编器源码不要凭感觉猜。这些老系统的设计往往有很多“反直觉”的地方猜错的概率很高。我当初实现CCS指令时就是凭感觉写的结果跟真实行为差了很多后来查了手册才发现它的累加器更新规则跟我以为的完全不一样。这个项目后续还可以往多实例并行的方向走比如同时跑多个AGC仿真器模拟多个制导系统协同工作的场景。不过这需要更复杂的同步机制有兴趣的话可以试试。
