RGB values for the standard Apple ][ colors
mun...@gcctech.com
values in RGB. First, though there is a bit to explain...
The Apple ][ hardware generates a NTSC composite (luma plus chroma)
signal complete with a color burst on the "back porch" of each
scanline. The dots for all display modes (text, lores and hires) come
from a master 14.31818-MHz clock, which is divided by 4 to produce the
color burst. Dots for 40-col text and hires graphics come out at
7.15909 MHz. Dots for 80-col text, lores graphics, and double hires
graphics come out at 14.31818 MHz. Although NTSC defines the scanline
as 227.5 cycles per scanline (so the phase alternates on alternate
scanlines, producing a dithering effect), the Apple rounds it up to
228. (This is why solid bright colors on a monochrome monitor appear
as vertical stripes rather than the "tiny checkerboard" pattern
you see when watching a TV program on the same monochrome monitor.)
To understand the NTSC standard fully, there are four
coordinate systems you have to deal with:
- chroma phase, chroma amplitude and luma
- YIQ
- Y B-Y R-Y
- RGB
The "color burst" signal I just described, plus the positions of
some of the coordinate axes of the other systems, are all defined by
relative phase angles with respect to each other. I'll skip all the
details, but you are invited to read any of the URLs I'm listing at
the end if you want to know more (some are dead but cached on Google).
The important things to know for our purposes are:
1. On the Apple ][, all pixels and the color burst are in phase with
the master clock. However, they come out as square waves, and the
effect of the TV's circuitry (or a composite monitor) is
to turn the square wave into the closest matching sine wave.
2. Because all the pixels generated are in phase with the color burst
signal, the phase of the sine wave is always 0, 45, 90, 135, 180, 225,
270, or 315. The color burst itself is phase 180. For example, "green"
HCOLOR=1 and "light green" COLOR=12 are 50% duty cycle square waves
centered at phase 225.
3. The 4 hires colors are all 50% square waves, which gives a chroma
amplitude higher than anything in a real TV broadcast. This is why
they look so garish. Contrary to what was recently said in the article
"Jon Relay's Apple II Info Archives" in the Aug 2000 GS WorldView,
these four colors are *not* the same as the NTSC "+I, +Q, -I and -Q"
colors. They are actually 12 degrees lower in phase -- probably not
enough to notice, since your tint control is probably a bit off anyway
(-:
4. The lores colors are derived a similar way, although two of them
(the two grays) are square waves of twice the chroma frequency, and
these are "averaged out" to a flat 50% gray by the TV. All of the
lores colors are binary combinations of the four PRIMARY lores colors,
which are the four that appear "dark gray" on a monochrome monitor:
duty cycle phase
Red COLOR=1 45 to 135 90
Dark-blue COLOR=2 315 to 45 0
Dark-green COLOR=4 225 to 315 270
Brown COLOR=8 135 to 225 180
If we combine COLOR 4 and COLOR 8, we get COLOR 12: 4 plus 8 = 12.
This color is "on" from 135 to 315, which makes a
50% square wave centered on 225. Thus, it appears the same as
the HCOLOR=1 described above.
Here is the table. It was used by taking the chroma/luma values and
transforming to R-Y and B-Y, then transforming to YUV and finally to
RGB. The last step requires a gamma correction for display on an
RGB monitor, I used Y to the power of -0.4. For reference, the NTSC
"color bars" test pattern colors and the YIQ axis colors are also given.
<pre>
--chroma--
Color name phase ampl luma -R- -G- -B-
black COLOR=0 0 0 0 0 0 0
gray COLOR=5 0 0 50 156 156 156
grey COLOR=10 0 0 50 156 156 156
white COLOR=15 0 0 100 255 255 255
dk blue COLOR=2 0 60 25 96 78 189
lt blue COLOR=7 0 60 75 208 195 255
purple COLOR=3 45 100 50 255 68 253
purple HCOLOR=2 45 100 50 255 68 253
red COLOR=1 90 60 25 227 30 96
pink COLOR=11 90 60 75 255 160 208
orange COLOR=9 135 100 50 255 106 60
orange HCOLOR=5 135 100 50 255 106 60
brown COLOR=8 180 60 25 96 114 3
yellow COLOR=13 180 60 75 208 221 141
lt green COLOR=12 225 100 50 20 245 60
green HCOLOR=1 225 100 50 20 245 60
dk green COLOR=4 270 60 25 0 163 96
aqua COLOR=14 270 60 75 114 255 208
med blue COLOR=6 315 100 50 20 207 253
blue HCOLOR=6 315 100 50 20 207 253
NTSC Hsync 0 0 -40 0 0 0
NTSC black 0 0 7.5 41 41 41
NTSC Gray75 0 0 77 212 212 212
YIQ +Q 33 100 50 255 81 255
NTSC magenta 61 82 36 255 40 181
NTSC red 104 88 28 255 28 76
YIQ +I 123 100 50 255 89 82
NTSC yellow 167 62 69 221 198 121
Color burst 180 40 0 0 4 0
YIQ -Q 213 100 50 51 232 41
NTSC green 241 82 48 12 234 97
NTSC cyan 284 88 56 10 245 198
YIQ -I 303 100 50 0 224 231
NTSC blue 347 62 15 38 65 155
</pre>
See also
http://www.ee.washington.edu/conselec/CE/kuhn/ntsc/95x4.htm
http://www.landfield.com/faqs/apple2/faq/part16/
http://www.grin.net/~cturley/gsezine/GS.WorldView/v2000/Aug/Articles/A2.InfoArchives.Aug.2000.txt
http://www-viz.tamu.edu/faculty/parke/ends489f00/notes/sec1_4.html
http://www.neutralzone.org/home/faqsys/docs/codet
http://www.belle-nuit.com/archives/videoglossary.html
http://www.itc-usa.com/noframe/radapclr.htm
- Robert Munafo
Apple ][ programmer since 1980!
Sent via Deja.com http://www.deja.com/
Before you buy.
Jon Bettencourt
--
== Jon Bettenct = Prgmr, Writer, Mathematician, Lisa Simpson Fan ==
= http://dimension18.cjb.net = ICQ76731065 = jonr...@napanet.net =
The only thing worse than dreaming about your math final is waking
with the realization that you still have to take it. -- Paige Fox
Holger Picker
> RGB values for the standard Apple ][ colors
Great work! Thank you very much for the values and the good explanation about the technical
details. I've put these values into my emulator and they seem to look right. I remember
having seen an old programme on television about the game "Little Computer People Project"
on the AppleII, and I wondered then about the colours as e.g. blue did not look like the
dark blue so many emulators use. Instead it was very bright and a bit green just like your
RGB-values. The only emulator that shows colours a bit similar to yours is ApplePC. I've
added its RGB-colours here just to your information and for comparison. As you can see the
major difference is that these values don't look so bright. Still it seems as if the author
has tried to copy the values he found on his Apple monitor to the emulator. Unfortunately
the programmers of AppleWin and Apple Oasis use completely different colours showing e.g.
pink like purple. It looks very ugly when you play Dragon Wars or Neuromancer. (Apart from
the fact that the whole double-hires output doesn't look right at all because it is shown as
140 * 192 instead of 560 * 192 making the output text sometimes absolutely illegible.)
Well, just in case, I've written a little script interpreter now for the emulator so that
everyone who doesn't like appropiate colours can set up different values however he/she
wants. I for myself think I'll stick to your RGB-values (now default values). Thanks again.
Holger
ApplePC
black COLOR=0 0 0 0 0 0 0
red COLOR=1 227 30 96 124 32 64
dk blue COLOR=2 96 78 189 32 48 124
purple COLOR=3 255 68 253 188 80 188
dk green COLOR=4 0 163 96 0 92 60
gray COLOR=5 156 156 156 124 124 124
med blue COLOR=6 20 207 253 64 140 184
lt blue COLOR=7 208 195 255 188 172 248
brown COLOR=8 96 114 3 60 76 0
orange COLOR=9 255 106 60 184 108 64
grey COLOR=10 156 156 156 124 124 124
pink COLOR=11 255 160 208 248 156 188
lt green COLOR=12 20 245 60 60 168 60
yellow COLOR=13 208 221 141 188 200 124
aqua COLOR=14 114 255 208 124 216 188
white COLOR=15 255 255 255 255 255 255
P.S.: Just one thing still baffles me. Why did so many programmers translate Apple-blue to
the CBM 64 as dark blue (colour 6) and not light blue (colour 14) or even cyan (colour 3)
when converting Apple programs to the CBM 64? We'll never know...
P.P.S.: Hmmm... What would be good values for monochrome output (green/amber)? ;-)
Phoenyx
> completely different colours showing e.g. pink like purple. It
> looks very ugly when you play Dragon Wars or Neuromancer.
Part of the problem with emulators running in Windows is the way
Windows controls the display. Eventually Oasis may improve this
since it is recently making use of direct draw routines.
For the time being, it is a simple matter to adjust any of the
color values Oasis uses from it's control panel. It should be
a trivial matter to select the RGB values you desire. This is
also very useful since different svga/monitor combinations can
have variations in hue.
As far as I know, this is the only emulator which supports this
feature.
--
Thank you for your time and interest. I hope it was helpful
or at least interesting.
Phoenyx,
Apple2 user since March 1984
Links to Phoenyx's pages:
preferred..... http://zip.to/Phoenyx_A2
alternate..... http://www.tinyangeldesigns.com/Apple2
Jon Bettencourt
> hiresscreen for no apparent reason. Is it a bug or a special feature?
Special feature, I guess. It occurs when you have a pixel whose color is
determined by two bits in two seperate bytes, but the color group bits of
those two bytes are different. You get yellow, cyan, brown, or pink (and
possibly other colors too) depending on the state of the bits.
It happens because of the way the Apple II's video system works. The
signal isn't exactly NTSC or PAL (it's slightly off), so you get an effect
called "color bleeding." A white dot of light can appear in different
colors depending on where it is. The color group bits push and pull it
ever so slightly to change the color.
If you do it very carefully, you can actually get 12 different hi-res colors.
Holger Picker
> For the time being, it is a simple matter to adjust any of the
> color values Oasis uses from it's control panel. It should be
> a trivial matter to select the RGB values you desire. This is
> also very useful since different svga/monitor combinations can
> have variations in hue.
>
> As far as I know, this is the only emulator which supports this
> feature.
here. I just meant that apart from wrong RGB values (AppleWin) both programs
had problems with the double hires graphic showing 140 * 192 pixels instead
of 560 * 192, which makes most programs unusable.
Apple Oasis has in addition another mistake(?): It shows all colours with
the pattern of 111011101110 ... (white mixed with x: light green, light
purple, light orange, light blue) as simple white and black dots, i.e. no
colour at all. Try to play adventure games with it (e.g. Masquerade) and you
get a horrible looking hires output. On the other hand of course you have a
sharp output of text on a hiresscreen. But that is neither what I want nor
what the original Apple would produce I assume.
Furthermore, it also sometimes produces bright yellow dots on the
hiresscreen for no apparent reason. Is it a bug or a special feature?
Another thing I don't understand is, why it offers "Smooth Color Pixels" in
its colour menu. If you set this option to "off", green, purple, orange and
blue are shown as vertical lines only instead of a big filled area. I wonder
what is the use of this, why has the programmer implemented this strange
feature? Has it got something to do with older Apple monitors? Could these
show e.g. blue only in those columns that had actually the bit set? The
whole thing does not make much sense to me, I'm afraid.
And a real big mistake besides the graphic output is the way Oasis handles
the LC-bank. It seems as if it copies the LC Bank $d000-$dfff into the
emulation memory every time it is switched. Now this slows down emulation so
much that Ultima IV becomes absolutely unplayable. (Try it! It only reaches
about 20% of the original speed on my Pentium II 350 even with Apple speed
set to 10 Mhz.) It would be great if the programmer could change that,
because with all these flaws Apple Oasis cannot be of any use for me.
Cheers
Holger
Phoenyx
with the author about the hires and dhr output but there are some
barriers in the way. For instance, he doesn't speak English but has
a program which helps him interpret it. All in all he does a good
job though.
Another problem, Oasis is based on his european clone. I don't know
exactly how the video output on this machine is but it apparently was
different somehow. A lot of the features of Oasis were added without
the benefit of the actual hardware. I can only assume he had access to
the technical info. I do know that he was an Apple II programmer in
his area. He created an alternative to Dos which allowed many games
to be played from it.
There is also a problem with trying to emulate the display on the
Windows screen. It is hard to allow for all the different color depths
and screen resolutions. He settled on a size which is (supposed to be)
the hires screen size doubled to allow for drawing the pixel and adding
the color bleed. I can understand where this would be difficult to do.
Have you tried Oasis in different depths and resolutions? You might
see why the smooth color pixels was added. It is actually supposed to
help with the display and on an old Dell pentium 70 system I used years
ago it did. The thing had an awful monitor. It barely supported 256
colors at 640x480, but it wasn't mine. I just had the chance to fool
around with it.
I have found that Oasis is better for text oriented functions. I try
and tell folks that too. I like the fact that I can give it 1 meg of
ram and run Appleworks then print to my Windows printer. I made myself
a nice manual for Hyper C this way. I printed it to an application that
converted the layout into a booklet form before sending it to the
printer.
Over the years I have found myself using a mix of emulators and real
hardware for various tasks. Lately though I primarily use Kegs under
Linux, but with a neat little app called Win4Lin I can quickly access
Oasis and it's utilities.
ta...@my-deja.com
muenster.de>,
Holger Picker <pic...@uni-muenster.de> wrote:
> Yes, you are right, of course. Sorry. My comment was about AppleWin
only
> here. I just meant that apart from wrong RGB values (AppleWin) both
programs
> had problems with the double hires graphic showing 140 * 192 pixels
instead
> of 560 * 192, which makes most programs unusable.
>
> Apple Oasis has in addition another mistake(?): It shows all colours
with
> the pattern of 111011101110 ... (white mixed with x: light green,
light
> purple, light orange, light blue) as simple white and black dots,
i.e. no
> colour at all. Try to play adventure games with it (e.g. Masquerade)
and you
> get a horrible looking hires output. On the other hand of course you
have a
> sharp output of text on a hiresscreen. But that is neither what I
want nor
> what the original Apple would produce I assume.
The manual I have read for color HGR says that when you have 2 or more
light (non-black) pixels they produce solid white. It seems not all
Apple video systems work in this way. On the other hand, a part of the
software is developed on B/W systems and it looks "strange" in color.
The best solution for this problem is to add a new option - how to
interpret color HGR mode.
> Another thing I don't understand is, why it offers "Smooth Color
Pixels" in
> its colour menu. If you set this option to "off", green, purple,
orange and
> blue are shown as vertical lines only instead of a big filled area. I
wonder
> what is the use of this, why has the programmer implemented this
strange
> feature? Has it got something to do with older Apple monitors? Could
these
> show e.g. blue only in those columns that had actually the bit set?
The
> whole thing does not make much sense to me, I'm afraid.
This mode is 280x192 graphic mode with colors. You see all pixels like
on B/W monitor but in addition they have colors.
For example, in double hires you can't read the text in menus for B/W
programs running in color. Really, disabling the Smooth Color Pixels
mode is not necessary in most cases.
> And a real big mistake besides the graphic output is the way Oasis
handles
> the LC-bank. It seems as if it copies the LC Bank $d000-$dfff into the
> emulation memory every time it is switched. Now this slows down
emulation so
> much that Ultima IV becomes absolutely unplayable. (Try it! It only
reaches
> about 20% of the original speed on my Pentium II 350 even with Apple
speed
> set to 10 Mhz.) It would be great if the programmer could change that,
> because with all these flaws Apple Oasis cannot be of any use for me.
Really, the LC bank $D000-$DFFF is copied each time it is switched.
This is realized in this way because of other implementation reasons.
Teodor Angeloff
(the author)
Holger Picker
Thank you for your answer, Mr. Angeloff, and please excuse the delayed reply.
(I have been very busy recently at university. Sorry.)
On Thu, 02 Nov 2000 ta...@my-deja.com wrote:
> The manual I have read for color HGR says that when you have 2 or more
> light (non-black) pixels they produce solid white. It seems not all
> Apple video systems work in this way. On the other hand, a part of the
> software is developed on B/W systems and it looks "strange" in color.
> The best solution for this problem is to add a new option - how to
> interpret color HGR mode.
Yes, I too had such a book (Jeffrey Stanton: AppleII Rastergraphik, I think)
and it never explained clearly what the colour output really looked like, in
case you had no colour monitor (like me). Comparing different emulators I
finally came to the decision that the following algorithm might give
good results. (It may still be improved. This is only a base.)
Important: always take 3 bits to define the colour of the pixel, i.e. the
original bit + 2 surrounding bits.
odd columns (1,3,5...) even columns (0,2,4...)
000 = black 000 = black
001 = black 001 = black
010 = green/orange 010 = purple/blue
011 = white 011 = white
100 = black 100 = black
101 = purple/blue 101 = green/orange
110 = white 110 = white
111 = white 111 = white
I think this is the way AppleWin or Apple2000 work. ApplePC only looks at the
preceding pixel (i.e. 2 pixels only). This is how it creates its blurry mode
(with some extras of course including the high bit). Please note: unlike e.g.
the CBM 64 where pixels had a specific bit combination to allow multicolour
graphic (00,01,10,11 for a two pixels wide dot) the AppleII always had a
resolution of 280 pixels with the colour of each single pixel generated by the
surrounding bits. The same is true for double hires. The last 4 bits of double
hires bits define the colour of one screen pixel. If you have a bit pattern of
01101101
the first pixel will have the colour 0110,
the second pixel will have the colour 1101,
the third pixel will have the colour 1011 etc
and not 4 pixels of 0110 followed by 4 pixels of 1101.
This is the reason why games could mix text output with graphic output. You
always have a resolution of 560 pixels. (Not 140! This may vary with special
graphic cards but does not seem to be the standard.) The programmers simply
ignored the fact that the edges of the characters then would look a bit red or
blue or whatever (see emulation of ApplePC). Using my emulator I have taken a
look into some professional double hires output and I did not find any traces
of evidence that programmers made use of e.g. the high bit to differentiate
between monochrome or colour output. Games like "Test Drive" or "Dragon Wars"
use the high bit as they like, sometimes at random (especially "Test Drive").
> Really, the LC bank $D000-$DFFF is copied each time it is switched.
> This is realized in this way because of other implementation reasons.
Yep, when I wrote my first Apple-emulator for the Amiga I too stumbled across
this big problem. (And I think Apple2000 also works like your emulator.) There
are some programs ("Dragon Wars", "Accolade Comics") that will not run on
ApplePC because parts of the program are loaded at address $dfff. This means
that some code will be put into bank 1 or 2 and the rest in the normal LC-Bank
at $e000 - $ffff. If the emulated memory will not produce the memory in a
row (Which bank will be located before $e000-$ffff? Bank 1 or 2?) and one
accesses memory in one go the emulator would read the wrong opcode bytes and
the program crashes. So copying is one solution but not the fastest as the
AppleIIe has so many memory windows ($400-$7ff, $2000-$3fff, $c100-$c7ff...)
that you can hardly copy all of them all the time without slowing down the
emulation... This is what I meant when I asked the author (you) to change it.
Maybe you can think of another way to handle this?
Best regards
Holger
Gargoyle_BG
>
> Teodor Angeloff
> (the author)
>
Zdravei, prochetoh tova v comp.emulators.apple2 i se setih che bylgarin e
avtor na toq emulator, az lichno polzvam ApplePC 2.52p.
No povoda po koito ti pisha e che otchaqno tyrsq .dsk image na igrata
TETRIS, koqto beshe dosta razsprostranena na jyltite Pravtci.
Ako sluchaino go imash moje li po nqkakyv nachin da mi go pratish.
Imam oshte stari disketi za Apple II obache nqmam takyv 'computer'.
Znam che imashe nqkakyv nachin za pravene na takiva images .dsk, no ne mi se
riskuva da si povredq neshto na normalniq computer.
--
---
John Minkov
--(3.7*@2.8#)--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=