I marked off the colors that are completely unviewable and stripped it
down to 68 colors that either appear solid (there are a handful of
those actually) or only have a slight amount of flicker.  I have a gif
of the simulated palette made with photoshop, as well as a photoshop
rgb color index file.  I also have made a spreadsheet documenting which
index colors go where in the simulated color grid, which means that it
should eventually be possible to convert images using this palette in
photoshop and then (most likely) passing the converted image in to a
java program to process as a series of two double-hires images that are
alternated to produce a pseudo 68-color image.

I have also updated the apple program to black out the unviewable
"colors" and have checked it using a //c on a regular TV.  There is a
little noticable flicker, but it is a lot easier to look at than when I
started.   Maybe it's because I've stayed up way too late working on it
and my eyes are playing tricks on me.  But that was also the same kooky
frame of mind I was in when I loaded up moon patrol the first time from
a serial cable, so who knows what will come of this crazy
experimentation?  More to follow soon (after I do this whole sleeping
ritual and such).

With PAL its only 25 hz - and believe me: It flickers like hell,
especially with bright colors.

Because of this I never used similar trickery with the 8 bit Ataris to
display 256 "real" colors or the interlaced modes of the Amiga with
twice the vertical resolution.

However, you may get much better results with a TV set that is capable
of displaying a NTSC or PAL picture at twice the normal frequency (120
/ 100 hz) or a modern LCD or plasma TV set.

Several scientific instruments and measurement techniques are based on
alternating between two different images at a "flicker" rate, so that
the eye will be drawn to differences.  For example, planets, asteroids,
and comets used to be found this way--and many still are, after computer
culling.

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

It's something to think about, anyway.

And which is why I prefer the II(e/c) platform for non-GS-software over
the GS or an emulator. Though I hope that the latter will someday
incorporate a more realistic composite simulation.

Some colors when alternated actually produce a black-and-white
checkerboard pattern.  So the dithering technique has a very limited
amount of appeal.  However, you can "sort of" get a good color
dithering conversion using photoshop to scale down the palette of an
image to the apple's 16-color palette and play with the diffusion
controls until you're happy with it.

Unlike the other systems you mention (which generate a true chroma
subcarrier), *all* color on the Apple is NTSC artifact color.  There
*is* no other native color.  And virtually all Apple graphics were
designed to be viewed as NTSC color images, so the "color bleed" you
talk about was an *intended effect* in most of those images.

(BTW, the reason everyone designed for NTSC color is that other ways
of viewing Apple color images were a small fraction of the market.
For many years, the most common way of using an Apple II was connecting
it to a TV set.)

There are two difficulties with Apple color that must be designed around
by a graphic artist:  1) the limited number of pure colors, and 2) the
inablilty to mix green or purple with orange or blue in the same 7-pixel
byte on the screen.  Any apparent color that can be produced by any
pattern of pixels is fair game--sometimes this is described as dithered
color.  Dithering can be horizontal and/or vertical (adjacent lines),
and it is *always* used for its color effect, and is *never* meant to
look good on a monochrome display (though sometimes the textures are
interesting).

The problem with using a "reduced palette" technique to synthesize
Apple graphics is that none of the tools for doing so takes into
account the actual NTSC artifacts that result in a color image for
Apple graphics.  It would be possible to do so--and might be a very
interesting project--but it has not yet been done.  Certainly the
current crop of emulators do a very poor job of rendering what would
be seen on an NTSC monitor, which is what the graphic artist intended.

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

FWIW, my "folk hypothesis" growing up was to consider the horizontal signal
to be divided into [R][G][B] sub-pixels, and Apple screen bits to be
approximately a half-pixel wide, e.g. [0][0] is the same width as [R][G][B].
The bit-7 shift would offset things so the same two bits [0][0] would
overlap the neighboring [G][B][R] subpixels instead. A pattern of [1][1]
would light up RGB (==white). A pattern of [0][1] would light up mostly
[B]=blue and [1][0] would light up [R][G]=orange, or with the bit-7 shift
[0][1] would light up [B][R] = violet and [1][0] would light up mostly [G] =
greeen.

Now I *know* that NTSC does not address individual pixels, but my
"folk-hypothesis" was remarkably effective so it burnt into my brain.

Looking at page 96, I see that it's strangely almost correct - there are 180
cycles across the screen of a color signal which goes through the spectrum
MROYGCBV, and if the monochrome signal is "on" in a particular field of that
you get those colors; Apple's pixels do address half of one of these cycles
each.  So [0][1] lights up GCB=green, [1][0] lights up MRO = purple. Shift a
little bit over and you get. [0][1] lighting up CBV=blue and [1][0] lighting
up ROY=orange.

This also explains the "fringing" rather nicely. The pattern
[0][0][1][1][0][0] which in (Apple Hi-Res)theory is perfect
black-white-black will inevitably have the "white" signal "leaking" to
either magenta or yellow on the edges depending on where it is within the
cycle.

Really, at the price, if you're doing Apple graphics programming you gotta
get this book.