AFLI-specs v1.0 by written by D'Arc/Topaz for Chief/Padua on 28.6.1994 Advanged FLI is name I came up with during the time I coded the first version of AFLI editor. I have never claimed to be the one who discovered this new graphics mode for 64. I myself give the credit for COLORFUL/ORIGO but I am not sure if anyone did it before him (splits have been done but in my eyes they don't count). In AFLI we can get 120 colors in theory (counted like this 16!/(2!*14!)=120). When we put red and blue hires pixels close to each other we get a vision of purple - thanks the television. AFLI is just like FLI with $08-$0f (hires value) in $d016 and a couple of sprites over the first three marks. With $d018 we change the start of screen memory. And the good old $d011 for the main work. AFLI is the same as FLI but we don't use the $d800-$dc00 area for the third color. Actually we can't. In normal hires pictures the colors on the picture is ordered in a normal screen (normal text screen is on $0400+). The upper 4 bits is the color for bit 0 in picture bitmap and the lower 4 bits is the color for bit 1 in picture bitmap (or the other way...but let us think that was the right way). For example: a normal hires picture char (8x8 bits) 01234567 in hires picture where 01234567 0 ***** the first spot of the 0bgggggbb 1*** *** screen has a value of 1gggbgggb 2*** *** $68 (blue&green) the 2gggbgggb 3******* hires picture looks 3gggggggb 4*** *** like this ----> 4gggbgggb 5*** *** b=blue, g=green 5gggbgggb 6*** *** 6gggbgggb 7 7bbbbbbbb The bitmap is built just as in a hires picture bit 1 means the pixel is on and 0 that the pixel is off. In FLI we have built the screen to have badlines on every scanline of the screen. This gives us the possibility to change the screenmemory the picture uses on everyline. Now... when AFLI (and FLI) uses screen memory for colors and we change the screenmemory start on everyline, we can have new colors on everyline. The screens are usually ordered like this. screen memory used 0 $4000-$43ff 1 $4400-$47ff 2 $4800-$4bff 3 $4c00-$4fff 4 $5000-$53ff 5 $5400-$57ff 6 $5800-$5bff 7 $5c00-$5fff $6000-$7fff BITMAP (the actual picture data) The number of the screen is considered as the number of the line in 8x8 pixel area. An example... Here we have cut from the memory showing the first bytes in every screen. screen/rownumber 00 01 02 03 04 05 06 07 08 09 10 11 12 13 ... 39 $4000 ff ff ff 56 .. .. .. $4400 ff ff ff 67 .. .. $4800 ff ff ff 91 .. $4c00 ff ff ff b3 $5000 ff ff ff 54 $5400 ff ff ff 8f $5800 ff ff ff 54 $5c00 ff ff ff 10 Actually the $ff won't have to be there. It will come to the screen anyway. We have the same 'A' on the screen on the fourth mark ($6018- $601f). BITMAP AFLI PICTURE (number is the color number) 01234567 screenvalue 01234567 0 ***** $56 0 56666655 1=white, 0=black, 2=red ... 1*** *** $67 1 77767776 2*** *** $91 2 11191119 3******* $b3 3 33333333 4*** *** $54 4 44454445 5*** *** $8f 5 fff8fff8 6*** *** $54 6 44454445 7 $10 7 11111111 Now the 'A' surely has a lot of colors. When we code a FLI routine we know that we have succeeded when we get a 3 marks wide area filled with value $ff on the screen. In FLI the thing is easily taken away; we just fill the three first bytes of a line with empty bytes ($00). In AFLI the value $ff is a color. If we try to clear the three first marks, we still have the gray area. WHY? The $ff value comes to the screen.. so... the $ff is a color and the upper four bits of the byte is the color for empty pixels. We can not clear the first three marks to wipe the thing off. We have a new lovely problem: we have to put black (or whatever) sprites over that area. This is just timing. This may look very complicated and I think you will still be asking many questions from me - the text I have written surely ain't the best novel ever written. I'm great in jumping from a thing to another. -- Chief/Padua +44 (0) 757 706791 -------------------- My opinions are not my employers