如果你的电脑里还存着一份 1970 年代的法国工业控制程序却找不到一台能运行它的机器你会怎么处理大概率不是去废旧市场淘一台 CII Mitra-15 小型机而是打开一个模拟器。最近在 SIMH 社区里出现了一个名为 “French CIIs Mitra-15 in SIMH. Work in Progress” 的项目目标就是把法国 CII 公司的 Mitra-15 小型机放进 SIMH 模拟框架里跑起来。这篇文章不是给你讲一个冷门硬件的历史课而是想和你聊清楚三件事Mitra-15 到底是一个什么样的存在SIMH 为什么适合承载这种老机器以及面对一个 Work in Progress 状态的模拟器项目作为开发者应该怎么跟、怎么测、怎么参与。我的判断很明确这类模拟器项目最大的价值不在“能开机”这个结果而在于它能成为一台可调试、可复现、可观察的“活体标本”。50 年前的实时控制、中断处理、引导加载和内存管理思路只有在模拟器里才能被现代工程师一行一行地看清楚。如果你对操作系统内核、实时系统或者复古计算感兴趣这个项目值得你花一个周末去研究。1. 为什么一台 50 年前的法国小型机值得被重新“做”出来1.1 从 CII 到 Mitra-15法国计算机产业的独特切片CII 的全称是 Compagnie Internationale pour lInformatique也就是“国际计算机公司”。这家公司出现在 1960 年代后期是法国在计算机产业规划中推动成立的整合性企业。从公开资料看CII 后来参与过 Unidata 计划与西门子、飞利浦等欧洲厂商合作最终又被整合进 Bull 体系。这段历史本身就很复杂但有一个事实很清楚CII 并没有走美国小型机的主流路线而是在欧洲市场建立起了一套自己的计算机产品体系。Mitra-15 就是 CII 产品线里的重要成员。它是一台面向实时控制和科学计算的小型机和 DEC 的 PDP-11 几乎是同一个时代的产品但在法国工业界尤其是电力、电信、军工和自动化领域它曾经扮演过不可忽视的角色。如果我们把 PDP-11 比作“那个时代的小型机标准答案”那么 Mitra-15 更像是法国工程师在标准答案之外写下的另一份答卷。硬件设计、指令集、外设接口都有自己的特色而这些特色恰恰是现在很多欧美模拟器项目没有覆盖到的空白。1.2 为什么现在还要模拟一台老机器有人会问这种老机器除了放进博物馆还有什么用这里有一个很实际的痛点是普通人看不到的大量 1970—1990 年代开发的工业控制程序、实时监控代码、Fortran 科学计算程序至今仍以私有格式保存在磁带、纸带和磁盘镜像里。它们不是不能运行而是找不到能运行它们的环境。真实硬件早就退役备件价格高得离谱维修保养的成本足够买几台新服务器。模拟器是唯一一种既能让旧软件继续跑又能让开发者安全地观察系统内部状态的方式。另一个角度是教育。今天很多做嵌入式、实时操作系统的人读再多的书、看再多的 Linux 源码也不一定理解“没有操作系统只有监控程序和中断向量”的系统是怎么工作的。Mitra-15 这样的机器恰恰是一个极好的教学样本指令集规模小、设备数量有限、实时性要求高。如果能把它完整模拟出来学生可以看着 CPU 如何响应外部中断可以在控制台输入命令加载纸带镜像可以亲手写一段汇编代码跑在那套老硬件上——这种体验是现代抽象层级的课程给不了的。1.3 “Work in Progress”意味着什么回到这个项目本身。标题里的 “Work in Progress” 是一个非常重要的信号。它告诉我们这不是一个已经打包好、下载即用的终端模拟器而是一个正在开发中的工程。可能还没有完整的设备集可能没有配套的 ROM 和磁盘镜像甚至 CPU 指令覆盖率都还停留在早期阶段。但这不意味着它不值得关注。恰恰相反WIP 状态的项目对贡献者最友好早期的架构设计、设备抽象、测试框架都在成型阶段你的每一条 issue、每一份测试用例都有可能直接影响项目走向。从项目名 “French CIIs Mitra-15 in SIMH” 来看作者选择的是把 Mitra-15 作为 SIMH 家族里新成员来做。SIMH 本身是个成熟的模拟框架所以这个项目大概率只需要集中精力实现 Mitra-15 的 CPU 和外设而不是再发明一套模拟器框架。这种“框架 特定机器实现”的组合是复古计算社区里最常见、也最可持续的路线。2. SIMH一个“什么都能跑”的模拟器框架2.1 SIMH 到底解决什么问题SIMH 的全称是 Simulated Historical Computer Systems中文通常叫做“历史计算机系统模拟器”。它的作者是 Bob Supnik最早是 DEC 的工程师后来为了保留老系统的运行能力开发了这一整套模拟器。SIMH 不是某一种机器的模拟器而是一整套模拟框架支持几十种经典机型从 PDP-8、PDP-11、VAX到 IBM System 360、Altair 8800都有对应的模拟器实现。它的核心设计理念是不仅要模拟 CPU 的指令执行还要模拟外部设备、终端、磁盘、打印机、网络接口让原始的软件不需要修改就能直接运行。你可以把 SIMH 理解为一座“数字博物馆”每一台老机器都在里面保留了一个可运行、可交互、可编程的“虚拟房间”。这不是简单的指令翻译器而是一个完整的硬件抽象环境。2.2 SIMH 的架构前端控制台 后端设备模拟接触过 SIMH 的人都知道它的使用方式通常是一个命令行控制台。启动某个机器的模拟器后你会看到类似sim的提示符。在这个提示符下你可以执行set、attach、boot、show等命令来配置内存大小、挂载磁盘镜像、启动 CPU、查看设备状态。这些命令构成了模拟器的“人机接口”。底层则是 C 语言写成的设备模拟代码。每个模拟器模块会实现自己的处理器核心、内存控制器、中断控制器、磁盘控制器、终端控制器等。这个架构的好处是新机器的模拟器可以复用很多公共设施比如控制台框架、命令解析器、设备 attach 机制、日志系统。对于 Mitra-15 这样一台设备也不算太复杂的小型机用 SIMH 框架来做远比从零写一个单体模拟器要高效得多。2.3 为什么 SIMH 适合承载 Mitra-15从开发角度看使用 SIMH 有三个明显的好处。第一调试工具现成。SIMH 自带日志、反汇编、内存 dump 等辅助能力开发者不需要自己再写一套调试器。第二社区经验丰富。几十台机器的模拟器已经完成遇到“磁盘镜像格式怎么定义”“终端输入输出怎么处理”这类问题几乎都能在已有模拟器代码里找到参照。第三测试方法成熟。老系统通常有诊断程序模拟器能不能通过对诊断程序的测试是衡量工作是否完成的金标准。不过选择 SIMH 也意味着需要遵循 SIMH 的框架约定。如果作者想引入一个完全不在框架支持范围内的特殊外设比如 Mitra-15 独有的实时设备就必须自己实现适配层。好在 Mitra-15 的定位是小型机外设类型大概率还是纸带、磁盘、终端这类经典设备完成度会更容易推进。3. Mitra-15 模拟需要解决的核心技术点3.1 CPU 与指令集模拟任何模拟器的第一步都是实现 CPU 核心。从公开资料看Mitra-15 是一台 16 位小型机和当时的许多小型机一样强调实时响应和中断处理能力。模拟器需要精确还原寄存器、寻址模式、条件码、堆栈操作以及所有指令的语义。这个阶段最容易犯的错误是“只做指令翻译不做状态还原”。很多模拟器项目在最早期只关注指令能不能得到正确结果却忽略了处理器状态在不同指令之间的变化。对于 Mitra-15 这种实时机器来说中断现场保存和恢复尤其重要如果模拟器在中断时没有正确保存程序计数器和处理器状态字后面所有设备交互都会走样。3.2 内存管理与外设地址映射小型机时代的内存管理往往很简单有时就是统一编址。模拟器需要决定内存的容量范围以及外设寄存器是否在内存地址空间里。如果 Mitra-15 采用内存映射 I/O那么模拟器就要对特定地址段进行拦截把读操作转发给外设控制器而不是普通内存。这听起来不复杂但在模拟器里性能优化往往在这里出现分歧。简单的 map 表查找可以满足早期调试但如果你希望模拟器跑得足够流畅就要考虑缓存最热门的地址映射结果。对 WIP 项目来说先保证正确再考虑速度这个顺序最好不要反过来。3.3 中断、实时时钟与设备模拟Mitra-15 如果像大多数实时小型机一样会提供多级中断和实时时钟。模拟器的中断处理要在“指令执行周期”和“外部设备事件”之间建立联系。例如纸带阅读器完成一个字符的读取后需要触发一次中断实时时钟每过一定时间也要触发一次中断。这些中断时序不精确的话运行结果就会出现偏差。设备模拟方面纸带阅读器、纸带穿孔机、控制台终端、磁盘驱动器都是常见外设。每一种设备都要实现“状态寄存器读取”“数据缓冲区读写”“中断触发”这三个基本能力。对于 WIP 项目设备往往是一个一个加进去的。最先完成的通常是最基础的终端因为它能立刻和用户交互也最容易验证。3.4 引导流程与软件镜像加载模拟器建设完成后面临的另一个问题是软件从哪里来老系统的引导流程通常是控制台面板上输入一段引导程序然后从纸带或磁盘读取操作系统。如果你手上没有原始的 ROM 或引导纸带镜像模拟器就只能停留在“裸机”状态CPU 能跑但没有东西可跑。这也是 WIP 项目比较尴尬的地方。CPU 设备代码可能已经写了 90%但缺一个镜像就不方便演示。因此在参与这类项目时除了关注模拟器代码本身也值得关注项目里有没有配套的镜像文件和授权说明。很多老软件的版权状态并不清晰如果要公开分发必须谨慎处理。4. 环境准备与前置条件4.1 软硬件环境想要编译并运行一个 Mitra-15 模拟器现阶段不需要太高配置。因为模拟对象是 50 年前的小型机性能压力非常小普通 x86_64 Linux 机器就足够甚至在一台 1 核 1GB 内存的云主机上也能完成编译和基础测试。如果你用的是 macOS 或 Windows也可以通过 WSL 或虚拟机跑 Linux 环境。本文后续命令以 Ubuntu/Debian 为例但这不代表其他系统不行。实际开发过程中最影响效率的不是 CPU 性能而是工具链和资料访问能力。你需要一个能稳定工作的 C 编译器、Git 和 make/cmake 等构建工具。如果项目启用了网络模拟可能还要安装 libpcap 开发库。不过对于 Mitra-15 这种小型机来说网络外设可能不是第一优先级装上也只是有备无患。4.2 安装基础工具链在 Ubuntu/Debian 系统上可以先执行以下命令安装基础依赖sudo apt update sudo apt install build-essential git libpcap-dev如果你的模拟器项目使用 CMake 管理构建还需要补上 cmakesudo apt install cmake这一步不需要额外配置。工具链装好后可以快速检查版本gcc --version git --version make --version只要这些命令能正常输出版本号说明环境基本就绪。需要注意不同项目的构建系统可能不一样有的用传统 Makefile有的用 CMake有的甚至直接提供预编译二进制。具体以项目 README 为准这里只是通用准备流程。4.3 获得模拟器源码因为“French CIIs Mitra-15 in SIMH”是社区项目源码获取方式以后续官方仓库为准。通常的路径是使用 Git 克隆git clone mitra15-simh-repo-url cd mitra15-simh如果项目直接集成在 SIMH 主仓库里那么你可以先克隆 SIMH 主仓库再查看其中是否有 mitra15 相关目录。无论如何进入源码目录后第一件事是读 README。WIP 项目的 README 会告诉你当前实现了什么、缺什么、怎么构建、有哪些已知问题。这些信息比任何第三方博客都准确。5. 构建 Mitra-15 模拟器的完整流程5.1 编译前的目录检查进入源码目录后先观察一下目录结构。一个典型的 SIMH 项目会包含src/或sim/模拟器核心源码。makefile或CMakeLists.txt构建脚本。doc/硬件手册、用法说明。test/回归测试脚本。ini/或misc/配置文件示例。先不要急着编译重点看一下 README 里有没有说明这个项目当前依赖哪个版本的“宿主 SIMH”。如果它是作为 SIMH 的分支开发你需要在正确的分支或提交上构建如果它是独立项目那通常自带全部模拟器代码不需要额外下载宿主框架。5.2 使用传统 make 构建很多 SIMH 系列模拟器延续了简单的 make 流程。在项目根目录执行make这一步会编译所有源码并生成和模拟器对应的可执行文件。如果只是要构建 Mitra-15 模拟器而项目同时包含多个模拟器目标可能需要指定目标名例如make mitra15具体目标名以 README 为准。编译成功后会看到类似simh-mitra15或mitra15的可执行文件出现在目录中。5.3 使用 CMake 构建如果项目采用 CMake则流程更现代化一些cmake -S . -B build cmake --build build构建产物会出现在build/目录下。CMake 的好处是可以生成不同平台的项目文件也方便 IDE 导入。对于 WIP 项目如果作者同时在开发新设备每次改动后重新跑cmake --build build就行增量编译速度比全量 make 更可控。5.4 确认模拟器可执行文件构建完成后先执行一个最简单的冒烟测试。启动模拟器./build/mitra15如果项目最终生成的可执行文件名不同请替换为实际名称。启动后如果能看到sim提示符说明模拟器内核已经能运行。这时候输入help或show version可以查看命令帮助和模拟器版本。如果这里就报错先回去检查编译过程有没有未解决的链接错误。6. 运行结果与效果验证6.1 没有镜像也能验证框架WIP 项目的一个常见现象是还没有运行镜像所以 CPU 无法启动。但这不代表模拟器无法测试。你仍然可以做几类验证检查设备枚举。在sim提示符下输入show devices或show configuration看模拟器是否能列出已经实现的设备。检查寄存器访问。如果模拟器提供examine命令可以查看 CPU 寄存器和内存地址。检查单步执行。如果实现了单步功能可以在没有镜像的情况下单步执行一条指令观察程序计数器和寄存器变化。下面是一个典型交互示例sim show version MITRA-15 simulator V0.1 (Work in Progress) sim show devices CPU: 16-bit MEM: 128K PTR: paper tape reader PTP: paper tape punch CON: console terminal sim exit请把这个输出当成演示不是实际输出。不同项目、不同阶段的输出差别非常大。关键是看命令是否能被识别、设备列表是否在逐步变完整。6.2 如果有引导镜像假如项目已经附带引导镜像或磁盘镜像可以尝试挂载并启动。以纸带镜像为例在sim提示符下sim attach -i ptr mitra15.pt sim boot cpu如果镜像正确且 CPU 模拟没有明显问题屏幕上可能会打印监控程序提示符或一段引导信息。此时你就进入了这台虚拟 Mitra-15 的操作环境。不过要注意如果镜像来自商业操作系统或私有软件必须确认其授权允许在模拟器中使用和分发。6.3 用脚本做自动化验证对于开发者和贡献者最后好用的方式是写一个自动化检查脚本把模拟器启动、命令交互、退出过程固定下来。比如#!/bin/bash # quick_check.sh ./build/mitra15 EOF show version help exit EOF运行bash quick_check.sh只要模拟器能正常走完这个流程说明基础框架没有崩溃。后续写回归测试时也可以用类似方式把某条指令的输入和输出记录下来做成 golden test。这类测试对 WIP 项目尤其有价值它能防止你在添加新外设时把旧功能弄坏。7. 常见问题与排查思路模拟器项目出了 bug最忌讳的是不读日志就直接改代码。先从现象下手一步步缩小范围。下表整理了几类常见问题和排查方向问题现象可能原因排查方式解决方案编译报错缺少头文件工具链或依赖库不完整查看第一行错误信息安装对应开发包如 libpcap-dev编译失败提示未定义的引用项目有多个目标链接选项不对阅读 makefile 或 CMakeLists用make help查看可用目标启动后没有sim提示符可执行文件选错或模拟器还在启动阶段崩溃用 gdb 或 strace 启动从错误堆栈定位具体签名错误attach镜像失败镜像格式与模拟器不匹配检查文件头对比 README 说明转换镜像格式或调整目标设备类型单步执行结果不对指令解码或标志位处理有误对照原厂手册手工推演一条指令编写最小指令测试用例终端输入不回显控制台终端模式不正确检查终端 raw/cooked 模式设置调整模拟器 console 配置磁盘读写总出错磁盘镜像偏移计算有误用 hexdump 检查镜像内容修正控制器逻辑中的块偏移每一个问题都不要靠猜。模拟器的调试过程很像历史侦探工作先确认输入数据再观察中间状态最后锁定代码位置。如果你手上能拿到原厂诊断程序那是最好的测试集因为诊断程序会以非常严格的方式遍历所有指令、内存和中断组合。WIP 项目能跑过自带测试已经很不错了跑过诊断程序则是里程碑。8. 最佳实践与工程建议8.1 从最小闭环开始迭代不管你是项目维护者还是贡献者第一个里程碑都应该是“最小闭环”。这意味着先不要追求完整外设只实现 CPU、少量内存和终端设备让模拟器能启动、能退出、能执行简单汇编指令。这个闭环一旦打通后续每次加入新指令和新设备都有稳定的测试基线。比如你可以先不管磁盘也不用管实时时钟先跑一个MOV或ADD指令在终端打印结果。实现一条指令就为它写一个测试。这种习惯在 WIP 项目里尤其重要因为代码变化快没有测试几天后就没人知道什么东西可用了。8.2 资料收集比写代码更花时间Mitra-15 的官方文档、原理图、指令手册是稀缺资源能找到扫描件要第一时间归档。很多老系统的细节光靠逆向工程很难猜准。硬件手册会明确告诉你怎么看状态寄存器指令手册会说明每条指令的周期和标志位变化。没有这些资料模拟器写出来很可能是“行为相似但细节错误”。如果项目是公开的最好把收集到的资料链接、扫描件元数据都写进文档。这不仅方便协作者也是在保护这段计算机历史。你保存一份资料可能就让多年后的研究者少走很多弯路。8.3 用诊断程序和原厂软件做交叉验证判断模拟器是否合格有两个层次。第一层是“能运行简单程序”第二层是“能运行原厂诊断程序和真实工业软件”。很多模拟器项目在第一层做得很快但到了第二层就被各种细节问题卡住某条指令的寻址模式差一位、某个中断的优先级反了、某次内存操作的时序不对。这些问题只能通过反复跑诊断程序来暴露。所以如果项目里还没有诊断程序镜像去收集和申请授权如果已经有把它纳入自动化测试。每修完一个 bug就重跑一遍全部诊断程序确保没有回归。8.4 版权与许可边界历史软件的版权问题绝对不能忽略。模拟器本身是开源代码这没问题但模拟器附带的 ROM、系统镜像、诊断程序可能并没有开源许可。在发布任何镜像之前先确认它的来源和授权。如果版权不明最好的做法是只提供“如何自行从原厂磁带提取镜像”的指南而不直接在仓库里分发。另外仓库文档里应该明确列出哪些内容是源码、哪些是第三方内容、各自采用什么许可证。这个动作虽然不写一行代码但对社区可持续发展非常重要。8.5 参与社区的正确姿势如果你想把 “French CIIs Mitra-15 in SIMH” 这个项目作为自己的练习场建议从阅读 issue 列表开始。不用急着提交大段补丁先找两个容易入手的地方一是补充测试用例二是改进设备模拟的边界条件处理。这类改动风险低、反馈快也容易让维护者信任你。在提 issue 或 pull request 时把复现步骤写清楚。模拟器相关的 bug 往往依赖镜像和命令序列只说“执行 boot 失败”几乎没人能帮你定位。最好附上你使用的构建命令、模拟器版本、镜像文件信息以及完整的终端输出。9. 总结与后续学习方向现在回到开头的问题为什么有人要花时间模拟一台法国 CII 的 Mitra-15答案不只是怀旧。一台老机器的模拟器是理解那个时代软件生态和硬件设计的最佳窗口也是保存计算机历史数据的唯一可靠方式。“French CIIs Mitra-15 in SIMH. Work in Progress” 这个项目虽然还处于早期但它选择了一条对的路借 SIMH 的成熟框架一步步还原 CPU、内存、中断和外设而不是从零开始重复造轮子。如果你想继续深入建议按下面的顺序实践先把 SIMH 跑起来随便选一台已完成的模拟器感受一下交互方式然后去读 Mitra-15 模拟器的最小源码理解它是如何注册控制台命令、如何映射内存、如何触发中断的接着找一份纸带或磁盘镜像试试能不能引导。如果镜像暂时缺失也不用着急把模拟器的单步执行和寄存器查看能力用好同样能学到很多处理器底层知识。最后提醒一句这类 WIP 项目变化很快今天写的命令可能下周就换了。最好的办法是保持对上游仓库的关注顺手把自己踩过的坑记成文档。等你真的跑通一条 Mitra-15 指令的那一刻那种穿越时间的感觉只有经历过的人才会懂。 法国CII Mitra-15小型机模拟器：用SIMH复活50年前的实时控制
如果你的电脑里还存着一份 1970 年代的法国工业控制程序却找不到一台能运行它的机器你会怎么处理大概率不是去废旧市场淘一台 CII Mitra-15 小型机而是打开一个模拟器。最近在 SIMH 社区里出现了一个名为 “French CIIs Mitra-15 in SIMH. Work in Progress” 的项目目标就是把法国 CII 公司的 Mitra-15 小型机放进 SIMH 模拟框架里跑起来。这篇文章不是给你讲一个冷门硬件的历史课而是想和你聊清楚三件事Mitra-15 到底是一个什么样的存在SIMH 为什么适合承载这种老机器以及面对一个 Work in Progress 状态的模拟器项目作为开发者应该怎么跟、怎么测、怎么参与。我的判断很明确这类模拟器项目最大的价值不在“能开机”这个结果而在于它能成为一台可调试、可复现、可观察的“活体标本”。50 年前的实时控制、中断处理、引导加载和内存管理思路只有在模拟器里才能被现代工程师一行一行地看清楚。如果你对操作系统内核、实时系统或者复古计算感兴趣这个项目值得你花一个周末去研究。1. 为什么一台 50 年前的法国小型机值得被重新“做”出来1.1 从 CII 到 Mitra-15法国计算机产业的独特切片CII 的全称是 Compagnie Internationale pour lInformatique也就是“国际计算机公司”。这家公司出现在 1960 年代后期是法国在计算机产业规划中推动成立的整合性企业。从公开资料看CII 后来参与过 Unidata 计划与西门子、飞利浦等欧洲厂商合作最终又被整合进 Bull 体系。这段历史本身就很复杂但有一个事实很清楚CII 并没有走美国小型机的主流路线而是在欧洲市场建立起了一套自己的计算机产品体系。Mitra-15 就是 CII 产品线里的重要成员。它是一台面向实时控制和科学计算的小型机和 DEC 的 PDP-11 几乎是同一个时代的产品但在法国工业界尤其是电力、电信、军工和自动化领域它曾经扮演过不可忽视的角色。如果我们把 PDP-11 比作“那个时代的小型机标准答案”那么 Mitra-15 更像是法国工程师在标准答案之外写下的另一份答卷。硬件设计、指令集、外设接口都有自己的特色而这些特色恰恰是现在很多欧美模拟器项目没有覆盖到的空白。1.2 为什么现在还要模拟一台老机器有人会问这种老机器除了放进博物馆还有什么用这里有一个很实际的痛点是普通人看不到的大量 1970—1990 年代开发的工业控制程序、实时监控代码、Fortran 科学计算程序至今仍以私有格式保存在磁带、纸带和磁盘镜像里。它们不是不能运行而是找不到能运行它们的环境。真实硬件早就退役备件价格高得离谱维修保养的成本足够买几台新服务器。模拟器是唯一一种既能让旧软件继续跑又能让开发者安全地观察系统内部状态的方式。另一个角度是教育。今天很多做嵌入式、实时操作系统的人读再多的书、看再多的 Linux 源码也不一定理解“没有操作系统只有监控程序和中断向量”的系统是怎么工作的。Mitra-15 这样的机器恰恰是一个极好的教学样本指令集规模小、设备数量有限、实时性要求高。如果能把它完整模拟出来学生可以看着 CPU 如何响应外部中断可以在控制台输入命令加载纸带镜像可以亲手写一段汇编代码跑在那套老硬件上——这种体验是现代抽象层级的课程给不了的。1.3 “Work in Progress”意味着什么回到这个项目本身。标题里的 “Work in Progress” 是一个非常重要的信号。它告诉我们这不是一个已经打包好、下载即用的终端模拟器而是一个正在开发中的工程。可能还没有完整的设备集可能没有配套的 ROM 和磁盘镜像甚至 CPU 指令覆盖率都还停留在早期阶段。但这不意味着它不值得关注。恰恰相反WIP 状态的项目对贡献者最友好早期的架构设计、设备抽象、测试框架都在成型阶段你的每一条 issue、每一份测试用例都有可能直接影响项目走向。从项目名 “French CIIs Mitra-15 in SIMH” 来看作者选择的是把 Mitra-15 作为 SIMH 家族里新成员来做。SIMH 本身是个成熟的模拟框架所以这个项目大概率只需要集中精力实现 Mitra-15 的 CPU 和外设而不是再发明一套模拟器框架。这种“框架 特定机器实现”的组合是复古计算社区里最常见、也最可持续的路线。2. SIMH一个“什么都能跑”的模拟器框架2.1 SIMH 到底解决什么问题SIMH 的全称是 Simulated Historical Computer Systems中文通常叫做“历史计算机系统模拟器”。它的作者是 Bob Supnik最早是 DEC 的工程师后来为了保留老系统的运行能力开发了这一整套模拟器。SIMH 不是某一种机器的模拟器而是一整套模拟框架支持几十种经典机型从 PDP-8、PDP-11、VAX到 IBM System 360、Altair 8800都有对应的模拟器实现。它的核心设计理念是不仅要模拟 CPU 的指令执行还要模拟外部设备、终端、磁盘、打印机、网络接口让原始的软件不需要修改就能直接运行。你可以把 SIMH 理解为一座“数字博物馆”每一台老机器都在里面保留了一个可运行、可交互、可编程的“虚拟房间”。这不是简单的指令翻译器而是一个完整的硬件抽象环境。2.2 SIMH 的架构前端控制台 后端设备模拟接触过 SIMH 的人都知道它的使用方式通常是一个命令行控制台。启动某个机器的模拟器后你会看到类似sim的提示符。在这个提示符下你可以执行set、attach、boot、show等命令来配置内存大小、挂载磁盘镜像、启动 CPU、查看设备状态。这些命令构成了模拟器的“人机接口”。底层则是 C 语言写成的设备模拟代码。每个模拟器模块会实现自己的处理器核心、内存控制器、中断控制器、磁盘控制器、终端控制器等。这个架构的好处是新机器的模拟器可以复用很多公共设施比如控制台框架、命令解析器、设备 attach 机制、日志系统。对于 Mitra-15 这样一台设备也不算太复杂的小型机用 SIMH 框架来做远比从零写一个单体模拟器要高效得多。2.3 为什么 SIMH 适合承载 Mitra-15从开发角度看使用 SIMH 有三个明显的好处。第一调试工具现成。SIMH 自带日志、反汇编、内存 dump 等辅助能力开发者不需要自己再写一套调试器。第二社区经验丰富。几十台机器的模拟器已经完成遇到“磁盘镜像格式怎么定义”“终端输入输出怎么处理”这类问题几乎都能在已有模拟器代码里找到参照。第三测试方法成熟。老系统通常有诊断程序模拟器能不能通过对诊断程序的测试是衡量工作是否完成的金标准。不过选择 SIMH 也意味着需要遵循 SIMH 的框架约定。如果作者想引入一个完全不在框架支持范围内的特殊外设比如 Mitra-15 独有的实时设备就必须自己实现适配层。好在 Mitra-15 的定位是小型机外设类型大概率还是纸带、磁盘、终端这类经典设备完成度会更容易推进。3. Mitra-15 模拟需要解决的核心技术点3.1 CPU 与指令集模拟任何模拟器的第一步都是实现 CPU 核心。从公开资料看Mitra-15 是一台 16 位小型机和当时的许多小型机一样强调实时响应和中断处理能力。模拟器需要精确还原寄存器、寻址模式、条件码、堆栈操作以及所有指令的语义。这个阶段最容易犯的错误是“只做指令翻译不做状态还原”。很多模拟器项目在最早期只关注指令能不能得到正确结果却忽略了处理器状态在不同指令之间的变化。对于 Mitra-15 这种实时机器来说中断现场保存和恢复尤其重要如果模拟器在中断时没有正确保存程序计数器和处理器状态字后面所有设备交互都会走样。3.2 内存管理与外设地址映射小型机时代的内存管理往往很简单有时就是统一编址。模拟器需要决定内存的容量范围以及外设寄存器是否在内存地址空间里。如果 Mitra-15 采用内存映射 I/O那么模拟器就要对特定地址段进行拦截把读操作转发给外设控制器而不是普通内存。这听起来不复杂但在模拟器里性能优化往往在这里出现分歧。简单的 map 表查找可以满足早期调试但如果你希望模拟器跑得足够流畅就要考虑缓存最热门的地址映射结果。对 WIP 项目来说先保证正确再考虑速度这个顺序最好不要反过来。3.3 中断、实时时钟与设备模拟Mitra-15 如果像大多数实时小型机一样会提供多级中断和实时时钟。模拟器的中断处理要在“指令执行周期”和“外部设备事件”之间建立联系。例如纸带阅读器完成一个字符的读取后需要触发一次中断实时时钟每过一定时间也要触发一次中断。这些中断时序不精确的话运行结果就会出现偏差。设备模拟方面纸带阅读器、纸带穿孔机、控制台终端、磁盘驱动器都是常见外设。每一种设备都要实现“状态寄存器读取”“数据缓冲区读写”“中断触发”这三个基本能力。对于 WIP 项目设备往往是一个一个加进去的。最先完成的通常是最基础的终端因为它能立刻和用户交互也最容易验证。3.4 引导流程与软件镜像加载模拟器建设完成后面临的另一个问题是软件从哪里来老系统的引导流程通常是控制台面板上输入一段引导程序然后从纸带或磁盘读取操作系统。如果你手上没有原始的 ROM 或引导纸带镜像模拟器就只能停留在“裸机”状态CPU 能跑但没有东西可跑。这也是 WIP 项目比较尴尬的地方。CPU 设备代码可能已经写了 90%但缺一个镜像就不方便演示。因此在参与这类项目时除了关注模拟器代码本身也值得关注项目里有没有配套的镜像文件和授权说明。很多老软件的版权状态并不清晰如果要公开分发必须谨慎处理。4. 环境准备与前置条件4.1 软硬件环境想要编译并运行一个 Mitra-15 模拟器现阶段不需要太高配置。因为模拟对象是 50 年前的小型机性能压力非常小普通 x86_64 Linux 机器就足够甚至在一台 1 核 1GB 内存的云主机上也能完成编译和基础测试。如果你用的是 macOS 或 Windows也可以通过 WSL 或虚拟机跑 Linux 环境。本文后续命令以 Ubuntu/Debian 为例但这不代表其他系统不行。实际开发过程中最影响效率的不是 CPU 性能而是工具链和资料访问能力。你需要一个能稳定工作的 C 编译器、Git 和 make/cmake 等构建工具。如果项目启用了网络模拟可能还要安装 libpcap 开发库。不过对于 Mitra-15 这种小型机来说网络外设可能不是第一优先级装上也只是有备无患。4.2 安装基础工具链在 Ubuntu/Debian 系统上可以先执行以下命令安装基础依赖sudo apt update sudo apt install build-essential git libpcap-dev如果你的模拟器项目使用 CMake 管理构建还需要补上 cmakesudo apt install cmake这一步不需要额外配置。工具链装好后可以快速检查版本gcc --version git --version make --version只要这些命令能正常输出版本号说明环境基本就绪。需要注意不同项目的构建系统可能不一样有的用传统 Makefile有的用 CMake有的甚至直接提供预编译二进制。具体以项目 README 为准这里只是通用准备流程。4.3 获得模拟器源码因为“French CIIs Mitra-15 in SIMH”是社区项目源码获取方式以后续官方仓库为准。通常的路径是使用 Git 克隆git clone mitra15-simh-repo-url cd mitra15-simh如果项目直接集成在 SIMH 主仓库里那么你可以先克隆 SIMH 主仓库再查看其中是否有 mitra15 相关目录。无论如何进入源码目录后第一件事是读 README。WIP 项目的 README 会告诉你当前实现了什么、缺什么、怎么构建、有哪些已知问题。这些信息比任何第三方博客都准确。5. 构建 Mitra-15 模拟器的完整流程5.1 编译前的目录检查进入源码目录后先观察一下目录结构。一个典型的 SIMH 项目会包含src/或sim/模拟器核心源码。makefile或CMakeLists.txt构建脚本。doc/硬件手册、用法说明。test/回归测试脚本。ini/或misc/配置文件示例。先不要急着编译重点看一下 README 里有没有说明这个项目当前依赖哪个版本的“宿主 SIMH”。如果它是作为 SIMH 的分支开发你需要在正确的分支或提交上构建如果它是独立项目那通常自带全部模拟器代码不需要额外下载宿主框架。5.2 使用传统 make 构建很多 SIMH 系列模拟器延续了简单的 make 流程。在项目根目录执行make这一步会编译所有源码并生成和模拟器对应的可执行文件。如果只是要构建 Mitra-15 模拟器而项目同时包含多个模拟器目标可能需要指定目标名例如make mitra15具体目标名以 README 为准。编译成功后会看到类似simh-mitra15或mitra15的可执行文件出现在目录中。5.3 使用 CMake 构建如果项目采用 CMake则流程更现代化一些cmake -S . -B build cmake --build build构建产物会出现在build/目录下。CMake 的好处是可以生成不同平台的项目文件也方便 IDE 导入。对于 WIP 项目如果作者同时在开发新设备每次改动后重新跑cmake --build build就行增量编译速度比全量 make 更可控。5.4 确认模拟器可执行文件构建完成后先执行一个最简单的冒烟测试。启动模拟器./build/mitra15如果项目最终生成的可执行文件名不同请替换为实际名称。启动后如果能看到sim提示符说明模拟器内核已经能运行。这时候输入help或show version可以查看命令帮助和模拟器版本。如果这里就报错先回去检查编译过程有没有未解决的链接错误。6. 运行结果与效果验证6.1 没有镜像也能验证框架WIP 项目的一个常见现象是还没有运行镜像所以 CPU 无法启动。但这不代表模拟器无法测试。你仍然可以做几类验证检查设备枚举。在sim提示符下输入show devices或show configuration看模拟器是否能列出已经实现的设备。检查寄存器访问。如果模拟器提供examine命令可以查看 CPU 寄存器和内存地址。检查单步执行。如果实现了单步功能可以在没有镜像的情况下单步执行一条指令观察程序计数器和寄存器变化。下面是一个典型交互示例sim show version MITRA-15 simulator V0.1 (Work in Progress) sim show devices CPU: 16-bit MEM: 128K PTR: paper tape reader PTP: paper tape punch CON: console terminal sim exit请把这个输出当成演示不是实际输出。不同项目、不同阶段的输出差别非常大。关键是看命令是否能被识别、设备列表是否在逐步变完整。6.2 如果有引导镜像假如项目已经附带引导镜像或磁盘镜像可以尝试挂载并启动。以纸带镜像为例在sim提示符下sim attach -i ptr mitra15.pt sim boot cpu如果镜像正确且 CPU 模拟没有明显问题屏幕上可能会打印监控程序提示符或一段引导信息。此时你就进入了这台虚拟 Mitra-15 的操作环境。不过要注意如果镜像来自商业操作系统或私有软件必须确认其授权允许在模拟器中使用和分发。6.3 用脚本做自动化验证对于开发者和贡献者最后好用的方式是写一个自动化检查脚本把模拟器启动、命令交互、退出过程固定下来。比如#!/bin/bash # quick_check.sh ./build/mitra15 EOF show version help exit EOF运行bash quick_check.sh只要模拟器能正常走完这个流程说明基础框架没有崩溃。后续写回归测试时也可以用类似方式把某条指令的输入和输出记录下来做成 golden test。这类测试对 WIP 项目尤其有价值它能防止你在添加新外设时把旧功能弄坏。7. 常见问题与排查思路模拟器项目出了 bug最忌讳的是不读日志就直接改代码。先从现象下手一步步缩小范围。下表整理了几类常见问题和排查方向问题现象可能原因排查方式解决方案编译报错缺少头文件工具链或依赖库不完整查看第一行错误信息安装对应开发包如 libpcap-dev编译失败提示未定义的引用项目有多个目标链接选项不对阅读 makefile 或 CMakeLists用make help查看可用目标启动后没有sim提示符可执行文件选错或模拟器还在启动阶段崩溃用 gdb 或 strace 启动从错误堆栈定位具体签名错误attach镜像失败镜像格式与模拟器不匹配检查文件头对比 README 说明转换镜像格式或调整目标设备类型单步执行结果不对指令解码或标志位处理有误对照原厂手册手工推演一条指令编写最小指令测试用例终端输入不回显控制台终端模式不正确检查终端 raw/cooked 模式设置调整模拟器 console 配置磁盘读写总出错磁盘镜像偏移计算有误用 hexdump 检查镜像内容修正控制器逻辑中的块偏移每一个问题都不要靠猜。模拟器的调试过程很像历史侦探工作先确认输入数据再观察中间状态最后锁定代码位置。如果你手上能拿到原厂诊断程序那是最好的测试集因为诊断程序会以非常严格的方式遍历所有指令、内存和中断组合。WIP 项目能跑过自带测试已经很不错了跑过诊断程序则是里程碑。8. 最佳实践与工程建议8.1 从最小闭环开始迭代不管你是项目维护者还是贡献者第一个里程碑都应该是“最小闭环”。这意味着先不要追求完整外设只实现 CPU、少量内存和终端设备让模拟器能启动、能退出、能执行简单汇编指令。这个闭环一旦打通后续每次加入新指令和新设备都有稳定的测试基线。比如你可以先不管磁盘也不用管实时时钟先跑一个MOV或ADD指令在终端打印结果。实现一条指令就为它写一个测试。这种习惯在 WIP 项目里尤其重要因为代码变化快没有测试几天后就没人知道什么东西可用了。8.2 资料收集比写代码更花时间Mitra-15 的官方文档、原理图、指令手册是稀缺资源能找到扫描件要第一时间归档。很多老系统的细节光靠逆向工程很难猜准。硬件手册会明确告诉你怎么看状态寄存器指令手册会说明每条指令的周期和标志位变化。没有这些资料模拟器写出来很可能是“行为相似但细节错误”。如果项目是公开的最好把收集到的资料链接、扫描件元数据都写进文档。这不仅方便协作者也是在保护这段计算机历史。你保存一份资料可能就让多年后的研究者少走很多弯路。8.3 用诊断程序和原厂软件做交叉验证判断模拟器是否合格有两个层次。第一层是“能运行简单程序”第二层是“能运行原厂诊断程序和真实工业软件”。很多模拟器项目在第一层做得很快但到了第二层就被各种细节问题卡住某条指令的寻址模式差一位、某个中断的优先级反了、某次内存操作的时序不对。这些问题只能通过反复跑诊断程序来暴露。所以如果项目里还没有诊断程序镜像去收集和申请授权如果已经有把它纳入自动化测试。每修完一个 bug就重跑一遍全部诊断程序确保没有回归。8.4 版权与许可边界历史软件的版权问题绝对不能忽略。模拟器本身是开源代码这没问题但模拟器附带的 ROM、系统镜像、诊断程序可能并没有开源许可。在发布任何镜像之前先确认它的来源和授权。如果版权不明最好的做法是只提供“如何自行从原厂磁带提取镜像”的指南而不直接在仓库里分发。另外仓库文档里应该明确列出哪些内容是源码、哪些是第三方内容、各自采用什么许可证。这个动作虽然不写一行代码但对社区可持续发展非常重要。8.5 参与社区的正确姿势如果你想把 “French CIIs Mitra-15 in SIMH” 这个项目作为自己的练习场建议从阅读 issue 列表开始。不用急着提交大段补丁先找两个容易入手的地方一是补充测试用例二是改进设备模拟的边界条件处理。这类改动风险低、反馈快也容易让维护者信任你。在提 issue 或 pull request 时把复现步骤写清楚。模拟器相关的 bug 往往依赖镜像和命令序列只说“执行 boot 失败”几乎没人能帮你定位。最好附上你使用的构建命令、模拟器版本、镜像文件信息以及完整的终端输出。9. 总结与后续学习方向现在回到开头的问题为什么有人要花时间模拟一台法国 CII 的 Mitra-15答案不只是怀旧。一台老机器的模拟器是理解那个时代软件生态和硬件设计的最佳窗口也是保存计算机历史数据的唯一可靠方式。“French CIIs Mitra-15 in SIMH. Work in Progress” 这个项目虽然还处于早期但它选择了一条对的路借 SIMH 的成熟框架一步步还原 CPU、内存、中断和外设而不是从零开始重复造轮子。如果你想继续深入建议按下面的顺序实践先把 SIMH 跑起来随便选一台已完成的模拟器感受一下交互方式然后去读 Mitra-15 模拟器的最小源码理解它是如何注册控制台命令、如何映射内存、如何触发中断的接着找一份纸带或磁盘镜像试试能不能引导。如果镜像暂时缺失也不用着急把模拟器的单步执行和寄存器查看能力用好同样能学到很多处理器底层知识。最后提醒一句这类 WIP 项目变化很快今天写的命令可能下周就换了。最好的办法是保持对上游仓库的关注顺手把自己踩过的坑记成文档。等你真的跑通一条 Mitra-15 指令的那一刻那种穿越时间的感觉只有经历过的人才会懂。