Difference between revisions of "Amstrad Whole Memory Guide - The display system"

Revision as of 16:14, 12 February 2020

In all, the Display System takes up some 4000 bytes of code and fixed data in ROM, and its workspace spans about 380 bytes of RAM, not to mention the 16K byte screen RAM. There are more than 100 entry points. Fortunately, the system divides into three maln parts:

• The Screen Pack deals directly with screen handling, colour selection and screen read and write.

• The Text VDU handles matters relating to text display, including the implementation of stream selection. It also deals with the control codes and their parameters.

• The Graphics VDU handles the graphic display.

Each of these parts requires a chapter to itself, but it will be useful to offer some general information first.

The Screen RAM

In theory, the Screen RAM could be any 16K byte area of memory starting at a multiple of 4000, but the 8000-BFFF block would overwrite workspace and RAM routines, while 0000-3FFF would overwrite the RST Area, so the choice narrows to 4000-7FFF or C000-FFFF, and it is usually more convenient to adopt the latter area, leaving the central half of RAM free for other purposes.

The Screen RAM is accessed by the Video Gate Array on a basis of addresses supplied by the CRT Controller, but the addresses are not used in a straightforward manner. The CRT Controller embodies two counters. One, output on RA0-RA4, is incremented after each line of the display has been scanned. When this count reaches the value set for the number of scan lines in the character height it is zeroed, and the second counter, output on MA0-MA13, is incremented. This counter is initialised to the Start Address set in the CRT Controller, which is 3000 when the C000-FFFF area is in use. These outputs are used as follows;

• Address bits A14,A15 are driven from MA12,MA13. Since the MA counter works from a Start Address of 3000, both these bits are true.

• Address bits A11-A13 are driven from RA0-RA3

• Address bits A11-A10 are driven from MA0-MA9

• Address bit A0 is driven from the CRT Controller clock.

The scan line takes 40 microseconds to traverse the visible part of the display, and during each microsecond the Video Gate Array requires two bytes of screen data. These are transferred directly from RAM to the Video Gate Array, the processor being meanwhile held in Wait. The process is so timed that the CRTC clock changes state between the two transfers. Once all the bytes have been read, the normal processor action is allowed to continue. The bytes are used in different ways in the three screen modes.

In Mode 2, each byte defines one row of a character pattern matrix, each bit determining which of two colours should be given to a pixel, and eighty characters are displayed in each screen row.

In Mode 1, two bytes are required to define each matrix row, two bits being used to give each pixel one of four colours. Successive pixels are defined by bits 3,7; 2,6; 1,5; and 0,4. This sequence is repeated in the second byte From each pair of bits, the Video Gate Array determines which palette entry should be used, and sets the colour accordingly. Since each matrix row requires two bytes, only forty characters can be displayed per screen row.

In Mode 0, four bits are required to define one of sixteen colours for each pixel. This means that four bytes are required for each matrix row. The first pixel is defined by bits 1,5,3,7 of the first byte, the second by bits 0,4,2,6 and so on. Twenty characters can be displayed in each screen row.

The way the CRT Controller counts are used complicates the calculation of screen addresses. Numbering columns and rows from 0:

Address = Base + Offset + N*Column + 86*Row + 2048 per scan line.

where N is the number of bits per pixel in the current mode.

For a given scan line, the bits are taken in sequence. The next scan line is located by increasing the addresses by 0800.

Fortunately, the system will work out screen addresses on the basis of column, line, base and offset.

Observant readers may notice a slight anomaly. If N*Column = 79, and Row = 25, the column and row terms in the above equation fotal 1999, so there are 48 locations in each scan line that are spare. The MA counter in the CRTC does not address them.

However, there is the Offset term to be taken into account. Making offset = &50 moves the screen up one line. Making the offset $869 would move the display up by one scan line, but offset is limited to 07FF by the routine normally used to set it. When Offset is used, the Start Address in the CRTC is modified, and the missing 48 bytes may then come into play. There is a lot of scope for gentle experiment here.

Streams

The system provides for the definition of eight 'streams' of sereen data, each with its own independent parameters, which are:

• Window
• Cursor Position
• Pen and Paper
• Cursor Enable
• Screen Enable
• Opaque or Transparent
• Text or Graphics Write
• Roll Type

All eight sets of parameters are held in store, the set in current use being copied into a common area.

Bach stream may reserve for itself a rectangular window. If two windows overlap, the streams may overwrite each other in the overlap area. Any area not so reserved may be accessed by stream 0, which is the default if no stream is specified.

Parameters

A certain amount of care is needed in dealing with screen parameters, as their definition can vary. A distinction is made between 'physical' and 'logical' values, the former numbering columns and rows from 0 upwards, while the latter start at 1. There are also distinctions between absolute and relative values.

Similar distinctions arise with Graphics parameters, user coordinates being relative to the origin set by the user, while standard coordinates are relative to the default origin.

Workspace

As many workspace locations are common to more than one section of the display system, the addresses for the whole screen workspace in Version 1.0 are given here

Scanned pages

• 

  page 39

• 

  page 40

• 

  page 41

• 

  page 42

• 

  page 43

• 

  page 44