GoDot's graphics data never represent a common sense bitmap. Instead of this there's full color information for each and every of the 64,000 pixels of a 320x200 picture (16 possible colors each).
One bit of a common bitmap only can represent 2 colors (foreground - background, this is called hires mode). Tricking with hardware and resigning the full screen resolution, the C64 displays 4 colors per pixel by collecting every two bits (multicolor mode).
The C64 color memory is organized in that manner that every 64 bits in the shape of a square (one tile) form a color unit containing a maximum of 2 resp. 4 colors. The next tile may contain different colors. Thus a C64 treats colors rather like characters on its text screen, its graphics color capabilities seem to be waste-product of the text mode.
GoDot has none of these restrictions. Every single point holds one out of the 16 colors.
This seems to mean the need for more memory, that is 32,000 bytes (instead of 9,000 bytes in hires mode). What is more, the C64 can't actually display colors that stick close together (see above). If a tile contains too many colors, it merely takes the last found 2 or 4 of them to display. This will often lead to distinctly visible color defects, mostly manifesting as pointed angles. So, GoDot will analyse each color tile before displaying to avoid such defects, by optimally choosing the (2 or) 4 most repeated colors. This process to first compute a pixel and then display it is called rendering.
From the first, GoDot was scheduled as a universal tool to render all existing screen modes a C64 has: hires, multicolor, FLI (Flexible Line Interpretation), and even IFLI (Interlaced FLI). Beyond that some printer drivers to optimally print out the contents of the 4Bit memory had been considered. Therefore GoDot's color palette has a different structure. It orders the C64 colors according to their brightness. Advantage: Each color can be easily dithered for printout so that a color gradient recognizable remains a gradient even if printed. GoDot's palette is a gray scale palette.
The quite big advantage of the 4Bit format however is its depth of information of 16 possible bit-states per pixel (4 bits may be combined in 16 different ways). Every point on screen can thereby be manipulated at almost any rate. There are many more alternatives than just "on" and "off". The abundance of GoDot's image processing modules only got imaginable for this reason.
The picture data is located in the memory area from $4000 to $BCFF (32,000 bytes), in fact identically ordered like in a normal bitmap. That means that every 8 pixels appear side by side, and the next 8 one row below, summing up to 8x8 pixels, thus spanning a tile. It is followed by the next tile, and so forth. Each tile occupies 32 bytes.
Saved to disk GoDot has its own, packed format with an initiating sign. Loaders (in future) may execute different functions according to their sign. Each GoDot picture starts with the characters "GOD0" ($47, $4F, $44, $30), there's no load address. It is nonintermittently succeeded by the contents of the 4Bit memory. A sequence of identical bytes (more than three) will be packed by being substituted by a counter. So that a reading program recognizes a counter, and which byte to count, svr.4BitGoDot will replace the sequence by a flag byte ($AD), the counter, and the counted byte, whereby a zero counter is equivalent to 256 counted bytes. A sequence of 100 times the value 88 hence would be represented by $AD $64 $58. The last of all bytes in the picture file is $AD again. It won't be utilized however, and is just a 'signature' of GoDot.
Copyright © 1997, A. Dettke, Last Updated - 08/01/97