Question about Commodore 64 FLI mode

[Synthpopalooza]

I've done a viewer/converter program on Atari XL that reads Commodore 64 standard multicolor pictures (in Koala Painter format) and converts them into ICE PCIN (Graphics 12+10) picture files. It's in this thread:

 

http://atariage.com/forums/topic/188370-doing-pictures-using-super-irg-2-and-other-ice-modes/page-7?do=findComment&comment=3033296

 

The next step, is to be able to convert .FLI files. Apparently this is a mode which allows anny of the 16 colors to be used per character cell, certainly no problem for the ICE PCIN mode which can do 35 colors per char. I did some research on codebase64.org and found this:

 

 

FLI Designer 2 (pc-ext: .fli) load address: $3ff0 - $83ee $3ff0 - $43d7 Color RAM $43f0 - $63d7 Screen RAMs $63f0 - $832f

Bitmap

 

I am assuming that the color ram and screen ram are like in Multicolor mode except that it's 8 bytes per character cell instead of the one that is in standard multicolor low res mode? Am I correct?

 

If anyone has any info on this mode and file format, I'd appreciate it.

[Rybags]

Some info http://codebase64.org/doku.php?id=base:vic#custom_graphics_modes

 

File storage format - no idea, it's up to the programmer but likely it's as "linear" as possible.

 

FLI generally forces the colour RAM fetch to occur every scanline which allows unique attributes per 8x1 or 4x1 pixels. In theory it could be done every 2nd, 3rd etc scanline if wanted.

 

The video matrix (text screen) is the colour memory for bitmap mode (both colours in hires, 2 of the 3 changable in multicolour), it cycles 0 thru 7 per scanline, repeating. The video matrix pointer is changed each time a badline is forced.

 

So, there is 8,000 bytes worth of bitmap and 8,000 bytes worth of video matrix (colour) and if multicolour also 1,000 nybbles worth of normal Vic colour values.

 

In theory the Vic colours could be packed since they're nybble values which could save 500 bytes.

 

Also there's the IFLI multicolour mode where 2 images are displayed - similar to HIP mode in that each scanline is shifted 1 pixel to the right, gives "perceived" 320 pixel resolution.

 

Also note there's the FLI bug where the first 3 (?) colour attributes aren't fetched properly so the colours are fixed. Some programmers overcome this by using sprites on the left of screen (which could complicate storage format even more)

[Synthpopalooza]

 

The video matrix (text screen) is the colour memory for bitmap mode (both colours in hires, 2 of the 3 changable in multicolour), it cycles 0 thru 7 per scanline, repeating. The video matrix pointer is changed each time a badline is forced.

 

So, there is 8,000 bytes worth of bitmap and 8,000 bytes worth of video matrix (colour) and if multicolour also 1,000 nybbles worth of normal Vic colour values.

 

OK. So would this be a correct assumption: Video matrix controls color bitpairs 00 and 01, the vic color map (1,000 nybbles) controls bitpair color 11? If so, I think I got it. I'd be working only with low-res multicolor FLI pictures at the moment, nothing interlace.

[Rybags]

http://codebase64.org/doku.php?id=base:built_in_screen_modes

 

In multicolour bitmap -

"00": Background color 0 ($d021)
"01": Color from bits 4-7 of screen mem

"10": Color from bits 0-3 of screen mem
"11": Color from bits 8-11 of color mem

[fox]

You can look at source code of http://recoil.sourceforge.net

Specifically, entry point for FLI format decoding is DecodeFli in recoil.ci.

[Synthpopalooza]

This is good news! Thanks for the info.

 

One other request: Anywhere I can get the source code for the kernal that displays Champions Interlace (.CIN) pictures? I am looking to hack it into doing a 15+10 interlace, which may help the converted Commodore pictures look a lot less flickery.

[fox]

Lepix from the creator of CIN. Edited July 22, 2014 by fox