VFLI mod(?) for C64

[eslapion]

I'm still dreaming of a VFLI mod for the C64...

(mod: topic deviation split off from the thread "Introducing VFLI for VIC-20: 208x256 pixels in 16 colours!" in the Hardware section)

[Mike]

I'm still dreaming of a VFLI mod for the C64...

Why exactly? FLI as such is possible on the C64 without any hardware modification, just by writing to $D011 at the right time on each raster.

VFLI as such is understood to be a contraction of "VIC-I FLI", with FLI meaning "Flexible Line Interpretation". Flexible in the sense, that VIC-II in the C64 is made to re-read (Edit:) the text RAM and the colour RAM information for a text line, which it normally only does once, in the first raster of a text line. This introduces an extra DMA and stops the CPU for most of the remaining raster time.

As the display routine for VFLI also needs to change the FLI bank on each raster, and additionally changes $900E (aux. colour) and $900F (background and border) as well and also needs to rewrite the character base register $9005 at least once, the CPU exclusively executes in the display routine for 256 of the 312 PAL rasters. In the upper and lower border though there's still CPU time left for the user program.


Added Edit: that's normally also only of use as the "text" RAM serves as colour source in the bitmapped modes of the C64 and its base address is changed on each raster. The colour RAM itself just returns the same data, so multi-colour FLI keeps the 8 row resolution for the %11 colour source. Notable exception being the HCB mode pioneered in "Edge of Disgrace", which does 4 raster high attributes for all three colour sources by rewriting the colour RAM data in-between.

[eslapion]

I'm still dreaming of a VFLI mod for the C64...

Why exactly? FLI as such is possible on the C64 without any hardware modification, just by writing to $D011 at the right time on each raster.

VFLI as such is understood to be a contraction of "VIC-I FLI", with FLI meaning "Flexible Line Interpretation". Flexible in the sense, that VIC-II in the C64 is made to re-read the colour RAM information for a text line, which it normally only does once, in the first raster of a text line. This introduces an extra DMA and stops the CPU for most of the remaining raster time.

As the display routine for VFLI also needs to change the FLI bank on each raster, and additionally changes $900E (aux. colour) and $900F (background and border) as well and also needs to rewrite the character base register $9005 at least once, the CPU exclusively executes in the display routine for 256 of the 312 PAL rasters. In the upper and lower border though there's still CPU time left for the user program.

Maybe I am missing something here...

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.

For this reason, on the VIC-20's VFLI, the CPU is charged with changing the selected bank which determines which color RAM bank is selected (through the user port) on each raster and this allow each character (group of 8x8 or 8x16 pixels) to have multiple different character colors for each specific scanline.

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 required for V2FLI on some scanlines (1 out of every 8 ), 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.

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.

Disable the counter during top and bottom border display and you can choose which bank the CPU can access to write the needed color data.

[Mike]

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.

[eslapion]

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.

1. Is there any benefits to having banked color RAM on a C64 ?

2. Is there any benefits to having a counter external to the CPU perform the bank switching ? (detecting the syncs necessary to get that counter performing is not incredibly difficult: https://www.digikey.ca/product-detail/e ... ND/2139048 )

[Mike]

1. Is there any benefits to having banked color RAM on a C64?

In text mode, you could have each 8x1 line of a character have its own foreground colour.

In bitmapped multicolour FLI, as I wrote, it would provide colour source %11 with the 1 pixel height attribute resolution, instead of only 8.

2. Is there any benefits to having a counter external to the CPU perform the bank switching? (detecting the syncs necessary to get that counter performing is not incredibly difficult: https://www.digikey.ca/product-detail/e ... ND/2139048)

Most probably not. Two reasons:

1. You still have to trigger DMA to have the VIC-II reload text and colour RAM data on each raster. This needs CPU activity regardless for writes to $D011 and doesn't leave enough cycles in the raster to do something else (like returning to the foreground user process in every raster). But the display routine surely can spare some 6 cycles to change the bank register in each raster.

2. Any external 'bank number generator' would need to be stopped in the top and bottom border if the foreground process is supposed to change the colour RAM contents of a given bank. With the CPU doing the job, there's no conflict - i.e. all changes to the bank register are localised in the display routine, which restores the original value upon exit (it runs in an interrupt) and the foreground process can handle the bank register as if it was uncommitted.