FLI - more color to the screen by Pasi 'Albert' Ojala (po87553@cs.tut.fi or albert@cc.tut.fi)
                       
(All timings are in PAL, altho the principles will apply to NTSC too)

All of us have heard complaints about the color constraints on C64. One 8x8
pixel character position may only carry four different colors.  FLI picture
can have all of the 16 colors in one char position.  What then is this FLI
and how it is done ?

In the normal multicolor mode can one character position (4x8 pixels) have
only four different colors and one of them is the common background color.
Color codes are stored in half bytes (nybbles) to the video matrix memory
(anywhere video matrix pointer points at, normally $0400) and to the color
memory ($D800-$DBFF). In multicolor mode the color of each pixel is
determined by two bits in the graphics memory. Bit pair 11 will refer to
color memory, background color is the color for bit pair 00, and video
matrix will define the colors for bit pairs 01 and 10.


_What happens in the VIC ?_

VIC (Video Interface Controller) fetches color information from memory on
each bad line. This will steal time from processor, because VIC needs to use
processor's bus cycles. Bad line is a curse in the C64 world. Fortunately
VIC's data bus is 12 bits wide and so the color data fetch for each character
position will take only one bus cycle. Color memory is physically wired to
the VIC databus lines D8-D11.

How does VIC know where to fetch the graphical information ? Some of you know
the mystical formulas needed to mess with the pixels in the hires screen.
How are these functions obtained ? Are they just magic ? No, there are some
internal counters in VIC. They always point to the right place in grafix
memory and the address is determined like this:

A13  A12 A11 A10 A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
CB13 VC9 VC8 VC7 VC6 VC5 VC4 VC3 VC2 VC1 VC0 RC2 RC1 RC0

Address bits A15 and A14 change according to the selected video bank.
Address bit A13 is CB13, which may be found in VIC register $18. It
selects the right side of the video bank to be the bitmap memory. With
these bits you can set the bitmap to eight different places in memory.
However, some of them are useless because of the character ROM images and
zero page/stack. Rest of the bits come from the internal counters.

VC9-VC0 (Video Counter) forms the address bits 12-3. The counter rolls
through all 1000 character positions, 0-39 on the first eight lines, 40-79
on the second eight lines and so on. The lowest three bits come from the row
counter, RC2-RC0. This is another VIC counter and it counts the scan lines
from zero to seven.


_A software graphics mode - FLI_

VIC will systematically go through every byte in the bitmap memory, but how
does it know where and when to get the color information ? This is where
the main principle of FLI (Flexible Line Interpretation) lies. Color data
is fetched (and this means it is a bad line), when the line counter matches
with the vertical scroll register. VC9-VC0 defines where the color data is
inside the video matrix and color memory.

If we change the vertical scroll register, we can fool VIC to think that
every line is a bad line, so it will fetch the color information on every
line too. Because VIC will fetch the colors continuosly, we can get
independent colors on each scan line. We just have to change colors and VIC
will handle the rest. Unfortunately the result is the loss of 40 processor
cycles per line (see the Missing Cycles article for more information about
VIC stealing cycles).


_Doing it in practice_

In practice there is no time to change color memory, but in multicolor
mode VIC uses video matrix for color information too. We have just enough
time to change the video matrix pointer, $D018. Now VIC will see a
different video matrix on each scan line, different block of memory. With
the four upper bits in the register we select one of the 16 video memories
in the video bank. Just remember that the register also selects the position
of the graphics memory (bitmap) inside the video bank.

Because we have to keep the bitmap in the same video bank, we only have half
of the bank free for video matrices. Fortunately, that's all we need to get
individual multicolor colors for each line and character position.
VIC will fetch the color data from the eight video matrices and then it will
roll on to the next 40 bytes. After eight lines and matrices we will select
the first video matrix again. (See picture 1)

Usually it is not necassary to use the whole screen for a FLI picture,
especially if you want to have a scroller or some other effects. You just
have to make sure that VIC is foolable in the usual way. The timing is also
very important, even one cycle variations in the routine entry are not
allowed. There is many ways to do the synchronization. One way is to use a
sprite, as in the previous article. (See C= Hacking, Vol. 1, Iss. 3, The
Demo Corner: Missing Cycles).


_Not much time_

Because a bad line will steal 40 cycles, there is only 23 cycles left on
each scan line. It is enough for changing the video matrix and backgroud
color. There is not a moment to lose, because you must change the vertical
scroll register, video matrix pointer and the background color. This is why
you can't have sprites in front of a FLI picture.

With FLI we get two selectable colors for each character position and line,
each scan line can have it's own background color and each character position
still has its own character color from color memory. In theory each character
position could have 25 different colors, unfortunately VIC only has 16.


_A little feature_

VIC does not like it when we change the vertical scroll register ($D011),
and is a bit annoyed. It 'sees' code 255 (light gray) in video matrix
and 9 (brown) in the color memory instead of the correct values stored there.
Actually the color value seems to be the lower nybble of the data byte
currently on the data bus (accessed by the processor (LDA#=$A9)).
Unfortunately there is no chance to do the register change in the border
and thus the three leftmost character columns are a bit useless, because
the colors are fixed.

However, this doesn't mean that you can't use those three columns. FLI
editors may not support the fixed colors though, so it may be hard to use
them.


_What to do with FLI ?_

Because FLI will eat up all the available processor time (no Copper :-),
it is not suitable for any action-games. Each FLI picture takes about 17 kB
of memory: not so many pictures fit on one floppy. So, the only place for FLI
is demos, intros, board-type games and maybe a GIF viewer..

--------------------------------------------------------------------------
Picture 1: From which matrix VIC fetches the multicolor values

 _          ___________________________________________________________
|      ... | Matrix0       | Matrix0       | Matrix0       |
|      ,  .|____3__________|____4__________|____5__________|  ...
|       U .| Matrix1       | Matrix1       | Matrix1       |
|       s .|____3__________|____4__________|____5__________| .
|Char   e  | Matrix2       | Matrix2       | Matrix2       | .
|Line   l  |____3__________|____4__________|____5__________| .
|Zero   e  | Matrix3       | Matrix3       | Matrix3       |
|       s  |____3__________|____4__________|____5__________|
|       s, | Matrix4       | Matrix4       | Matrix4       |
|          |____3__________|____4__________|____5__________|
|       c  | Matrix5       | Matrix5       | Matrix5       |
|       o  |____3__________|____4__________|____5__________|
|       l  | Matrix6       | Matrix6       | Matrix6       |
|       u  |____3__________|____4__________|____5__________|
|       m  | Matrix7       | Matrix7       | Matrix7       |
|_      n  |____3__________|____4__________|____5__________|
        s  | Matrix0       | Matrix0       | Matrix0       |
           |___43__________|___44__________|___45__________|
           | Matrix1       | Matrix1       | Matrix1       |
           |___43__________|___44__________|___45__________|
           |
           |   ...
           | .
           | .
           | .

--------------------------------------------------------------------------
_Additional reading_

If you have an Amiga you might want to get your hands into my conversion
programs in C64GFX1.lha. The packet also includes FLI viewer for PAL C64's
and some documentation about the FLI file format. It also has the same
utilities for Koala format pictures.

Available from:
cwaves.stfx.ca
nic.funet.fi:/pub/amiga/graphics/applications/convert


C64GFX.doc
                        C64Gfx1.0
           A C64 grafix format conversion package
           )1991,1992  Pasi 'Albert' Ojala

           E-mail: po87553@cs.tut.fi
                   albert@cc.tut.fi

This package contains programs which are used to convert portable
pixmap (ppm) files to C64 graphics formats (FLI and koala) under
AmigaOS. The package includes C source codes for the programs, so
it is possible to port the programs to another environment. C64GFX1.1
includes Unix-compilable sources.

In addition to this package you need e.g. PBMPlus to convert Amiga
ilbm files to ppm first. And of course some way to transfer files
between the machines.

