FLI | Code Like It's 198x

“If you’re frustrated by the 64’s color cell limitations,” Compute! told its American readers in January 1992, “check the freedom that FLI can offer.” Bill Pitts’s article explained a graphics mode that Commodore never designed and that no commercial paint program supported: “European software producers originally developed FLI to create more colorful logos for their software demonstrations.” Even its name was unsettled. “Depending on whom you ask, FLI stands for Flexible Line Interrupt or Flexible Line Interpretation.” The C64’s demo coders had found a way to put all sixteen colours into a single character cell, and graphics artists on the American online service QuantumLink were trading the editors to use it.

Christian Bauer’s 1996 description of the VIC-II calls FLI “probably the most outstanding example of ‘unconventional’ VIC programming”.

The problem it solves

In the C64’s multicolour bitmap mode, each cell of 4×8 double-width pixels can show four colours: the shared background colour, one colour from colour RAM, and two from the byte for that cell in screen memory. The VIC-II reads screen memory only on a badline, the first raster line of each character row, so those two colours apply to all eight lines of the cell. That is the colour clash C64 artists worked around.

How it works

FLI forces a badline on every raster line. The VIC-II treats a line as a badline when the bottom three bits of the raster line equal YSCROLL, the vertical scroll value in bits 0–2 of $D011. A program that sets YSCROLL to match each new line in turn makes every line a badline, so the chip reads screen memory for colours on every line. Bauer: “This way, each of the 4×8 pixels of a block in multicolor mode can have a different color.”

Two details make it work, and both come from Bauer:

The screen address does not move on. A badline that starts before the current character row has finished does not advance the chip’s pointer into screen memory, so every forced badline would read the same 40 bytes again. The processor cannot rewrite them fast enough, so the program switches to a different screen instead, with the top four bits of $D018. It keeps eight screens and cycles through them: the first raster line of the picture reads row 0 of screen 1, the second reads row 0 of screen 2, and so on, until the ninth line reads row 1 of screen 1.
The write has to wait until cycle 14. If the $D011 write that forces the badline comes earlier in the line, the chip’s row counter is cleared on every line “and the bitmap display would not be as desired”. So each line needs two register writes, $D018 and $D011, on known cycles, which means a stable raster routine and code counted to the cycle.

Colour RAM cannot be switched, so the colour for the 11 bit pair stays the same for all eight lines of a cell. Compute! put the result in an artist’s terms: “we can call up any of eight sets of two foreground colors and one unique background color per row”, which with the fixed colour RAM value “makes it possible to use all 16 available colors in each cell”. The newer editors it described also changed the background colour on every line, from a 256-byte table saved with the picture.

The stripe down the left

FLI leaves a mark on every picture. Because the badline is created on cycle 14, the chip is late taking the bus, and Bauer explains that its first three screen-memory reads on each line “do not read valid data”. It reads $FF instead, and for colour RAM the low four bits of the instruction that follows the $D011 write. The result is a stripe 24 pixels wide, three character cells, down the left of the screen, in which the 01 and 10 bit pairs both show light grey.

In multicolour pixels that is 12 columns, and that is how Compute!’s artists counted it: “the first 12 columns (3 cells) on the left side of the screen must be left blank, usually by setting them to the background color”. Pitts suggested balancing the gap with “an equally sized right border”. Chris Tucker, whose FLI picture illustrated the article, trimmed and re-centred his image so that the columns the editor lost on the left were matched on the right.

What it costs

Memory. Eight screens of 1K each, on top of the 8K bitmap and colour RAM. Compute! gave the file size of an FLI picture as 69 disk blocks, against 40 for an ordinary multicolour picture, and noted that compression could shrink one “to as little as 10 blocks”.
Processor time. Every line of the picture is a badline, and on a badline the VIC-II stops the processor for 40 to 43 of the line’s 63 cycles (on a PAL machine). What is left of each line goes on the two register writes and the timing around them, so while an FLI picture is being drawn the processor can do almost nothing else.
Timing between machines. Compute! warned that in most editors “set up for NTSC (American) systems, the top and bottom horizontal rows may be unusable”, and that editors said to allow more colours in the left-hand columns were “only available in a European PAL version”.
Tools. In January 1992 there were “no full-blown FLI drawing programs”, because the screen switch had to happen on time whatever the editor was doing: “This means no program features like fancy sprite pointers; plotted squares, circles, or other shapes; drop-down windows; and so on.” The magazine’s advice was to draw in an ordinary multicolour program such as KoalaPainter or OCP Advanced Art Studio, then finish the picture pixel by pixel in one of the public domain FLI editors.

Who did it first

Public lists of C64 “world firsts” credit two people, both in 1989. Solomon of the group Beyond Force used FLI in January 1989 as a moving colour effect, and ASP of Black Mail showed the first FLI picture in July 1989; the list adds that Solomon “laid the groundworks for FLI with the colours only and not the bitmap itself”. The list does not name the productions, but the dates match two demos in the CSDb release database: Beyond Force’s Charlatan (January 1989) and So-Phisticated III (15 July 1989), which Black Mail made with two other groups. These lists were compiled long afterwards by the scene itself and invite corrections. Both groups were back in 1992, when ZZAP!64 named Black Mail and Beyond Force among the groups making “a comeback with some awesome demos”.

Variations

FLI became a family. Bauer names two variants: AFLI, “Advanced FLI”, which uses the high-resolution bitmap mode and “simulates color blends by similarly colored adjacent pixels”, and IFLI, “Interlaced FLI”, which “alternates between two frames in a sort of interlace mode”. ZZAP!64’s glossary of scene slang in November 1992 defined FLI for its readers as “a graphic mode enabling the use of all 16 colours (instead of the usual three) within one character in low-resolution”, and grouped HI-FLI and AFLI as its high-resolution relatives.

Sources

Christian Bauer, The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64 (1996): section 3.5 (the badline condition and the 40–43 cycle stall), section 3.14.3 (FLI: forced badlines, eight video matrices switched with $D018, the cycle-14 rule, the 24-pixel stripe, AFLI and IFLI), section 3.14.6 (what the chip reads in the first three cycles: $FF and the low four bits of the next opcode).
Bill Pitts, “Flying Colors”, Compute! issue 137, January 1992, Gazette section, pp. G-6–G-10, with Chris Tucker’s sidebar “An Artist’s Explanation”: the name, European origin, eight video matrices, colours per cell, per-line background colours, the blank 12 columns, 69-block files, NTSC limits and the state of FLI editors.
ZZAP!64 issue 90, November 1992, public domain column: the “scene slang” definition of FLI, HI-FLI and AFLI; Black Mail and Beyond Force.
“World firsts and records”, Recollection (web, secondary; based on the Codebase64 world-firsts list): Solomon/Beyond Force, January 1989; ASP/Black Mail, July 1989. https://www.atlantis-prophecy.org/recollection/?load=world_of_demos
CSDb release entries for Charlatan (Beyond Force, January 1989) and So-Phisticated III (15 July 1989) (web, secondary). https://csdb.dk/