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.