The OSCA Video System

There is 512KB of "background video" RAM available (separate to sprite and system memory). It's normally accessible to the CPU in 8KB pages @ CPU address $2000-$3FFF as selected by the register vreg_vidpage. However, a special write-only mode allows the entire Z80 address space to be mapped onto a 64KB page of video RAM (see sys_mem_select).

There are two main video modes, bitmap and tilemap - both allow up to 256 colours. CPU access TO VIDEO MEMORY whilst the display window is being generated is hindered by the video system. The different video modes affect how long the CPU is kept waiting - Dual Playfield tilemap mode is the most demanding. The display is normally non-interlaced, PAL ~50Hz or NTSC ~60Hz, when the VGA mode jumper is installed the output is VGA 60Hz (with the option of 50Hz)

BITMAP "CHUNKY" MODE:

"Chunky" refers to the fact that in this mode each pixel's colour index is fetched in one chunk from a single memory address. The byte fetched from VRAM simply represents an index in the video palette. Pixel data is fetched linearly from VRAM left to right, top to bottom of the screen (a modulo register can be used to skip n bytes at the right side of the display at the end of each line - useful for interlaced displays, an area for fresh data when scrolling etc). The data-fetch start address can be manipulated to achieve scrolling effects.

In chunky mode, a fast line draw system is available (125ns per 256 colour pixel) are possible. The hardware requires Bresenham constants, octant number, video start address and length of line to be set up in the line draw registers, then the hardware carries out the algorithm. The registers are doubled up, allowing line set-up data for a new line to be loaded up whilst the previous line is being drawn.

Chunky mode also offers "pixel flooding" (see bit 6 of vreg_vidctrl) which repeats the last pixel colour to achieve flood fill effects. Pixel data is interpreted according to the setting of bit 4 of vreg_vidctrl. When it is zero, the following rules are used:

• If current pixel colour is 128->255, display the pixel as normal and remember it.
• If current pixel colour is 0->127: If bit 6 of the previously stored colour is one and bit 6 of the current pixel colour is zero, show a pixel of the previously stored colour. Otherwise, use the current pixel colour (but do not remember it).
• The stored colour is reset to zero at the start of each scan line.

When bit 4 of vreg_vidctrl is set, a simpler rule is used:

• If the current pixel is zero, use the last non-zero colour

Finally in chunky mode, pixels can be horizontally expanded from 1 to 8 times (see bit 3 of "vreg_vidctrl" and bits 0:2 "vreg_yhws_bplcount")

BITMAP "PLANAR" MODE:

Planar mode allows more flexibility: The display can have up to 8 linear bitplanes which are internally combined to form an index byte to the palette table for each pixel. Each bitplane has its own 19 bit start location register, and in fact there are two sets of bitplane pointers and the video hardware uses the set indicated in the video control register vreg_vidctrl. These pointers need only be written once, as an internal counter adds the offset to the video memory required as the frame is built up (this offset register can be reset at any time). The pointers can be manipulated to achieve scrolling effects etc (Horizontal pixel scrolling is provided via a hardware scroll register.) The modulo register can be used to skip bytes at the end of each line.

The bitplanes are combined to form pixel palette indexes in following fashion (diagram shows 4 bitplane display).

TILE-MAP MODES:

In tile-map mode the display is built up in a less direct manner: The hardware reads a look-up table and displays a block for each tile position. The blocks can be 8x8 or 16x16 pixels in size (they are defined in a simple, linear 1 byte = 1 pixel colour index left to right, top to bottom fashion). Dual playfield capability is provided so that one map can be overlayed on top of the other (pixels of value 0 are taken as transparent). The playfield priority is selectable. Each playfield can be offset by 0-15 pixels in the vertical or horizontal direction allowing smooth scrolling. There are two map buffers per playfield which allows double buffering if desired. The registers VREG_VIDCTRL, VREG_EXT_VIDCTRL, VREG_XHWS and VREG_YHWS_BPLCOUNT contain the control bits for the tilemap modes.

LEGACY TILE MODE

The original OSCA tilemap mode was quite primitive: tiles can only be 16x16 and are indexed with a single byte allowing a maximum of 256 different tiles per set. This is referred to as Legacy Tilemap mode. In this mode there are two sets of tile definitions available with 248 and 256 tile images available respectively. Tile set A has fewer definition blocks available as the video memory for blocks 0-7 (VRAM $0-$7ff) is assigned for use as the four available tile maps.

In Legacy Tile Mode: VRAM is organized as follows:

$00000 - $001FF: Playfield A - tilemap 0
$00200 - $003FF: Playfield A - tilemap 1
$00400 - $005FF: Playfield B - tilemap 0
$00600 - $007FF: Playfield B - tilemap 1

$00800 - $0FFFF: Tile definition set A (Tile defs 0-7 are unavailable)
$10000 - $1FFFF: Tile definition set B (Tile defs 0-255 available)

The horizontal size of the tile map buffer is always 32 bytes, no matter what the size of the display window.

EXTENDED TILE MODE

In Extended Tilemap Mode (IE: when bit 0 of vreg_ext_vidctrl is set), tiles are indexed by 2 bytes and can be 16x16 or 8x8 pixels. There is a single set* of 2048 16x16 tiles or 8192 8x8 tiles (the tile set select bits used in legacy mode have new meanings in Extended Tilemap Mode.) The tile maps are located between at $70000-$73fff in video memory, well clear of the tile definitions which are located at VRAM $0 (The memory space used by the tile maps will produce garbage tiles if indexed). The upper byte of the tile index also holds 2 control bits: Bit 6 = flip tile horizontally, bit 7 = flip tile vertically.

Although the tile definitions are normally indexed in a straightforward linear manner, there is an option to flip between the definitions held at VRAM $0-$3FFFF and $40000-$7ffff.

In Extended Tile Mode with 16x16 tiles: VRAM is organised as follows:

$00000-$6FFFF: Tile definitions (256 bytes each)

$70000-$701FF: Playfield A Buffer 0 tilemap LSBs
$70200-$703FF: Playfield A Buffer 1 tilemap LSBs
$70400-$705FF: Playfield A Buffer 0 tilemap LSBs
$70600-$707FF: Playfield A Buffer 1 tilemap LSBs
$70800-$709FF: Playfield B Buffer 0 tilemap MSBs (incl. flip control)
$70A00-$70BFF: Playfield B Buffer 1 tilemap MSBs (incl. flip control)
$70C00-$70DFF: Playfield B Buffer 0 tilemap MSBs (incl. flip control)
$70E00-$70FFF: Playfield B Buffer 1 tilemap MSBs (incl. flip control)

In 16x16 tilemap mode, the width of each horizontal map line is 32 bytes no matter what the size of display window. Each tilemap has room for 16 rows of tiles (ie: a 256 scanline display), however when using vertical hardware scroll, the maximum y window should be 240 lines to mask off the last tile-line (where the internal tilemap line pointer wraps back to 0)

In Extended Tile Mode with 8x8 tiles: VRAM is organised as follows:

$00000-$6FFFF: Tile definitions (64 bytes each)

$70000-$707FF: Playfield A Buffer 0 tilemap LSBs
$70800-$70FFF: Playfield A Buffer 0 tilemap MSBs (incl. flip control)
$71000-$717FF: Playfield A Buffer 1 tilemap LSBs
$71800-$71FFF: Playfield A Buffer 1 tilemap MSBs (incl. flip control)
$72000-$727FF: Playfield B Buffer 0 tilemap LSBs
$72800-$72FFF: Playfield B Buffer 0 tilemap MSBs (incl. flip control)
$73000-$737FF: Playfield B Buffer 1 tilemap LSBs
$73800-$73FFF: Playfield B Buffer 1 tilemap MSBs (incl. flip control)

(Note that the LSB/MSB arrangement is slightly different to that of the 16x16 mode.)

In 8x8 tilemap mode, the width of each horizontal map line is 64 bytes no matter what the size of display window. The hardware scroll registers still provide a 0-15 pixel offset.

Each tilemap has room for 32 rows of tiles (ie: a 256 scanline display), however when using vertical hardware scroll, the maximum y window should be 248 lines to mask off the last tile-line (where the internal tilemap line pointer wraps back to 0)