Overview of the Mega Drive’s Hardware Architecture
This additional section is included for anyone interested in how the VDP is situated within the Mega Drive hardware architecture. I will briefly introduce the architecture and discuss how the CPU interacts with and sends data to the VDP. A simplified diagram of the architecture is shown here:
This diagram is intended to show the main components of the system and how they are connected together. The first thing to note is that there are two processors, each with its own bus: 1) the CPU, a Motorola 68000, and 2) the co-processor, a Zilog Z80. The Z80 was the CPU used in the Sega Master System, and it was included in the Mega Drive primarily to support backward compatibility. It also functions as a controller for the Yamaha YM2612 FM and the TI SN76489 PSG sound chips (the SN76489, physically a part of the VDP, was also included in the Master System). I won’t say much more about the Z80 or the sound chips of the Mega Drive here, since they don’t directly relate to the graphics capabilities of the system.
The Mega Drive’s CPU is a Motorola 68000. The 68000 was one of the most popular processors of the 1980s and could be found in PCs such as the Apple Macintosh, Commodore Amiga, Sharp X68000, and Atari ST. It was also used extensively in arcade game systems by Sega and other developers. By the late 1980s, the price of the 68000 was low enough for Sega to include it in the Mega Drive (after successful negotiations with manufacturer Signetics). There were several advantages to using the 68000 beyond its affordable cost and capable performance. It had a well-designed architecture, it was already familiar to many developers due to its widespread use, and it allowed developers to easily port arcade games that used the 68000 to the console.
Although termed a game console, the Mega Drive is functionally a computer with a CPU, RAM, video and sound chips, and peripheral device support (including modem and keyboard support). As in any computer, the Mega Drive’s CPU is in charge of executing the program instructions. Put in the simplest of terms, the CPU is responsible for moving data between the console’s various components and for performing calculations on the data. CPU instructions consist of data movement instructions (e.g., move a value from one memory location to another), arithmetic instructions (e.g., add/subtract/multiply/divide two numbers), program control instructions (e.g., jump to a place in the code if a particular condition is fulfilled), and so on. The Mega Drive itself does not have an OS or persistent storage; when the game cartridge is inserted and the console powered on, the CPU loads all of its instructions from the cartridge. The game ROM, found on the cartridge, contains two basic things: 1) the CPU instructions, and 2) the game data.
Let’s look at the function and organization of the system’s memory, with the ultimate goal of understanding how the 68000 interacts with the VDP. The Mega Drive’s 68000 has access to 64 KB of RAM, which is used to temporarily store data being processed. Specifically, all of the game state variables are stored in the RAM, including things such as the player’s health and score, the locations of the sprites on the screen, the current action states of the enemy characters, and so on. Additionally, decompressed graphics, software-based graphical effects, or other such data that the CPU is processing may be temporarily stored in the RAM before being sent to the VDP or elsewhere.
The 68000 writes data to and reads data from the RAM via the system bus, which is the wired pathway connecting the two. When sending data to the RAM, two things must be sent: the data itself, and the address in memory where the data will be stored (the 68000 has two buses to accomplish this, a 16-bit data bus and a 24-bit address bus). For example, if the programmer wants to store the number 21 at RAM location $FF0352, the following assembly language instruction to the CPU can be used:
move.b #21, $FF0352
This can be read as “Move the byte-sized decimal number 21 to memory address $FF0352” (the address is written in hexadecimal notation). Reading data from the RAM works in a similar fashion: the CPU sends a read command via the system bus to the RAM along with a memory address, and the corresponding data is sent back to the CPU. The most important point here is that each byte of the RAM is referred to by a specific address, and the CPU references that address when moving data around via the bus.
The CPU interacts with the RAM via the system bus, but what about the other components of the system, such as the cartridge ROM, the VDP, the control pads, and the Z80? These are also connected to the system bus and are referenced by the CPU in the same way as the RAM: via specific memory locations. This is a concept known as memory-mapped I/O. Each of the system’s devices is referred to by a particular memory address or range of addresses. Here is a simplified list of the 68000’s memory map in the Mega Drive for illustrative purposes:
|Start Address||End Address||Description|
|$A10002||$A10003||Controller 1 data port|
|$A10004||$A10005||Controller 2 data port|
|$C00000||$C00003||VDP data port|
|$C00004||$C00007||VDP control port|
From the programmer’s perspective, the CPU is instructed to read data from the cartridge ROM in the same way as from the RAM. The only difference is the specified address. The Z80 RAM is on a separate bus and requires an additional step for the 68000 to access it, but the same principle applies.
Although the 68000 has access to the entire range of memory addresses for the ROM and RAM (as well as the Z80’s RAM), when it communicates with the controllers and the VDP, it does so through what are called ‘ports’ defined at specific addresses. These ports have specific requirements for how they are accessed.
For the VDP, our primary concern here, there are two main ports: a control port and a data port. The 68000 sends commands to the control port 1) to set up the VDP’s registers (which define the current settings of the VDP) and 2) to tell the VDP what to do with incoming data. The VDP data port is used to read and write data to and from the VRAM (Video RAM), the VDP’s 64 KB of memory, where the graphics to be rendered on the screen are stored. To send graphics to the VRAM, for example, the 68000 first sends the VRAM address where the graphics will be written to the VDP’s control port, and then it sends the graphics data itself to the VDP’s data port. Instead of accessing the VRAM directly, the 68000 must make use of the VDP’s ports in this way, since the VRAM is not on the 68000’s bus. Note that there is a method for the VRAM to access the system bus known as DMA (Direct Memory Access), which is discussed here.
Let’s go over a brief, abstracted example of what happens when a game cartridge is played in the console. First, when the console is powered on, the CPU is initialized and begins to read in the start of the program code from the cartridge ROM. Very soon, the CPU is instructed to initialize the VDP by writing to the VDP’s control port. Through the control port, each of the VDP’s 24 registers is set to a particular value that specifies things such as where certain data will be stored in the VRAM, the background color, the background plane size, and so on. Following VDP initialization, the CPU is ready to send graphics data to the VDP. The CPU writes to the VDP’s control port, telling it that it wants to write data to the VRAM and at which address, and then the CPU writes the data to the VDP’s data port. With both the data and address known, the VDP is able to store the incoming data in VRAM. This process is repeated over and over until all of the graphics data has been loaded into VRAM.
To summarize, one of the primary functions of the CPU is to move data around the system. The components of the system (such as the RAM and the VDP) are connected to the CPU through the system bus, and the CPU accesses them through specific memory-mapped addresses. The VDP, in particular, is accessed through two main ports, a control port for sending instructions and a data port for sending and receiving data. In order to display graphics on the screen, the CPU must first send the graphics data from the cartridge ROM or the RAM to the VRAM through the VDP’s data port.
Why is it important to understand how the console sends graphics data to the VDP? This highlights one of the limitations that programmers faced: there is a bottleneck in regards to how much data can be sent to the VDP in a short period of time. Therefore, even though a large amount of data can be stored in the cartridge ROM, only a small portion of it is accessible to the VDP at any one time in VRAM, and the process of sending new data to the VDP is relatively slow.
Want to post a comment? You can do so here.