As BladeJunker already hinted at, the VIC-I allows for a wide range of different resolutions, so I found it appropiate to list some 'modes' which actually have been implemented and backed up even by editors and/or converters. In most cases there are no universally accepted abbreviations for these modes, so I made up some descriptive names:

* 'PETSCII text mode': normally 23 rows @ 22 characters, glyph data taken from character ROM.

This is the mode all VIC-20 users are familiar with. Two fonts are provided (switchable with SHIFT+CBM): upper case+graphics or lower+upper case. The VIC chip can be programmed to show another number of rows and columns, but the full screen editor can only handle the 22x23 layout.

* '64 UDG + non-inverse text mode':

This is a mode quite often used by BASIC programmers on the unexpanded or +3K RAM expanded VIC-20. It allows for 64 user defined characters (8x8 pixels high-res or 4x8 pixels multi-colour). In addition, the non-inverse characters (128 in total) from the character ROM are still accessible (by printing them in inverse video), so a lot of RAM is saved. Another 64 characters are lost, as their definitions would overlap with the standard 22x23 text screen.

* 'full 256 UDG text mode':

It is possible to redefine all 256 characters (again, 8x8 pixels high-res or 4x8 pixels multi-colour). This requires 2K RAM for the character definitions + any RAM required for the text screen within the overscan limits. This mode has been used to implement the editor display of MINIPAINT, for an example.

All the preceding modes might reuse character definitions (from RAM or ROM) at various places on the screen. That is what makes the distinction between text modes, and the following bitmap modes, regardless what exactly is displayed on screen:

* 'full 256 single-height UDG bitmap mode':

The text screen is set up so each character appears only once, and addresses an 8x8 pixels high-res or 4x8 pixels multi-colour tile from the 2K character definition. Effectively, the text screen implements an address generator, all changes to the graphics are then done by updating the bitmap data in the character definition. As there is a 1:1 correspondence between screen pixels and bits in memory, this is a bitmap mode.

Double-height UDG bitmap modes: The VIC chip can be programmed so characters aren't anymore 8x8 (high-res) or 4x8 (multi-colour) pixels, but rather 8x16 or 4x16 pixels. As a consequence, a character set can now span up to 4K. Only the built-in RAM (5K in total) is accessible by the VIC chip, though. Two variants are possible:

* '4K restricted VRAM double-height UDG bitmap mode':

Here, both 'text' screen (again serving as address generator) and character definitions (serving as bitmap data) reside in the upper 4K built-in RAM. As 17 bytes are required to display a tile (1 text byte + 16 bitmap data bytes), up to 240 tiles are possible (4096/17 ~= 240.9). One possible layout is 20x12 tiles, or 160x192 pixels. This is the resolution implemented by MINIPAINT and the MINIGRAFIK extension. This mode is highly compatible with the OS. It can also be used to host a soft 40-column text screen, with 4x8 pixel glyphs.

* '5K full VRAM double-height UDG bitmap mode':

The upper 4K are fully used for character definitions. Up to 256 tiles are usable. A 16x16 arrangement is only possible on PAL though, 128 pixels horizontal and 256 pixels vertical. Other resolutions not exceeding 256 tiles would include 136x240, 144x224, 152x208, 168x192, 184x176 and 200x160. Regardless the resolution, all of them require the 'text' screen to be placed at addresses $0000 or $0200 in the lower 1K RAM which normally is used by the OS. That precludes the use of these modes outside viewers or demos. 176x176 (also requiring more than 240 tiles) for example is implemented by Aleksi Eeben's Picasso editor.

...

Up to now, all these modes require neither interrupts nor dynamic updates of the bitmap data to function. Once set up, the CPU can access the bitmap data and/or the text screen as appropiate (even in the 5K bitmap mode, though interrupts should be disabled in that case). The background/exterior border and auxiliary colour are global to the whole screen, each character/tile has its own foreground colour and multi-colour enable bit. Background and auxiliary colour can be any one of the 16 available colours; border and foreground are restricted to the first 8 ones.

Characters/Tiles in high-res map: %0 to background, %1 to foreground.

Characters/Tiles in multi-colour map: %00 to background, %01 to the exterior border colour, %10 to foreground, %11 to auxiliary colour. Twice-wide pixels.

...

The following bitmap modes require interrupts and/or strong assistance by the main CPU to shuffle bitmap data around, synchronised to the raster beam. As this puts a heavy load on the CPU, in most cases the main program is halted during display.

* PAL 208x256 plain 'MAXIGRAFIK' bitmap:
Implemented with double-height characters, i.e. 26x16 tiles. Halts the main program, until SPACE is pressed. A BASIC extension is available. A corresponding (non-interlaced) NTSC mode (which would end up at a slightly smaller resolution, anyway) hasn't been implemented thus far, but see MIFLI below.

* PAL 208x256 MAXIGRAFIK FLI (in short: MFLI):
Implemented with single-height characters, i.e. 26x32 tiles. Much improved version of the preceding mode. In addition background/border and auxiliary colour are updated on each raster. A converter into a pure multi-colour display (i.e. 104x256 twice-wide pixels) is available. Stops the CPU as above.

* NTSC 168x384i MAXIGRAFIK INTERLACE FLI (in short: MIFLI):
Also implemented with single-height characters. Two different colour RAMs for the even and odd fields. Again, background/border and auxiliary colour are updated on each raster. A converter into a pure multi-colour display (i.e. 84x384 twice-wide pixels) is available. Stops the CPU as above.

* PAL 72x256 FULL FLI:
Much increased colour resolution with single pixel tall attribute cells. Background/border and auxiliary colour are updated on each raster. A converter into mixed high-res/multi-colour display (i.e. full 72x256 resolution) is available. Interoperable to the OS, leaves ~20% original CPU speed. An NTSC variant with 64 pixels width is possible, but not currently implemented.

* PAL 168x192 Flexible Char Bitmap (FCB):
Increased colour resolution with 8x4 (high-res) or 4x4 (multi-colour) attribute cells. Not only can background/border and auxiliary colour be changed on every raster, even in-line splits are allowed within certain limits. Implemented by Daniel Kahlin's fcbpaint. Currently outside the editor only a viewer is available. During display, the lower 1K are used, so this mode is not exactly OS friendly.

* NTSC 192x416i 'Retina Display' bitmap:
Compared to MIFLI, this mode dispenses with updates of the background/border/auxiliary colour registers on each raster, but it now allows for an increased resolution of 79872 pixels, which is even ~25% more than the C64 can display as standard hires bitmap. Implemented with single height characters, but shared colour RAM for both fields, i.e. 8x16 (high-res) or 4x16 (multi-colour) pixel attribute cells.

...

This is more or less a round up, what is possible to display with the unmodified VIC-20.

In an effort to combine the resolution of MAXIGRAFIK (208x256) with the colour resolution of FULL FLI (1 pixel tall attribute cells), I came up with:

* PAL 208x256 VIC-I FLI (VFLI): (requires a hardware mod to increase VRAM to 8K and colour RAM to 16K nibbles)
208x256 resolution, 8x1 (high-res) or 4x1 (multi-colour) attribute cells, freely mixable. Background/border and auxiliary colour updated on each raster, a converter for the full resolution is available. In-line splits possible but not currently implemented. Interoperable to the OS, leaves ~20% original CPU speed.

An NTSC variant is also possible (even interlaced), but also is not currently implemented. Would most probably come out at 168x384i as with MIFLI. With the hardware mod in place, the plain 'MAXIGRAFIK' display (without colour FLI) can be re-implemented by just using 2 NMIs per frame, thus requiring minimal CPU load, and is also OS compatible.

...

Updates of the colour registers on each raster or in-line splits are also possible with the 'standard' graphics modes in the first half of this post, which don't shuffle around bitmap data. I don't think though they require special names. One example for the raster-enhanced full 256 UDG text mode is implemented by PWP's brickshop editor (used in the 'Robotic Liberation' demo).

... that's quite a lot of resolutions IMO.


Edit: in the meantime, the software-only FLI mode was extended in width to 96 pixels. However, the 20% CPU time in the border is gone now, that mode again can only be used for still images.

Second, another overscan PAL mode has been created with a resolution of 224x280 pixels. This mode also dispenses with updates of the background/border/auxiliary colour registers on each raster (for the same reasons as Retina vs MIFLI on NTSC), but keeps 8x8 attributes.

Both new modes have been demonstrated with converted pictures in the demo 'Überflieger'.

Edit 2: For PAL, it was actually possible to eke out another 8 horizontal pixels in the software FLI mode, so there's now 104x256 available - actually half of what is possible with the hardware mod I wrote about earlier.

Also, finally a(n interlaced) NTSC FLI mode was made available at 88x400i pixels.

Both these two new modes are demonstrated with another set of converted pictures in the demo 'Flinale' (tokra and I do not expect we or someone else can excel at these modes, given a uniform bitmap and colour attributes )

These two palettes are very very different, though. Hasn't there been a consensus on which one is closer?

The palette in the Wikipedia article as from May 17, 2012 is definitely wrong. For me, it looks more like a copy of the C64 palette; with the greys replaced by the light versions of yellow, cyan and purple. Furthermore the outputs of a PAL and NTSC VIC-20 are different, this had been confirmed by a Denial member, who imported a NTSC VIC-20 to Germany and tested it against his PAL VIC-20 with a beamer that accepted both TV norms.

I am asking because the c64 is also notoriously difficult to get the exact palette values from, but they eventually sorta kinda almost did it if I remember correctly. Is the VIC-20 only perceptually tested on this issue? Can't the guts of the system give exact values somewhere?

The VIC chip outputs Chroma and Luma, not a RGB signal per se. Which colours are generated from these two signals is at the discretion of the receiving device in any case. Using a frame grabber instead of a CRT/digital camera combination would eliminate one unknown, but still something has to convert LC to RGB.

I know about Pepto's elaboration, but I'm not entirely convinced. For me, the middle-intensities in the Pepto palette appear too dark, and Brown has a greenish tint I couldn't observe on any combination of C64/C128 and CRT I had used.

...

@BladeJunker: Today, I pixeled your concept canvas of the SMB3 mockup (including all test tiles ) into MINIPAINT. Some elements had to be re-arranged horizontally (160 pixels horizontal resolution in MP instead of 176 pixels in the concept canvas). It took me roughly 2 hours:


(download)

Hi, BladeJunker,

Speaking of ANSI mode it doesn't appear to have any color restrictions as all colors can be displayed at once.

This is based on a color test program I came across on the Denial VIC-20 forum a guy named Mike made to test his S-video mod. Despite that not all combinations are supported in the 2 graphic modes you can see the ones that do in this chart.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5164

I wrote this program, so I thought I'd should comment on this a bit:

Regardless whether the VIC chip fetches pixel data from the built-in character ROM, or from user defined graphics in RAM, there's - in principle - only one background colour. The display is tiled in 8x8 or 8x16 'attribute cells' which can have one of 8 different foreground colours, and can be switched between high-res and multi-colour mode. The latter mode combines two bits horizontally to twice-wide pixels in either background (%00), exterior border (%01), foreground (%10) or auxiliary colour (%11) to form 4x8 or 4x16 pixel tiles. The exterior border colour can be chosen from the first 8 colours (like the foreground colour), while for the auxiliary colour all 16 colours are available (like for the background colour).

For the test program above, the different background colours in each line were achieved by changing the background register with the raster beam. This can be done by polling the raster line counter register and/or synchronizing a timer to the VIC chip. Thus, this is a software-assisted 'mode', even if it only displays pixel data from the character ROM.

Another restriction of the VIC chip is, that it only can access the character ROM, and the built-in RAM (5K)! 1K of the RAM is used for the system. In search for a bitmapped graphics mode, which does not use that 1K system area (but rather contents itself with the remaining other 4K RAM), and which also does not use interrupts, I came up with a 160x192 resolution. That one is built from 20x12 attribute cell tiles, each with 8x16 (high-res) or 4x16 (multi-colour) pixels, each one again with a different foreground colour. Background, exterior border and auxiliary colour are global.

I wrote a pixel-oriented editor for this resolution, MINIPAINT, which I published in 2009 on Denial VIC-20. It is hosted on the VIC-20 itself (runs fine under VICE) and produces picture files, that are actually executable programs. Furthermore, it is backed up by a BASIC extension, so the pictures can easily be loaded and used (and even changed!) in own programs. Saehn pixeled the title screen of 'Realms of Quest 3' with MINIPAINT.

With interrupts, cycle exact coding and the CPU shuffling bitmap data around in RAM the restrictions mentioned above can be lifted A LOT (say, 208x256 pixels resolution and/or 8x1 or 4x1 attribute cells), but these enhancements come at the expense of nearly monopolising the CPU to assist the VIC chip for display, so their use is limited to still images.

Greetings,

Michael

P.S.: This is my first post on wayofthepixel.net, so please bear with me.