eslapion wrote:Maybe I am missing something here...
Yes. Here:
AFAIK, the 40 bytes cache of the VIC-II alleviates the need to re-read the character code for each groupe of 8 scanlines but it obviously doesn't do that for character generator data as well as character color.
Exactly the change of $D011 at a certain position in the raster is what makes VIC-II
re-read the text and colour RAM. On purpose!
As I wrote, the text screen serves as colour source in the bitmapped modes and this gives the FLI mode its name, Flexible Line Interpretation. By changing the text RAM base on each raster, different data is returned as colour data.
The colour RAM is also re-read, but - as you correctly noticed - it returns the same data for all 8 rasters. Thus, with FLI on a multicolour bitmap, only sources %01 and %10 have 1 pixel high attributes, %11 remains at 8 pixel high attributes.
My understanding is that on the VIC-20, the VIC-I can display a number of horizontal characters (columns) and vertical characters (rows) that can vary greatly. On the C64 (VIC-II) your choices are much more limited. The visible area is from scanline 51 to 251 only, the rest is border color.
It's also possible on the VIC-II to display things in the border overscan area, by 'opening' the border and using sprites. But this isn't directly relevant to the FLI topic here.
While on the C64, you can have different text or graphic regions and switch them, the color RAM on the VIC-II remains a single 1kx4 SRAM IC providing a single nibble of information for each group of 8x8 pixels. While it is true that the CPU is stopped during the first scanline of each text line of text thereby preventing it from performing the bank switching operation on some scanlines (1 out of every 8),
... only for 40..43 cycles in said "badline" - provided all sprites are switched off. Sprites eat extra DMA in the left and right border.
the job could be performed by an external 4 bit counter detecting horizontal syncs since we know only scanlines 51 to 251 will carry displayable information which uses something other than border color. The CPU could be used to reset and trigger that counter when the raster register hits 50.
There should still be enough time in each raster (and note - full FLI introduces a badline in *each* raster) to reprogram a user-port register and also have a banked colour RAM return different values for each raster, giving 1 pixel high attributes for the %11 colour source with a multicolour bitmap. It's just no-one thus far has bothered to try this out.
...
I split off this topic deviation into the "Other Systems" section, as your posts don't specifically relate to VFLI as working on the VIC-20, but rather how the existing C64 FLI modes could be improved in one detail.