Developper's Notes Addendum



On the Z88 the screen is hardware managed. The screen base file (SBF) is built by OZ on each OS_OUT or OS_MAP call. This screen base file is independantly read by the blink directly in memory. Then, it reconstructs 64 frames of 640 bits and send them to the LCD drivers. There is no interrupt nor hardware routines specific to LCD.

1 - General organisation

The LCD is a 640*64 Dot matrix panel.
Two types of character can be used :
The LORES : 6x8 character set
The HIRES : 8x8 character set

On the right of the screen, there is always the OZ window : 2 HIRES chars wide (16 pixels).
The left part is a combination of windows and map.

Windows use LORES chars, maximum 104 (*6=624 pixels).
Map uses HIRES chars, maximum 32 (*8=256 pixels).

2 - Pixel Base files : LORES and HIRES organisation

The blink can address 512 different chars of each res.

512 LORES :
448 defined in ROM : LORES1 ($000-$1BF)
64 user defined in RAM : LORES0 ($1C0-$1FF)

512 HIRES :
256 defined in ROM : HIRES1 ($000-$0FF)
256 defined by the map in RAM : HIRES0 ($100-$1FF)

LORES1 contains the Normal, Tiny, Bold, Foreign and Special characters.

The Underline, Grey, Reverse and Flash attributes are hardware managed.

HIRES1 contains the characters for the OZ window :
an upper case character set for COMMANDS and SQUARE+application letter keys.
special chars (OZ, SQUARE, DIAMOND, FAIL, INDEX, CLI, CAPS, caps, BAT LOW...)

For sparing space in the tidy 128K ROM, the LORES1 and HIRES1 are mixed together.
They could be set independantly...(next OZ).
There is some space left but it seems to be impossible to respect the full ISO LATIN1 character set if we want to keep the three polices. Each foreign OZ has his own LORES1. Keyboard driver and screen driver are specific too.

You can find the description of these in 'HiLoRes.txt', it describes the character set of OZ V4.005 (UK), exactly the same as OZ V3.26 (FR)!

3 - The Screen Base File (SBF)

3.1 - Attributes

The Screen Base File is 2K long file containing the screen character numbers referring to the Lores or Hires set. A visible character is stored in two bytes. Attributes are described below. These bits define a precise hardware command.

Byte 1 (odd)
ch7 ch6 ch5 ch4 ch3 ch2 ch1 ch0

Byte 2 (even)
sw1 sw2 hrs rev fls gry und ch8

SW1 x No hardware command (only used by OZ)
SW2 x No hardware command (only used by OZ)
HRS 0 Refer to LORES offset, display a 6 bits wide matrix
1 Refer to HIRES offset, display a 8 bits wide matrix
REV 1 Reverse attribute for LORES, Special use for HIRES
FLS 1 Flash attribute
GRY 1 Grey attribute
UND 1 Underline attribute

ch0-ch8 character number (refering to the RES tables, not ascii)

0 0 Normal charset (ascii order)
0 1 Bold charset (ascii order)
1 0 Tiny charset (ascii order)
1 1 Special (see RES tables) and user defined (LORES0)

0 0 Map (HIRES0)
0 1 Map (HIRES0)
1 0 Unused
1 1 Char set (upper case only) and specials

When HRS and REV are set, it is a special command, FLS selects the type :

FLS set : LORES cursor (other attributes are valid),
It is clear that the cursor is only a Reversed char when flashing (once per second).
The cursor will always look like : $xx $38 or $xx $39.

FLS res : null character (always $00 $34)
The null character fulls the empty areas of the screen (it is not spaces).

Set HRS REV FLS GRY UND CHAR (bit 0 - bit 8)
LORES1 0 v v v v 000-1BF (448 chars)
LORES0 0 v v v v 1C0-1FF (64 chars)
HIRES0 1 0 v v v 000-0FF (256 chars)
HIRES1 1 0 v v v 100-200 (256 chars)
CURSOR 1 1 1 v v 000-1FF (lores char number)
NULL 1 1 0 1 0 000

v = valid (1 is set)

The OZ window is the right part of the map. There are 2 visible hires char (16 pixels). In fact, it is 3 chars wide window, the third char is always a space.

1 $80 $81 'OZ'
1 $82 $83 'LOCK OUT'
1 $94 $95 'CARD'
1 $96 $97 'INDEX'
1 $8A $8B 'FAIL'
2 $92 $93 Bell symbol
3 $88 $89 'CLI'
4 - -
5 $90 Diamond symbol
5 $91 Square symbol
6 $8C $8D 'BAT'
7 $8E $8F 'LOW'
8 $84 $85 'CAPS'
8 $86 $87 'caps'

3.2 - Hidden data of the SBF

The SBF is 2K long. Each line uses 256 bytes (*8=2K). As there was space left in the screen base file, each line uses only (104+3)*2=214 bytes. The conceptors placed some important data of screen configuration after these bytes. It the data for each window and main datas like the active window and the VDU buffer. If you try to move the SBF directly, the screen turns to black and flickers because OZ uses absolute addresses (always $21 $7800) but in theory it could be possible (by rewriting all the routines) to move the SBF, the blink register exists. Each line contains a window frame. In the the last line are stored the main datas. The following parts are not exhaustive, some bytes havent been discovered.

3.2.1 - Main datas

$7FE7 2 Active window frame (=IX)
$7FE9 1 VDU length, zero if no VDU
$7FEA 1 ?
$7FEB 1 ?
$7FEC n buffer for VDU.

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

3.2.2 - Window frame structure

The window frame contains informations about the window appearance and the cursor (if selected). The different Window frames are :
$78E6 win #1
$79E6 win #2
$7AE6 win #3
$7BE6 win #4
$7CE6 win #5
$7DE6 win #6
$7EE6 win #7
$7FE6 win #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 data of each window are stored. All the coordinates are absolutes. These coordinates are the address of the character attributes. One X is two bytes (attribute 1 and 2). The screen base file address is $21 7800 on expaned and unexpanded machines. These (X,Y) coordinates are L H addresses.

For example: (0,0) will be $00 $78 (HL=$7800). (105,7) will be $E2 $7F (HL=$7FE2).

IX-01 Y up left coordinate
IX-02 X up left coordinate
IX-03 Y down right coordinate
IX-04 X down right coordinate
IX-05 Left margin
IX-06 Right margin
IX-07 Y cursor address
IX-08 X cursor address
IX-09 cursor attrib
bit 5 ? set=08 res=38
IX-0Dbit 0justification bit 1
bit 1justification bit 2
0 normal
1 right
2 left
3 centered
bit 6 update cursor
bit 7 cursor mode (res=OFF, set=ON)
IX-0E bit 7 ? set=in use, res=first time

4 - The BLINK screen registers

The blink screens registers stores the screen files addresses in order to read them directly for the screen refresh 50 times per second. There are 4 pixel base registers (PBx) for each pixel base address and the screen base register (SBR). These registers have a special bit length, it will define the screen granularity : the screen mask in HL. For a 4K granularity screen address will be 0,4,8,12K.

Their softcopies are stored in $047n and $046n where n is screen reason minus one. Be careful when you set the register, you have to use both B, C and A registers in OUT (C),A. B contains the left bits of data (more than 8), A the data, C the port. So, A will be ($047x) and B will be ($046x).

PortNumberWith (bits)GranularityScreen fileReasonSize
PB0$7013512 bytes Lores01512
PB1$71104K Lores123.5K
PB2$729 8K Hires032K
PB3$73112K Hires142K
SBR$7411 2K Base 52K

The coding method to set the address in the blink register is below, the non significant bits are set to zero.
Example with Lores0.

PB0 : Lores0

B                       / H                    / L
b7 b6 b5 b4 b3 b2 b1 b0 / 0 0 h5 h4 h3 h2 h1 0 / 0 0 0 0 0 0 0 0

will become

$0460                  $0470
0 0 0 b7 b6 b5 b4 b3 / b2 b1 b0 h5 h4 h3 h2 h1

Now the table of the screens address defined by OZ on reset :

ScreenUnexpanded machineExpanded machine
Lores1$070000 2K --$00$1C
Hires0$212000 512B$4300002K$00$86
Hires1$070800 1.8K --$00$39
Base$217800 2K --$01$0F

For getting the screen addresses, you can use an undescribed feature of OS_SCI. Call it with the screen file reason in A and B=0. The screen file address is outed in BHL without changing the register value.


The screen driver is one the main advanced part of OZ. It interfaces with this hardware description via VDUs. The latest Z88 have more ROM (Flash Eproms) and RAM, this new place could be used to improve and speed up the display.

Thierry Peycru (Zlab), April 1998.