PC Engine CPU

# PC Engine CPU 来源：https://jsgroth.dev/blog/posts/pc-engine-cpu/ 在萌生了研究新系统的念头后，我一直都在开发一款 PC Engine 模拟器（又名 TurboGrafx-16），并在硬件层面发现它相当有趣。这款主机最初于 1987 年发布，其硬件在技术上处于一个比较尴尬的位置——介于第三代游戏主机（NES、Sega Master System）和第四代主机（Genesis / Mega Drive、SNES）之间，不过由于图形表现比 NES 和 SMS 有明显提升，通常被归入后一类。它在日本销量不错，但在北美却难以与 Genesis 和 Super Nintendo 竞争，而且从未（正式）在欧洲发售。它在历史上具有重要地位，因为它是第一款通过 CD-ROM² 附加组件（又名 TurboGrafx-CD）支持光盘游戏的主机。 这篇文章专门概述 PC Engine 的 CPU，我认为其有趣之处在于，它在其时代*非常*快，但指令集功能却比其直接竞争者（[Motorola 68000](https://en.wikipedia.org/wiki/Motorola_68000) 和 [WDC 65C816](https://en.wikipedia.org/wiki/WDC_65C816)）要有限得多。 ## 涡轮增压版 6502 尽管在北美被称为 TurboGrafx-"16"，这款主机实际上并没有 16 位 CPU！这不像 68000 那样会有人在争论它到底是 16 位还是 32 位；PC Engine 的 CPU 根本没有任何 16 位的成分。它拥有 8 位寄存器、8 位 ALU 和 8 位数据总线。不过它试图用纯粹的速度来弥补这一点。 该 CPU 是 Hudson 设计的定制封装芯片 **HuC6280** 的一部分，其中除了 CPU 核心外还包含一些其他硬件，例如 PSG 声音芯片和硬件定时器。CPU 本身*大量*基于 **65C02**（Western Design Center 对经典的 **6502** 8 位 CPU 的增强版）。任何有 NES（6502 减去 [BCD](https://en.wikipedia.org/wiki/Binary-coded_decimal) 模式）或 SNES（[65C816](https://en.wikipedia.org/wiki/WDC_65C816)，WDC 对 65C02 的 16 位扩展）编程经验的人都会觉得其指令集*非常*熟悉，不过它还添加了许多 HuC6280 独有的额外指令。 HuC6280 继承了 65C02 的大部分新指令和新寻址模式（零页间接寻址），并修复了 6502 一些比较别扭的问题，比如 `jmp ($xxFF)` 指令在读取跳转地址时会不直观地在同一个 256 字节页面内回绕。此外，6502 中那些疯狂的非法操作码行为也不存在了；PC Engine CPU 有 22 个未使用的操作码，但它们似乎都只是普通的 NOP，甚至不像某些非法 6502 操作码那样会执行有趣的多字节 NOP。 CPU 可以在两种时钟速度下运行：“低速”（约 1.79 MHz，与 NES 相同）或“高速”（约 7.16 MHz）。CPU 总是以低速启动，游戏可以使用 CPU 指令 CSL（Clock Speed Low，或 Change Speed Low？）和 CSH（Clock Speed High）在两种速度之间切换。据我所知，以更快的 7.16 MHz 运行没有任何缺点，因此游戏通常会在启动后立即执行 CSH 指令，然后将 CPU 保持在高速状态。 对于一款 80 年代末/90 年代初基于 6502 的 CPU 来说，7.16 MHz *很快*！这正好是 SNES CPU 速度的两倍，而且更重要的是，PC Engine CPU 大部分情况下不会像 SNES CPU 那样遇到内存延迟问题。每次访问视频处理器端口时都会有一个等待周期，但除此之外，PC Engine 中没有内存延迟——ROM 和 RAM 的所有区域都可以在一个 7.16 MHz 时钟周期内响应。实际上，这使 PC Engine CPU 通常*超过* SNES CPU 速度的两倍……只要你不需要对 16 位值执行任何数学或逻辑运算。 就原始速度而言，PC Engine 与 Genesis 的主 7.67 MHz 68000 CPU 相比也占优势，尽管这种比较远没那么直接。68000 每个时钟周期完成的工作量比基于 6502 的 CPU 少，但它通过大量几乎通用的 32 位寄存器（“几乎”是因为数据/地址寄存器分开）和更强大的指令集来弥补。哪个 CPU 性能更好取决于代码及其编写方式。 在周期计数方面，值得注意的是，许多 HuC6280 指令比等效的 6502 或 65816 指令多花费 1 或 2 个周期。例如，使用绝对寻址的 ADC 在 6502 上需要 4 个周期，但在 HuC6280 上需要 5 个周期。此外，对于 6502 在页面交叉时有潜在惩罚周期的指令（例如绝对索引寻址指令），HuC6280 似乎*总是*占用惩罚周期，即使没有发生页面交叉。这样做可能是为了更容易支持高时钟速度，或者通过在不同指令之间共享更多电路来节省成本。但这纯粹是猜测。 ## 内存管理 HuC6280 上运行的软件使用 16 位内存地址，与 6502 软件相同，但 HuC6280 内置了一个 **MMU**，将物理地址空间从 16 位扩展到 21 位（2 MB 地址范围）。就 MMU 而言，它极其简单：它将 16 位逻辑地址空间分割成八个 8 KB 页面，每个页面都有自己的 8 位 MPR（内存页面寄存器），直接映射到一个 8 KB 物理页面。这与许多 NES / Game Boy / Master System / Game Gear 卡带中的内存组映射器非常相似，只是它内置于 CPU 中，因此游戏卡带无需包含自己的映射器硬件（尽管有一款游戏由于 ROM 体积庞大，仍然带有映射器）。 | MPR | 逻辑地址 | |---------|--------------| | MPR0 | $0000-$1FFF | | MPR1 | $2000-$3FFF | | MPR2 | $4000-$5FFF | | MPR3 | $6000-$7FFF | | MPR4 | $8000-$9FFF | | MPR5 | $A000-$BFFF | | MPR6 | $C000-$DFFF | | MPR7 | $E000-$FFFF | 地址转换很简单： ``` # logical_addr 是 16 位地址，返回 21 位物理地址 def translate_address(logical_addr): logical_page = logical_addr >> 13 physical_page = MPR[logical_page] return (physical_page << 13) | (logical_addr & 0x1FFF) ``` 按照惯例，PC Engine 游戏似乎总是将页面 0（$0000-$1FFF）映射到内存映射 I/O 页面（$FF），页面 1（$2000-$3FFF）映射到工作 RAM 页面（$F8），页面 7（$E000-$FFFF）映射到卡带 ROM 的前 8 KB（页面 $00），同时根据需要自由重映射页面 2-6。游戏可以使用 CPU 指令 TAMi（将累加器传输到 MPRi）和 TMAi（将 MPRi 传输到累加器）与八个 MPR 进行交互。 HuC6280 的零页和硬件堆栈位于 $2000-$21FF，而不是 6502 上的 $0000-$01FF。这大概是因为游戏预计会将 $0000-$1FFF 页面完全用于内存映射 I/O。是的，“零页”这个名称在它实际上不在 $0000 时有点别扭，但我猜 Hudson 认为使用与 6502 相同的术语更有利。相比之下，65816 支持重定位零页，WDC 将其重命名为“直接页”作为其中的一部分。 主机的物理内存映射非常简单，远没有复杂的 SNES 内存映射那么复杂： | 页面 | 描述 | |------------|----------------------------------------| | $00-$7F | HuCard 游戏卡带或 CD-ROM² System Card | | $80-$F7 | 扩展（CD-ROM² 附加组件用于额外 RAM） | | $F8 | 8 KB 工作 RAM | | $F9-$FB | 扩展（SuperGrafx 用于额外 RAM） | | $FF | 内存映射 I/O 寄存器和端口 | 这限制了游戏卡带的大小为 1 MB，不过《街头霸王 II》通过一个组切换映射器来管理对其庞大 2.5 MB ROM（至少按 PCE 标准来说很大）的访问，从而解决了这个问题。Genesis 版本的《超级街头霸王 II》也恰好是唯一一款官方授权的、卡带中带有组切换映射器的 Genesis 游戏，所以我想 Capcom 只是愿意使用定制硬件来移植他们旗舰街机游戏的高 ROM 量版本。 8 KB 的工作 RAM 并不算多！它比 NES（2 KB）多得多，但相当于原始 Game Boy 和 Sega Master System / Game Gear，并且*远*少于 Genesis（64 KB）或 SNES（128 KB）。CD-ROM² 附加组件的各种修订版通过添加 64 KB 到 2 MB 的额外 RAM 来增强这一点，这还不包括声音芯片缓冲区 RAM。尽管考虑到 CD-ROM² 游戏需要提前将代码和资源加载到 RAM 中（因为从光盘读取的延迟极高），而 HuCard 游戏可以随时直接从卡带执行代码和读取数据，64 KB 确实不算多。 ## 一些新的技巧 在新指令中，最突出的是五条块传输指令：TAI、TDD、TIA、TII 和 TIN。它们都执行相同的操作——从一块内存批量复制到另一块内存——但每种指令对源地址和目标地址应用不同的地址步进。这些类似于 65816 的 MVN 和 MVP 指令（负/正向移动数据），但与 SNES 不同，PC Engine 没有可以访问卡带 ROM 或 CPU 工作 RAM 的 DMA 硬件，因此这些指令在 PC Engine 上实际上很有用。 | 指令 | 源地址步进 | 目标地址步进 | |------|------------|--------------| | TAI | 交替 | 递增 | | TDD | 递减 | 递减 | | TIA | 递增 | 交替 | | TII | 递增 | 递增 | | TIN | 递增 | 无（固定） | HuC6280 块传输指令 “交替”是指在每个字节复制后交替进行递增 1 和递减 1，这对于批量复制进出例如视频处理器的 16 位数据端口非常有用。 这些指令以每字节 6 个周期的速度复制，外加每条指令 17 个周期的开销。如果复制足够多的数据，开销可以忽略不计，每字节 6 个周期虽然不算飞快，但比软件复制快得多。专用硬件 DMA 单元可能会比这更快，但在 PC Engine 上，这些指令似乎是向 VRAM 或工作 RAM 复制大量数据的最佳方式。 需要注意的一点是，CPU 在执行块传输过程中无法响应中断。单个块传输指令最多可以复制 64 KB，而在 7.16 MHz 模式下，CPU 每帧大约只有 120,000 个周期，因此如果你运行足够大的块传输，很容易错过多个 VBlank 中断。如果在屏幕过渡期间屏幕是黑屏的，这没问题，但在游戏过程中你可能不希望运行跨多帧的传输。 另一个我认为值得注意的新指令是 SET（设置 T），它设置新的 T 标志，但仅针对紧随其后的指令。当紧接着在 ADC、AND、EOR 或 ORA 指令之前执行时，ADC/AND/EOR/ORA 指令会对内存中的零页值进行操作，而不是对累加器进行操作，具体来说是对 ZeroPage\[X\] 处的值进行操作。这对于操作零页中的值而无需经过累加器很有用。 一些新指令高度特定于 PC Engine：ST0、ST1 和 ST2 分别将立即操作数直接写入三个 VDC 端口（视频显示控制器）之一。这对于稍微加快更新各种 VDC 寄存器的代码很有用。 除此之外，还有一条新的 BSR 指令（Branch to Subroutine，子程序分支），它的工作方式与 JSR（Jump to Subroutine，跳转子程序）几乎完全相同，只是操作数是相对于 PC 的偏移量，而不是绝对地址。我认为 BSR 相对于 JSR 的主要好处是，使用 BSR 的代码不关心它被映射到哪个内存组，而使用 JSR 的代码要求它被映射到特定的 8 KB 逻辑页面。 TST（测试位）类似于 65C02 的 TRB 和 TSB 指令（测试并重置/设置位），只是它不改变内存值，只测试指定的位。还有新的交换指令 SAX、SAY 和 SXY，用于在两个寄存器之间交换值。最后，还有新的清零指令 CLA、CLX 和 CLY，用于快速将寄存器清零而不修改 CPU 标志位。 ## 结束？ 我想后续再写一些关于 PC Engine 其他硬件部分的文章，但看情况吧。我认为视频硬件在如何与 Genesis 和 SNES 视频硬件对比方面很有趣，所以我至少可能会写一篇关于它的文章。 ## 一些参考资料 - HuC6280 CPU：http://shu.emuunlim.com/download/pcedocs/pce_cpu.html - HuC6280 操作码矩阵：https://www.chrismcovell.com/PCEdev/HuC6280_opcodes.html - TurboGrafx-16 硬件笔记：https://www.romhacking.net/documents/302/ - PC Engine / TurboGrafx-16 架构：https://www.copetti.org/writings/consoles/pc-engine/