dmb@TIS.COM (David M. Baggett) (03/19/88)
I thought about this some more last night and I'm pretty sure you can't
get more than 3 palette changes per scan line. I played around with two
other approaches:
1) Make the whole screen color 0 and just change that palette
entry as fast as you can. Of course, this is only worthwile
if you can change it 200 times a line (which you can't).
2) Do a similar thing with two colors and use a single move.l (20)
instruction to set the first two palette entries as fast as
possible. Turns out you can get about 45 of these in a line
(not enough since you need 100).
There really isn't much flexibility, given that you only have 508 cycles
to play with, so I think Wayne's approach is the best. Too bad there isn't
a fast move immediate on the 68000; that would help.
I can think of an entirely different appoach to getting more colors on
the screen, which I'm sure others have mentioned. I have tried this with
good results (under some cicumstances -- keep reading). With enough
effort, I think this can work nicely (maybe not as nicely as Wayne's idea,
though...). Here goes:
Page flip between two screens 60 times/second. This causes
really bad flicker if the colors of the alternated pixels are
too different, but looks ok with some color combinations.
e.g., alternating red (700) with white (777) does NOT give you
pink (it gives you a headache), but alternating red (700) with
darker red (500) gives you a pretty stable color blend.
If we could determine which combinations looked acceptable, we
could create a new palette of colors which contained them, giving
(theoretically) 16x16 = 256 colors on the screen at once, with
each pixel individualy set-able (no color band foolishness).
Add to this the standard HBL palette change, and you get each of
256 colors per scan line, with a theoretical limit of 512x512 =
262,144 colors on the screen at once. The acutal number would
be a lot smaller, since many combinations look like hell (besides,
we don't have that many pixels).
Plusses: Each pixel can be set to a certain color (no bands).
Does not require all processing time.
Minuses: Tough to find out which colors look good alternated.
Large regions of colors flicker more than small ones.
I noticed that it looks a lot better with the contrast turned down some.
"Alert Box: Please turn the contrast down on your monitor or your eyeballs
will be turned to jell-o. [OK] [Cancel]"
Something else to look into: There maybe other hardware registers that
control the video out that we don't entirely understand that may be useful
to us. Looking in the Abacus books, I noticed a few crytic comments about
one or two of the registers. I'm sure someone knows what they all do (as
descibred), but has anyone messed with all of them to see what really happens
when you fiddle with them?
Last thing: I couldn't get the screen base to change in mid-screen by
changing the hardware screen base register. Is this just incompetence on my
part, or is this really impossible? If you can change the screen base after
each line, it might be possible to do some kind of interlacing and reduce the
filcker caused by the page flipping idea above. Ideas, anyone?
Dave Baggett
arpa: dmb@tis.com