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

[Mike]

I once had something similar in mind, using a controller to "inject" new register values (especially those four necessary for $9005, $900E, $900F and the colour RAM bank), as (Atari/Amiga-like) display list. That would allow to put a VFLI image on display with essentially zero overhead: For each displayed raster, one cycle to assert RDY, 3 wait cycles to allow the 6502 to finish up to 3 writes, and then the four register writes, while the 6502 idles. Timed so the register writes happen during HSync.

Could be implemented with two counters, one for the 71 or 65 cycles per line, the other one for the 312, 261 or 525 rasters per frame. At one time, it would be necessary to reset and start that counter pair, but that could be done with one of the established methods doing stable rasters.

Regarding the interrupt facility you brought into play: even when asserted at a given fixed horizontal position, the 6502 needs up to 7 cycles (8 for some illegals) to finish the current instruction, +3 if the IRQ happens during a taken branch (one that doesn't straddle the page boundary), so it's not stable. And you still have to do the housekeeping for all the CPU registers used in the vectored routines. For niceness, we assume the foreground process didn't do a SEI.

Is the 'faked' text screen data (using your approach of an address generator) going to provide any advantage beyond some saved memory?

[TLovskog]

I once had something similar in mind, using a controller to "inject" new register values (especially those four necessary for $9005, $900E, $900F and the colour RAM bank), as (Atari/Amiga-like) display list. That would allow to put a VFLI image on display with essentially zero overhead: For each displayed raster, one cycle to assert RDY, 3 wait cycles to allow the 6502 to finish up to 3 writes, and then the four register writes, while the 6502 idles. Timed so the register writes happen during HSync.

Interesting!

I suppose we then need to get control over the address buffers to keep the 6502 address high-z stated when we (during the 6502 part of the clock) adds $9004 etc and data to simulate register updates. Today it is directly tied to clock out from the 6560/61. The data buss is already under control through the 13 input NAND gate.

We also need to separate RDY and SO pin on the CPU since they share the same pull-up.

Devilishly intriguing.

[unebonnevie]

Can VFLI mode be done with RAM expansion board via the cartridge port, that is, without doing the hw modification you outlined?

[groepaz]

inspired by this thread i hacked a bit....

... now before i commit it, could you (mike) please confirm what i did:
- the VIC can "see" all RAM in $0000-$1fff range
- the colorram was extended from 1k to 16k
- colorram address bits 10-13 come from VIA1 PB bits 0-3 (userport pins C-F)
- every instance of the VIC or CPU accessing colorram uses the new address scheme
(and of course you need to enable ram in block 0 and block 1)

if you spot obvious mistakes please shout (does this count as the third VIC with this mod? =P)

edit: cleaned it up a bit and committed anyway (r30797) - please test
edit^2: use -vflimod to enable

[Mike]

[...] could you please confirm what i did:
- the VIC can "see" all RAM in $0000-$1fff range
- the colorram was extended from 1k to 16k
- colorram address bits 10-13 come from VIA1 PB bits 0-3 (userport pins C-F)

Check. Check. Check - when the DDR is set to input, those four bits should default to high, and thus select bank 15.

- every instance of the VIC or CPU accessing colorram uses the new address scheme
(and of course you need to enable ram in block 0 and block 1)

Check. And Check - however IMO -vflimod should force RAM for block 0 anyway. No point in having the VFLI mod without RAM in $0400..$0FFF. I didn't include an enable switch - if a program requires the original RAM setup on the real h/w, I run a small program to set the limits of BASIC for 3583 bytes free.

Block 1 isn't strictly necessary. It's just required for anything that needs RAM there, like of course those slide shows.

if you spot obvious mistakes please shout

No obvious mistakes, but possibly one other thing to be wary about: the VFLI mod needs to explicitly disable *external* +3K expansions of any kind - see reasons here. If those +3K come with extra functions, like banking or write-protect (on FE3), that doesn't work anymore on real h/w. Gives quite some cross-dependencies with all those cartridge simulations ...

In practice, it's for the moment only the write protect of the FE3 wedge which isn't anymore present. Also, on Mega-Cart, "unexpanded" doesn't mean anymore 3583 bytes free, but rather now 6655 bytes free, and I need to run the aforementioned utility to reduce it to 3583 with BASIC starting at $1001.

Just so one doesn't fall into a trap when he writes a program that requires both VFLI mod && (Mega-Cart || FE3 || UltiMem), and doesn't take into account, that the +3K don't anymore come from the cartridge, and thus don't anymore have the cartridge's extra functions.

...

Thanks!

[groepaz]

is there a simple way to test for this problem?

[joshuadenmark]

Parts ordered to do this mod, some from Germany and some from China, prepare for some possible stupid questions

[Mike]

There are no dumb questions ... ... any news?

[joshuadenmark]

The parts from germany and france has arrived, still waiting for the Chinaware

[Mike]

[...] still waiting for the Chinaware

In case the 16Kx4 SRAM is still missing, drop me a PM.

[joshuadenmark]

Thanks for your kind offer Mike

All components has arrived, but private circumstances are eating up my spare time (=retrofun). But my stuff are soon too be available and setup in my retro man cave

[Mike]

At this time of the year (download) ...



... it's best to sit in a warm lodge with all the cold snow outside.

... giving credit to the photographer, Christian Frumolt from Aalen, Germany. This is the Emerald Lodge, located in the Yoho National Park, Canada.

[Kakemoms]

Wow! Thats a really great picture.. maybe I need to modify one of my 5 Vic's..

[Mike]

Some time ago I could source a Sony PVM monitor, which has BNC inputs for composite and S-Video inputs for Luma/Chroma.

My VIC-20 is also equipped with an own variant of the S-Video mod, and I needed to 'extend' my monitor cable (DIN to 4x Cinch breakout adapter + AV cable) with yet another 2x Cinch to S-Video plug adapter. Before that, and with just an additional Cinch to BNC adapter on Luma, I was stuck with a B/W picture.

Here's the new cable:



And here's the backside of the monitor with the new adapter plugged in LINE A Y/C IN:



Now for a quick test - here we go: Let's bring colour to life!



Cheers,

Michael

[freshlamb]

For TL;DR: I built a VFLI vic in 2013. Thought it was broken in 2014. After sitting in a box for some time I decided I HAD to see why my VFLI Vic wasn't working. From many of the new threads on fixing Vics it seemed like a memory problem. Long story short, I removed the piggybacked 2K chips and checked my soldering and it looked good so I firmly re-inserted them. I just tried it and it worked! It has happened since then and I just have to firmly press the chips into the sockets. But the reason I am posting is more about this:

I know Mike has said this before but it is worth repeating.
For those who are hesitant to try this mod, once it is complete, your modded Vic will still run almost all software (and hardware) regularly. The exceptions are : hardware that uses the user port. It may not be compatible if it uses port B. Aside from that you may have to poke the Start of Basic vector to go back to your 3583 byte machine (poke642,16;sys58232) for unexpanded programs. Other than that it will work exactly the same! I just loaded the 3K version of Skyhawk (by Quicksilver) and it played fine.