Content deleted Content added
nesdev.parodius.com -> nesdev.com |
No edit summary |
||
Line 17:
The PPU is controlled via eight [[Processor register|registers]] visible in the [[CPU]]'s address space in the addresses $2000 through $2007. All data and information is passed to the PPU through these, except the raw tile data (there are exceptions, as some games had RAM instead of ROM to store the tile data, and the tiles had to be written each time), which is hardwired to the PPU's address space. The PPU uses the tile graphics data together with information stored by the program in the PPU's RAM, such as color and position, to render the final graphical output to the screen.
The lowest graphical components the PPU operates with are [[tile]]s, which are blocks of 8×8 or 8×16 pixels. The tiles are stored in a [[Read-only memory|ROM]] chip on the game cartridge.
Due to the small size of NES sprites, most moving objects are made of multiple ones. If 8x16 sprites are used, the number of addressable ones are reduced from 64 to 32. Only 8 sprites can be on each scanline, and so the PPU contains an "overflow" flag to indicate if this is happening.
Essentially, the PPU supports two different kinds of objects: movable (sprites) and non-movable (background). Both kind of objects are basically a tile, and moreover a sprite and background object can use the same tile. The difference is that a tile used as a sprite can move around, whereas a tile used as a background cannot. ▼
As noted above, some games (mostly early MMC1 titles such as Legend of Zelda and Castlevania) store their graphics data in the main PRG ROM. These have a CHR RAM chip instead of a ROM and pass the data from the PRG ROM to the CHR RAM, the main purpose of this being to produce animated background tiles. The arrival of the MMC3 mapper in 1988 eliminated the need for this as animated tiles could now be banked from the CHR ROM on the fly. As the PPU has a 14-bit address bus, it can access up to 16k of CHR ROM or RAM at once.
▲Essentially, the PPU supports two different kinds of objects: movable (sprites) and non-movable (background). Both kind of objects are basically a tile, and moreover a sprite and background object can use the same tile. The difference is that a tile used as a sprite can move around, whereas a tile used as a background cannot. There are no collision detection registers for sprites as was common on most game systems of the era.
Sprite data is stored in a special memory called the "Sprite-RAM" or "SPR-RAM" for short, which is a 256-byte memory built into the PPU core. The data stored here is 4 bytes; the position, color and tile, for each of the 64 sprites. This data is used by the PPU to place the sprite when it [[Rendering (computer graphics)|renders]] the frame. Background objects, however, are stored in a much less exclusive way, which is more like the way characters are stored in [[text mode]] on [[Personal computer|PCs]]. A background is defined by a simple data structure called a nametable, which is essentially a two dimensional array. The integer value in each array slot corresponds to a tile number, and the index values of this slot correspond to the tile's intended x/y position on screen. The PPU has, without the use of memory mappers, two nametables, so smooth scrolling between backgrounds is possible.
Once tile data is set up in the pattern table, it is a simple matter of adjusting the PPU's X/Y scrolling registers to move the screen around.
A color palette must be defined in order to show graphics on the screen. It is stored in a separate 32 byte ___location in RAM, known as "palette-RAM". Each entry here picks a color from the hardware color palette, which are the predefined colors to choose between. 16 colors can be chosen for sprites, and 16 colors for backgrounds. However, bytes 4, 8 and 12 of the sprite palette, and bytes 0, 4, 8, and 12 of the background palette, are not in use by the PPU. Therefore, the number of actually usable colors is reduced to 25 instead of 32. The first byte of the sprite palette also defines the global background color for both sprites and the background.
|