PPU registers

The PPU exposes eight memory-mapped registers to the CPU. These nominally sit at $2000 through $2007 in the CPU's address space, but because they're incompletely decoded, they're mirrored in every 8 bytes from $2008 through $3FFF, so a write to $3456 is the same as a write to $2006.

Immediately after powerup, the PPU isn't necessarily in a usable state. The program needs to do a few things to get it going; see PPU power up state and Init code.

Controller ($2000) > write

Is often referred as PPUCTRL.

Various flags controlling PPU operation

7654 3210
|||| ||||
|||| ||++- Base nametable address
|||| ||    (0 = $2000; 1 = $2400; 2 = $2800; 3 = $2C00)
|||| |+--- VRAM address increment per CPU read/write of PPUDATA
|||| |     (0: add 1, going across; 1: add 32, going down)
|||| +---- Sprite pattern table address for 8x8 sprites
||||       (0: $0000; 1: $1000; ignored in 8x16 mode)
|||+------ Background pattern table address (0: $0000; 1: $1000)
||+------- Sprite size (0: 8x8; 1: 8x16)
|+-------- PPU master/slave select
|          (0: read backdrop from EXT pins; 1: output color on EXT pins)
+--------- Generate an NMI at the start of the
           vertical blanking interval (0: off; 1: on)

Equivalently, bits 0 and 1 are the most significant bit of the scrolling coordinates (see Nametables and PPU scroll):

7654 3210
       ||
       |+- 1: Add 256 to the X scroll position
       +-- 1: Add 240 to the Y scroll position

Another way of seeing the explanation above is that when you reach the end of a nametable, you must switch to the next one, hence, changing the nametable address.

After power/reset, writes to this register are ignored for about 30000 cycles.

Master/slave mode and the EXT pins

When bit 6 of $2000 is clear (the usual case), the PPU gets the palette index for the background color from the EXT pins. The stock NES grounds these pins, making palette index 0 the background color as expected. A secondary picture generator connected to the EXT pins would be able to replace the background with a different image using colors from the background palette, which could be used e.g. to implement parallax scrolling.

Setting bit 6 causes the PPU to output the lower four bits of the palette memory index on the EXT pins for each pixel (in addition to normal image drawing) - since only four bits are output, background and sprite pixels can't normally be distinguished this way. As the EXT pins are grounded on an unmodified NES, setting bit 6 is discouraged as it could potentially damage the chip whenever it outputs a non-zero pixel value (due to it effectively shorting Vcc and GND together). Looking at the relevant circuitry in Visual 2C02, it appears that the background palette hack would not be functional for output from the EXT pins; they would always output index 0 for the background color.

Bit 0 bus conflict

Be very careful when writing to this register outside vertical blanking if you are using vertical mirroring (horizontal arrangement) or 4-screen VRAM. For specific CPU-PPU alignments, a write near the end of a visible scanline may cause only the next scanline to be erroneously drawn from the left nametable. This can cause a visible glitch. Worse, it can theoretically cause a sprite 0 hit to fail, which may crash a game using a sprite 0 spin loop that's not resilient.

Only writes at the exact moment between active picture and horizontal blanking cause this glitch; well-timed mid-scanline writes do not, nor do writes that land well within horizontal blanking. The glitch has no effect in horizontal or one-screen mirroring. It also does not appear if bit 0 of the written value is 0; this always correctly sets the left nametable.

This produces an occasionally visible glitch in Super Mario Bros. when the program writes to PPUCTRL at the end of game logic. It appears to be turning NMI off during game logic and then turning NMI back on once the game logic has finished in order to prevent the NMI handler from being called again before the game logic finishes. To work around this in new productions, have your game logic set a flag that your NMI handler checks.

Mask ($2001) > write

Is often referred as PPUMASK.

This register controls screen enable, masking, and intensity. Write $00 here if you want to turn rendering off so that you can update the pattern tables or nametables outside of vertical blanking. Write $1E when you're done to turn rendering back on. The other bits do special effects with the colors.

76543210
||||||||
|||||||+- Grayscale (0: normal color; 1: produce a monochrome display)
||||||+-- 1: Show background in leftmost 8 pixels of screen; 0: Hide
|||||+--- 1: Show sprites in leftmost 8 pixels of screen; 0: Hide
||||+---- 1: Show background
|||+----- 1: Show sprites
||+------ Intensify reds (and darken other colors)
|+------- Intensify greens (and darken other colors)
+-------- Intensify blues (and darken other colors)

When grayscale is turned on, the PPU ignores the lower nibble of each palette entry. This causes a bitwise AND with $30 on any value read from PPU $3F00-$3FFF, both on the display and through PPUDATA ($2007). Writes to the palette through PPUDATA are not affected.

Hiding the leftmost 8 pixels is often done to cover artifacts from using horizontal scrolling with horizontal mirroring. Sprite 0 hit does not trigger in any area where the background or sprites are hidden. If both the background and sprites are hidden, the PPU enters "forced blank" state, where it stops rendering and releases control of the address and data bus.

NTSC video describes how bits D7-D5 (the "emphasis" bits or the "tint" bits) work on NTSC and PAL PPUs. Each bit's color have been confirmed on an NES; some older documents have them wrong. Caution: The RGB PPU (used on PlayChoice, Famicom Titler, and a couple Japanese TVs) treats the tint bits differently: instead of darkening other RGB components, it forces one RGB component to maximum brightness. A few games, which set all three tint bits to darken all colors, are unplayable on these PPUs. In either case, the tint bits are applied after grayscale, which means they still tint the gray image.

Status ($2002) < read

Is often referred as PPUSTATUS.

This register reflects the state of various functions inside the PPU. It is often used for determining timing. To determine when the PPU has reached a given pixel of the screen, put an opaque pixel of sprite 0 there.

7654 3210
|||| ||||
|||+-++++- Least significant bits previously written into a PPU register
|||        (due to register not being updated for this address)
||+------- Sprite overflow. The intent was for this flag to be set
||         whenever more than eight sprites appear on a scanline, but a
||         hardware bug causes the actual behavior to be more complicated
||         and generate false positives as well as false negatives; see
||         PPU sprite evaluation. This flag is set during sprite
||         evaluation and cleared at dot 1 (the second dot) of the
||         pre-render line.
|+-------- Sprite 0 Hit.  Set when a nonzero pixel of sprite 0 overlaps
|          a nonzero background pixel; cleared at dot 1 of the pre-render
|          line.  Used for raster timing.
+--------- Vertical blank has started (0: not in VBLANK; 1: in VBLANK).
           Set at dot 1 of line 241 (the line *after* the post-render
           line); cleared after reading $2002 and at dot 1 of the
           pre-render line.

Notes

• Reading the status register will clear D7 mentioned above and also the address latch used by PPUSCROLL and PPUADDR. It does not clear the sprite 0 hit or overflow bit.
• When the sprite 0 hit flag is set on a frame, it will not be cleared until the vertical blank has ended on the next frame. If attempting to use this flag for raster timing, it is important to ensure that the sprite 0 hit check happens outside of vertical blank, otherwise the CPU will "leak" through and the check will fail. The easiest way to do this is to place an earlier check for D6 = 0, which will wait for the pre-render scanline to begin.
• If using sprite 0 hit to make a bottom scroll bar below a vertically scrolling or freely scrolling playfield, be careful to ensure that the tile in the playfield behind sprite 0 is opaque.
• Sprite 0 hit is not detected at x=255, nor is it detected at x=0 through 7 if the background or sprites are hidden in this area.
• This timing diagram might clarify the timing of setting and clearing the flags (source Inkscape SVG file).
• Some Vs. System PPUs return a constant value in D4-D0 that the game checks.
• Caution: Reading PPUSTATUS at the exact start of vertical blank will return a 0 in D7 but clear the latch anyway, causing the program to miss frames. See NMI for details.

OAM address ($2003) > write

Is often referred as OAMADDR.

Write the address of OAM you want to access here. Most games just write $00 here and then use OAM_DMA ($4014). (DMA is implemented in the 2A03/7 chip and works by repeatedly writing $2004.)

Obscure details of OAMADDR

OAMADDR is set to 0 during each of ticks 257-320 (the sprite tile loading interval) of the pre-render and visible scanlines.

The value of OAMADDR when sprite evaluation starts at tick 65 of the visible scanlines will determine where in OAM sprite evaluation starts, and hence which sprite gets treated as sprite 0. The first OAM entry to be checked during sprite evaluation is the one starting at OAM[OAMADDR]. If OAMADDR is unaligned and does not point to the y position (first byte) of an OAM entry, then whatever it points to (tile index, attribute, or x coordinate) will be reinterpreted as a y position, and the following bytes will be similarly reinterpreted. No more sprites will be found once the end of OAM is reached, effectively hiding any sprites before OAM[OAMADDR].

Other oddities have been observed to occur when manually changing OAMADDR (as opposed to allowing it to auto-increment on writes to the data port), possibly related to the fact that OAM is made of dynamic memory which can decay into an "indeterminate" state (where bits are neither set nor clear) such that they could potentially inherit the state of other bits if OAMADDR is changed during the wrong clock phase. Whatever the actual glitchy behavior is, the Sachen game "Huge Insect" seems to rely on it.

On the 2C02, writes to OAMADDR seem to reliably corrupt OAM. This can then be worked around by writing all 256 bytes of OAM. It is also the case that if OAMADDR is not less than eight when rendering starts, the eight bytes starting at OAMADDR & 0xF8 are copied to the first eight bytes of OAM; it seems likely that this is related.

OAM data ($2004) <> read/write

OAM data port, often referred as OAMDATA.

Write OAM data here. Writes will increment OAMADDR after the write; reads during vertical or forced blanking return the value from OAM at that address but do not increment.

Most games access this register through $4014 instead. Reading OAMDATA while the PPU is rendering will expose internal OAM accesses during sprite evaluation and loading; Micro Machines does this.

Writes to OAMDATA during rendering (on the pre-render line and the visible lines 0-239, provided either sprite or background rendering is enabled) do not modify values in OAM, but do perform a glitchy increment of OAMADDR, bumping only the high 6 bits (i.e., it bumps the [n] value in PPU sprite evaluation - it's plausible that it could bump the low bits instead depending on the current status of sprite evaluation). This extends to DMA transfers via $4014, since that uses writes to $2004. For emulation purposes, it is probably best to completely ignore writes during rendering.

Historically, it's been reported that reading from this register isn't reliable, however, more recent evidence seems to suggest that this is solely due to corruption by OAMADDR writes.

Scroll ($2005) >> write x2

Is often referred as PPUSCROLL.

This register is used to change the scroll position, that is, to tell the PPU which pixel of the nametable selected through PPUCTRL should be at the top left corner of the rendered screen. Typically, this register is written to during vertical blanking, so that the next frame starts rendering from the desired location, but it can also be modified during rendering in order to split the screen. Changes made to the vertical scroll during rendering will only take effect on the next frame.

After reading PPUSTATUS to reset the address latch, write the horizontal and vertical scroll offsets here just before turning on the screen:

 bit PPUSTATUS
 ; possibly other code goes here
 lda cam_position_x
 sta PPUSCROLL
 lda cam_position_y
 sta PPUSCROLL

Horizontal offsets range from 0 to 255. "Normal" vertical offsets range from 0 to 239, while values of 240 to 255 are treated as -16 through -1 in a way, but tile data is incorrectly fetched from the attribute table.

By changing the values here across several frames and writing tiles to newly revealed areas of the nametables, one can achieve the effect of a camera panning over a large background.

Address ($2006) >> write x2

Is often referred as PPUADDR.

Because the CPU and the PPU are on separate buses, neither has direct access to the other's memory. The CPU writes to VRAM through a pair of registers on the PPU. First it loads an address into PPUADDR, and then it writes repeatedly to PPUDATA to fill VRAM.

After reading PPUSTATUS to reset the address latch, write the 16-bit address of VRAM you want to access here, upper byte first. For example, to set the VRAM address to $2108:

  lda #$21
  sta PPUADDR
  lda #$08
  sta PPUADDR

Valid addresses are $0000-$3FFF; higher addresses will be mirrored down.

note

Access to PPUSCROLL and PPUADDR during screen refresh produces interesting raster effects; the starting position of each scanline can be set to any pixel position in nametable memory. For more information, see The skinny on NES scrolling and tokumaru's sample code on the BBS.

Editor's note: Last comment about external page should be re-directed to the getting started section instead.

Data ($2007) <> read/write

Is often referred as PPUDATA.

VRAM read/write data register. After access, the video memory address will increment by an amount determined by $2000:2.

When the screen is turned off by disabling the background/sprite rendering flag with the PPUMASK or during vertical blank, you can read or write data from VRAM through this port. Since accessing this register increments the VRAM address, it should not be accessed outside vertical or forced blanking because it will cause graphical glitches, and if writing, write to an unpredictable address in VRAM. However, two games are known to read from PPUDATA during rendering: see Tricky-to-emulate games.

VRAM reading and writing shares the same internal address register that rendering uses. So after loading data into video memory, the program should reload the scroll position afterward with PPUSCROLL writes in order to avoid wrong scrolling.

The PPUDATA read buffer (post-fetch)

When reading while the VRAM address is in the range 0-$3EFF (i.e., before the palettes), the read will return the contents of an internal read buffer. This internal buffer is updated only when reading PPUDATA, and so is preserved across frames. After the CPU reads and gets the contents of the internal buffer, the PPU will immediately update the internal buffer with the byte at the current VRAM address. Thus, after setting the VRAM address, one should first read this register and discard the result.

Reading palette data from $3F00-$3FFF works differently. The palette data is placed immediately on the data bus, and hence no dummy read is required. Reading the palettes still updates the internal buffer though, but the data placed in it is the mirrored nametable data that would appear "underneath" the palette. (Checking the PPU memory map should make this clearer.)