2018-12-23 14:45:38 -07:00
|
|
|
//! Module for all things relating to the Video RAM.
|
|
|
|
|
//!
|
|
|
|
|
//! Note that the GBA has six different display modes available, and the
|
|
|
|
|
//! _meaning_ of Video RAM depends on which display mode is active. In all
|
|
|
|
|
//! cases, Video RAM is **96kb** from `0x0600_0000` to `0x0601_7FFF`.
|
|
|
|
|
//!
|
|
|
|
|
//! # Safety
|
|
|
|
|
//!
|
|
|
|
|
//! Note that all possible bit patterns are technically allowed within Video
|
|
|
|
|
//! Memory. If you write the "wrong" thing into video memory you don't crash the
|
|
|
|
|
//! GBA, instead you just get graphical glitches (or perhaps nothing at all).
|
|
|
|
|
//! Accordingly, the "safe" functions here will check that you're in bounds, but
|
|
|
|
|
//! they won't bother to check that you've set the video mode they're designed
|
|
|
|
|
//! for.
|
|
|
|
|
|
|
|
|
|
pub use super::*;
|
|
|
|
|
|
2018-12-25 14:44:05 -07:00
|
|
|
pub mod bitmap;
|
|
|
|
|
pub mod tiled;
|
|
|
|
|
|
2018-12-23 14:45:38 -07:00
|
|
|
/// The start of VRAM.
|
|
|
|
|
///
|
|
|
|
|
/// Depending on what display mode is currently set there's different ways that
|
|
|
|
|
/// your program should interpret the VRAM space. Accordingly, we give the raw
|
|
|
|
|
/// value as just being a `usize`. Specific video mode types then wrap this as
|
|
|
|
|
/// being the correct thing.
|
|
|
|
|
pub const VRAM_BASE_USIZE: usize = 0x600_0000;
|
