Topic : TOS - The Operating System
Author :
Version : tos.hyp (December 19, 2008)
Subject : Programmieren/Atari
Nodes : 3010
Index Size : 93790
HCP-Version : 5
Compiled on : Atari
@charset : atarist
@lang :
@default : Title
@help :
@options : +g -i -s +x +zz -t4
@width : 70
View Ref-File7.2.10 Raster formats TOSFor working with screens the raster functions play a special role;
they are responsible for everything that has to do with movement or
changes of screen clipping. Example: Scrolling within a document or
the depiction of icons.
Naturally, the raster functions can only perform their tasks efficien-
tly if the same format is used for internal depiction as that used in
video memory; otherwise the data would have to be converted for each
individual call of a raster function. However, the internal structure
of the video memory depends on the hardware of the graphics system in
use - quite apart from the fact that the video memory need not
necessarily be directly accessible to the processor.
The number of bits per pixel required depends, naturally, on the
number of colours that can be displayed simultaneously; for monochrome
pixels 1 bit is sufficient, for 16 colours one already needs 4 bits.
Depending on the video hardware in use, these bits can, of course, be
arranged in completely different ways; one should not be surprised,
therefore, that various formats are available for this purpose:
Pixel-oriented format: In this case, all bits belonging to a pixel are
coded together in one or more bytes. In a system using 16 colours,
therefore, two pixels would be saved together in one byte in each
case; for 256 colours, each pixel occupies one byte.
Plane-oriented format: In this case one treats the video memory as a
collections of monochrome (i.e. single-coloured) image planes. To
obtain the colour of a pixel, one combines the relevant bits from the
individual planes to a colour value. This says nothing, of course,
about how the individual planes are arranged in the video memory. A
simple solution (common in the PC domain) is to store one plane after
the other (sequentially) in video memory.
So as not to be restricted to a given, hardware-dependent format, the
VDI differentiates between the device-depedent format (which depends
on the hardware), and the so-called standard format. The standard
format is the same for all VDI systems, and can therefore be used any
time one wants to import raster graphics from outside into the system
(example: depiction of icons in a resource file). For conversion
between the two fomats one can make use of the vr_trnfm function.
The VDI standard format is defines as follows: . The format is plane-oriented. Each image plane occupies a
contiguous block of memory, and has the same number of image
points.
. The highest bit of a 16-bit WORD represents the furthest left
pixel
. Sequential words in video memory form the individual lines. The
first WORD of such a line lies at the left image border; the
first line of the plane codes the topmost pixel line.
The following figure shows an example for the device-independent
standard format with 3 colour planes, where each small square
represents a pixel:
Warning: In the monochrome graphics modes of the ST and TT030, the
device-dependent format happens to (!) correspond to the device-
independent one (i.e. the standard format). This does not mean, of
course, that one may therefore dispense with the use of the vr_trnfmfunction. As one normally has no information about the device-specific
format, this reason alone forbids any direct manipulation of the video
memory.
As a matter of principle, the VDI works in a colour register oriented
(colour lookup table or CLUT) manner. It starts off by assuming that
there is a maximum number of colours that may be displayed simulta-
neously, and that one can assign to these colour registers a palette
of certain (relatively freely selectable) tints. As this feature is by
no means self-evident, it can be inquired for via vq_extnd. There
follow two examples for graphics modes without a colour lookup table:
. The TT030 graphic mode 'TT-high': there are only two colour
registers and two tints (black and white), which may also not be
swapped.
. With True-Color graphics cards such as the Crazy-Dots-II, an
'arbitrary' number of colours may be displayed simultaneously.
Normally 24 bits per pixel are used for this, so that some 16
million colours are available. With such a large number of
colours the idea of colour registers is out of the question: The
number of tints principally displayable simultaneously far
exceeds the typical number of image points.
There remains the question how the pixel values in video memory are
related to the VDI colour indices. Answer: (a) On historical grounds, the start point is that for a pixel in the
VDI colour 0 (normally white) all bits are cleared, and for black
image points (VDI colour 1) all bits are set. This is logical if
only for the reason that by completely inverting all bits of the
pixel display, white and black are swapped.
(b) With the aid of the v_get_pixel function one can obtain both the
VDI colour index as well as the pixel value for a given image
coordinate.
In addition, Atari and Digital Research have documented the standard
assignments for 4, 8 and 16 colour palettes: . For four colours, the following apply:
Pixel value Colour index Colour Name
00 0 White WHITE
01 2 Red RED
10 3 Green GREEN
11 1 Black BLACK
. bei acht Farben gilt
Pixel value Colour index Colour Name
000 0 White WHITE
001 2 Red RED
010 3 Green GREEN
011 6 Yellow YELLOW
100 4 Blue BLUE
101 7 Magenta MAGENTA
110 5 Cyan CYAN
111 1 Black BLACK
. bei 16 Farben gilt
Pixel value Colour index Colour Name
0000 0 White WHITE
0001 2 Red RED
0010 3 Green GREEN
0011 6 Yellow YELLOW
0100 4 Blue BLUE
0101 7 Magenta MAGENTA
0110 5 Cyan CYAN
0111 8 Light grey LWHITE
1000 9 Dark grey LBLACK
1001 10 Light red LRED
1010 11 Light green LGREEN
1011 14 Light Yellow LYELLOW
1100 12 Light Blue LBLUE
1101 15 Light Magenta LMAGENTA
1110 13 Light Cyan LCYAN
1111 1 Black BLACK
Note: For other colour depths, no unambiguous assignments exist. As
there is also no general formula for a conversion, one has to resort
to the function v_get_pixel when necessary.
See also: AES object coloursRaster functionsvq_scrninfo