« Mega Drive / Genesis Architecture (index)

Mega Drive / Genesis Architecture

Chapter 4: Graphics


Table of Contents

  1. Behind the multiple display resolutions
  2. Organising the content
    1. Memory available
  3. Constructing the frame
    1. Tiles
    2. Background
    3. Foreground
    4. Sprites
    5. Result
  4. A dedicated transfer unit
  5. Video Output

The answer is Blast Processing! What else do you need to know?

Okay, if you want to know the real answer: graphics data is processed by the 68000 and rendered on a proprietary chip called Video Display Processor (or 'VDP' for short), which then sends the resulting frame (in the form of scan lines) for display.

The VDP runs at ~13 MHz and supports multiple resolution modes depending on the region: up to 320x224 pixels in NTSC and up to 320x240 pixels in PAL.

Behind the multiple display resolutions

Technically speaking, the VDP can fit either 40 or 32 columns of tiles per scan-line, and the number of tile rows depends on the region (28 in NTSC or 30 in PAL) . Although, most PAL games do not bother with the extra tiles allowed in PAL systems (as they probably need to keep consistency between the two regions, and NTSC is the common denominator) so they instruct the VDP to render with 28 rows (as in NTSC systems). Thus, the VDP has no option but to fill the unused area with a backdrop colour (also used during overscan).

You can identify which PAL games render in NTSC mode by checking the Mode Set Register #2 in an emulator with debugging capabilities (e.g., Exodus). If the fourth bit from the right is 0, the VDP is running in NTSC mode .

Image
To provide a quick multiplayer mode in Sonic 2 (1992), the game activates 'interlaced mode' to render a single-player level using 8x16 pixel tiles instead (along with other changes).

Image
By contrast, the more sophisticated multiplayer mode of Sonic 3 (1994) relies on dedicated 8x8 pixel tiles that are separate from single-player levels.

Furthermore, there's an additional parameter that can be set on the VDP to stack two tiles to form 8x16 maps and then treat them as a single tile. Hence, doubling the vertical resolution. However, this halves the refresh rate as frames are now rendered with interlacing (one frame renders even scan-lines, the next beams odd ones, and so forth) so it's more limited in terms of functionality. The multiplayer mode of Sonic 2 is a good representation of this mode .

Finally, it's worth pointing out that the VDP automatically takes care of adding padding for the overscan area, so games don't have to worry about which areas are safe to draw graphics into (as it happened with the NES' 'danger zones').

Organising the content

In terms of processing the graphics data, this chip has two modes of operation:

What about Modes 0 to III? Well, these belong to the even older SG-1000 and the Mega Drive does not support them.

As an interesting note, a former developer of this system told me that the command structure of Mode V (used to control the VDP) inherits the design from the TMS9918, the well-known video chip used in the SG-1000 . This made it easier for third-party developers to operate Mode V without relying on official documentation (and subsequent licensing costs).

Memory available

Image
Memory architecture of the VDP.

The graphics content is distributed across three regions of memory :

Constructing the frame

The following section explains how the VDP draws each frame. For demonstration purposes, Sonic The Hedgehog is used as an example. Before proceeding, I recommend checking out the modus operandi of its predecessor since a lot will be revisited here.

Tiles

Image
Multiple tiles squashed together. For demonstration purposes, a default palette is being used.

Image
A single 8x8 pixel tile.

Some tiles found in VRAM.

Just like Nintendo's PPU, the VDP is a tile-based engine, and as such, it uses tiles (basic 8x8 bitmaps) to compose graphic planes. In the case of the VDP, each tile is encoded with a 4-byte-long array, where each 4-bit entry corresponds to a pixel and its value corresponds to a colour entry (pointing to a colour palette).

Game cartridges store tiles in their ROM (found in their cartridge) but these must be copied to VRAM for the VDP to read them . Traditionally, this was only possible during specific time frames and handled by the CPU, fortunately, this console added special circuitry to offload this task to the VDP (we'll get into details later on).

Tiles are used to construct a total of four planes, which, when merged, form the frame seen on the screen. Additionally, the tiles in these planes can overlap with each other, so the VDP determines which tile is visible based on the type of plane and the tile's priority value.

Background

Image
Allocated Background map.

Image
Allocated Background map with selected area marked.

Example of Background plane.

The Background plane, also known as Plane B, is a scrollable tilemap (set of tiles) containing static tiles .

This plane supports six different dimensions: 256x256, 256x512, 256x1024, 512x256, 512x512, and 1024x256. Programmers may select the dimension that best suits the required scrolling type.

Each tile can be flipped horizontally and/or vertically and have a priority set.

In the example shown, you will notice that the selected area for display is not a square... It doesn't have to be!. The VDP allows to set up horizontal scrolling values for the whole frame, each individual scan-line or every eight pixels. This means that developers can shape the selected area like a rhomboid and alter its angles as the player moves to simulate perspective effects. Tricks like this do not corrupt the plane; the VDP fetches each selected horizontal line and constructs a regular frame from it.

Foreground

Image
Allocated Foreground plane.

Image
Allocated Foreground plane with selected area marked.

Example of Foreground plane, the Window Plane is not used.

The Foreground plane, also known as Plane A , shares the same properties as the Background Plane except this plane has a higher priority, meaning tiles rendered here will always be on top of the Background Plane.

Additionally, this plane can divide itself to form a new sub-plane: The Window Plane. The only difference is that the latter doesn't scroll.

All in all, you can see the new priority values and separate planes enable game designers to bring new types of scenery. Furthermore, by using different scroll speeds on each plane, a parallax effect can be achieved.

Sprites

Image
Allocated Sprite layer.

Image
Allocated Sprite layer with selected area marked.

In this plane, tiles are treated as sprites. They are positioned on a 512x512 pixel map and only a portion of it (the VDP's output resolution) is selected for display. This is convenient for hiding unwanted sprites or preparing others that will be shown in the future. The VDP also provides an old collision detection function.

Sprites are formed by combining up to 4x4 tiles (32x32 pixel map) and selecting up to 16 colours (including transparent). If a bigger sprite is needed, multiple sprites can be combined into one.

There can only be a maximum of 20 sprites per scan-line and 80 per screen. Overflowing these limits will corrupt the entire layer.

The region in VRAM where sprites are defined is called Sprite Attribute Table and each entry contains the tile index, layer coordinates (x and y), link value (manages which sprites are drawn first), priority (the sprite with the highest priority is the one to be displayed during overlaps), colour palette index, and vertical and horizontal flip.

Result

Image
Resulting frame.

Image
Frame broadcasted to the TV (in NTSC format). The VDP automatically adds an overscan area, which most CRT TVs will hide.

Tada!

Image
CRAM dots in the bottom-left corner of the overscan area.

While the frame is being drawn, the system sequentially calls different interrupt routines based on the position of the CRT's beam. As you have probably seen in previous consoles, this allows the CPU to prepare the next frame (or alter the current one).

Conventionally, two types of interrupts are called: H-Blank (at every horizontal line) and V-Blank (at the end of each frame).

H-Blank is called numerous times per frame, but is limited to executing short routines. V-Blank, on the other hand, allows for longer routines, with the drawback of only being called 50 or 60 times per second (depending on the console's region).

Notice that the overscan area in the example exhibits some random coloured dots in the bottom-left corner. This phenomenon, known as CRAM dots, occurs when the CPU updates the palettes in CRAM while the VDP is beaming the remaining scan-lines (in the example, this happens during overscan). This conflict causes the VDP to fetch whatever value the CPU is writing at that moment, rather than the required location in CRAM. So, the image gets corrupted. In this particular case, the game updates CRAM only during overscan, so this anomaly goes unnoticed on traditional CRTs. At another level in the game, however, the game changes the palette mid-frame to simulate water effects. Hence, programmers tried to mask it by drawing a flickering water ripple in-between . As you can see, it's all about balancing the extra colours with the CRAM side-effect.

A dedicated transfer unit

So far we've discussed what the CPU can do to update frames, but what about the VDP? Does it provide something more specialised? Well yes, this chip features a Direct Memory Access ('DMA' for short) that allows moving data between memory locations at a faster rate and without the intervention of the CPU.

The DMA can be activated during H-Blank, V-Blank, or active state (outside any interrupt) and can be used to write over VRAM, CRAM, and/or VSRAM . However, during CPU RAM transfers using DMA, the CPU bus is blocked, so careful planning is critical for achieving performance.

Effective use of these features may enable high-resolution graphics, smooth parallax scrolling, and high frame rates. In the best cases, your game might even be featured in TV ads with lots of Blast Processing! signs over it.

Video Output

The first design of this console (commonly referred to as the 'Model 1') includes the same video out port as the Master System. The subsequent 'Model 2' and 'Model 3' revisions switched to a mini-DIN port.


Previous: 3. CPU

Next: 5. Audio


Rodrigo Copetti © 2026 RSS Feed

Switch to modern edition

Home · Writings · Support · About author · About website