Mega Drive Architecture

Architecture of Consoles: A Practical Analysis, Volume 3

Rodrigo Copetti

Published by Rodrigo Copetti, 2019.

While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

MEGA DRIVE ARCHITECTURE

First edition. May 18, 2019.

Copyright © 2019 Rodrigo Copetti.

ISBN: 979-8201146818

Written by Rodrigo Copetti.

10 9 8 7 6 5 4 3 2 1

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture

Mega Drive/Genesis Architecture

New techniques of composition

Rodrigo Copetti

2019-05-18

© 2023 Rodrigo Copetti, CC BY-NC 4.0

1 About this edition

This edition originates from the article initially published on my personal website, it’s been re-styled to take advantage of the capabilities of PDF/eBook documents.

While identical content-wise, interactive widgets have been simplified to work with a static environment - in other words, anything that physical pages allow us, though these will offer a link to the original article in case the reader wants to try the ‘full version’. Please keep this in mind when you see references to interactivity throughout the writings.

As always, the original manuscript of the articles is available on Github to enable readers to report mistakes or propose changes. There’s also a supporting reading list available to help understand the series. The author also accepts donations to help improve the quality of current articles and upcoming ones.

1.1 Open to feedback

Last but not least, for any comments and/or issues regarding this edition of the article, please get in touch using the links provided on the About page.

2 A quick introduction

Sega (and their TV ads) want you to know: Developers can’t come up with decent games unless the console provides faster graphics and richer sounds.

Their new system includes lots of already familiar components ready to be programmed. This means that, in theory, developers would only need to learn about Sega’s new GPU… right?

3 Suporting Imagery

3.1 Models

Figure 3.1: The Mega Drive. Released on 29/10/1988 in Japan. [1]

Figure 3.2: The Genesis. Released on 14/08/1989 in America. [1]

Figure 3.3: The Mega Drive. Released on 09/1990 in Europe. [1]

3.2 Motherboard

Figure 3.4: Motherboard. Showing the Japanese ‘VA0’ revision. Notice the unusual daughterboard on top of the VDP used to fix post-manufacturing glitches (properly corrected in later revisions). [2]

Figure 3.5: Motherboard with important parts labelled.

3.3 Diagram

Figure 3.6: Main architecture diagram.

4 CPU

This console has two general-purpose processors.

Firstly, we’ve got a Motorola 68000 running at ~7.6MHz, a popular processor already present in many computers at that time, such as the Amiga, the (original) Macintosh, the Atari ST… Curiously enough, each one of these computers succeeded its ‘6502 predecessor’, and while the Master System (Mega Drive’s precursor) doesn’t use a 6502 CPU, the NES did (and in some way, Sega’s goal was to win Nintendo consumers over). All in all, you can see a bit of correlation between the evolution of computers and game console technology.

Back on topic, the 68k has the role of ‘main’ CPU and it will be used for game logic, handling I/O and graphics calculations. It has the following capabilities [3]:

68000 ISA: A new instruction set with plenty of features, including a set of multiplication and division opcodes. Some instructions are 8-bit long (called ‘byte’), others are 16-bit long (called ‘word’) and the rest are 32-bit long (called ‘long-word’).

32-bit registers: This is a big step, considering the 6502 and Z80 only have 8-bit registers.

16-bit ALU: Meaning it needs extra cycles to compute arithmetic operations on 32-bit numbers, but it’s fine on 16-bit/8-bit ones.

External 16-bit data bus: As you can see, while this CPU has some ‘32-bit capabilities’, it hasn’t been designed to be a complete 32-bit machine. The width of this bus implies better performance when moving 16-bit data around.

Interestingly enough, Motorola debuted a complete 32-bit CPU, the 68020, four years before this console’s release. But I imagine costs would’ve skyrocketed had Sega chosen the latter chip.

24-bit address bus: This means that up to 16 MB of memory can be accessed. Memory addresses are still encoded with 32-bit values inside the CPU (the upper byte is just discarded). Having said that, the bus is physically connected to [4]:

64 KB of general-purpose RAM.

Cartridge ROM (up to 4 MB).

Two Controllers.

The Video Display Processor’s registers, ports and DMA.

Motherboard’s registers (identifies the console).

Expansion ports (used for ‘future’ accessories).

The second CPU’s RAM, intermediated by the bus arbiter.

(If you wonder the reason behind using 24-bit addresses with a CPU that can handle 32-bit words, I doubt that in the 80s many were asking to manage 4 GB of RAM and adding unused lines is costly in terms of performance and money).

Secondly, there’s another CPU fitted in this console, a Zilog Z80 running at ~3.5 MHz. This is the same processor found on the Master System and it’s mainly used for sound control. It features [5]:

Z80 ISA: An extension of the Intel 8080 ISA, it handles 8-bit words.

8-bit registers and 8-bit data bus: No surprises here.

4-bit ALU: This may be a bit shocking, but it managed to handle 8-bit operations without problems, it just takes twice the cycles to compute.

Notice how the 6502 runs at ~2 MHz in some systems while this one almost reaches 4 MHz: Clock speed doesn’t make the Z80 faster per se, but helps to balance the lack of transistors in some areas.

16-bit address bus with the following address map [6]:

8 KB of RAM.

Two sound chips.

68000’s RAM (again, handled by the bus arbiter).

Finally, both CPUs run in parallel.

4.1 Memory available

The main CPU contains 64 KB of dedicated RAM to store general-purpose data and the Z80 contains 8 KB of RAM for sound-related operations.

4.1.1 Intercommunication

Sega chose two independent processors that have no awareness of each other, so how can games manage both at the same time? Well, the main program is executed in the 68000, and this CPU can subsequently write on Z80’s RAM. So, the 68000 can send a program to the Z80’s RAM and instruct the Z80 to load it (by sending a reset signal to the Z80) [7]. Once the Z80 is under control, it can then be used to manage the sound sub-system and move memory around using the previously described method, all of this while the 68000 is taking care of other operations.

Figure 4.1: Memory architecture of the Mega Drive/Genesis.

Because one CPU will have to step in the other’s CPU bus and both can’t use it at the same time, there’s an extra component called Bus arbiter that must be activated to stall either processor, so memory can be written without hazards.

It’s important to point out that this design can underperform if not managed properly, so games will have to take special care of the bus arbiter and watch for not stalling either CPU for longer than needed.

5 Graphics

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.

5.1 Behind the multiple display resolutions

Technically speaking, the VDP can either fit 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) [8]. Although, most PAL games don’t 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 they would do 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 see which PAL games render in NTSC mode by checking the Mode Set Register #2 in an emulator with debugging capabilities (i.e. Exodus). If the fourth bit from the right is 0, then the VDP is running in NTSC mode [9].

Figure 5.1: 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).

Figure 5.2: 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 [10].

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’)

5.2 Organising the content

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

Mode IV: Legacy mode that behaves like its predecessor.

This doesn’t mean this console will play Master System games right away, as an additional accessory (the Power Base Converter) is required to fit previous cartridges on this console. The converter will also instruct the I/O chip to put the Z80 in control.

Mode V: Native mode of operation, we’ll focus on this one.

What about Mode 0 to III? Well, these belong to the even older SG-1000 and the Mega Drive doesn’t support them.

As an interesting note, I’ve been later told by a former developer of this system that the command structure of Mode V (used to control the VDP within the game) inherits the design from the TMS9918 (the famous video chip used in the SG-1000) [11]. This made it easier for third-party developers to use Mode V without depending on the official documentation (and subsequent licensing costs).

5.2.1 Memory available

Figure 5.3: Memory architecture of the VDP.

The graphics content is distributed across three regions of memory [8]:

64 KB VRAM (Video RAM): Contains most of the graphics data.

80 B VSRAM (Vertical Scroll RAM): The VDP supports vertical and horizontal scrolling and V-scroll values are stored in this separate space, for some reason.

128 B CRAM (Colour RAM): Stores four palette entries with 16 colours each (including transparent), the system provides 512 colours to choose from. Additionally, Highlight and Shadow effects can be applied to each palette to achieve a wider range of colours per palette.

5.3 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 starting, I recommend checking out the modus operandi of its predecessor since there will be a lot revisited in here.

5.3.1 Tiles

Figure 5.4: Multiple tiles squashed together. For demonstration purposes, a default palette is being used.

Figure 5.5: A single 8x8 pixel tile.

Figures: 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 stores tiles in their ROM (found in their cartridge) but they have to be copied to VRAM so the VDP can read them [12]. 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 build a total of four planes which, once merged together, form the frame seen on the screen. Also, planes’ tiles will overlap with each other, so the VDP will decide which tile is going to be visible based on the type of plane and the tile’s priority value.

5.3.2 Background

Figure 5.6: Allocated background map.

Figure 5.7: Allocated Background map with selected area marked.

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

This plane can have six different dimensions: 256x256, 256x512, 256x1024, 512x256, 512x512, 1024x256. Programmers may select the dimension that adheres better to the type of scrolling that will be required.

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

On the showed example you’ll 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 one don’t corrupt the plane, the VDP fetches each (selected) horizontal line and builds a regular frame from it.

5.3.3 Foreground

Figure 5.8: Allocated Foreground plane.

Figure 5.9: Allocated Foreground plane with selected area marked.

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

The Foreground plane, also known as Plane A [13], has the same properties as the Background Plane except this plane has a higher priority, so tiles rendered here will inherently be on top of the Background Plane.

Additionally, this plane allows to 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.

5.3.4 Sprites

Figure 5.10: Allocated Sprite layer.

Figure 5.11: Allocated Sprite layer with selected area marked.

In this plane, tiles are treated as sprites. They are positioned in a 512x512 pixel map and only a part of it (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, then multiple sprites can be combined into one.

There can only be a maximum of 20 sprites per scan-line and 80 per screen (overflowing this will corrupt the whole layer).

The region in VRAM where Sprites are defined is called Sprite Attribute Table [13] 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.

5.3.5 Result

Figure 5.12: Resulting frame.

Figure 5.13: Frame broadcast to the TV (NTSC format), the VDP automatically covers the frame with overscan area that most CRT TVs will hide.

Figures: Tada!

While the frame is being drawn, the system will sequentially call different interrupt routines depending on where the CRT’s beam is pointing to. As you have probably seen in previous consoles, this allows the CPU to work on the next frame (or alter the current one).

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

H-Blank is called numerous times but is limited to executing short routines. Also, only CRAM and VSRAM are accessible, so games can only update their colour palettes or vertically scroll their planes.

V-Blank allows for longer routines with the drawback of being called only 50 or 60 times per second (depending on the console’s region), but it’s able to access all memory locations.

Notice that the overscan area in the example exhibits some random coloured dots at the bottom right corner. This is popularly known as CRAM dots and what’s happening is that the CPU is updating the palettes in CRAM at the same time the VDP is beaming the remaining scan-lines (in the example, this happens during overscan). This conflict makes the VDP fetch whatever value the CPU is writing at that time (as opposed to the required location in CRAM) so the image gets corrupted. However, since in this case the game only updates CRAM at overscan, this anomaly goes unnoticed on traditional CRTs. Other games attempt to update the palettes mid-frame to achieve more colours, with the cost of having to balance the appearance of CRAM dots.

5.4 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 [13]. Additionally, during CPU RAM transfers using DMA, the CPU bus will be blocked, so good planning is critical to achieving performance.

Exceptional use of these features may provide high-resolution graphics, fluid parallax scrolling and high frame rates. Moreover, your game may also be featured on TV ads with lots of Blast Processing! signs all over it.

5.5 Video Output

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

6 Audio

The audio capabilities of this console are a bit unorthodox, to say the least. On one side, the Mega Drive provides existing audio technology from the previous generation, on the other side, it adds a new (but complicated) synthesis technique on top of the existing one. So, in some ways, you get both generations.

That being said, the Mega Drive houses two sound chips: A Yamaha YM2612 and a Texas Instruments SN76489.

6.1 Functionality

Let’s now see what each chip offers, as each one is very different.

6.1.1 Yamaha YM2612

Figure 6.1: FM channels. Interactive viewer available in the website edition.

Figure 6.2: PCM channel. Interactive viewer available in the website edition.

Figures: Sonic The Hedgehog (1991).

The Yamaha YM2612 is an FM synthesiser [14] that runs at the 68000 speed and supplies six FM channels, where one can play PCM samples (with 8-bit resolution and 32 kHz sampling rate).

Frequency modulation or ‘FM’ synthesis is one of many professional techniques used for synthesising sound, it significantly rose in popularity during the 80s and made way to completely new sounds (many of which you can find by listening to the pop hits from that era).

In an incredibly simplified nutshell, the FM algorithm takes a single waveform (carrier) and alters its frequency using another waveform (modulator). The result is a new waveform with a different sound. The carrier-modulator combination is called operator and multiple operators can be chained together to form the final waveform. Different combinations achieve different results. This chip allows 4 operators per channel.

Compared to traditional PSG synthesisers, this was a drastic improvement: You were no longer stuck with pre-defined waveforms.

6.1.2 Texas Instruments SN76489

Figure 6.3: PSG Channels. Sonic The Hedgehog (1991). Interactive viewer available in the website edition.

The Texas Instruments SN76489 is a PSG chip that can produce three pulse waves and one noise.

This is actually the original Master System’s sound chip and it’s embedded in the VDP. It runs at the speed of the Z80.

Notice the ‘Pulse 3’ channel remains unused. This is because the game uses a mode for the noise channel that reserves the third pulse channel for modulation [15], a function featured on the Master System as well.

6.1.3 Mixed

Figure 6.4: All audio channels. Sonic The Hedgehog (1991). Interactive viewer available in the website edition.

Both chips can output sound at the same time, then an extra component called ‘audio mixer’ is tasked with receiving both signals and mixing them.

Finally, the resulting analogue signal is sent through the audio output.

6.2 The conductor

In theory, the Z80’s memory map suggests the Z80 is the only CPU capable of commanding those two chips (which may a relief for the 68000 since the latter is already fed up with other tasks). In practice, however, the Z80 can be shut down so the 68000 has access to the YM2612 (but not the SN76489) [16]. So, for simplicity purposes, in this article, we are going to assume audio tasks are designated to the Z80.

Moving on, the Z80 is an independent processor by itself, so it needs its own program (stored in the 8 KB of RAM available) to be able to interpret the music data received from the 68000 and effectively manipulate the two sound chips accordingly. This program is called sequencer or driver.

6.3 Cracking sampling

Some music composers may decide to focus on the PCM channel to play more truthful sounds, and for that, games will need to continuously sequence and stream their music using the rest of RAM available. The main constraint is that to fill that memory, the main bus has to be blocked first (so no commands or samples can be sent to the audio chips during that timeframe). Otherwise, sound anomalies may appear (muting, frozen notes, low sample rates, etc).

For that reason, I’ve decided to dedicate this section for a few instances of games which successfully managed to overcome the aforementioned constraint. Instead of just sticking with ordinary drum kits, some games found incredible ways to stream richer samples to that single PCM channel, check out these examples:

Figure 6.5: PCM channel. Interactive viewer available in the website edition.

Figure 6.6: All audio channels. Interactive viewer available in the website edition.

Figures: Sonic The Hedgehog 3 (1994). This is one of the tracks said to be co-authored by Michael Jackson. In any case, the overall soundtrack had a distinctive beat compared to its predecessors.

Figure 6.7: PCM channel (the only channel used). Toy Story (1995). This is sequenced in real time with the help of the 68000 [17] . A very intensive task, meaning it could only be played at very particular points of the game (i.e. the main menu). Interactive viewer available in the website edition.

I know they are nowhere near CD-quality (16-bit at 44.1 kHz), but bear in mind those sounds were once deemed impossible to reproduce in this console and I’m not even emphasising how much progress this represents compared to the previous generation, so they certainly deserve some merit at least!

6.4 Assisted FM Composition

If programming an FM synthesiser was already considered complicated using the Yamaha DX7’s dashboard, imagine the headaches of composing music with only 68k assembly…

Luckily, Sega later distributed a piece of software for MS-DOS PCs called GEMS to facilitate the composition (and debugging) of Mega Drive music [18]. It was a very complete tool, among many things it included lots of patches (pre-configured operators to choose from), which would also explain why some games have very similar sounds.

Moreover, the audio subsystem enabled games to instantiate more channels than allowed and assign each one a priority value, then when the console would play the music, it dynamically dispatched the music channels to the available slots based on priorities. Additionally, channels with a high priority but without music could be automatically skipped.

Channels also contained some logic by implementing conditionals inside their data, enabling music to ‘evolve’ depending on how the player progresses in the game.

6.5 (Bonus) Mega CD Sound

Here’s an interesting fact: The Mega CD add-on provided 2 extra channels for CD Audio (among other things). One of its most famous games, Sonic CD, had very impressive music quality but like all games it had to loop, the problem was that looping music on a 1x CD reader exposed noticeable gaps, so the game included loop fillers that were executed from another PCM chip while the CD header was returning to the start.

These fillers are only found on early betas of the game and they didn’t make it for the release, the 2011 remake finally included them. This is one of the levels of the game:

Figure 6.8: MegaCD version (1993). Interactive viewer available in the website edition.

Figure 6.9: Remastered version (2011). Interactive viewer available in the website edition.

Do you notice the gap in the Mega CD’s version?

7 Games

Games are mainly written in 68000 assembly while the sound driver is implemented with Z80 assembly. Both reside in the cartridge ROM and can size up to 4 MB without the need for a mapper.

7.1 Extra functions

In terms of expandability, this design wasn’t as modular as the NES or the SNES. Hence, later add-ons like the 32x (which included a new chipset that takes over the 68k) had to bypass the VDP (hence the need for the ‘Connector Cable’).

Only one custom chip was produced for cartridges, the Sega Virtua Processor [19] (a rebranding of the Samsung SSP1601, a 16-bit Digital Signal Processor), which produced polygons subsequently encoded in the form of tiles (so the VDP can read them). In any case, only one game shipped with it, as the SVP turned out very expensive to produce.

7.2 Early network attempts

Before online services became widely adopted (and standardised), Sega tried its luck with Sega Meganet, a dial-up service for games to use. Meganet required users to purchase a separate accessory called Sega Mega Modem, then plug it in at the back of the console (where the DE-9 connector was found) and finally, connect it to the phone line. Games would then treat the modem unit as another controller, with the addition of communicating with it serially [20] (as opposed to the parallel encoding used for the controllers).

Be as it may, this feature only lasted a couple of years before Sega removed the DE-9 connector on future revisions and shut down the service altogether.

8 Anti-piracy / Region Lock

To block imported games, Sega slightly changed the shape of the cartridge slot between regions though it kept the same pinouts. Games could also perform ‘region locking’ by checking the value of the Version register (which outputs the region value).

There were two easy ways to bypass this. First, by buying one of those third-party cartridge converters. Or second, by disassembling the console and bridging the pins on the motherboard that alter the value of the Version register.

When it comes to software anti-piracy measures, the easiest check was on the SRAM size: Bootleg cartridges had more space than needed to fit any game, so games checked for the expected size on the startup. Programmers could also implement extra checksum checks at random points of the game in case hackers were to remove the initial SRAM checks. The only way to defeat this was to tediously find all the checks and remove them one by one…

9 That’s all folks

10 Support

If you enjoyed what you read and would like to help out, please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.

You can go to the donation page to find out more.

Along with the donation you can leave a note stating which article in particular you want me to invest in. As a token of gratitude, your name will be included in the credits section of the next article or your nominated one, unless you state otherwise.

10.1 Other ways of contributing

Alternatively, you can help out by suggesting changes on the Github repository and/or adding translations on the Crowdin page.

10.2 Acknowledgments

I want to give a big thanks to the following people for their past donation (which contributed to this article):

Adam Obenauf

Adrian Burgess

Alberto Cordeddu

Alberto Massidda

Alexander Perepechko

Alí El wahsh

Andreas Kotes

Andrew Woods

Antonio Bellotta

Antonio Vivace

BBQ Inc

Ben Morris

Bitmap Bureau

Brenden Kromhout

Carlos Díaz Navarro

Chiang Yi-Ta

Christopher Henderson

Christopher Starke

Cirilla Rose

Colin Szechy

Daniel Cassidy

David Bradbury

David Portillo

David Sawatzke

Dominic Wehrmann

Dudeastic

Duncan Bayne

Dávid Major

Eli Lipsitz

Elizabeth Parks

Eric Haskins

eurasianwolf

Gerald Mueller-Bruhnke

Grady Haynes

Guillermo Angeris

Ifeanyi Oraelosi

Izsak Barnette

Jack Wakefield

Jacob Almoyan

Jaerder Sousa

James Kilner

James Knowler

James Montgomerie

James Osborne

James William Jones

Jan Straßenburg

Jason Strothmann

Jerre van der Hulst

Joe Pugh

Johannes Baiter

John Mcgonagle

Josh Enders

Julius Hofmann

ltlollo

Luke Wren

Manish Sinha

Matthew Butch

MCE

Michael Chi

Michal Borsuk

Nathan Castle

Neil Moore

Nick T.

Oleg Andreev

Olivier Cahagne

Owen Christensen

Parker Thomas

Paul Adamson

Payam Ghoreishi

petey893

Phil Stevenson

Piergiorgio Arrigoni

Racri

rocky

Roger Bolsius

Samuel Shieh

Sanqui

Shoaib Meenai

Simon Pichette

Stephen Molyneaux

Stuart Hicks

Sébastien Lethuaire

Thomas Finch

Thomas Lanner

Thomas Peter Berntsen

Tim Cox

Ulrich Bogensperger

11 Licensing

Just like the contents on the website, all of my writings and multimedia assets authored by me are available under a permissive Creative Commons license. This edition in particular, however, is available under the Creative Commons Attribution-NonCommercial 4.0 International (I had to make it ‘non-commercial’ in order to protect this document from being sold without my authorisation).

The chosen license also means you can use my content for your own work, what I ask is that you reference my work properly. Please pay attention when you quote or paraphrase my work, as you need to explicitly state when you do either. Unfortunately, throughout my time writing the articles, I’ve come upon derivative works that didn’t respect these simple steps (i.e. they don’t specify when they quote me or they don’t provide the complete URL of the article). To be fair, sometimes this is involuntarily but others are the result of lack of care, so I find myself dedicating more text explaining this. On the other side, there are derivative works which have surprised me (in the positive way) with their way of referencing my articles, providing beyond of what the CC license asks for.

Anyway, if you have any doubts, you can check this referencing guide made by the University of Leeds.

12 Changelog

It’s always nice to keep a record of changes.

2022-12-17

Added visual examples about interlaced mode and removed wrong examples. See https://github.com/flipacholas/Architecture-of-consoles/issues/163 (thanks @Mittens0407)

2022-01-12

Corrected statement about the pulse 3 (see https://github.com/flipacholas/Architecture-of-consoles/issues/86), thanks @Ralakimus

2021-11-27

Updated game screenshots and graphic materials.

Added diagrams.

General grammar and spelling fixes, with some re-phrasing in-between.

Added information about accessing the YM2612 through the 68000 and the command structure of Mode V (see https://github.com/flipacholas/Architecture-of-consoles/issues/54), thanks @djmips.

Added info about CRAM dots and MegaNet.

Improve referencing style.

2020-10-25

Added more content focusing on the 68k-z80 communication

2020-09-07

Expanded CPU section

Corrected main RAM values

2020-01-18

Expanded Audio section and included more audible content

2019-09-17

Added a quick introduction

2019-05-23

Improved definition of FM (such a difficult topic)

2019-05-18

Ready for publication

13 Sources

The contents of this document could not have been possible without the research and expertise provided by the works listed here. Some are carried out for commercial purposes while others are entirely volunteer-driven.

[1]

E. Amos, “The vanamo online game museum.” [Online]. Available: https://commons.wikimedia.org/wiki/User:Evan-Amos

[2]

Okqubit, “Motherboard.” [Online]. Available: https://www.okqubit.net/machines/gamecons.html

[3]

Motorola, “M68000 8-/16-/32-bit microprocessors user’s manual.” [Online]. Available: https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf

[4]

MegaDrive Development Wiki, “Main 68k memory map.” [Online]. Available: https://wiki.megadrive.org/index.php?title=Main_68k_memory_map&oldid=251

[5]

Zilog, “Z80 CPU user manual.” [Online]. Available: http://www.zilog.com/docs/z80/um0080.pdf

[6]

MegaDrive Development Wiki, “Z80 area.” [Online]. Available: https://wiki.megadrive.org/index.php?title=Z80_Area&oldid=469

[7]

Plutiedev, “Using the Z80.” [Online]. Available: https://plutiedev.com/using-the-z80

[8]

A. Keil, “Sega genesis/mega drive VDP graphics guide - v1.2a.” 2017 [Online]. Available: https://megacatstudios.com/blogs/press/sega-genesis-mega-drive-vdp-graphics-guide-v1-2a-03-14-17

[9]

Plutiedev, “Changing screen resolution.” [Online]. Available: https://plutiedev.com/screen-resolution

[10]

Nemesis, “Double-screen?” SpritesMind.Net [Online]. Available: http://gendev.spritesmind.net/forum/viewtopic.php?t=1034#post_content14396

[11]

djmips, “Mega drive: Corrections around audio and VDP clarification plus IP thoughts.” Github [Online]. Available: https://github.com/flipacholas/Architecture-of-consoles/issues/54

[12]

MegaDrive Development Wiki, “VDP ports.” [Online]. Available: https://wiki.megadrive.org/index.php?title=VDP_Ports&oldid=275

[13]

C. MacDonald, “Sega genesis VDP documentation - version 1.5f.” 2000 [Online]. Available: http://jiggawatt.org/genvdp.txt

[14]

Wikipedia contributors, “Yamaha YM2612.” Wikipedia, The Free Encyclopedia [Online]. Available: https://en.wikipedia.org/wiki/Yamaha_YM2612

[15]

cvghivebrain, “Sonic the hedgehog (mega drive) disassembly.” Github [Online]. Available: https://github.com/cvghivebrain/s1disasm/blob/main/sound/music/GHZ.s#L467

[16]

ChibiAkumas, “Lesson P21- FM sound on the genesis via the 68000.” [Online]. Available: https://www.chibiakumas.com/68000/platform3.php#LessonP21

[17]

GameHut, “Toy story’s hardware defying music - how we did it.” Youtube [Online]. Available: https://www.youtube.com/watch?v=x3m3JrVImmU

[18]

GST Channel, “How to make sega genesis music (in 1994).” Youtube [Online]. Available: https://www.youtube.com/watch?v=WEvnZRCW_qc

[19]

HandWiki, “Engineering:sega virtua processor.” [Online]. Available: https://handwiki.org/wiki/index.php?title=Engineering:Sega_Virtua_Processor&oldid=1996641

[20]

Plutiedev, “I/o ports.” [Online]. Available: https://plutiedev.com/io-ports

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture