by two additional bits that can make the colours flashing and/or brighter. *Fig. 12*, shows how colour information is stored in each byte in the COLOUR_FILE area.  ``` 0 1 2 3 4 5 6 7 MSB FL BR G R B G R B LSB |--Paper Colour-| |--Ink Colour--| ``` *Fig. 12 - Attribute byte organisation* The two colours stored within are named INK and PAPER mainly to reference the printed characters we explored in the previous chapter since INK is the colour of the character itself and PAPER is the rest of the background, in a sense a form of virtual paper we write on[^p99-4]. That way *Layer 0* graphics can display up to 16 colours on screen using very little memory but with the tradeoff of *colour clash*. This term simply describes the fact that the *colour resolution* is much lower than the *spatial* one. Like its DISPLAY_FILE counterpart, COLOUR_FILE can have a secondary area which, when enabled, is called COL_FILE2 and resides right after DISP_FILE2. Unlike the DISPLAY_FILE areas, COLOUR_FILE areas are *normally* straightforward in how they are stored and that is simply in order of cells from top leftmost to right bottommost. The secondary DISPLAY_FILE area, other than the *HiRes* (*Layer 1,2*) area for even display addresses can also function as a *shadow screen* which is a non-visible screen, identical in organisation to the first one, that holds a visual we may want to project quickly thus creating animation effects as we'll see in *Chapter 17 – Time and Motion* later on. In that usage the secondary COLOUR_FILE area functions exactly the same way as the primary one. In *HiColour* mode however (*Layer 1,3*), DISP_FILE2 becomes itself a COLOUR_FILE and the normal COL_FILE1 and COL_FILE2 are not used. It's also noteworthy, that *HiRes* mode also does not use the COLOUR_FILE areas but for a different reason *HiColour* mode (*Layer 1,3*) reduces the amount of *colour clash* by reducing the size of *attribute cells* thereby extending the colour resolution to 32x192 cells of 8x1 *pixels* in size. As the colour resolution increases, the memory requirements are increased as well and that is why the entire memory of DISPLAY_FILE2 is used in lieu of a COLOUR_FILE. It's easy to figure out why this happens: The original COLOUR_FILE area of 768 bytes is extended (therefore multiplied) by 8 times to make the vertical colour resolution equal to the spatial resolution. If you make the multiplication 768 x 8 you see that a further 6.144 bytes are needed to increase the colour resolution. COLOUR_FILE1 and COLOUR_FILE2 areas are unused in this mode. The organisation however of this enlarged COLOUR_FILE since the colour resolution has grown follows the one of the DISPLAY_FILE meaning that it uses the same interleaved storage as the graphic data. We can therefore modify our original program to also display colour attributes so we can get a visual idea of the two modes' differences: ``` 10 LAYER 1,1 20 BANK 5 ERASE 0,6912,4 30 BANK 5 ERASE 8192,6912,4 40 FOR %m=0 TO 6143 50 BANK 5 POKE %m,%@10101010 60 NEXT %m ``` [^p99-4]: This distinction is purely arbitrary but it helps distinguish these two colours from one another in a more human–readable way. They could have been easily called COLOUR_A and COLOUR_B.