34. The Screen Files

Preamble

The Z88 LCD display is completly hardware driven by the Blink gate-array :
- No interrupt drives the screen construction
- The screen is not stored on a 640 * 64 bits memory area

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 definitions of those characters. The four character sets are called LORES0, LORES1, HIRES0 and HIRES1 where the LORES character sets consist of 6 by 8 pixel characters (used for printing characters) and the HIRES characters are 8 by 8 (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 one. 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. It represents an amount of 512 characters ($000-$1FF).
- Lores1 ($000-$1BF) is the 6 * 8 OZ characters file in ROM
- Lores0 ($1C0-$1FF) is the 6 * 8 user defined characters file in RAM. Assignment starts from top address with the character for code '@'.

The Hires chars are addressed by 10 bits. It represents an amount of 1024 characters ($000-$3FF).
- Hires0 ($000-$2FF) is the 8 * 8 map file in RAM (only 256 are used)
- Hires1 ($300-$3FF) is the 8 * 8 characters for the OZ window (only 128 are used)

Theyre 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. You can use this C program (zdc.c) to view those files.

The mapping of those files depends on OZ version but is generaly located at the bottom of bank $07. The 128K ROM was a bit short so conceptors mixed Lores1 and Hires1. Here is mapping for OZ v4.0 (UK), the same as v3.26 (FR) :

$0000-$07FF LORES1 (set at $070000)
	$0000-$03FF Normal 6*8 font (128)
	$0400-$07FF Bold 6*8 font (128)
$0800-$0EFF HIRES1 (set at $070800)
	$0800-$0BFF Tiny 6*8 font (128)
	$0C00-$0EFF OZ 8*8 font (96 with some 6x8 inside)

The precise Res1 mappings can be obtained on Dennis homepage. Actually, 58 characters are free in the Lores1, 134 in the Hires1.

In order to spare the 32K RAM of the original z88, the Res0 length and address vary if the machine is expanded or not.

Font    Unexpanded                        Expanded
Lores0  $21-2200 (256 bytes, 32 chars)    $43-0800 (512 bytes, 64 chars)
Hires0  $21-2000 (512 bytes, 64 columns)  $43-0000 (2K bytes, 256 columns)
SBF     $21-3800 (8 rows of 256 bytes)    $21-3800 (8 rows of 256 bytes)

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 builts the 640 rows it only reads the 216 first bytes. So up to 108 characters are stored by line. The 48 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 lrs 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
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.

It will also define 4 modes : Lores, Hires, Lores cursor and 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.

Windows and Status informations

In the SBF, the 48 bytes unused on each line are used by OZ to store windows and cursor informations. As OZ uses absolute addresses, those data are defined according theyre address. Each line contains the relative window frame (1-8) and the main data are stored in the last line.

Main data
$7FE7 2 Active window frame
$7FE9 1 SOH sequence length (0 if none)
$7FEC x 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 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 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 ?
IY-11 ?
IY-12 ?
IY-13 Control
      b0-b1 Jutification (0 normal, 1 right, 2 left, 3 centered)
      b6    Set to update cursor
      b7    Cursor mode (set=ON)
IY-14 ?

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.