Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add cross-page links to the "Accessing VRAM" warning box #572

Merged
merged 1 commit into from
Oct 4, 2024
Merged

Add cross-page links to the "Accessing VRAM" warning box #572

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 11 additions & 16 deletions src/Accessing_VRAM_and_OAM.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,20 +3,16 @@

:::warning Warning

When the PPU is drawing the screen it is directly reading
from Video Memory (VRAM) and from the Object Attribute Memory (OAM).
During these periods the Game Boy CPU may not access VRAM and OAM.
That means that any attempts to write to VRAM or OAM are ignored (data
remains unchanged). And any attempts to read from VRAM or OAM will return
undefined data (typically $FF).

For this reason the program should verify if VRAM/OAM is accessible
before actually reading or writing to it. This is usually done by
reading the Mode bits from the STAT Register (FF41). When doing this (as
described in the examples below) you should take care that no interrupts
occur between the wait loops and the following memory access - the
memory is guaranteed to be accessible only for a few cycles just
after the wait loops have completed.
When the PPU is [drawing the screen](<#Rendering overview>), it is often directly reading from Video Memory (VRAM) and from the Object Attribute Memory (OAM).
During these periods, the Game Boy CPU cannot access VRAM and OAM.

That means that any attempts to write to VRAM or OAM are ignored (data remains unchanged).
And any attempts to read from VRAM or OAM will return undefined data (typically $FF).

For this reason the program should verify if VRAM/OAM is accessible before actually reading or writing to it.
This is usually done by reading the Mode bits from [the STAT Register](<#FF41 — STAT: LCD status>).
When doing this (as described in the examples below) you should take care that **no interrupts occur between the wait loops and the following memory access**;
the memory is guaranteed to be accessible only for a few cycles (less than Mode 2's length) just after a wait loop exits.

:::

Expand Down Expand Up @@ -66,8 +62,7 @@ During those modes, OAM can be accessed directly or by doing a DMA
transfer (FF46). Outside those modes, DMA out-prioritizes the PPU in
accessing OAM, and the PPU will read $FF from OAM during that time.

A typical
procedure that waits for accessibility of OAM would be:
A typical procedure that waits for accessibility of OAM would be:

```rgbasm
ld hl, $FF41 ; STAT Register
Expand Down