Introducing VFLI for VIC-20: 208x256 pixels in 16 colours!

[Mike]

How long does it take to load and display the picture?

The file size is 10499 bytes including the 2-byte load address, i.e. 42 blocks.

The files are loaded with the standard LOAD kernal vector call, in one piece. Without fast loader, this takes maybe half a minute. On my FE3 with SJLOAD, only 3-4 seconds.

[Ghislain]

Impressive. I remember soldering being my least favorite part of my classes in college (I burned myself many many times). I haven't touched a soldering iron in years, I think I would fry my VIC-20 if I dared to try this. I was all thumbs with even a dummy breadboard. I can't imagine even desoldering chips from a real Commodore board.

I have a silly question though.

Why is normal 3K cartridge memory expansion from 0400-0FFF inadequate for 208x256 VLFI mode?

(I'm certain that there's a valid technical reason of course)

As well, is this newly-modified VIC-20 backwards compatible?

[Ghislain]

Impressive. I remember soldering being my least favorite part of my classes in college (I burned myself many many times). I haven't touched a soldering iron in years, I think I would fry my VIC-20 if I dared to try this. I was all thumbs with even a dummy breadboard. I can't imagine even desoldering chips from a real Commodore board.

I have a silly question though.

Why is normal 3K cartridge memory expansion from 0400-0FFF inadequate for 208x256 VLFI mode?

(I'm certain that there's a valid technical reason of course)

As well, is this newly-modified VIC-20 backwards compatible?

I guess the most obvious answer must be that the VIC chip (or the internal VIC-20 hardware that communicates with it) differentiates between internal "natural" ram and external "cartridge" ram? I never tested this myself. I always assumed that the VIC-20 graphics chips were able to "see" whatever was in memory locations 0000-1FFF.

I think it would have been pretty cool if the VIC-20 always had 8K of internal RAM right from the get-go.

[Mike]

I guess the most obvious answer must be that the VIC chip (or the internal VIC-20 hardware that communicates with it) differentiates between internal "natural" ram and external "cartridge" ram?

Exactly.

As well, is this newly-modified VIC-20 backwards compatible?

It's still possible to temporarily 'unexpand' the VIC-20 by issuing 'POKE642,16:POKE644,30:POKE648,30:SYS64818'. When there is a game cartridge inserted, that method obviously is not applicable. Even though, screen and colour RAM are still at the same addresses like on an unexpanded VIC, so cartridges relying on fixed addresses in that range are still supposed to work.

The colour RAM banking takes four address bits from the userport. For the moment, this precludes the usage of the userport for RS232.

[Mike]

Here's '3k.prg' (download). Just load it ',8,1' to unexpand the VIC-20 - that should be a little easier than remembering the above incantation.

It's only 30 bytes in size, and I've put it in the root directory of my SD card.

[Kananga]

Is it possible to detect your expansion from software?
I thought about how to detect the 3K being accessible from the VIC, but that's perhaps a task for tlr.
I would adopt the vic GUI to use the extra 3K for video ram and offer 26 character blocks in addtion (for PAL), but I'd like to have no dedicated binary. Right now, all different configurations (RAM, PAL, NTSC) are covered by one binary.

[Mike]

Is it possible to detect your expansion from software?
I thought about how to detect the 3K being accessible from the VIC, but that's perhaps a task for tlr.

That should be possible by putting screen and char data into the range of $0400 of $0FFF (after the presence of the 3K itself has been established), these forming an easy to find signature string when read out over unconnected memory. An external 3K expansion would not be able to reproduce that string. Much the same method tlr uses in his 'timing.prg', indeed.

I would adopt the vic GUI to use the extra 3K for video ram and offer 26 character blocks in addition (for PAL), but I'd like to have no dedicated binary.

Me !

I'm also working on light-weight version of the graphics mode, where 208x256 without FLI (i.e. like MAXIGRAFIK, but now with ~100% available CPU for the user program) is realised with just 3 raster splits of NMI. In that case, vin could do a simple bitmap access from $0600 to $1FFF. I'll just have to check, if that method plays nice with disc access.

[Mike]

Here's a working prototype of the detection routine: (download). Besides the 3K expansion it also needs at least an external 8K expansion. Source is included. Since I couldn't test it on my unmodded VIC-20, it should also be interesting to run it on an unmodded VIC-20, to make sure it doesn't return false positives. Both PAL and NTSC are supported.

...

During that session, I also wrote 'max.prg' (download, load with ',8,1'), which moves screen memory down to $0400 and the BASIC start to $0601, providing up to 31231 BYTES FREE for BASIC with a +24K RAM expansion.

Cheers,

Michael

[Kananga]

Here's a working prototype of the detection routine: (download). Besides the 3K expansion it also needs at least an external 8K expansion. Source is included. Since I couldn't test it on my unmodded VIC-20, it should also be interesting to run it on an unmodded VIC-20, to make sure it doesn't return false positives. Both PAL and NTSC are supported.

Great, thanks! And here I was already trying to figure out how to do it... I will give it a try at the weekend. Too much work presently

[GreyGhost]

Heck Mike, why not move it down a little further ($0338) and grab the cassette buffer too.

[tokra]

Display memory can only be placed at $0200-byte steps, so $0338 is not possible. However you can gain a whopping 6 bytes, by placing the BASIC-start $05fa instead of $0600.

[GreyGhost]

Ah crap. I knew that. I was thinking about the 3k expansion and screen memory being where it is for unexpanded vic ($1e00)and moving basic up to $0338. My bad.

[Mike]

If you meant that, with no further external expansion (only the internal 8K after the mod, and no tape usage), this is of course a perfectly valid method to squeeze out a few extra bytes for BASIC programs. But then, this also works with a standard (external) 3K expansion: POKE641,56:POKE642,3:SYS64818 gives 6855 BYTES FREE.

The internal expansion however allows to combine the extra 3K in the range from $0400 to $0FFF with external RAM expansions in the blocks 1, 2 and 3 by moving the screen down to $0400. The internal 3K are accessible by the VIC chip, which is not the case with an external 3K expansion. In the latter case, the screen start address can only be moved down to $1000. That locks away the external 3K expansion for BASIC use when at least a RAM expansion in BLK1 is present.

[eslapion]

Its not such an easy mod but the results are stunning!

The ability (finally!) to have the 3K ram expansion area with the VIC's internal AND 8K BLK ram expasion areas all contiguous is just plain lovely.

Now, could we use such a mod to have interlaced display on the VIC as well? (double the vertical resolution)

Could you make a modded kernal that would automatically recognise all 3 memory areas to provide for a VIC with about 31k of BASIC ram?

[Mike]

Its not such an easy mod but the results are stunning!

The ability (finally!) to have the 3K ram expansion area with the VIC's internal AND 8K BLK ram expasion areas all contiguous is just plain lovely.

Now, could we use such a mod to have interlaced display on the VIC as well? (double the vertical resolution)

I remember there had been some controversy in the forum, as to whether interlace on the 6560 really works as expected.

In principle, that would require flipping two different screens every 1/60 second and properly discerning even and odd frames. If the latter point is not adhered to, even and odd lines in the picture are swapped, distorting the display.

The address generator would consist of two text screens at $0400 and $1200, pointing to the two different bitmaps, each one of them using half of remaining memory like this:

Code: Select all

$0400 .. $04D1 - text screen 1 for odd field
$04E0 .. $11FF - odd field bitmap
$1200 .. $12D1 - text screen 2 for even field
$12E0 .. $1FFF - even field bitmap

... which would yield a 168 x 320i resolution. This one can also be done as FLI variant.

Could you make a modded kernal that would automatically recognise all 3 memory areas to provide for a VIC with about 31k of BASIC ram?

If the kernal can savely assume, that internal RAM has been expanded, this just requires two changes in RAMTAS:

Code: Select all

.FDD2  A9 06     LDA #$06   ; had been LDA #$12
.FDD4  8D 82 02  STA $0282
.FDD7  A9 04     LDA #$04   ; had been LDA #$10 
.FDD9  8D 88 02  STA $0288

Without an external RAM expansion, screen memory remains at $1E00 and BASIC starts at $0400. Those four instructions shown above move down screen to $1000 and BASIC start to $1200 on an unpatched kernal - and the patch alters these addresses to $0400 and $0600, respectively.

OTOH, this could lead to increased incompatibility, as a lot of programs which require 8K or more depend on the BASIC start being at $1200 - so for me the solution with 'max.prg' seems to be an easier way to get the same result.