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

[tokra]

This will explain how the graphic mode used in the Yes VIC can-demo came about. Part 9 ended with the 208x256 hires (or 104x256 multicolor)-mode with 64 raster splits for background/border/auxiliary-color and 8x8 (or 4x8) color blocks, but I still had hope for realizing a mode with 256 splits to provide the three colors on each line.

However if you calculate the layout from Part 9 you will see there are 10 x 208 bytes placed in the zeropage that need to be updated, and 8 x 208 bytes from $1340-$167f, which means copying the graphics data alone takes up 10 x 208 x 5 + 8 x 208 x 6 = 20384 cycles. Each raster split takes another 12 cycles (updating $900e and $900f). So the mode with 64 splits takes 21152 cycles, not eving counting the switches in the character generator ($9005) and the JMPs into and out of the switching routines for easy addressability. A whole VIC20 PAL-picture only has 312 lines x 71 cycles = 22151 cycles. Using 256 splits with the same layout would come out to a neat 23456 cycles, too much to be displayed in one refresh of the picture.

So what was needed, was an even faster routine to update the picture in the 22152 cycles. The first idea where to get those cycles I got from the Andropolis-demo for the C128. The C128 has an MMU that can place the zeropage and stack anywhere in RAM. The Andropolis-demo uses this to always use zeropage and stack addressing when writing bytes leading to 20% speed-up because zeopage and stack addressing only takes 5 cycles instead of 6. The stack however can only be adressed fast with the PHA and PLA machine-language commands. It didn't occur to me to use these before, but since graphics-data is writting sequentially instead of using

Code: Select all

lda #$aa
sta $01ff
lda #$ab
sta $01fe

to set the byte at $01ff which takes up 12 bytes and 12 cycles, I can instead use

Code: Select all

lda #$aa
pha
lda #$ab
pha

which only uses 6 bytes and 10 cycles, not only being quicker but only half as large in memory. I only needed to make sure the stackpointer is set correctly at the start. This of course means the stack cannot be used for anything else, but that was true for the other graphic-modes that used the stack-memory as well. Also since the stack is being written from the top down, the graphics-data that is stored in the stack needs to be addressed differently, which is something that needs to be taken care of later when you want to set a pixel.

After some calculations, I noticed that I can use some of the area in the zeropage and stack twice to make maximum use of the fast-adressable areas. So graphic-data can use the 208 bytes from $00-$cf or $1ff-$130 (backwards) or $12f-$60 (backwards). This lead to the following layout:

Code: Select all

Line    Char    Memory
 0      0-25    $0000-$00cf     update $0187-$0130 (88 byte) line1c
 1      63-38   $0130-$01ff     update $012f-$0100 (48 byte) line4a, $0000-$002f (48 byte) line7a
 2      64-89   $0200-$02cf     update $0030-$005f (48 byte) line7b, $00ef-$00c0 (48 byte) line4c
 3      90-115  $02d0-$039f     update $00bf-$0060 (96 byte) line4d
 4      12-37   $0060-$012f     update $01ff-$01a8 (88 byte) line8a
 5      104-129 $1340-$140f     update $01a7-$0188 (32 byte) line8b, $0060-$009f (64 byte) line7c
 6      130-155 $1410-$14df     update $00a0-$00cf (48 byte) line7d, $00ff-$00f0 (16 byte) line11b
 7      0-25    $0000-$00cf     update $0187-$0130 (88 byte) line8c
 8      63-38   $0130-$01ff     update $012f-$0100 (48 byte) line11a, $0000-$002f (48 byte) line14a
 9      156-181 $14e0-$15af     update $0030-$005f (48 byte) line14b, $00ef-$00c0 (48 byte) line11c
10      182-207 $15b0-$167f     update $00bf-$0060 (96 byte) line11d
11      37-12   $0060-$012f     update $01ff-$01a8 (88 byte) line15a
12      80-105  $1680-$174f     update $01a7-$0188 (32 byte) line15b, $0060-$009f (64 byte) line14c
13      106-131 $1750-$181f     update $00a0-$00cf (48 byte) line14d, $00ff-$00f0 (16 byte) line18b
14      0-25    $0000-$00cf     update $0187-$0130 (88 byte) line15c
15      63-38   $0130-$01ff     update $012f-$0100 (48 byte) line18a, $0000-$002f (48 byte) line21a
16      132-157 $1820-$18ef     update $0030-$005f (48 byte) line21b, $00ef-$00c0 (48 byte) line18c
17      158-183 $18f0-$19bf     update $00bf-$0060 (96 byte) line18d
18      37-12   $0060-$012f     update $01ff-$01a8 (88 byte) line22a
19      184-209 $19c0-$1a8f     update $01a7-$0188 (32 byte) line22b, $0060-$009f (64 byte) line21c
20      210-235 $1a90-$1b5f     update $00a0-$00cf (48 byte) line21d, $00ff-$00f0 (16 byte) line25b
21      0-25    $0000-$00cf     update $0187-$0130 (88 byte) line22c
22      63-38   $0130-$01ff     update $012f-$0100 (48 byte) line25a, $0000-$002f (48 byte) line28a
23      108-133 $1b60-$1c2f     update $0030-$005f (48 byte) line28b, $00ef-$00c0 (48 byte) line25c
24      134-159 $1c30-$1cff     update $00bf-$0060 (96 byte) line25d
25      37-12   $0060-$012f     update $01ff-$01a8 (88 byte) line29a
26      160-185 $1d00-$1dcf     update $01a7-$0188 (32 byte) line29b, $0060-$009f (64 byte) line28c
27      186-211 $1dd0-$1e9f     update $00a0-$00cf (48 byte) line28d, $00ff-$00f0 (16 byte) line31b
28      0-25    $0000-$00cf     update $0187-$0130 (88 byte) line29c
29      63-38   $0130-$01ff     update $012f-$0100 (48 byte) line31a, $00ef-$00c0 (48 byte) line31c
30      212-237 $1ea0-$1f6f     update $00bf-$0060 (96 byte) line31d
31      37-12   $0060-$012f     update $01ff-$01a8 (88 byte) line1a
(32)                            update $01a7-$0188 (32 byte) line1b
(33)                            update $0000-$002f (48 byte) line0a, $0030-$005f (48 byte) line0b
(34)                            update $0060-$009f (64 byte) line0c, $00a0-$00cf (48 byte) line0d       
(35)                            update $00ff-$00f0 (16 byte) line4b
(36)            
(37)
(38)

This way 15 of the 32 lines are placed in the "fast" areas and the remaining seventeen nicely fit into the rest of the available ram visible to the VIC. Interestingly this mode leaves nearly 32 full rasterlines in the border free (about 2000 cycles). To make the raster-switches work I had to place them directly within the graphics-data filling loops, leading to a very complicated adressing routine later which takes up more than 2K in machine language and is about 50% slower than the one from MAXIGRAFIK. A small price to pay for the added features.

It took about a week of very long evenings to get this mode working in the first place and the addressing routine took about the same time after that as well.

Now the mode was finally working, but there still were no pictures for it. A friend of mine who knows more about image processing tried a few things, but the results were unsatisfactory, also he was busy finishing his own PC 4K demo for the Revision-party. In parallel I had some discussions with Mike about this mode and it's possibilities. Mike was also kind enough to make some amendments to his VFLI-converter to use on some new C128-graphic modes I came up with in March (thanks again!), however the new MFLI-mode (short for MAXIGRAFIK FLI) on the VIC was still without good demonstration pictures. Why this proved so difficult and how Mike quite brilliantly came through in the end he will hopefully tell you himself...

[Mike]

Indeed shortly after tokra came up with the FLI mode, the project effectively split into two branches.

I forsaw the possibilities of a hardware extension, which would make the memory shuffling unnecessary and give the CPU time for other effects. The aim being to combine the colour resolution of the 72x256 FLI mode (see Part 10 of the series) with the pixel resolution of MAXIGRAFIK (see Part 7). For the example images, I "just" needed to expand the converter from 72 to 208 pixels horizontally. There is still a display routine running, but the design of that routine surely was less time consuming than tokra's work on the software-only modes he designed in succession of MAXIGRAFIK. Of course the hardware mod also took time, roughly 10 hours, spanned over 4 evenings.

In the meantime though, tokra really optimized the software-only modes. Already when we could easily do the 8x8 attributes in 208x256 (see Part 9), I wrote to him that this really was the version of MAXIGRAFIK we should have published. Quickly thereafter the mode with 64 splits then, though it really looked to me more like a curiousity.

But then, tokra came up with splits of background/border and auxiliary colours on every raster! I immediately realised this was on par - regarding the colour resolution - with Pasi Ojala's 100x160 multicolour "FLI" mode. So one option was to 'simply' extend this converter to the new resolution. As it showed, Pasi's converter required a lot of finetuning for the input images. The results often either had blocky artifacts, or showed a *wild* colour soup.

The main issue for writing a good converter stems from the fact, that the global colour attributes each raster, and the foreground attributes each 8x8 pixel cell form a combinatorial problem for optimization:

Each raster line has, in principle, 2048 possible combinations of background, border, and auxiliary colours. If one sees them as most constrained resource, they need to be optimised first - for all 8 rasters of a "text" line!

However that brute-force method gets bogged down very quickly: 2048^8 = 309485009821345068724781056 combinations to try about are beyond the reach of any computer affordable for a private person today. Additionally, one would need to try out all 16 colours (8 hires + 8 multi-colour) for each cell (26 in a line) and do the actual quantization with error-distribution, but that factor dwarfs against 2048^8.

Pasi's converter instead took another approach: pre-quantizing the image to the VIC colours, and then applying statistics. The most used colour in each 4x8 multi-colour block, of the first 8 ones, is assigned the foreground, and then taken out of the statistics for each line. Then, for every line, the one of the 2048 combinations with the least total error is chosen, and then the line again is mapped to the then available colours. However, it is exactly this quantizing done two times, which leads to visible blocky artifacts. Another stumbling block was the distance function between two colours which really did not take well into account, that the human eye is more sensitive to differences in luminance (or the green channel), than hue or saturation (cf. red or blue channel).

I thawed up my converter for the 208x256 VFLI mode and adapted it in two new versions for the VDC in the C128. As in VFLI, all attributes are chosen by brute-force with rather nice results.

Then in one mail I described to tokra a new idea which allowed a single pass quantization for his latest mode (translated):

Addendum, the second:

On Wed, 13 Apr 2011, Torsten Kracke wrote:

> This converting method would of course be rather messy, but possibly
> still better than all earlier Ideas... maybe else we'd would have to
> adapt Pasi's method.

Well, I just had a feasible idea, if you'd be satisfied with a resolution
of 104x256 in multi-colour:

- In each group of 8 rasters one proceeds as follows:
- for each character, take (without dithering!) the "dominant" colour as
foreground - this is the one, which has the least (weighted) squared error
to the 32 pixels.
- all 26 characters thus determined, one then assigns in each one of the 8
raster lines the three global colours, so the error over the line also gets
minimal - with integrated Floyd-Steinberg dithering applied to just this stage!

I'll try it out this weekend, let's see what results.

Greetings,

Michael

...

well, I had been that much under tension that I finished the new converter already at Wednesday evening.

[Mike]

I've posted the converter for MFLI images in the 'Emulation & Cross-development' section. It does the PC based side of the conversion. Two resulting files, 'bitmap.prg' and 'colour.prg' are then imported with a tool running on the VIC-20.

Greetings,

Michael

[tokra]

Here's a little tutorial how to use the converter and the VIC-20 to create the executable image-files as used in the "Yes VIC can"-demo. First of course you will need a picture to convert. For example try http://www.deviantart.com/ - lots of nice pics to be found there.

First you will probably need to create a 4:3 aspect ratio out of the image. If your pic is 900x600 fo example use your favorite image-processing tool to cut the picture to the correct ratio (in this case 800x600).

Once you have the correct aspect ratio you need to resize/resample the picture to exactly 104x256 resolution. Make sure to do this without aspect-ratio correction. As a result you will see a picture that will look very squashed horizontally. That's fine.

Next you need to save the picture in the Portable Pixmap Format (.ppm). Make sure to choose Binary encoding and Compression level 0 when saving as this is the only format Mike's converter uses. Also, you need to save the file under the filename: input.ppm

Just put this file into the same folder as the mfli_quant.exe and double-click on the .exe - you should see it processing the image in the DOS-window.

This will produce 3 files: result.ppm - a PC-representation of the conversion for quick checking and two files bitmap.prg and colour.prg. Copy these two files into the "basicextension"-directory of the unzipped "Yes VIC can"-archive. Now start VICE (or fire up your VIC-20) with at least 32K expansion, go into that directory and type:

Code: Select all

LOAD"MAXIFLI.PRG",8,1
SYS27467

This will initialize the full BASIC-extension in memory. Next type

Code: Select all

LOAD"MFLIVIEW-32K.PRG",8
RUN

This will load the two files into memory and after hitting the spacebar you can save the whole file together with the viewer. You can LOAD this file with only a 16K-expansion and start by SYS24171 to show the picture.

Have fun, and let's see some nice conversions, please!

[orion70]

Only imagine how the VIC impact on the competitors would have been if these graphics were ready in 1981...

[Jeff-20]

[tokra]

Nice pics, Orion! Can you post the files?

Here are some more pics to try out that didn't make the cut for the demo:

http://www.tokra.de/vic/yesviccan/mfli-pics.zip



Start each as usual with SYS24171 (16K RAM expansion at least)

[Boray]

Cool! Thanks!

[orion70]

I deleted them . Well, it was just a proof of concept to demonstrate the superior graphics of the VIC, and to say it's a pity these graphics were only potential back then...
Great screens, Tokra!

[Mike]

it was just a proof of concept to demonstrate the superior graphics of the VIC,

... not to forget what is possible with the VFLI mod: effectively twice the pixel resolution, and 8x1 instead of 8x8 colour cells.

and to say it's a pity these graphics were only potential back then ...

At that time, it was nearly impossible to obtain a screenful of true colour image data, let alone store it away or process it. These things had been a privilege of big mainframes. That computing power now sits comfortably on or below your desk.

Affordable graphics hardware was not able to faithfully display that data. Only since beginning of the 90'ies, true colour display hardware has been become widespread. Before that, one had to use quantizers to scale down the image data to a palette or even fixed-colour display.

This project here also shows, that single-person projects have their limits. Over the last year, Torsten and I put up new ideas to try out literally every week, lots of e-mails being sent to and fro. VFLI (hardware) and MFLI (software) are the result of one year dedicated effort, and we both want these developments put to good use by the community!

Michael

[Boray]

True. Would have been cool to send a couple of diskettes back in time though!

[Mike]

But then, we'd still be using VIC-20's ... wait ... we are still using VIC-20's.

[siccoyote]

I've been playing around with PPMtoVIC would also like to play with this but can't work out the command line I need ot put in to make it convert images.

could someone help please?

(mod: post moved to appropriate thread)

[Mike]

Could you please be more specific which of the converters for what mode you exactly have difficulties with?

As you mention Pasi's PPMtoVIC in passing, I presume you tried to convert an image into MFLI - mfli_quant doesn't take any parameters, but rather converts the file 'input.ppm' into the result files. Make sure your original image has a 4:3 screen format, from there first convert that image to 104x256 (in IrfanView, without 'keeping aspect ratio', the intermediary will look squashed, but that's o.k.) and name that temporary file 'input.ppm'.

To view the result, follow the other instructions in this thread here.

[siccoyote]

Well I was trying to use fli_quant.exe that was included in the nsfw demo.

Downloaded mfli_quant.exe from where you linked.
I was looking at the Vertical 1:2 ratio version.

But really whatever is the most up to date impressive version, for PAL.

I made a batch file with

mfli_quant.exe hm.ppm

but it didn't do anything