AuthorTopic: Commodore VIC-20 Pixel Art Guide.  (Read 22772 times)

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #10 on: May 18, 2012, 10:44:50 pm
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.

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 ;))
« Last Edit: June 07, 2014, 03:42:45 pm by Mike72 »

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #11 on: June 04, 2012, 05:49:42 pm
Here's now a summary of available pixel editors hosted on the VIC-20.

Working with these editors ensures the restrictions are correctly enforced, as they run on the real iron. ;D

Of course some knowledge regarding use of the VIC-20 itself or its emulation in VICE and how to transfer programs and data (especially the pictures) to <-> from VIC-20, VICE, PC is necessary, but that's the case anyway if you're serious about it and team up with a coder to produce pixel art for a demo or game. :)

To save on screen estate, I resampled the pictures for the PAL 5:3 pixel aspect ratio, but kept their original height. Sorry for the resulting 'blur' effect. I've included links to the editors, the example pictures and instructions, which mode is used, and which memory expansion is necessary to run the editor:

* fcbpaint-0.5 (by Daniel Kahlin):

('doozy.prg' by Exin, fcbpaint.prg, instructions)
Uses PAL 168x192 Flexible-Char-Bitmap (FCB), +32K RAM expansion required.

* MINIPAINT 1.2 (by Michael Kircher):

('Realms of Quest 3' title screen by Saehn, MINIPAINT, instructions)
Uses PAL/NTSC 160x192 4K restricted VRAM double-height UDG bitmap mode, +16K RAM expansion required.

* Brickshop-0.8 (by Viznut/PWP):

(Brickshop (including ''), instructions)
Uses PAL 200x160 raster-enhanced full 256 UDG text mode, runs on unexpanded VIC-20.

* Picasso 1.2 (by Aleksi Eeben):

(Picasso (including 'Flower' picture by Mermaid), instructions)
Uses PAL 176x176 5K full VRAM double-height UDG bitmap mode, +3K or +8K RAM expansion required.

If any questions arise, don't hesitate to ask! :)
« Last Edit: October 30, 2019, 07:32:14 pm by Mike72 »