Tiles and Things

The Mega Drive's VDP has a built in CRAM ($80 bytes), built in VSRAM ($80 bytes), and an external VRAM ($10000 bytes) to be used together in conjunction with each other for display.

The VDP's CRAM is Colour RAM, it is used to store colour data in 9bpc (9 bits per colour), and these 9 bits are stretched and stored in a word of data in the format of (in binary): 0000 BBB0 GGG0 RRR0 (effectively in hex: 0BGR). Where B is blue, G is green, and R is red. The amount set for each colour combines together to create a single colour, for example, the colour yellow can be made with no blue, lots of green, and lots of red: 00EE. The red and green will mix to create the yellow.

CRAM can hold $10 of these (0 to F) in a single palette line:



There are four of these palette lines available to store colour. The first colour (slot 0) is always the transparent colour of the line).

The VDP displays all graphics (standardly speaking here) in what are known as "tiles" (the official name is actually "cells", but for consistency with other documentation, we'll stick with "tiles"), these tiles are 8 pixels horizontally and 8 pixels vertically (8x8 tiles), and are stored and read in VRAM (these are $20 bytes per tile). The VDP will read these tiles from VRAM aligned to each $20 section (meaning the tiles should be written starting at an aligned offset of $20, e.g. $0000, $0020, $0040, $0060, etc). Tile 000 is read from VRAM $0000 - $001F, Tile 001 is read from VRAM $0020 - $003F, and so on, you can fit $7FF tiles into VRAM, though VRAM is also used for mappings, horizontal scroll data, and sprite data, so some of VRAM will need to be reserved.

The tiles being $20 bytes, each "nybble" (half a byte) represents a pixel, meaning each byte is a pair of pixels. Each pixel can be 0 to F, this selects a colour slot from 0 to F in CRAM, so $20 bytes following:

00 00 0B BA 02 34 4A B9 01 23 4A B9 01 23 4A B9 01 23 4A B9 01 23 49 A1 01 23 42 00 01 12 31 00

...will output the tile (using the example palette above):



The VDP has two map planes, a plane A (often used for foregrounds) and plane B (often used for backgrounds), these map planes read map data from allocated spaces in VRAM and can map at a certain width/height depending on how the registers are set, since you're using Sonic 1, we'll use Sonic Team's settings. Plane A is allocated to VRAM $C000 - $CFFF, and plane B is allocated to VRAM $E000 - $EFFF. The map planes consist of words of data, each word represents a tile to display, the format is (in binary): PCCY XAAA AAAA AAAA.

• A - together forms the tile number (this can be from $000 to $7FF, selecting the tile from VRAM $0000 to $FFFF in groups of $20 bytes).
• X - is the horizontal mirror flag (0 normal | 1 mirrored).
• Y is the vertical flip flag (0 normal | 1 flipped).
• CC is the palette line to use:
  
  • 00 = Palette line 1
  • 01 = Palette line 2
  • 10 = Palette line 3
  • 11 = Palette line 4
• P - is priority (0 low priority (behind) | 1 high priority (in front))

This is a standard pattern index format. Each word for the plane will display the tile, using the palette line, flipping and priority that is set, (in Sonic 1) horizontally for $40 tiles at the top ($80 bytes per line, a word per tile), the next $80 bytes will be the next horizontal line of $40 tiles for the second line. The next $80 after that will be the next horizontal line, and so on, for $20 lines (top to bottom). If the plane should be scrolled out of the screen range, it'll be wrapped and repeated over and over, a bit like a repeating texture for a 3D polygon item. Speaking of scrolling, the planes can be scroll vertically altogether or in slices of $10 pixel slots using VSRAM, and horizontally altogether, or in 8 pixel slices, or single pixel slices.

Sonic 1 by default has vertical altogether, and horizontal in single pixel slices. So for vertical scrolling in VSRAM (Vertical Scroll RAM), only the first long-word will be of your concern; AAAA BBBB, where "A" is plane A vertical scroll position, and "B" is plane B vertical scroll position. The higher the the number is, the more it'll reposition the plane upwards, and the lower the number is, the more it'll reposition the plane downwards (remember, the plane will repeat and wrap if it goes off screen). For horizontal scrolling, the scroll table is stored in VRAM, for Sonic 1, they store this at VRAM offset $FC00 - $FF7F. Leaving you with $380 bytes ($E0 long-words, a long-word per line), and each long-word is the same as vertical scrolling; AAAA BBBB, where "A" is plane A horizontal scroll position, and "B" is plane B horizontal scroll position. Though the larger the number, the more to the right the plane is repositioned, and the lower the number, the more to the left the plane is repositioned. Each long-word represents a scanline starting from the top of the screen, the second long-word = second scanline, third long-word = third scanline, etc.

The sprites are also stored in VRAM, Sonic 1 has the screen resolution set such that the most number of sprites you can have will be $50 sprites. Each sprite displays tiles in a rectangle/square shape, and can display up to $10 tiles from VRAM in order. Please see this post for further details.

 

that is some really useful information MarkeyJester, I am amazed at your knowledge of the inner workings of a megadrive