Enum Access 

pub enum Access<'a> {
    #[non_exhaustive]
    Direct(PhantomData<&'a ()>),
    Polled,
}

How a write reaches video memory.

VRAM at 0x8000 and OAM at 0xFE00 are locked on different schedules: VRAM is reachable except in mode 3, OAM except in modes 2 and 3, and turning the LCD off opens both. See https://gbdev.io/pandocs/Accessing_VRAM_and_OAM.html.

Where the hardware has them locked it ignores writes and reads back 0xFF, so a value written there is lost rather than wrong, and nothing reports it.

Variants

#[non_exhaustive]

Direct(PhantomData<&'a ()>)

The caller is already inside a window where both are open, so writes go straight through.

Minted by Vblank::with and with_lcd_off, and bounded to the closure they run. It is zero-sized and Copy; the lifetime is the only thing stopping it being carried out of the window:

let mut saved: Option<Access> = None;
vblank.with(|d| { saved = Some(d); }); // ERROR: `d` escapes the closure

Polled

Wait for the PPU to release video memory before writing, which makes the call safe at any point in the frame.

This reaches far more of the frame than one VBlank does, since HBlank recurs on every line. What it costs is the wait, which a bulk write pays for every byte: one this way can hold the CPU for more than a frame while the picture stays up.

Implementations

impl<'a> Access<'a>

pub const unsafe fn assume() -> Self

Mint Direct, asserting that video memory is reachable.

The escape hatch for a context Vblank::with cannot serve, such as a VBlank handler, which is already inside the window it would wait for.

Safety

The PPU must be in mode 0 or 1, or the LCD off. The returned lifetime is unconstrained, so the caller must bound it to the period that holds.

Trait Implementations

impl<'a> !Send for Access<'a>

impl<'a> !Sync for Access<'a>

impl<'a> Clone for Access<'a>

fn clone(&self) -> Access<'a>

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'a> Copy for Access<'a>