> > not to mention a mode i came up with recently, called LFLI, which in
> > addition to koala and FLI uses pixels and colors in four layers and
> > several nasty hardware tricks to create hires close-to-truecolor
> > images on the C64
> How do you do that? I mean, the palette is (officialy) only 16 colors? :-)
“ColorView” mode on the Atari 8-bit is a software-driven graphics mode
which can display 4096 colors (in a hideously low resolution of 80x192),
64 colors (160x192) or 8 colors (320x192).
All it does is flip between three ‘normal’ modes (80x192x16 grey,
160x192x4 paletted, with grey colors, or 320x192x2, with black/white).
Flipping sounds atrocious, thanks to Display List Interrupts (similar to
Copper on Amiga), the screen doesn’t flip between red, green, and blue
images all at once. Thanks to DLIs, it can change the palette (as
well as the ‘where to get the bitmap data from in RAM’ pointer) on each
and every line.
Frame 1: Frame 2: Frame 3: Frame 4: …
Red Green Blue Red
Green Blue Red Green
Blue Red Green Blue
Red Green Blue Red
… … … …
So, while not a perfectly static image, thanks to persistence of vision
in the human eye (and the residual glow of TV/monitor phosphors), the
image looks pretty good. The only noticable flickering is usually a kind
of ‘upwards shimmer’ of the pure colors (pure red, green, or blue…
where the pixel is black 2/3rd of the time)
The idea for this came based on a mode which combined two built-in
displays, 80x192x16 grey, and 80x192x16 hue. (Neither palettized.)
When you interlaced or flickered between them, you could simulate
256 colors. (A slightly desaturated display of the actual 256 colors
which were possible on the Atari, but not anywhere… this mode was
aptly called “APAC: Any Point, Any Color” )
Newer modes some folks have come up with produce more greys, or
’high resolution’ greyscale (eg, perceived 320x192x16 or 32 shades),
or do other tricks to add more coloring to hi- and med-rez (HIP and RIP
Again, all software based, and works on any Atari with a “GTIA” graphics
chip (all of them except Atari 400s and the earlier Atari 800s)
> Yeah, I know. The good old days, with fun hardware and concistent CPU
> speed. :-)
As off-topic as this is getting, this kind of stuff might actually
be useful to people trying to do software-driven graphics tricks to
simulate higher resolution or more colors.
And since we’ve been talking about low-palette SDL stuff (eg, for PDAs
and other small devices), I’m thinking this isn’t QUITE as off-topic
as it seems… all of this C=64, Amiga and Atari 8-bit reminiscing.
> Sure, it can be dealt with, but I can't see a way to do it without
> breaking all existing code that deals with the PixelFormat struct. At the
> very least, existing code will crash if it sees surface in one of the new
Maybe a kludge would be to store the bitmap as 8bpp internally, but
then convert on display. Or did someone already suggest that?
Maybe we need a new API! D’oh!
-bill!On Thu, Oct 18, 2001 at 06:37:09PM +0200, David Olofson wrote: