Hotdry.

Article

Plexus P/20 模拟器的架构设计与指令集映射策略

解析 Plexus P/20 模拟器的架构设计与指令集映射策略，探讨如何通过软件模拟实现复古硬件平台的工程挑战。

2026-04-23systems

在复古计算机保存与研究领域，软件模拟器是连接历史硬件与现代计算环境的关键桥梁。Plexus P/20 作为一款上世纪八十年代的 UNIX 服务器，其模拟器项目展示了如何通过精细的架构设计实现对特定硬件平台的软件复现。本文将从模拟器的核心架构、CPU 仿真策略、内存映射机制以及外设模拟四个维度，深入剖析 Plexus P/20 模拟器的工程实现路径。

模拟器整体架构概述

Plexus P/20 模拟器的设计目标并非仅仅模拟一颗处理器，而是要完整复现一个可以启动 UNIX 操作系统的服务器系统。从架构角度来看，该模拟器采用了经典的模块化设计思路，将整个系统划分为中央处理器单元、内存管理子系统、设备仿真层和系统总线四个主要模块。这种分层架构的优势在于各模块职责清晰，便于独立测试和迭代开发。模拟器的代码库完全使用 C 语言编写，核心库依赖仅有 Musashi M68k 处理器仿真核心和标准 C 编译工具链，这使得构建过程极为简洁 —— 在类 Unix 系统上仅需执行 make 命令即可完成编译。

模拟器目前可以正常运行的环境包括 Linux、macOS 等桌面操作系统，同时项目还提供了 WebAssembly 版本，用户可以直接在现代浏览器中运行模拟器。从功能完整性来看，模拟器已经支持从硬盘镜像启动 Plexus UNIX 系统并完成登录操作，但磁带驱动器、软盘驱动器和 Multibus 扩展卡等外设尚未实现模拟。这种分阶段实现的策略对于开源模拟器项目而言是务实的选择：先确保核心功能可用，再逐步完善周边设备支持。

Musashi 核心的定制化集成

模拟器的核心是 Motorola 68010 处理器的仿真，这是 Plexus P/20 所搭载的 CPU 型号。项目采用了久经考验的 Musashi 仿真库作为基础，该库广泛存在于各类 68k 处理器模拟项目中。然而，标准版 Musashi 并不能满足 Plexus 硬件的特定需求，因此项目进行了两项关键定制。第一项定制涉及总线错误异常处理的栈帧格式：Plexus 软件依赖于特定的栈帧结构，而上游 Musashi 的默认实现与此不兼容。项目维护者从 MAME 项目的 Musashi 分支反向移植了相关修复，确保异常处理与真实硬件行为一致。第二项定制是为 System V 系统调用追踪功能添加陷阱指令回调，模拟器中的 sysvr2-strace.c 和 sysvr2-strace.h 正是实现这一功能的代码。

这些定制修改反映了模拟器开发中的一个重要原则：通用仿真库往往无法满足特定硬件平台的细微差异要求。在实际项目中，开发者需要深入理解目标软件的运行时行为，而非仅仅追求指令级别的准确模拟。正是因为进行了这些针对性修改，Plexus UNIX 才能在模拟器上正常启动并运行。

内存映射与地址空间管理

内存子系统是模拟器中另一个关键组成部分。模拟器通过 mapper.c 和 mapper.h 两个文件实现了 68k 处理器的完整地址空间映射管理。在真实的 Plexus P/20 硬件中，系统采用统一的内存映射机制，将 RAM、ROM、I/O 设备寄存器等不同类型的物理资源映射到处理器可访问的线性地址空间中。模拟器必须精确还原这一映射关系，才能确保运行在模拟环境中的软件能够正确访问各类资源。

具体的内存区域包括：RAM 区域对应系统内存，最大支持 8MB（尽管实际销售的配置通常为 2MB）；ROM 区域存放系统启动固件，需要两个 ROM 镜像文件（U15-MERGED.BIN 和 U17-MERGED.BIN）才能正常工作；I/O 区域则映射到各个外设设备的控制寄存器。这种基于内存映射的 I/O 访问模式是早期小型计算机系统的典型特征，模拟器需要准确还原每一块寄存器的位置和访问行为。

配合内存映射，ramrom.c 实现了 RAM 和 ROM 的具体读写逻辑，包括初始化时的内存自检以及运行时的数据读写。rtcram.c 和 rtc.c 则分别处理实时时钟的 NVSRAM 存储和计时功能，这些外设在 UNIX 系统的启动过程中扮演着重要角色 —— 系统需要通过 RTC 读取当前时间来完成引导过程。

外设仿真与系统交互

除了核心的处理器和内存，Plexus P/20 模拟器还实现了多项外设的仿真。SCSI 控制器是其中最关键的部分，因为系统必须能够从硬盘启动：scsi.c、scsi_dev_hd.c 和相关头文件共同实现了 SCSI 协议和硬盘设备的仿真逻辑。用户需要准备一个 87MB 的 MFM 硬盘镜像文件（这也是真实硬件上使用的典型配置），模拟器通过仿真 SCSI 接口的读写命令来完成对镜像文件的访问。

串行通信通过 uart.c 实现，这是 Plexus P/20 与用户交互的主要方式。模拟器的控制台输出和用户输入都通过 UART 进行，在 WebAssembly 版本中，这些信号会被转换为浏览器端的交互界面。csr.c 实现的控制状态寄存器（CSR）则提供了系统级别的状态管理和中断控制功能，mbus.c 负责模拟系统总线行为，确保各设备之间的数据传输正确无误。

从构建和运行参数的角度，使用该模拟器需要关注以下几个关键点：编译阶段只需执行 make 命令生成 emu 可执行文件；运行时需要确保 ROM 镜像文件存在于指定路径（可使用系统级目录 /usr/share/p20-emu/ 或本地目录）；硬盘镜像文件需要在启动时作为参数传入。整个模拟器依赖极少，除了 C 编译器外无需其他第三方库，这大大降低了跨平台移植的难度。

工程实践的启示

Plexus P/20 模拟器的实现为复古硬件模拟提供了一个值得参考的工程范例。首先，采用模块化架构降低了各子系统之间的耦合度，使得开发团队可以并行推进不同外设的实现进度。其次，对 Musashi 核心进行针对性定制的做法说明了一个重要道理：模拟器的准确性不仅体现在指令执行层面，更体现在对目标软件运行时环境的完整还原上。第三，项目提供了 WebAssembly 版本，这一决策显著降低了用户的使用门槛，无需配置开发环境即可在浏览器中体验复古系统。

对于有兴趣构建类似模拟器的开发者，建议从以下参数开始入手：确保 68k 处理器核心支持目标型号的特定指令变体；精确还原内存映射表的每一个区域；优先实现系统启动所必需的外设（硬盘、串口、实时时钟），再逐步添加其他设备；提供清晰的错误信息和调试接口，以便用户反馈问题。随着模拟器的逐步完善，未来有望支持更多 Plexus 附件设备，进一步丰富这一复古计算平台的软件生态。

资料来源

systems