** New Frontiers in VIC-Hires-Graphics, Part 16

[tokra]

Announcement/Download

The VIC-chip on the VIC-20 can only display graphics by redefining characters. With 256 different characters of 8x8 dimensions this would only allow for pictures of up to 16384 pixels, which is probably why the engineers provided the VIC with a so-called "double height character mode" which offers characters of 8x16 pixels and as such theoretically 32768 separate pixels.

As graphics are just redefined characters each 8x8 or 8x16 block can only have one foreground-color which is stored in the separate color-RAM. The background color is the same for the whole picture and as such called a global color. The VIC-20 offers a multicolor-mode with pixels twice as wide as well. This adds two more global colors, defined by the border-color and an auxiliary color.

The FLI-modes of this little demo are lifting these restrictions of the VIC-chip by having the CPU aid in the display of the picture. In each rasterline the three global colors as well as the color-RAM can now be set freely, meaning you now have a forground color with an 8x1 resolution compared to 8x8 or 8x16 and can set the three other colors per rasterline instead of per picture. The size of the area that can be displayed this way is only restricted by the combined memory bandwith of the CPU and VIC-chip.

For PAL I already demonstrated a FLI-mode of 96x256 with last year's release of "Uberflieger". Soon after I had an idea to increase the horizontal resolution of that graphics-mode by another 8 pixels, leading to a 104x256 FLI-mode. How this was accomplished is explained in:

** New Frontiers in VIC-Hires-Graphics, Part 15

I postponed the release of that mode however since I was planning to use the knowledge I gained for a NTSC-Interlace-FLI-mode, that has been lingering in the back of my head for some time. Earlier this year and with the help of SvOlli's "Fridgegrid"-program I managed to lay out how this mode would fit in the available raster-time and after that the question remained whether it would fit into the available memory of an expanded VIC. Luckily in the end everything fit within a 32K expansion nicely and the mode of 88x400 interlace was born.

To be able to really enjoy this mode I strongly suggest an S-Video modification on your VIC: S-Video mod

The NTSC-mode will not work in the VICE-emulator, since it does not emulate the interlace-feature of the VIC.

Mike provided converters for both the PAL- and NTSC-modes again. Both modes have an aspect ratio of 2:3. You will need to convert your pictures without aspect ratio correction to 104x256 for PAL or 88x400 for NTSC, respectively and save them as input.ppm. The converter will create files which will need to be post-processed on the VIC-emulation in VICE. Just drop the "boot"-file from the appropriate "converters"-directory into VICE. The resulting file will be the executable image. For NTSC the file with the -emu extension will give a glimpse on VICE of what the result will look like, but the picture will just have 200 flickering lines instead of the full 400.

[metalfoot76]

This is amazing. Just curious if it's possible to somehow test for a keypress or something to break out of the picture display and load another picture? (Thinking in terms of making a slideshow on VIC). If there's not enough memory or remaining cycles, I totally understand! And I don't know the first thing about ML coding, so I don't think I could do it.

[Mike]

metalfoot76,

Just curious if it's possible to somehow test for a keypress or something to break out of the picture display and load another picture?

The demo of this new screen mode actually *is* a slide show and advances to the next picture by pressing the SPACE bar ...

[metalfoot76]

OK. Sorry, but I hadn't actually looked at the demo disk, just played with the converter itself! Thanks. Sorry about being stupid! Now I see how it works.

[tokra]

Small bugfix-release for the PAL-mode. I updated the original package on my server Please re-download, the viewer mistakenly set a byte in video-RAM to $c5 instead of $c6 as such 32 pixels are wrong in each picture. The new package fixes this. I also re-converted the 7 demo-pictures to use the fixed viewer, although the change is barely noticeable. Thanks to Mike for finding this!

Regarding the NTSC-version: Did anyone else try this on their real machine? Would love to get some feedback on how it works/looks in NTSC-land.

[darkatx]

Oh man, sorry for dropping the ball and not checking up on this thread sooner. I was so impressed by the original posting that I finally went through all 15 previous threads (ahem - during work hours ) and finally realized what you guys were doing to pull this off.

On a side note, I read Marko's interrupt tutorial and understood it after several reads but didn't have the nerve (nor the time) to try it out.

I will get onto converting this old school and checking out the results on my machine here in NTSC land.

[darkatx]

As promised I dusted off the old tools using my old 486 and Star Commander (I know, I know I really oughta update my gear) and took a bit of tinkering due to having bad 3 1/2 floppies.

Finally got the demo going and Lo and Behold, it was superb!



Some nice pics off of the slideshow...there's some really nice pics on the slideshow I left off
Definitely, worth the effort running it on real hardware.

Well done gentlemen

[Mike]

Here are two other images I converted to 104x256 Wide FLI (PAL, +24K RAM required) some time ago:


(download)


(download)

Anyone got an idea for which game the bottom picture could usefully serve as intro screen?

Greetings,

Michael

[orion70]

If these were the real graphics of the game, it would have sold way more, and wouldn't have become the Holy Grail of VIC collectors

[Mike]

... Holy Grail ...

Yes, the in-game graphic would have needed to hold up at least somewhat against both box art and (newly supposed) intro screen. The PETSCII graphics it only got are really a disappointment ...

[Noizer]

Very impressive! The only disturbing factor in my opinion are the colored bars on the sides of the picture. Can't they be covered up / hidden?
BR

[orion70]

If you read them with a barcode scanner, they say VIC TWENTY IS THE BEST

[tokra]

Very impressive! The only disturbing factor in my opinion are the colored bars on the sides of the picture. Can't they be covered up / hidden?

This mode is using pretty much every trick in the book to provide 104 pixel-wide FLI. The bars are either the border-color (which is a multicolor-color) or the background-color for 3 char-wide block to the left of the picture. There is no way to cover up or hide those without sacrificing the display-mode itself completely and then it becomes pointless.

In a game which uses raster-split-effect you can cover those up with chars usually or with another type of raster-color. But again, this is a trade-off.

For the Vic McKracken-picture, which I pixelled in FCBPaint I took care to return the border-color to black at the right side of the screen to make the picture look good. In the working-stages you can still see the color-splits going into the border. See the live-showing at Revision 2017

[Mike]

Very impressive! The only disturbing factor in my opinion are the colored bars on the sides of the picture. Can't they be covered up / hidden?

To rephrase and extend a bit upon tokra's answer: with the VIC-I, the exterior border colour doubles as one of the palette colours for multi colour attribute cells. That means, in a multi colour attribute cell - with bit 3 (value: 8) set in the corresponding colour RAM cell -, the bit combination %01 appears in the same physical colour as does the exterior border.

The 104x256 Wide FLI mode changes the corresponding VIC register contents (the lowest 3 bits of $900F) in each raster line, along with the other two 'global' colours, namely the background and auxiliary colour, to improve upon the colour resolution within the display window. In doing so, we accept the resulting colour stripes in the border as negligible side effect.


The only two conceivable ways to improve upon this disallow themselves for the following reasons:

1. Change back the register value of the exterior border colour to one common colour which then is the defined exterior border colour:

There are no cycles left in the display routine to do this. All the available cycles are used to make the necessary updates of colour RAM (to provide the 8x1 pixel attribute cells), changes of the global colour registers (as explained above), changes of the colour RAM base (either $9400 or $9600) which is also necessary for the colour RAM update to work, and finally, changes of the display width between 13 and 16 characters, which open up a 'reserve' of extra colour RAM data. The latter action is what allowed the FLI mode to expand from 96 to 104 pixels width.

If there had been the necessary cycles left to make the additional change of the exterior border colour, we'd probably have used them instead to add another 8 pixels width to the display window.

Also, even if we had actually decided to make that change of the exterior border colour regardless - the hardware of the VIC pixel serializer would make this somewhat imperfect: as it happens, changes of colour register values do not take effect exactly at (half-)character boundaries! Rather, they appear one hires pixel late. You would either still see the picture's border colour definition for 1 pixel within the exterior border at the right edge of the display window (and 'lose' one hires pixel of any border and background(!) coloured colour pixel at the left edge when you change to the picture's $900F definition of the next raster), or - if done one CPU cycle earlier - lose 3(!) hires pixels of border and background colour pixel to the redefinition of $900F at the right edge of the display window (and correspondingly, have a 3 hires pixels thick stripe of border colour changes to the left edge of the display window).

(aside: you find an example of the aforementioned technique, with the noted 'delayed colour change' caveat, in the thread 'VIC 20 in Black and White mode', where it provides yellow as exterior border colour and redefines this colour source to be black within the display window.)

2. Use an overscan display window and cover the colour register changes to the left and right of the original display window with a completely filled character in a common foreground colour:

That overscan display window would need to be at least 28 characters wide (on PAL), because that is the maximum width of the display window the VIC-I chip can put to display.

Unfortunately, any extension of the display window is at odds with the internal RAM remaining for the bitmap! It would be necessary to reduce the height of the display window, from 256 pixels to some lower value. The amount of that reduction might be minimized when some of the extra CPU time gained - remember, rasters without display window do not need the running VIC register and colour RAM updates! - is used to shuffle bitmap data from expansion RAM instead; exactly as we do in the other modes shown in the other parts of the "VIC Hires Series" which focus more on pixel resolution and less on colour resolution.

(aside: you find an example of the aforementioned technique in the thread 'REALMS OF QUEST V', where it provides an independent value of $900F within the top-left (bitmap) display window. Two character columns to the left and right of that window are used to cover the colour register changes exactly as in the way described.)

A reduction of the display resolution for this reason however was not a route tokra and I were willing to take. We wanted a given colour resolution (FLI with updated background/'border'/auxiliary colour on each raster and 1 pixel height colour RAM attributes), at the maximum attainable display resolution - here: 104x256 pixels.


In doing so, we regard the behaviour outside the actual display window as unavoidable but acceptable side effect.

[Mike]

This display mode got some coverage in Twitter lately:

https://twitter.com/shieladixon/status/ ... 4882861057

What sorcery is this?? The Flinale demo running on #Vic20 #realhardware