1 byte = 2 pixels 560x448@4bpp = 125 440 bytes 560x448@8bpp = 250 880 bytes -> 262144 bytes (256 kB) [USER AREA | HW AREA] Number of pheripherals = 8, of which the computer itself is considered as a peripheral. HW AREA = [Peripherals | MMIO | INTVEC] User area: 8 MB, hardware area: 8 MB 8192 kB User Space 1024 kB Peripheral #8 1024 kB Peripheral #7 ... 1024 kB (where Peripheral #0 would be) MMIO and Interrupt Vectors 128 kB MMIO for Peri #8 128 kB MMIO for Peri #7 ... 128 kB (where Peripheral #0 would be) MMIO for the computer 130816 bytes MMIO for Ports, etc. 256 bytes Vectors for 64 interrupts -------------------------------------------------------------------------------- IO Device Endianness: little Note: Always takes up the peripheral slot of zero Latching: latching is used to "lock" the fluctuating values when you attempt to read them so you would get reliable values when you try to read them, especially the multibyte values where another byte would change after you read one byte, e.g. System uptime in nanoseconds MMIO 0..31 RO: Raw Keyboard Buffer read. Won't shift the key buffer 32..33 RO: Mouse X pos 34..35 RO: Mouse Y pos 36 RO: Mouse down? (1 for TRUE, 0 for FALSE) 37 RW: Read/Write single key input. Key buffer will be shifted. Manual writing is usually unnecessary as such action must be automatically managed via LibGDX input processing. Stores ASCII code representing the character, plus: (1..26: Ctrl+[alph]) 3 : Ctrl+C 4 : Ctrl+D 8 : Backspace (13: Return) 19: Up arrow 20: Down arrow 21: Left arrow 22: Right arrow 38 RW: Request keyboard input be read (TTY Function). Write nonzero value to enable, write zero to close it. Keyboard buffer will be cleared whenever request is received, so MAKE SURE YOU REQUEST THE KEY INPUT ONLY ONCE! 39 WO: Latch Key/Mouse Input (Raw Input function). Write nonzero value to latch. Stores LibGDX Key code 40..47 RO: Key Press buffer stores keys that are held down. Can accomodate 8-key rollover (in keyboard geeks' terms) 0x0 is written for the empty area; numbers are always sorted 64..67 RO: User area memory size in bytes 68 WO: Counter latch 0b 0000 00ba a: System uptime b: RTC 72..79 RO: System uptime in nanoseconds 80..87 RO: RTC in microseconds 4084..4091 RO: Block transfer status 0b nnnnnnnn a000 mmmm n-read: size of the block from the other device, LSB (4096-full block size is zero) m-read: size of the block from the other device, MSB (4096-full block size is zero) a-read: if the other device hasNext (doYouHaveNext), false if device not present n-write: size of the block I'm sending, LSB (4096-full block size is zero) m-write: size of the block I'm sending, MSB (4096-full block size is zero) a-write: if there's more to send (hasNext) 4092..4095 RW: Block transfer control for Port 1 through 4 0b 00ms abcd m-readonly: device in master setup s-readonly: device in slave setup a: 1 for send, 0 for receive b-write: 1 to start sending if a-bit is set; if f-bit is unset, make other device to start sending b-read: if this bit is set, you're currently receiving something (aka busy) c-write: I'm ready to receive c-read: Are you ready to receive? d-read: Are you there? (if the other device's recipient is myself) NOTE: not ready AND not busy (bits b and d set when read) means the device is not connected to the port 4096..8191 RW: Buffer for block transfer lane #1 8192..12287 RW: Buffer for block transfer lane #2 12288..16383 RW: Buffer for block transfer lane #3 16384..20479 RW: Buffer for block transfer lane #4 -------------------------------------------------------------------------------- VRAM Bank 0 (256 kB) Endianness: little From the start of the memory space: 250880 bytes Framebuffer 3 bytes Initial background (and the border) colour RGB, of which only the lower 4 bits per each channel are used 1 byte command (writing to this memory address changes the status) 1: reset palette to default 2: fill framebuffer with given colour (arg1) 2 bytes argument for "command" (arg1: Byte, arg2: Byte) write to this address FIRST and then write to "command" to execute the command 86 bytes *Unused* IF graphics_mode THEN (41 sprites : 260 bytes each -> 10660 bytes) 0th sprite is always the GUI cursor 2 bytes Ob hv0000xy yyyyyyyy (h: horizontal flip, v: vertical flip, x: show/hide, y: y-position) 2 bytes 0b rr0000xx xxxxxxxx (r: rotation, x: x-position) 256 bytes 16x16 texture for the sprite ELSE 2978 bytes *Unused* 2 bytes Cursor position in: (y*32 + x) 2560 bytes Text foreground colours 2560 bytes Text background colours 2560 bytes Text buffer of 70x32 (8x14 character size, and yes: actual character data is on the bottom) FI 512 bytes Palette stored in following pattern: 0b rrrr gggg, 0b bbbb aaaa, .... Palette number 255 is always full transparent (bits being all zero) MMIO 0..1 RO Framebuffer width in pixels 2..3 RO Framebuffer height in pixels 4 RO Text mode columns 5 RO Text mode rows 6 RW Text-mode attributes 0b kkkk 00rc (k: currently using character rom, r: TTY Raw mode, c: Cursor blink) 7 RW Graphics-mode attributes 0b 0000 000g (g: Use sprites(wipes out text buffer)) 8 RO Last used colour (set by poking at the framebuffer) 9 RW current TTY foreground colour (useful for print() function) 10 RW current TTY background colour (useful for print() function) Text-mode-font-ROM is immutable and does not belong to VRAM Even in the text mode framebuffer is still being drawn onto the screen, and the texts are drawn on top of it