PPU registers: Difference between revisions
m (nitpick: 1F will turn on grayscale, which probably isn't what you intended) |
|||
Line 44: | Line 44: | ||
This register controls screen enable, masking, and intensity. | 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 $00 here if you want to turn rendering off so that you can update the pattern tables or nametables outside of vertical blanking. | ||
Write $ | Write $1E when you're done to turn rendering back on. | ||
The other bits do special effects with the colors. | The other bits do special effects with the colors. | ||
76543210 | 76543210 |
Revision as of 16:15, 25 January 2010
The PPU exposes only 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.
Note: The next paragraph explain details that should be more in the getting started reference?
Immediately after powerup, the PPU must wait at least one full frame before it is stable enough to operate normally. The first thing that should be done on startup is to write a zero byte to registers PPUCTRL and PPUMASK (to disable rendering and NMIs) and then wait for bit 7 of PPUSTATUS to be set twice. Some programs will wait for $2002 bit 7 to be set, initialize hardware other than the PPU (such as zeroing CPU RAM), and then wait for $2002 bit 7 to be set again.
Controller ($2000) > write
Is often referred as PPUCTRL.
Various flags controlling PPU operation
76543210 |||||||| ||||||++- Base nametable address |||||| (0 = $2000; 1 = $2400; 2 = $2800; 3 = $2C00) |||||+--- VRAM address increment per CPU read/write of PPUDATA ||||| (0: increment by 1, going across; 1: increment by 32, going down) ||||+---- Sprite pattern table address for 8x8 sprites (0: $0000; 1: $1000) |||+----- Background pattern table address (0: $0000; 1: $1000) ||+------ Sprite size (0: 8x8; 1: 8x16) |+------- PPU master/slave select (has no effect on the NES) +-------- 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):
76543210 || |+- 1: Add 256 to the X scroll position +-- 1: Add 240 to the Y scroll position
Note
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.
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: AND all palette entries ||||||| with 0x30, effectively producing a monochrome display; ||||||| note that colour emphasis STILL works when this is on!) ||||||+-- Enable backgrounds in leftmost 8 pixels of screen (0: hide; 1: display) |||||+--- Enable sprites in leftmost 8 pixels of screen (0: hide; 1: display) ||||+---- Enable background rendering |||+----- Enable sprite rendering ||+------ Intensify reds (and darken other colors) |+------- Intensify greens (and darken other colors) +-------- Intensify blues (and darken other colors)
NTSC video describes how bits D7-D5 (the "emphasis" bits or the "tint" bits) work in detail. 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. The identities of the tint bits need verification.
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.
76543210 |||||||| |||+++++- Unimplemented ||+------ Sprite overflow. The PPU can handle only eight sprites on one || scanline and sets this bit if it starts dropping sprites. || Normally, this triggers when there are 9 sprites on a scanline, || but the actual behavior is significantly more complicated. |+------- Sprite 0 Hit. Set when a nonzero pixel of sprite 0 'hits' | a nonzero background pixel. Used for raster timing. +-------- Vertical blank has started (0: not in VBLANK; 1: in VBLANK)
Notes
- Reading the status register will clear D7 mentioned above and also the address latch used by PPUSCROLL and PPUADDR.
- 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).
This register also seems to affect Sprite 0 Hit, though it is not yet understood exactly how it does. The upper 5 bits of this register seem to select which SPR-RAM data is used for sprites 0 and 1 (instead of the first 8 bytes of SPR-RAM), though actual behavior varies between resets.
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.
Scroll ($2005) >> write x2
Is often referred as PPUSCROLL.
This register is used 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 VBlank, 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 writing different values here across several frames and modifying the nametables accordingly one can achieve the effect of a camera panning over a large background.
Address ($2006) >> write x2
Is often referred as PPUADDR.
This register selects what VRAM address will be accessed next. It is normally used before data is written to or read from VRAM.
After reading PPUSTATUS to reset the address latch, write the 16-bit address of VRAM you want to access here, upper byte first. Valid addresses are $0000-$3FFF.
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" by loopy, available from the main site.
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 data register.
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.
Note
Reads are delayed by one cycle; discard the first byte read. Do not attempt to access this register while the PPU is rendering; if you do, Bad Things™ will happen (i.e. graphical glitches and RAM corruption).