PPU 레지스터 편집하기 (부분)

=== OAMDATA - 스프라이트 RAM 데이터 ($2004 읽기/쓰기) ===
----
 7  bit  0
 ---- ----
 DDDD DDDD
 |||| ||||
 ++++-++++- OAM 데이터

여기에 OAM 데이터를 쓴다. 쓰기는 쓰기 후 [[#OAMADDR|OAMADDR]]을 증가시킨다. 읽기는 그렇지 않다. 수직 또는 강제 블랭킹 중 읽기는 해당 주소의 OAM에서 값을 반환한다.

'''대부분의 경우 이 레지스터에 직접 쓰지 마라.''' OAM에 대한 변경은 일반적으로 vblank 중에만 이루어져야 하므로, OAMDATA를 통한 쓰기는 부분 업데이트에만 효과적이다. 한 vblank 간격 내에 모든 OAM을 업데이트하기에는 너무 느리고, 위에서 설명한 것처럼 부분 쓰기는 손상을 유발하기 때문이다. 대부분의 게임은 대신 [[#OAMDMA|OAMDMA]]를 통해 DMA 기능을 사용한다.

* PPU가 렌더링하는 동안 OAMDATA를 읽으면 스프라이트 평가 및 로딩 중 내부 OAM 접근이 노출된다. ''Micro Machines''가 이를 수행한다.
* 렌더링 중(프리 렌더 라인 및 가시 라인 0-239에서, 스프라이트 또는 배경 렌더링이 활성화된 경우) OAMDATA에 대한 쓰기는 OAM의 값을 수정하지 않지만, [[#OAMADDR|OAMADDR]]의 결함 있는 증가를 수행하여 상위 6비트만 증가시킨다(즉, [[PPU sprite evaluation]]에서 ''[n]'' 값을 증가시킨다. 스프라이트 평가의 현재 상태에 따라 하위 비트를 대신 증가시킬 수도 있다). 이는 $2004에 대한 쓰기를 사용하므로 [[#OAMDMA|OAMDMA]]를 통한 DMA 전송에도 적용된다. 에뮬레이션 목적으로는 렌더링 중 쓰기를 완전히 무시하는 것이 가장 좋다.
* 이전에는 이 레지스터에서 읽는 것이 신뢰할 수 없다고 생각되었다<ref>[//forums.nesdev.org/viewtopic.php?t=6424 $2004 읽기 신뢰성?] blargg의 스레드</ref>. 그러나 최근 증거에 따르면 이는 전적으로 [[#OAMADDR|OAMADDR]] 쓰기에 의한 손상 때문인 것으로 보인다.
* 초기 Famicom 및 NES에서 발견된 가장 오래된 PPU 구현에서는 이 레지스터를 읽을 수 없다<ref>[//forums.nesdev.org/viewtopic.php?p=62137#p62137 초기 리비전에서는 $2004를 읽을 수 없음] jsr의 답글</ref>. 읽기 기능은 대부분의 NES 및 이후 Famicom에서 발견된 RP2C02G에 추가되었다.<ref>[//forums.nesdev.org/viewtopic.php?p=150926#p150926 하드웨어 리비전 및 $2004 읽기] Great Hierophant의 답글</ref>
* 2C07에서는 스프라이트 평가를 ''절대'' 완전히 비활성화할 수 없으며, vblank 시작 후 24 스캔라인 후에 항상 시작된다<ref>[//forums.nesdev.org/viewtopic.php?t=11041 2C07 PPU 스프라이트 평가 노트] thefox의 스레드</ref>(2C02에서 프리렌더 스캔라인이 있었을 때와 동일). 따라서 OAM에 대한 모든 업데이트는 2C07이 수직 블랭킹을 신호한 후 처음 24 스캔라인 내에 수행되어야 한다.

{{Anchor|PPUSCROLL}}{{Anchor|Reg2005}}{{Anchor|Scroll_($2005)_>>_write_x2}}