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

Modding and Technical Issues

Moderator: Moderators

User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Today, I converted another set of images. These should be well known to most Vista users, they're the 'Sample Images' in the 'Pictures' folder (download):

Here are four of them as a preview:

Image Image

Image Image

For those, who still haven't modded their VIC-20, a pure software solution allows to pan the images left-right in a window of roughly one-third horizontal width. I also included the previews above together with the other images as *.png's in the archive, 15 in total.

Most of them converted exceptionally well, only 'Garden' has extremely saturated red colours, which sadly bleeded out in the conversion.

The display routine has been updated to exit more cleanly, and now optionally loads SJLOAD to BLK5.

Cheers,

Michael
Last edited by Mike on Thu Feb 20, 2014 4:19 pm, edited 2 times in total.
matsondawson
The Most Noble Order of Denial
Posts: 343
Joined: Fri May 01, 2009 4:44 pm

Post by matsondawson »

All the images are dead in this thread, any possibility of a refresh?
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

matsondawson wrote:All the images are dead in this thread, any possibility of a refresh?
I've put the images and download links up again.

Greetings,

Michael

Edit: A meta-discussion about this mod is currently running here.
User avatar
darkatx
Vic 20 Afficionado
Posts: 471
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Post by darkatx »

I'm definitely got my mind on doing this...oh yeah - I REALLY WANT TO TRY THIS!
Learning all the time... :)
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Can you confirm that this display window fits neatly in your monitor without cropping the corners?

Code: Select all

POKE36864,2
POKE36865,20
POKE36866,24
POKE36867,52
I can then provide you with a display routine and converter for a VFLI mode with 192x208 pixels on NTSC (non-interlaced), on short notice.

As interlaced resolution, 168x384i is possible. This will however have to wait until beginning of next year as my NTSC VIC-20 is away at ~600 km distance. :)


(Incidentally, this is my 1729th post ...)
User avatar
darkatx
Vic 20 Afficionado
Posts: 471
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Post by darkatx »

Looks like its a bust...

Image

I was a bit concerned seeing as I am in NTSC land and all but I figured if I can get one whipped up - I could always tackle the software side later. And thanks again for the earlier help with the line drawing routine - been done for months now just been a bit slow to tackle the rotation matrix tables and etc...lack free time with a new job and all :roll:
Last edited by darkatx on Sat Dec 22, 2012 11:18 am, edited 2 times in total.
Learning all the time... :)
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

darkatx wrote:Looks like its a bust ...
There not much one could do about the number of columns, the leftmost one would have to go. The remainder could be shifted up 3/4 of a row to keep all rows, resulting in:

Code: Select all

POKE36864,4
POKE36865,17
POKE36866,23
POKE36867,52
for 184x208 pixels. Does this look better?
User avatar
darkatx
Vic 20 Afficionado
Posts: 471
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Post by darkatx »

here it is - looks good :)

Image
Learning all the time... :)
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

darkatx wrote:here it is - looks good :)

Image
O.K. then - the display routine is in the works. You can already warm up the soldering iron. :)
User avatar
tokra
Vic 20 Scientist
Posts: 1123
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

Mike wrote:Can you confirm that this display window fits neatly in your monitor without cropping the corners?

Code: Select all

POKE36864,2
POKE36865,20
POKE36866,24
POKE36867,52
I noticed these are the values I used for "Retina Display" which shows 192x416 interlaced. I came up with these values by using the horizontal and vertical height knobs to squeeze the picture as much as possible on my 1084 and then used the most centered values for the resolution.

I think from previous discussions it is clear that there is no "perfect" setting that works good on all displays. Each one seems to have a slightly different size, position or cut-off point at the borders. That is probably why Commodore included the thick borders in the first place to fit as much TV-sets as possible.

So, a "perfect" software solution would ask the user to set the screen paramters upon first install and then use these values the rest of the time.
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

tokra wrote:I noticed these are the values I used for "Retina Display" which shows 192x416 interlaced.
Well spotted. :)

I'm quite aware, that the settings I worked out with darkatx within two iterations might possibly again be cropped on the monitors of other users. The point however is to have a working NTSC VFLI mode available at all as soon as darkatx has conducted the mod.

The target resolution of 168x384i has a similar display window size as used by MINIGRAFIK and should work without any problem on most NTSC monitors.
User avatar
freshlamb
Vic 20 Dabbler
Posts: 76
Joined: Sun Apr 04, 2004 5:38 pm
Website: http://www.rufnoiz.com
Location: Prince Albert SK Can

Post by freshlamb »

QAPLA!! I have successfully wired up Mikes VFLI mod on an NTSC computer. Mike has also uploaded a NTSC version of the VFLI disk and tools. I wanted to document my progress, so I put up a quick web page here http://www.rufnoiz.com/Vic/vfli.html . I also collected Mikes instructions into a PDF and they are here: http://www.rufnoiz.com/Vic/VFLI.pdf . I hope to do some work with the new VFLI system but I imagine it will be later, when it gets cold here.

K
Last edited by freshlamb on Mon Dec 16, 2013 5:04 pm, edited 1 time in total.
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

freshlamb wrote:Mike has also uploaded a NTSC version of the VFLI disk and tools.
The archive can be downloaded here: vfli_ntsc_prototype.zip.

As I wrote earlier, the resolution of 184x208 pixels is intended as stop-gap measure until I find time to implement the 168x384i display routine.
Last edited by Mike on Thu Feb 20, 2014 4:19 pm, edited 1 time in total.
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Introducing VFLI for VIC-20: 208x256 pixels in 16 colour

Post by Mike »

One month ago, I had a short PM exchange with Richardc64 regarding an alternative approach to fill up BLK0. He also brought forward his concerns about the permanent character of the RAM expansion, to quote him, and my replies:
Richardc64 wrote:First, there can never be external 3K.
Mike wrote:That is only a 'problem' if the external 3K comes with some intended extra-function, like a banking scheme (which I've not yet seen thus far), or the possibility to write protect it. The latter is actually the case with FE3, which provides the SJLOAD floppy speeder in that address range, and write-protects it to guard it, well, against writes. With the internal BLK0 expansion that write protection doesn't work anymore, as the internal RAM expansion takes precedence. Nevertheless, the floppy speeder itself continues to work.
Richardc64 wrote:Second, and more significant, IMO, is the possibility of a program that requires an unexpanded Vic and is incompatible with the software method of limiting memory. I don't see any simple way to hardware disable internal 3K.
Mike wrote:Of course it is possible to write a program, which checks for RAM being present in $0400 .. $0FFF (but doesn't use it) and then maliciously decides not to run. I'd consider such cases 'broken by design'.

To date, I have not encountered any program which would even unintentionally fall over the extra RAM, when using the software method of limiting memory (say, with POKE642,16:POKE644,30:POKE648,30:SYS64818). For auto-starting cartridges, you couldn't software-limit the RAM anyway, but screen memory and colour RAM also sit at the same correct address, regardless of unexpanded or +3K expanded RAM.

Conversely, [there are] cartridges like 'Bug Crusher'[, which] *don't* work together with a +8K RAM expansion (using a multi-slot expander), because they still execute parts of the KERNAL reset which puts the screen at $1000, but they then expect it at $1E00. m(
That being said, I still have to see an example program which requires a +8K or bigger RAM expansion but doesn't anymore work, when the +3K RAM expansion is added to that. Or a program for unexpanded VIC-20, which trips over the extra +3K, when it has been blocked for BASIC use by the POKE/SYS statement above.
User avatar
Mike
Herr VC
Posts: 4832
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Introducing VFLI for VIC-20: 208x256 pixels in 16 colour

Post by Mike »

In another thread, Mike wrote:The VIC chip is not able to access *anything* at the expansion port. There's a timing barrier in-between, formed by three 74245 buffer chips. They're necessary, because the 6502 cannot tri-state its address bus.
In yet another thread, Vic20-Ian wrote:Ref earlier comments ref tristate:

While you are hacking the hardware, could the tristate buffers be removed by replacing 6502 with the Atari 6502 or the 6510?

"Tri-stating the buses
The 6510 and an Atari version of the 6502 can be tri-stated. 573s have an OC input that takes care of that. The 6510 and the Atari version go into tri-state mode the moment AEC/BE becomes (L). A 573 is active the moment OC is (L). This means an inverter is needed: IC07d.
The R/W has to be tri-stated as well: IC11c, a 125 buffer, takes care of this.
ID signal I123 takes care of enabling IC05, the 573 that outputs the data. IC06c, an OR gate, makes sure that IC05 is tri-stated as well during a tri-state demand from the outside world.

Supporting the 6510
The major difference with the 6502 is the 6-bits onboard I/O port. An added 6526 takes care of that. The 6526 may only be visible at the addresses $0000 and $0001. Two 688s, IC08 and IC09 take care of that. Signal I121 and OR gate IC06a take care of the fact whether the 6526 will be enabled at all or not.
When reading from $0000 or $0001, we must make sure that there is no conflict with IC04, the 573 that reads the data from the outside world. Inverter IC07c and OR gate IC06b take care of that."

http://www.baltissen.org/newhtm/ttl6502.htm
and
Vic20-Ian also wrote:"On the original 400/800 design, a series of tri-state buffers surround the 6502 and
do the job of 'detaching' the 6502.

To lower the chip count on the XL & XE lines, Atari developed a custom version of the 6502 which had the simple
tri-state buffers built-in."


If I understand the article correctly it may be that an Atari XL or XE has a Tristate capable 1.7MHz 6502.

Could this be dropped into the Vic and then remove the tri-state buffers to overcome your problem?

http://www.atarimax.com/freenet/freenet ... cle.php?38
Let's keep the discussion in the thread where it really belongs.

The 6502, together with the three 74245 buffers and a few other ICs in the select logic perform a function, which actually could be perceived similar to the capability of the 6510 to tri-state its address bus, so another bus master can address the memory.

However, all the additional hacks necessary to put a 6510 in place of the 6502 in the VIC-20 would presumably result in something quite resembling another well known computer, only it would be using VIA instead of CIAs (and at another address), would 'lack' the SID, and of course keep the VIC-I.

Anyway, what's the point in hacking around the mainboard, just so external memory could be read by VIC-I, if there's a straightforward solution? Namely, putting 8K RAM in place where it can be accessed by the VIC, instead of the 'original' 5K RAM, thus lifting a restriction on the mainboard which has been put into the design just by accident.

Actually, in the meantime I came up with an even simpler solution than what I described here 3 and a half years ago: it replaces the four 6116 2Kx8 SRAM chips with a single 6264 8Kx8 SRAM, and dispenses with UC4 and U13 alltogether - they are not anymore needed! That's the alternate solution, that RichardC64 also discussed with me over PM.

In the end it all boils down whether there is any interest by other people to keep the discussion up. If there's no live discussion, people shouldn't wonder when improvements ultimately are kept under the rug.
Post Reply