Visit Atarimax Store

Free-Net Logo
The Atari SIG Historical Archive
Created and hosted by:

Article #28 (51 is last):
From: aa700@cleveland.Freenet.Edu (Michael Current)
Newsgroups: freenet.sci.comp.atari.product.8bit.tricks
Subject: ColorView files
Reply-To: aa700@cleveland.Freenet.Edu (Michael Current)
Posted-By: xx004 (aa700 - Michael Current)
Date: Tue Mar 23 09:55:12 1993


               "The general way of viewing ColorView files."
                       By Bill Kendrick, NBS 1993.
ColorView files:
     ColorView mode is a 4096 color mode generated on the Atari Classic 
of computers.  It was created by Jeff Potter in a program called 
which is used in conjunction wit a GIF viewer called "APACView" (which 
originally used a different, 256 color screen mode created by him as 
It is done by viewing three 16 color screens "simultaneously."  These 16
color screens are in 80 x 192 resolution (not exactly high for today's
standards), and are simply part of the Atari's built-in graphics modes.
This 80 x 192 x 16 mode supports 16 shades of a specified color.  This
has come in handy with ColorView, because by using three screens, one
being red, the second green, and the third blue, the Atari simulates 4096
true colors.  (Another great advantage to ColorView modes was what it was
originally made for: viewing GIF files.  GIF files store their palettes'
colors as red/green/blue values, so a program that converts GIFs into 
View files only needs to know how to read the "RGB" palette and 
the image.)
     ColorView files are really made of three files.  (Actually, this is
really just the standard created by the inventor of ColorView, Jeff 
The three files all have the same filename (8 characters), and have
extenders of ".R", ".G", and ".B" (for "red", "green", and "blue.")
Now that you know how ColorViews are viewed and stored, all you need to
know is how to read in the intensity values from each file.  (These will
be 0 to 15 (16 shades of each color), so you have a total of 12-bits of
color on the screen, so if you're using a graphics mode on your system 
can't handle that much, you'll have to just drop some of the lower bits.
(The number of bits of color of just one of the screens alone is 2^4=16, 
a whole ColorView image uses (2^4)x(2^4)x(2^4)=4096, three sets of 4 
The closest one can get in an 8-bit color mode (which is more or less
"standard VGA") would be (2^8)=256 colors!  Converting a 4096 color value
to a 256 color value would mean dropping some bits.  One way someone can
overcome this is to use dithering by drawing the actual red, green, and 
pixels onto the screen! (not just drawing a pixel with the blended color)
In this case, you're only using three sets of 16-colors which is only 48, 
the palette size is greatly reduced, but the image quality is lower.  One 
the reasons I mentioned this is because compared to a normal (320 x 200 x 
VGA screen, ColorView (80 x 192 x 4096) has pixels 4 times as wide.
     Alright, now the format of the single files...  Each file is 
of an uncompressed 80 x 192 x 16 image, so each line is 40 bytes wide
(16 colors takes only 4 bits, or 1/2 a byte, so each byte represents >2<
pixels).  The actual byte size of the file is 40 x 192 = 7680 bytes.
     Let's look at it binarily:
76543210  <- bit positions.  The decimal values derived from these are
             really just 2^position, so the if only the leftmost bit was 
             the decimal value of that byte would be 128.  If the 
             bit only was on, it'd be 1.  If both the left and right were 
             it'd be 129, if all were on, it'd be 255, and if all were 
             it'd be 0!
10000000  <- 128
00000001  <- 1
10000001  <- 129
11111111  <- 255
00000000  <- 0
Now, remember, each byte represents >2< pixels, each having a value
(representing brightness) of 0 to 15.  The leftmost (high) 4 bits are the
left pixel, and the rightmost (low) 4 bits are the right pixel.
11111111  <- 255
1111      <- left    (these 4, being high, represent 240)
    1111  <- right   (these 4, being low, represent 15)
11001001  <-
1100      <- left    (these 4, being high, represent 192  (128 + 64))
    1001  <- right   (these 4, being low, represent 9 (8 + 1))
Well, we've just found out that the highest 4 bits are WAY too high.
Fortunately, all we need to do is divide the value by 16 to get the
brightness value (which will be 0-15)!!!
Simple.  Now, how does one go about splitting a byte up into two high/low
values?  Just use "binary AND" (what represents it all depends on what
language you're using).
"AND" the byte with "240" (all left bits on) to get the left bits all 
"AND" the byte with "15" (all right bits on) to get the right bits all
Simple example:
Open red file for read
Open green file for read
Open blue file for read
Set up screen (320 x 200 x 256 or more colors prefered)
Set up palette
Set X,Y coordinates to (0,0)
  Get next from red file
  Binary AND the red value with 240
  Divide it by 16
  Set the color to that intensity of red
  Plot at X,Y
  Binary AND the red value with 15
  Set the color to that intensity of red
  Plot at X+(one-80-column-pixel),Y
  Get next byte from green file
  Binary AND the green value with 240
  Divide it by 16
  Set the color to that intensity of green
  Plot at X,Y
  Binary AND the green value with 15
  Set the color to that intensity of green
  Plot at X+(one-80-column-pixel),Y
  Get next byte from blue file
  Binary AND the blue value with 240
  Divide it by 16
  Set the color to that intensity of blue
  Plot at X,Y
  Binary AND the blue value with 15
  Set the color to that intensity of blue
  Plot at X+(one-80-column-pixel),Y
  Increase X by two 80-column pixels (which would be "8" VGA pixels)
  If X is past the right edge of the screen Then:
    Set X to 0
    Increase Y by 1
Until you've read 7680 bytes
The end.  Need any help?  Contact Phbill.

         Michael Current, Cleveland Free-Net 8-bit Atari SIGOp
Carleton College, Northfield, MN, USA / UUCP: ...!umn-cs!ccnfld!currentm
      Internet: / Cleveland Free-Net: aa700

Visit Atarimax Store