Batsocks - Text on TV - Display Data

Text on TV

Display Data

This section covers the data that is used.

A 'Display' array:

25 rows, each with 38 characters.
The character at a particular location will be rendered to the screen.
The size is 25*38 = 950 bytes.

A 'Row Attributes' array:

One 'row attributes' byte per row
If bit 0 is a '0', the row is rendered blank (regardless of the contents of the Display array for that row).
Originally designed as a speed-up for clearing the screen
Other bits are now used to apply row-based effects (double-width, double-height)

Cursor position:

Current Column
Current Row

A 'Font' array:

256 characters.
8 pixels wide by 9 slices tall
The size is 9 * 256 = 2304 bytes
Held in program space (flash rom), hence read-only
Aligned to a 256-byte boundary (see tricks and tips for why this is useful)
The font array is arranged in 9 slices - each containing 256 bytes of character pixel data
9 slices are used to ensure there is enough room under most characters for an underline cursor

Structure of Font Data

The Display Line Renderer reads these variables/arrays to display the screen.
The Serial processing routines modify some of these variables/arrays.

The 'Row Attributes' array is an important speed-up. Without it, clearing the screen (either wholly or partially) would take an exorbitant amount of time - possibly over 4000 clock cycles. That equates to several scanlines of disruption to the video signal. Using the array means that the screen can be 'cleared' by simply setting 25 bytes to 0 - a much faster proposition, especially as it makes loop-unrolling feasible (see tricks and tips).

The downside to the 'row attributes' speed-up is that at some point, the characters in the display array will actually have to be cleared before that row can be displayed normally again. Clearing the characters within a 'not displayed' row so that it can be marked for normal display has been called 'normalising'.

Normalising is carried out when no character (or a NUL character) has been received. To guarantee that the row containing the cursor will be normalised before the next character is received, the serial data rate is limited (purely by specification) to a maximum of one character every-other scanline. This means that normalisation can always be carried out in-between characters being received.