Graphics are managed by the Hudson Soft HuC6270, a separate chip also referred to as the Video Display Controller or 'VDC'. The HuC6270 draws everything that the player sees on the screen, and its functionality is very similar to Sega's counterpart. For this article, I will focus on the unique aspects of Hudson's offering.
Organising the content
First things first, the VDC is a tile engine (a standard feature until the 5th generation showed up) - but note that the PC Engine includes 64 KB of Video RAM (VRAM), which is a significant amount compared to the competition. This may lead to new types of content, which we will explore later.
Memory architecture of the VDC.
The arrangement of graphics data can be somewhat confusing: both the CPU and VDC use 16-bit addresses, but while the CPU can only handle 8-bit words, the HuC6270 stores 16-bit words in VRAM . This means that a single address in RAM stores one byte, whereas an address in VRAM stores two bytes. Developers therefore needed to account for this discrepancy when transferring data to VRAM.
The reason for this lies in the way Hudson organised the circuitry: The VDC has a 16-bit address bus, but only the first 15 lines are controlled (the last one is always set to 0), meaning odd addresses are fetched from the second byte. I am unsure why Hudson went down this path, but it would make more sense if the system had 128 KB of VRAM instead (since a 16-bit address bus can only access up to 64 KB, doubling the data bus could allow up to 128 KB to be retrieved). Perhaps this was the original plan for Hudson/NEC?
Constructing the frame
Aside from the aforementioned granularity oddity, the VDC is functionally straightforward. The subsystem has three main components: The VDC and VRAM, which we already discussed, and the Video Colour Encoder (also called 'VCE'; we will examine it in due course).
The system supports multiple resolutions; this is because the game can modify a set of registers that act as parameters for controlling the display timings, which in turn alter the CRT's scan timings. The minimum resolution is 256 × 224 pixels , while some homebrew projects have demonstrated that this system can achieve resolutions as high as 512 × 240 pixels.
Now, let's see how a frame is drawn step by step. For this, I will borrow assets from Bonk's Adventure.
Tiles
Background tiles.
Sprite tiles.
As a quick reminder, tiles are simply 8x8 pixel bitmaps that the renderer fetches to draw portions of the screen. With the VDC, the frame is composed of two planes: the background layer and the sprite layer.
Inside VRAM, there is an area called Character generator, where tiles exclusive to the background layer are defined. Each pixel of a tile occupies four bits, allowing to use up to 16 colours. In theory, up to 4096 background tiles can be defined, but this is reduced in practice due to VRAM being much smaller.
Sprites, on the other hand, are drawn using tiles from a separate memory location in VRAM. This is called Sprite Generator and differs from the previous Character generator, as tiles here are 16x16 pixels wide.
The video encoder is a separate chip that stores 32 colour palettes (16 for the background and 16 for sprites) . Each palette stores 16 colours, and each colour is 9 bits wide (3 bits for Red, 3 bits for Green, and 3 bits for Blue).
Storing tiles
Structure of a single Background tile.
Structure of a single Sprite tile.
(This section is written for those interested in how Hudson leveraged the 64 KB of VRAM with its 16-bit granularity, but you don't need to fully understand it to follow the rest of the article).
So far, we have discussed that each pixel of a tile is stored using 4 bits (or half a byte, also called a nibble). Now, Hudson dictates that tiles are encoded as four 8x8 bitmaps (called 'CH0', 'CH1', 'CH2', and 'CH3', respectively). Each map is 1-bit wide, but when the four are combined, they form the final tile with 4-bit pixels.
Due to the 16-bit alignment, each 16-bit word stores a single row of two 1-bit bitmaps (8 rows + 8 rows). So, writing eight entries results in two maps being stored (instead of just one). Please have a look at the diagrams for a clearer understanding.
The same applies to Sprite tiles, but since they are 16x16 bitmaps, each bitmap occupies 16 words. To put it another way, storing a single sprite tile requires 64 words (resulting in 8 bytes from VRAM).
Background Layer
Rendered background layer.
The background layer is constructed by filling the Background Attribute Table with entries in VRAM. The position of each entry defines the X/Y coordinates of the tile on the screen. Each entry contains the tile index from the Character Generator and the colour palette.
The maximum dimension of this layer is 1024 x 512 pixels (128 x 64 tiles), but programmers can configure a 256 x 256 pixels (32 x 32 tiles) layer as the minimum.
As always, this layer is scrollable by changing particular registers in the VDC.
Sprite Layer
Rendered Sprite layer.
The VDC contains an internal memory called Sprite Attribute Table Buffer, where up to 64 sprites can be defined. Each entry in the table stores the independent X/Y position, colour palette, tile index, and horizontal/vertical flip. Furthermore, there is an attribute that allows to combine a sprite with another.
Each entry is 8 bytes long, although some space is wasted due to the 16-bit granularity.
To top it all off, the CPU can't access this table, so it must be completed in VRAM first and then transferred to the VDC via a Direct Memory Access (DMA) channel.
Regarding limitations, only up to 16 sprites can appear per scan-line. On the other hand, interrupts can be configured to notify the game in case of sprite overflow or collision.
Result
Tada!
Until now, we have seen how the VDC performs most of the heavy work, but the final task is actually delegated to the Video Colour Encoder or 'VCE'. Found on the motherboard as the HuC6260 chip, its primary function is to receive 9-bit data streams from the VDC, apply the colour palettes, and send the result to the TV as an analogue signal.
If you have read previous articles, you may be familiar with the importance of timing. This case is no exception: to avoid unwanted artefacts (such as 'snow'), the VCE can only be updated during a vertical interrupt.
Video Output
The video encoder outputs RGB (along with Sync) and YPbPr, which is ideal for use with a SCART cable or component cable, respectively. This looks promising so far...
RF port at the right side of the PC Engine.
The 'Turbo Booster' for the TurboGrafx-16 , connected to the Expansion port to supply video composite and power.
... Unfortunately, Hudson decided to fit an RF modulator as the only way to get video out-of-the-box, so it's not that great after all. But then again, the PC Engine was designed in the 80s, so this approach guaranteed compatibility with most TVs of the same region.
On the bright side, the 'Expansion Port' exposes pins that carry RGB video and multiple sync types, but an external accessory is required to take advantage of them.