The screen files

Preamble

The screen is generated from the Screen Base File (SBF), a 2K file containing character codes, window and status information with four more files which contain font definitions of those characters. They are called LORES0, LORES1, HIRES0 and HIRES1 where the LORES character sets consist in 6 by 8 pixels characters (used for characters) and the HIRES characters are 8 by 8 pixels (used for the map area and the OZ window). 

The screen is refreshed every 10ms. It consists of 64 rows of 640 bits (pixels). Each 156µs, the 640 bits shift-register is built by combining character set data according to the screen codes stored in the Screen Base File (SBF). When the Blink reads a line, it shifts 6 or 8 bits to the row register according the Hires (HRS) flag. Those bits are given by the corresponding character number in the definition file (LORESx or HIRESx). Some text effects are hardware driven (reverse, flashing, grey, underlining). The flags behaviour depends on the HRS state.

The Definition Files

The Lores fonts are addressed by 9 bits (ch8-ch0) : 512 characters
- Lores1 (448 characters) is the 6 * 8 fonts in ROM
- Lores0 (64 characters) is the 6 * 8 user graphic defined (UGD) characters file in RAM. Assignment starts from top address with the character for code 64 ('@'). 

The Hires fonts are addressed by 10 bits (ch9-ch0) : 1024 characters
- Hires0 (768 characters) is the 8 * 8 map file in RAM (only 256 are used for map)
- Hires1 (256 characters) is the 8 * 8 fonts in ROM for the OZ window (only 128 are used)

Their structure is simply the 8 bytes of each character in the row order 1 to 8. For the Lores the 6 bits are stored in a byte but only uses bits 0-5 like UDG.

The mapping of those files depends on OZ version. Since 4.2, all LORES have been merged to allow country and keymap selection.

LORES1 map
128 normal lores (32 foreign + 96 ascii)
128 bold lores (same order as normal)
128 tiny lores (same order as normal)
64  symbol lores (10 lores are still free)
 
HIRES1 map
96 characters for OZ window (ascii, icons...)

In order to spare the 32K RAM of the original z88, the RES0 size vary if the machine is expanded or not.

On an unexpanded Z88 Hires0 may actually overlap Lores0. If Map=Yes and Map size in Panel is set to more than 64 (up to 96), UGD characters may be overwritten by map information if PipeDream is run. 

The Screen Base File

It is a 2K file consisting of 8 lines of 256 bytes. In a line, each character position is stored on 2 bytes with its attributes. When the Blink builds the 640 rows it only reads the 216 first bytes. So up to 108 characters are stored by line. The 40 bytes remaining are used to store windows status and information (see below). The format of these two bytes is like this: 

Attribute 2 (odd address):      Attribute 1 (even address): 
7   6   5   4   3   2   1   0   7   6   5   4   3   2   1   0 
---------------------------------------------------------------
sw1 sw2 hrs rev fls gry und ch8 ch7 ch6 ch5 ch4 ch3 ch2 ch1 ch0
---------------------------------------------------------------

sw1 : no hardware effect (used to store tiny flag)
sw2 : no hardware effect (used to store bold flag)
hrs : refer to Hires font (i.e. shift 8 bits in register), else Lores (shift 6 bits in register)
rev : reverse (i.e. XOR)
fls : flash (1 second period)
gry : grey (probably a faster flash period)
und : underline (i.e. set the 8 bits when on 8th row), only valid for Lores it becomes ch9 when hrs is set.

Four types of character can also be displayed : Lores, Hires, Lores cursor or the Null character.

                 5     4     3     2     1     0,  7-0
                 hrs   rev   fls   gry   und   ch8-ch0
------------------------------------------------------
LORES            0     v     v     v     v     000-1FF
LORES CURSOR     1     1     1     v     v     000-1FF
NULL CHARACTER   1     1     0     1     xxx    -  xxx
HIRES            1     0     v     v     000    -  3FF
x = don't care, v = valid, (i.e. the attribute depends on the value of the bit)

The Null character ($34 or $35) is used when there is nothing to add to the shift-register. For example, when there is no map, the first line shifts 104 lores characters (6*104=624 pixels), 1 null (0), 3 hires (O, Z, space, 16 bits the third is not displayed). It corresponds to 640 pixels. This null character is used many times when there is a map.

Lores cursor : is just a reversed flashing character with hrs flag set.

Windows and Status information

In the SBF, the 40 bytes free at the end of each line are used by OZ to store windows and cursor informations. As OZ uses absolute addresses, those data are defined according their address. Each line contains the relative window properties (1-8) and the main data are stored in the last line.

SBF structure
Row 1 : 108 chars ($7800-$78D7) + Window 1 properties ($78D8-$78E6) + 25 bytes free ($78E7-$78FF)
Row 2 : 108 chars ($7900-$79D7) + Window 2 properties ($79D8-$79E6) + 25 bytes free ($79E7-$79FF)
Row 3 : 108 chars ($7A00-$7AD7) + Window 3 properties ($7AD8-$7AE6) + 25 bytes free ($7AE7-$7AFF)
Row 4 : 108 chars ($7B00-$7BD7) + Window 4 properties ($7BD8-$7BE6) + 25 bytes free ($7BE7-$7BFF)
Row 5 : 108 chars ($7C00-$7CD7) + Window 5 properties ($7CD8-$7CE6) + 25 bytes free ($7CE7-$7CFF)
Row 6 : 108 chars ($7D00-$7DD7) + Window 6 properties ($7DD8-$7DE6) + 25 bytes free ($7DE7-$7DFF)
Row 7 : 108 chars ($7E00-$7ED7) + Window 7 properties ($7ED8-$7EE6) + 25 bytes free ($7EE7-$7EFF)
Row 8 : 108 chars ($7F00-$7FD7) + Window 8 properties ($7FD8-$7FE6) + Main screen data ($7FE7-$79FF)

Main screen data are :
$7FE7 2 bytes : Active window frame
$7FE9 1 byte  : SOH sequence length (0 if none)
$7FEC x bytes : SOH buffer

Example with a sequence defining a user lores character : 1,138,'=',..,...
$7FE9 10 the length
$7FEC '=' the command
$7FED user defined character number
$7FEE user defined character data (8 raws)

The window properties frame contains informations about the window appearance and the cursor (if selected). The 8 frames are :

IX frame
$78E6 window 1
$79E6 window 2
$7AE6 window 3
$7BE6 window 4
$7CE6 window 5
$7DE6 window 6
$7EE6 window 7
$7FE6 window 8

When addressing a frame, its number is in IX. The data i/o are done with LD (IX-nn) instructions. nn defines the data described in the window frame structure. In that frame, the coordinates are absolutes. It is the address of the character attributes. Stored in HL, H refers to the row, L to the column. For example, (0,0) will be $00 $78 (HL=$7800). (105,7) will be $E2 $7F (HL=$7FE2).

Window properties frame structure 
IX-01 Y up left
IX-02 X up left
IY-03 Y down right
IY-04 X down right
IY-05 Left margin
IY-06 Right margin
IY-07 Y cursor address
IY-08 X cursor address
IY-09 cursor attributes
IY-10 always 0
IY-11 flags low
IY-12 open flags
IY-13 flags hi
   b0-b1 Justification (0 normal, 1 right, 2 left, 3 centered)
   b6 Set to update cursor
   b7 Cursor mode (set=ON)
IY-14 flags 2 (1 initialization bit used)

Uses of the Screen Registers

Obviously, any routines which look directly at screen information are very hardware specific. Use of the OS_Sci call means that in future such routines would not cause code to fail, in the way that writing directly to hardware registers might, but if the system hardware arrangement did change, any code which relies on the screen information, almost certainly would not work properly. Therefore it makes sense that code using the OS_Sci call checks for error returns and can cope with the concept of the screen information being unavailable. 

Screen file address are read by OS_Sci with A=file reason and B=0, result is in BHL. The Lores0 and Hires0 can be moved by the user (often used in the Ranger software). For more details about the Screen registers consult Blink registers manipulations chapter.

Full Graphic Screen

It is possible to have a full graphic array of 640x64. It requires only HIRES0. A total of 640 HIRES0 characters are needed. The SBF is filled with all of those HIRES0 characters (80 characters by row). Accessing the screen matrix is done by changing the HIRES0 settings directly in the RAM.