On Fri, 21 Mar 1997, Roger Merchberger wrote:
> The "mixed" colors are created thru a phenomenon called "color
> artifacting." This happens when you try to display thin (vertical usually)
> white lines on a color TV. The TV cannot show lines that thin on the
> phosphor grid, so you end up activating only the (usually) blue or red pixels.
This is actually similar to the way the Apple ][ does its colour in high
resolution modes. I don't remember the exact way it worked, but there
were seven visible pixels per byte, and one hidden bit. When that hidden
bit was on, pixels in that display byte were orange or blue, and when it
was off they were green or purple. A pixel turned on alone had its
colour decided by whether it was in an even or odd position,
horizontally, and by that hidden bit. If two pixels were turned on
side-by-side, the result was a fat white pixel.
Of course, if you made the mistake of attempting to plot an orange pixel
in a byte with green and purple pixels, the pixels would change colour.
And if you POKEd the same value into two bytes that were beside each
other, the colours would reverse (green would become purple in the second
byte, orange would become blue...).
This is how it works on the Laser 3000, too, in HGR and HGR2 modes. But
go up to HGR5 and HGR6 modes, and it doesn't work like the Apple anymore.
In HGR5 and HGR6 modes, you can plot any colour to any pixel, without
affecting the other pixels in that byte. And the basic colours are
different:
HCOLOR= Apple ][ Laser 3000
0 black1 black
1 green green
2 magenta magenta
3 white1 cyan
4 black2 yellow
5 orange red
6 blue blue
7 white2 white
On the Laser 3000, you can do something like this:
10 HGR5
20 FOR X=1 TO 280 STEP 2
30 HCOLOR=X/35
40 HPLOT X,0 TO X,191
50 NEXT X
60 FOR Y=1 TO 7
70 FOR X=0 TO 279 STEP 2
80 HCOLOR=Y
90 HPLOT X,Y*24 TO X,Y*24+23
100 NEXT X,Y
On a composite monitor, this gives 64 visually distinct colours.
I presume an RGB monitor would show what's really going on, but some of
the colours that come out of the "mixing" are really strange, when the
two "source" colours are taken into account.
I don't really know what the Laser 3000 is doing internally with this...
It only seems to use 2 bitplanes for 8 colours (compared to the Apple's
use of one bitplane for 6 colours). If I knew how to plug an RGB monitor
into this thing (it does have an RGB port, but I don't know the pinouts)
I'd be able to see better what it's doing.
BTW, in case anyone's interested:
In memory, HGR5 occupies $4000-$5FFF and $6000-$7FFF
HGR6 occupies $8000-$9FFF and $A000-$BFFF
I still don't know where in memory HGR3 and HGR4 are (double hi-res modes
with the standard Apple colours). I can't seem to address them directly
with POKE. Must be hiding up there in those other memory pages.
> The Color Computer 1 / 2 had the same "problem" and many programs for this
> took advantage of this to show color for the highest-resolution which was
> monochrome. I think it's the phase of the video sync that changes with
> respect to the TV that makes the colors swap... Many of the CoCo programs
> that used this technique actually remapped the reset key so it would
> re-enter the program, and showed a test screen with 2 boxes and "this
> should be blue" under one and "this should be red" under the other. You
> just kept resetting the computer (without having to re-load the pgm every
> time) until the colors synced correctly. Helpful for RPG's that said "you
> need the blue key..."
At least the Apple was consistent with the colours, so I guess it's not
just artifacting called a 'feature' (it really is a feature).
That's cool, BTW. I think I'll drag my Laser 3000 out as soon as I have
time and see if its reset can swap the colour sets. If so, I can use the
same trick the Color Computer used for my own software.
> Of course, when we "geeks" upgraded to the RGB monitor on the CoCo 3, we
> lost all color artifacting... and the games became almost totally
> unplayable. (No! You need the *other* white-striped key!) ;-)
Yup, I remember this on the Apple, using the monochrome monitor. :)
> Roger "Merch" Merchberger
>
> --
> Roger Merchberger | Everyone complained to me to change my .sig,
> Programmer, NorthernWay | but no-one could recommend something better.
> zmerch_at_northernway.net | So you'll have to put up with this *junk*
> | until I find some new wisdom to share.
Doug Spence
ds_spenc_at_alcor.concordia.ca
Received on Tue Mar 25 1997 - 00:45:40 GMT
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:30:32 BST