GoKawiilI’ve been working on a PC Engine emulator (aka TurboGrafx-16) after getting the bug to start looking at a new system, and I’ve found it to be pretty interesting hardware-wise. Originally released in 1987, its hardware is in a sort of awkward spot between the 3rd generation gaming conoles (NES, Sega Master System) and the 4th generation consoles (Genesis / Mega Drive, SNES), though it’s generally grouped with the latter due to featuring notably improved graphics over NES and SMS. It sold pretty well in Japan, but in North America it couldn’t really compete with the Genesis and Super Nintendo, and it never even released in Europe (officially). It’s historically notable for being the first gaming console to support CD-based games via its CD-ROM2 add-on (aka TurboGrafx-CD).
This post is specifically an overview of the PC Engine’s CPU, which I think is interesting in that it’s very fast for its time but has much more limited instruction set capabilities than its immediate competition.
Despite being called the TurboGrafx-“16” in North America, this console doesn’t actually have a 16-bit CPU! This isn’t like the 68000 where people sometimes quibble over whether it’s a 16-bit CPU or 32-bit; there is simply nothing 16-bit about the PC Engine CPU. It has 8-bit registers, an 8-bit ALU, and an 8-bit data bus. It tries to make up for this with raw speed though.
The CPU is part of a custom-designed package by Hudson called the HuC6280, which includes some other hardware alongside the CPU core such as a PSG sound chip and a hardware timer. The CPU itself is heavily based on the 65C02, Western Design Center’s enhanced version of the venerable 6502 8-bit CPU. The instruction set will look very familiar to anyone with experience programming for the NES (6502 minus BCD mode) or the SNES (65C816, WDC’s 16-bit extension of the 65C02), though it also adds a number of additional instructions exclusive to the HuC6280.
The HuC6280 inherits most of the 65C02’s new instructions and the new addressing mode (zero page indirect), along with the fixes for some of the jankier aspects of the 6502, like how jmp ($xxFF) instructions would unintuitively wrap within the same 256-byte page when reading the jump address. There’s also none of the 6502’s crazy illegal opcode behavior; the PC Engine CPU has 22 unused opcodes, but they all seem to function as plain old NOPs, not even the funny multi-byte NOPs that some of the illegal 6502 opcodes would perform.
The CPU can run at one of two clock speeds: “low” (~1.79 MHz, same as NES) or “high” (~7.16 MHz). The CPU always powers on in low speed, and games can switch between the two speeds using the CPU instructions CSL (Clock Speed Low, or maybe Change Speed Low?) and CSH (Clock Speed High). As far as I can tell there are no downsides to running at the faster 7.16 MHz speed, so games tend to almost immediately execute a CSH instruction and then leave the CPU in high speed.
7.16 MHz is fast for a 6502-based CPU in the late 80s / early 90s! That’s exactly twice as fast as the SNES CPU, and even better, the PC Engine CPU mostly doesn’t suffer from memory latency like the SNES CPU does. It gets a wait cycle every time it accesses one of the video processor ports, but otherwise there is no memory latency in the PC Engine - all areas of ROM and RAM can respond in a single 7.16 MHz clock cycle. In practice this makes the PC Engine CPU usually more than twice as fast as the SNES CPU…as long as you don’t need to perform any math or logic on 16-bit values.
In terms of raw speed, the PC Engine also compares favorably to the Genesis’ main 7.67 MHz 68000 CPU, though that’s much less straightforward of a comparison. The 68000 gets much less work done per clock cycle than 6502-based CPUs, but it makes up for that with a large number of mostly-general-purpose 32-bit registers (“mostly” because of the data/address register split) and a much more powerful instruction set. Which CPU will perform better depends on the code and how it’s written.
For cycle counting, it’s worth noting that many HuC6280 instructions take 1 or 2 cycles longer than the equivalent 6502 or 65816 instruction. For example, ADC with absolute addressing takes 4 cycles on 6502 but 5 cycles on HuC6280. Also, for instructions where 6502 has a potential penalty cycle on page crossing (e.g. absolute indexed instructions), it seems like the HuC6280 always takes the penalty cycle even when there’s not a page crossing. This was maybe done to make it easier to support the high clock speed, or maybe to save costs by sharing more circuitry between different instructions. That’s purely a guess though.
Software running on the HuC6280 operates on 16-bit memory addresses, same as 6502 software, but the HuC6280 has a builtin MMU that expands the physical address space from 16-bit to 21-bit (2 MB address range). It’s extremely simple as far as MMUs go: it splits the 16-bit logical address space into eight 8 KB pages, and each page has its own 8-bit MPR (Memory Page Register) that maps it directly to an 8 KB physical page. It’s very similar to the memory-banking mappers seen in many NES / Game Boy / Master System / Game Gear cartridges, only it’s built into the CPU, so game cartridges don’t need to include their own mapper hardware (though one game still does due to its massive ROM size).
... continue reading