--gfx-palette flag

[mthompson]

I'm hoping to have jzIntv load an alternate color palette when launching a game. I know there's a flag for doing this, but I need a little guidance in putting it to use.

 

--gfx-palette=<file> Load alternate palette from <file>

 

Is there an existing palette file in the .bin folder or elsewhere that I can modify or use as a template?

 

Thanks.

[intvnut]

I don't know off the top of my head whether I included a demo version of the palette w/ jzIntv. Here's the Q&D docs:

.

    /* -------------------------------------------------------------------- */
    /*  Format:                                                             */
    /*   -- 16 non-empty lines, one for each of the 16 INTV colors.         */
    /*   -- Empty lines ignored.                                            */
    /*   -- Anything after a ';' ignored                                    */
    /*   -- Each line must either have:                                     */
    /*       #rrggbb        HTML-style hexadecimal color triple             */
    /*       dec dec dec    Three decimal numbers separated by spaces       */
    /*   -- Lines must be less than 256 characters.                         */
    /* -------------------------------------------------------------------- */

.

And here's jzIntv's default palette in terms of the HTML-style triples. I can't really try it right now as I am at work, but it should work:

.

#000000
#002DFF
#FF3D10
#C9CFAB
#386B3F
#00A756
#FAEA50
#FFFCFF
#BDACC8
#24B8FF
#FFB41F
#546E00
#FF4E57
#A496FF
#75CC80
#B51A58

.

The colors are expected to be in the same order as the Intellivision palette. (0 = black, 1 = blue, 2 = red, etc.) Here's the full order for reference (from doc/programming/stic.txt):

.

         Primary Color Set                Pastel Color Set                    
      ------------------------       -----------------------------          
       0 Black   4 Dark Green          8 Grey     12 Pink                   
       1 Blue    5 Green               9 Cyan     13 Light Blue             
       2 Red     6 Yellow             10 Orange   14 Yellow-Green           
       3 Tan     7 White              11 Brown    15 Purple              

[mthompson]

Thanks, helps a lot. I'm hoping to get colors from my Raspberry Pi that approximate what an Intellivision looks like on a CRT.

 

I looked in the jzIntv package files but didn't see anything like this. So the file specified in the flag is a .txt file with the 16 color values, much like a game's .cfg file?

 

One option is HTML style (white = #ffffff). Is the other style RGB (white = 255 255 255) ?

[mthompson]

Looks like the answers to each of my questions above is "yes."

 

This will also make my life 10 times easier making screen grabs for game manuals, as I need yet a different palette for the way the images print at my local print shop. No more need to adjust all the game screens!

 

I really appreciate your help

[tacrec]

Here's one of my palettes from baseball. You can see where I modified the colors.

colors_amda.txt

[mthompson]

Here's one of my palettes from baseball. You can see where I modified the colors.

colors_amda.txt

 

I figured that you were using the palette flag for the baseball games. If your request prompted this feature being added, thank you! With all due respect to intvnut, I've never been 100 percent satisfied with the look of the emulator's colors. Some of the pastels seem pretty far off, to my eye. Plus, when I'm making graphics for game manuals, I have to change more than half of the colors to get a "TV look" on paper. I took the color samples I've come up with for that and made a new palette for jzIntv. No more touching up all the pixels in my screen grabs!

 

For my Raspberry Pi, I made a palette that pretty closely matches the output of a console using composite video (rather than the muddy colors you get from the stock RF output – but maybe I'll make a palette for that, too). Here is my color chart for the composite colors and the text file with the hex values. If anyone has an opinion about my choices, I'm open to feedback. I'm thinking of posting this to the Ultimate Flashback thread eventually in case others want to go down this road.

 

composite_colors.txt

[mthompson]

FWIW, I adjusted my colors a bit and am now very happy with how things look. Thanks again for adding this feature to jzIntv.

 

These are the new color values I'm currently using:

 

#000000 ; black

#0000ff ; blue

#c40202 ; red

#bcc75e ; tan

#0f8223 ; dark green

#04b640 ; green

#f6e806 ; yellow

#fffbff ; white

#9b9ea1 ; gray

#13d1d1 ; cyan

#e39401 ; orange

#355002 ; brown

#ff00ea ; pink

#918ff5 ; light blue

#27d305 ; yellow-green

#8a229f ; purple

... to get this result:

[intvnut]

Wow, your pink is decidedly more purplish than mine.

 

I believe the composite mod shifts the colors slightly by putting a little load on the circuit. The real grey, for example, isn't quite that flat.

 

I'm sure your Cyan is closer to correct than mine is, though.

[intvnut]

I'm tagging "watch this thread," as I missed the followups. (I don't generally visit AtariAge idly these days. I wait for someone to tag me in, or a thread I'm watching to show activity.)

[tacrec]

That TV version of magenta looks straight up purple! I like the brighter YG and pink.

[mthompson]

#16 is supposed to be purple, but jzIntv makes it look like raspberry red.

#13 is supposed to be pink, but in jzIntv it's very close to red.

 

I did a lot of A/B comparisons between RF and composite and came up with shades that I think are pretty faithful to both. The exception is yellow, which is quite dark on RF, so I went with a truer yellow. Of course, the vibrance you'll see is partly determined by your TV settings. These days I don't think people will have the "hue" out of whack, so the colors themselves should ring true.

 

I first got excited about the new palette flag because I've always been puzzled that many of the colors I see in emulation don't match the jzintv example file…

 

Here are the jzIntv default colors captured on my MacBook:

 

And here's what I'm now using for a custom palette, which, except for pink and purple, is actually pretty similar to that example file:

 

Having the ability now to customize the palette is great, but I wonder if it would benefit novice programmers and others who aren't inclined to tinker "under the hood" if the default palette were closer to real hardware. Regardless, I'm thankful that intvnut keeps track of all this stuff and keeps improving jzIntv.

[intvnut]

So, I've been fairly quiet on this thread, partly because I was on my own journey to try to work out the correct colors for the Intellivision. Interestingly enough, I had started that journey a week or two before this thread appeared.

 

This is a rat hole I go down every few years, actually, which is why the colors for jzIntv changed a couple times. Each time I think I might get there because I've discovered new information and think "It's really a rabbit hole!" However, each time I end up disappointed and discover, no, I'm in yet another rat hole. I figured I would share everything I've learned, in case someone decides to go down the rabbit hole / rat hole themselves.

 

The first times I tried working out the colors from first principles, I started with the I/Q table that's in the AY-3-8915 data sheet. I can now state, unequivocally: This datasheet is completely incorrect. The numbers in the data sheet do not correspond to the chip inside the Intellivision. They may reflect a palette used in early development. They do not reflect the palette that's in the actual production Intellivision.

 

Rather, page 96 of this procurement specification, found on Papa Intellivision, is closer to reality. I say closer, because there is one error: The sequence for brown is 5, 5, 9, 9, not 9, 9, 5, 5 as listed. To verify this, I put together a simple Arduino setup and dumped the I/Q values out myself:

 

But, before I tried that, I actually tried working from a different set of color information: Mattel had contracted Radofin to develop the PAL circuitry for the PAL version of the Intellivision. In that document (also on Papa Intellivision), Mattel had listed Y, I, Q, R-Y, and B-Y values for the intended color set. So I first tried to work with those. I built up a grand spreadsheet with the color difference values and tried that. No matter what I tried, I found various problems: The brown wasn't green enough. The tan was too dark. The grey was much too dark. The magenta and purple just looked "off." I tried various tweaks, such as applying gamma correction at various places, or using different scale factors. I even tried applying various rotations (equivalent of turning the "tint" knob.) Nothing gave an acceptable palette. I could get some colors right by making other colors wrong. I couldn't make them all look right at the same time.

 

I then tried using Mattel's Y, I, and Q values. Long story short, I reached roughly the same not-right colors, in the same ways. I shouldn't have been surprised: The YIQ values gave roughly the same color difference values. I say roughly, as I found more than one variation of the YIQ => RGB translation matrix. None of them really "worked."

 

So, I returned my attention to the I/Q table from the AY-3-8915 spec. (The correct table from the procurement spec (flipping brown around the right way), not the crazy one from the datasheet.)

 

My initial approach was straightforward: Take the +Q, -I, -Q, and +I labels at face value.

 

A quick aside on how NTSC color works: NTSC color is built upon black and white NTSC. At its heart is a black and white signal. Each scan line contains a synchronization pulse that's "blacker than black", surrounded on either side by a reference level that's just a shade darker than black. Those reference levels are called the "front porch" and "back porch." NTSC signals are measured in a fun unit called IRE. The full swing of an NTSC signal goes from -40 IRE for the sync, 0 IRE for the back/front porch, 7.5 IRE for black, and 100 IRE for white. What does IRE stand for? Institute of Radio Engineers. Now we know who to blame for these fun units.

 

The color signal is superimposed on the black and white signal by modulating it with a color carrier. The color carrier is a sine wave at the ever familiar 3.579545MHz. The color components I and Q are computed as differences from the underlying monochrome signal. The I axis is roughly the "blue-orange" axis, while the Q axis is roughly the "green-purple" axis. (Image thanks to Wikipedia.)

 

 

For reasons unbeknownst to me, the original monochrome signal is named luma (short for luminence), but given the completely obvious label Y. Hence the name YIQ for this color space. The matrices used to convert between YIQ and RGB are on the Wikipedia page I linked above, so I won't repeat them here.

 

The way I and Q get modulated onto the signal is somewhat clever. I stands for "in-phase" and Q stands for "quadrature." The I component modulates a sine wave that's in-phase with the color carrier, while the Q component modulates a sine wave that's exactly 90 degrees out of phase with it. This keeps the two components separated. You can think of one as a sine wave and the other as a cosine wave, if that helps. The Y signal is then recovered by low-pass filtering below the color carrier.

 

In order to phase-lock a receiver to the color carrier (and therefore the I and Q signals), the NTSC color signal adds a color burst to the back porch of the NTSC signal. This is a few cycles of the color carrier inserted directly into the video signal. The I signal should be in-phase, while the Q signal should be 90-degrees shifted. The result looks like this:

 

 

You'll also note the cute nomenclature that the back porch is now cut into three pieces: breezeway, burst, back porch. Cute.

 

So anyway, I started by taking the I and Q tables in the chart at face-value. For Y, I simply averaged the four values. For I and Q, I took the difference between the corresponding columns ((+I) - (-I) and (+Q) - (-Q)). I further shifted and scaled all of the values so that Y would end up with 1.0 at white and 0.0 at black. I and Q get a slightly different scaling: First there's a factor of 2 to remove as (+I) - (-I) gives you 2*I. Then there's an additional factor of 2 to remove because apparently the I and Q values are scaled by 2 before transmission.

 

Interestingly, this gave me Y, I, and Q values that bore a shockingly similar set of values to the values I saw in the Mattel/Radofin memo. Cripes.

 

Therefore, I started to dig a little deeper. If you look at the color burst row in the AY-3-8915 table, you see the sequence 2, 2, 6, 6. This is a square wave. The peak and trough of that square wave aren't quite aligned on the +I/-I columns. This explains why I need a bit of 'tint' adjust, rotating the I/Q values. (For the record, I get the best results with a 45 to 60 degree rotation.) In case you're wondering why I call this a rotation: I interpret I and Q as coordinates of a vector, landing on a point in the I/Q plane image I posted above. To rotate that vector, you can use a standard rotation matrix (involving sin/cos) to rotate that vector about the origin without changing its magnitude. This is literally what the tint knob is for on old TVs.

 

I even had a short-lived flash of brilliance (or so I thought): Maybe the problem was the handling for out-of-gamut colors. See, when you apply the YIQ to RGB transformation, you get some colors components outside the acceptable range. Some are brighter than white. Others are negative. So, I even played around with an even more exotic approach: Transform YIQ to L*a*b, perform gamut compression in L*a*b, and then transform that into RGB. Because you're reading this here in the middle of the story, you can guess how well that turned out.

 

Since even these values weren't getting me anywhere, I had to start looking elsewhere for possible sources of "interesting" distortion.

 

One thing that occurred to me was that I didn't really know what the RF modulator looked like in the system electrically. Tim Lindner and I developed the composite mod empirically, and were puzzled then why we needed so much gain in the circuit to get a reasonable output. There was the additional mystery of why all of the resistors in the video circuit pull down, when the AY-3-8915 itself was only capable of sinking current toward 0V (up to 4mA or 5mA, depending where you look), but not really sourcing current (10µA). That is, the AY-3-8915 can pull down, but not up.

 

The various UM1285-8 data sheet scans out there (such as this one) weren't terribly helpful. The chart that shows the input impedance for the RF mod wasn't particularly helpful. You'll notice that the chart that gives the "typical transfer characteristic" has no units on the Y axis, and completely missing labels on the X axis.

 

And then I found through further searching: Archer (of Radio Shack fame) stocked this RF modulator for a time! Archer had really good databooks in the 80s. Once I had the Radio Shack part number for this component, I was able to find a high quality scan of the data sheet from an Archer data book. (Attached.)

 

That version of the data sheet had useful labels on the transfer characteristic plot. From that, I was able to determine that the RF modulator acts roughly as a 441Ω resistor pulled up to 2.85V.

 

I quickly modeled the resistor ladder in the Intellivision video circuit with this pullup. Now all of the output codes resulted in voltages roughly in the band I expected, based on other plots in the datasheet (2.2v to 2.7v). Now I was getting somewhere.

 

Armed with all that, I set about trying to model the resistor ladder in SPICE, the circuit simulator. I tried a few iterations, eventually settling on a model that used NMOS output drivers with transistor models borrowed from a Z80 spice simulation and tweaked slightly. I also was sure to add in the 200pF capacitor, which acts as a low pass filter. I then set about SPICEing all the colors.

 

The SPICE output was interesting. The color burst square wave now became a rather shark-fin-looking beast that better resembled a triangle wave. (See below.) Others had some strange lumps. But mostly, they looked roughly like triangle-ish waves of various magnitudes and phases. They seemed pretty reasonable, really.

 

The version of SPICE I used (AIM SPICE) was able to write CSV files out for each of the colors. I wrote a quick-and-dirty C++ program to read in these CSV files and apply YIQ demodulation to those. The YIQ demodulator was a belt-and-braces demodulator, performing a full sine-wave correlation with the signal to extract I and Q, and an averaging function to extract Y. For extra bells and whistles, I had it also try to determine the phase angle of the color burst, to automatically lock onto the color burst frequency for the rest of my math.

 

You can guess where this went: Nowhere. I got slightly better colors in some cases, but still had the same general problems: Tan and grey are too dark. The magenta and purple don't look quite right. etc. If I make the brown "green" enough, the other colors start to get out of whack.

 

I was basically at a dead end.

 

Now, I'd like to take a moment to point out some oddities I noticed in the I/Q values really quick, and perhaps they may help the next person. Recall that the Y value was computed as the average of the four values, with I and Q interpreted as waves superimposed on top. That means +I and -I should be the same distance from Y, just on opposite sides of it. Likewise for +Q and -Q.

 

For most of the colors, this is true or very close to true. Take, for instance, the sequence 8, 13, 12, 7 for the color Cyan. The average of these four values is 10. (8 + 13 + 12 + 7 = 40) 8 and 12 are both 2 units away from 10. 13 and 7 are both 3 units away. Or, take one of the greens: 3, 9, 12, 7. The average of these four values is 7.75. This didn't land on an integer, so they did the best they could: 3 and 12 are 3.75 and 4.25 units away, while 9 and 7 are 1.25 and 0.75 units away.

 

But now look at Tan. It's 10, 8, 12, 12. It averages out to 10.5. 10 and 12 are really asymmetric: 0.5 and 1.5 away. 8 and 12 are similar, being 2.5 and 1.5 away. What's going on there? Is that a factor in the strange results I got with Tan?

 

Even if it is, it still doesn't explain why grey is too dark though. It's 9, 9, 9, 9.

 

The end of this long story is that I gave up trying to get the color set from first principles. I instead resorted to a screen cap. I obtained a screen cap of the color test and derived a color set from that. That color set is a bit brighter than mthompson's but looks similar. I also made a slightly tweaked version that adjusts the magenta and purple to better match what I see on my TV via RF, while also brightening the grey a little bit, and shifting brown manually slightly toward green.

 

I'm pretty happy with this color set.

 

BTW, I figured out a really good acid test for a color set, at least to check the green, brown, tan, orange, and yellow: Congo Bongo!

 

I used Congo Bongo throughout the work above to check out whether I really have the right tan, orange, yellow, and so on. On my TV, Congo Bongo's first level looks really rather nice. The current jzIntv color set looks horrible. mthompson's looks OK. I rather like my final color set.

 

Attached are screen shots with jzIntv's current color set, my tweaked color set, mthompson's color set, and a photo from my TV. Also attached is a photo of the color test from my TV.

 

 

And finally, here's the final color set I settled on.

.

  0   0   0
 20  56 247
227  91  14
203 241 104

  0 148  40
  7 194   0
255 255   1
255 255 255

200 200 200
 35 206 195
253 153  24
 58 138   0

240  70  60
211 131 255
 72 246   1
184  17 120

.

I realize this was a pretty long post. I didn't even cover everything. But... I figure now's a good place to stop and accept questions.

Archer-UM1285-8-Datasheet.pdf

Edited May 24, 2018 by intvnut

[intvnut]

Oh, and one other minor thing I forgot: I did find a YouTube video posted by someone in Brazil that was captured with a capture card. It appears, at first glance, that those colors are closer to the Mattel/Radofin memo. It's hard to say, as it was a video of B17 Bomber, and that doesn't give me a lot of datapoints. The biggest is that the brown looks more brown than on NTSC. (It's still rather olive.)

 

So that adds an additional twist: The PAL colors may indeed be slightly different than their NTSC counterparts.

 

Joy!

[intvnut]

One other minor note: My phone's camera didn't quite capture just how violet the violet areas are in the Congo Bongo image. It flattened them out closer to mthompson's palette. That is one of the frustrating aspects of this process.

[+nanochess]

Wow! are you sleeping enough?

 

This was a pretty interesting trip! But how we can be sure of the hue for pictures if this has variations in all NTSC sets?

 

For my CoolCV emulator I wrote a YUV converter to RGB that runs dinamically because you can have NTSC/PAL palettes, the input values come from the VDP datasheet, for some reason TI shows all values as integers.

 

Y runs from 0-100, R-Y and B-Y runs from 0-84. (center is 47)

 

I gave a look to the AY-3-8915 values you show and that was non-sense for me, but the Papa document was pretty close to what I understood.

 

So I've took the Papa document values, passed them thru my YUV converter adjusting my contrast number and I surprisingly I feel as it looks like in screen.

 

  0,  0,  0
  0,117,255
255, 76, 57
209,185, 81
  9,185,  0
 48,223, 16
255,229,  1
255,255,255
140,140,140
 40,229,192
255,160, 46
100,103,  0
255, 41,255
140,143,255
124,237,  0
196, 43,252

palette.bmp

[intvnut]

Wow! are you sleeping enough?

 

This was a pretty interesting trip! But how we can be sure of the hue for pictures if this has variations in all NTSC sets?

 

For my CoolCV emulator I wrote a YUV converter to RGB that runs dinamically because you can have NTSC/PAL palettes, the input values come from the VDP datasheet, for some reason TI shows all values as integers.

 

Y runs from 0-100, R-Y and B-Y runs from 0-84. (center is 47)

 

I gave a look to the AY-3-8915 values you show and that was non-sense for me, but the Papa document was pretty close to what I understood.

 

So I've took the Papa document values, passed them thru my YUV converter adjusting my contrast number and I surprisingly I feel as it looks like in screen.

 

  0,  0,  0
  0,117,255
255, 76, 57
209,185, 81
  9,185,  0
 48,223, 16
255,229,  1
255,255,255
140,140,140
 40,229,192
255,160, 46
100,103,  0
255, 41,255
140,143,255
124,237,  0
196, 43,252

 

 

Yep, that looks about like one of the "wrong" palettes I generated along the way. Notice how the orange is "nuclear bright" compared to the dark tan areas. On my NTSC screen, the tan areas are roughly equal brightness to the orange areas, and almost as bright as the orange!

 

I guess that confirms that PAL and NTSC have different palettes, and PAL is closer to the documentation we have from Papa Intellivision. It's good to know that the math I was doing wasn't really off in the weeds compared to those numbers at least.

 

As far as the TI numbers go, I have some TI documentation for proposed improvement on PAL devices that gives the numbers in a different form. It excludes black, grey, and white, but at least walks through the computations for NTSC and PAL from YIQ through RGB (before and after gamma correction) for the chip as it was built. The values given there are all on a 0.00 to 1.00 scale (although a couple values are >1.00). The particular doc I linked was complaining about low color saturation on PAL, and a few other issues.

 

I was hoping to be able to do similar math for the STIC on NTSC, because my longer term goal was to emulate the color-fringing effects that NTSC machines show on color transitions. Some games rely on these to provide additional depth. The plants in Shark! Shark! for example.

Edited May 24, 2018 by intvnut

[mthompson]

I've been doing some work on this also and was excited to see the posts this morning.

 

I had a conversation this week with JohnPCAE recently, and I used his YIQ to RGB conversion to make a palette and see what it looked like. I used an as-yet unreleased utility to generate nice big color squares and photographed the screen of an LCD TV in a dim room. I also did screen captures on my MacBook because the colors can look a bit different on the computer.

 

Man, if that's what the Intellivision "brown" was supposed to look like, I'm really bummed that it didn't turn out that nice.

 

Here is a comparison of my colors next to the current jzIntv defaults, just to show everything on the same screens. I had tweaked the pink/magenta a bit from last time to remove some blue. Everything I've come up with is purely subjective, rather than the result of any technical calculations.

 

And here are the color values I used. I still prefer my purple when compared to the Intellivision screen.

 

000 000 000 ; black

000 000 255 ; blue

228 004 004; red

188 199 094; tan

015 130 035 ; dark green

004 182 064; green

246 232 006; yellow

255 251 255; white

149 152 155; gray

019 209 209; cyan

227 148 001; orange

053 080 002; brown

255 000 160; pink

145 143 245; light blue

039 211 005; yellow-green

138 034 159; purple

 

Here are Joe and Nanochess' new color palettes that were posted this morning.

 

 

Tan, brown, pink, light blue, and purple seem to be the toughest to nail down. The other colors are pretty good in some of these palettes. I feel like some combination would result in a palette that's subjectively faithful to the actual hardware (although RF yellow and tan are pretty awful).

Edited May 24, 2018 by mthompson

[+DZ-Jay]

Fascinating! Thank you all for posting all that information.

 

So... TL;DR: the colour was specified in one way but implemented in some as-yet-undetermined-but-decidedly-weird way for NTSC, which apparently was "corrected" in the PAL version. Is that anywhere near accurate?

 

dZ.

[intvnut]

Fascinating! Thank you all for posting all that information.

 

So... TL;DR: the colour was specified in one way but implemented in some as-yet-undetermined-but-decidedly-weird way for NTSC, which apparently was "corrected" in the PAL version. Is that anywhere near accurate?

 

The NTSC circuit is pretty straightforward, but its effects are not fully understood. The PAL system seems closer to the intended result than what NTSC actually achieves, and it's hard to say why.

 

What I'd really like now is actual oscilloscope data for Intellivision "color bars." I don't have an appropriate scope, though. I might buy one. They have some low cost USB scopes. If I can find one that'll output a captured waveform as something I can read from a program, that'd be perfect. Or, if someone reading this already has a setup, contact me. (Email is better than AA private message.)

 

As long as the scope can sample 10MHz or higher, that should be enough. NTSC bandwidth goes up to about 4.5MHz, IIRC.

 

BTW, one other thing I noticed: the procurement data sheet lists the current sink capacity of the AY-3-8915 as 4mA, while the official data sheet lists it as 5mA. I wonder if that has anything at all to do with the oddity? I did try playing with different output impedances for the AY-3-8915 (which would then change the linearity of the 4-bit DAC), but I didn't have any "aha" moments. You'd need a truly non-linear phenomenon, I think, to really see something.

 

For example, highly asymmetric switching characteristics on the output transistors might be a factor. Thus, the repeated "12, 12" in the Tan color might be important. The '8' bit is on for all four samples in Tan (10, 8, 12, 12), and likewise for Grey (9, 9, 9, 9). Could its weight actually be greater than 8 when held on like that?

 

Oscilloscope output would tell us for sure.

[carlsson]

So to paraphrase an already incorrect Star Trek quote: "It's colors Jim, but not as we know them".

[+DZ-Jay]

Oscilloscope output would tell us for sure.

 

Doesn't Frank have one? Perhaps he'll be willing to help.

[mr_me]

On my TV today (a sony trinitron) the sky in B17 Bomber looks pink. That's colour 14 aka light-blue. It looks like the congo bongo water in Joe's second image. I don't think that's how the original programmers saw it, and it's not how I remember it from 35 years ago on a completely different TV. Is it my eyes or does the water in that congo bongo image look pink?

 

I appreciate all this effort.

 

Edit: I should have mentioned that I am using a real ntsc Intellivision (sears model).

 

Thinking about this a little more. I remember TVs of the early 1980s had a problem with red bleed and we often adjusted red down to avoid this. My newer year 2000 trinitron probably does a much better job displaying red. Maybe the guys at Mattel Electronics added a bit more red to some colours to compensate for the TVs of the day, so now light-blue looks pinkish/purple.

Edited May 25, 2018 by mr_me

[+DZ-Jay]

On my TV today (a sony trinitron) the sky in B17 Bomber looks pink. That's colour 14 aka light-blue. It looks like the congo bongo water in Joe's second image. I don't think that's how the original programmers saw it, and it's not how I remember it from 35 years ago on a completely different TV. Is it my eyes or does the water in that congo bongo image look pink?

 

I appreciate all this effort.

 

The water in that Congo Bongo image looks purple to me but moving towards the reddish side, so I can see why it may look pink on some TVs.

 

I haven't played B-17 Bomber in a while, but wasn't the sky "Cyan" instead of "Light Blue"?

 

-dZ.

[intvnut]

On my TV today (a sony trinitron) the sky in B17 Bomber looks pink. That's colour 14 aka light-blue. It looks like the congo bongo water in Joe's second image. I don't think that's how the original programmers saw it, and it's not how I remember it from 35 years ago on a completely different TV. Is it my eyes or does the water in that congo bongo image look pink?

 

I appreciate all this effort.

 

Edit: I should have mentioned that I am using a real ntsc Intellivision (sears model).

 

Thinking about this a little more. I remember TVs of the early 1980s had a problem with red bleed and we often adjusted red down to avoid this. My newer year 2000 trinitron probably does a much better job displaying red. Maybe the guys at Mattel Electronics added a bit more red to some colours to compensate for the TVs of the day, so now light-blue looks pinkish/purple.

 

The "light blue" color has always been a weird, frustrating one for me. It has a definite purplish/violet hue on my TV, but can look close enough to "sky blue" in context that some games use it. However, "violet" is apparently has a wide palette all its own, see below.

 

The other choice for sky blue is cyan, which is too greenish on some TVs.

 

 

 

The water in that Congo Bongo image looks purple to me but moving towards the reddish side, so I can see why it may look pink on some TVs.

 

I haven't played B-17 Bomber in a while, but wasn't the sky "Cyan" instead of "Light Blue"?

 

Both B-17 Bomber and Thin Ice use the "light blue" color for sky. It's decidedly close to violet on my TV.

 

 

Also a quick aside: I discovered once upon a time that different peoples' dividing line between what's "pink" and what's "purple" is very person-dependent. The pink-purple axis is a weird one. I can point at a color and call it "purple" and be told "that's pink."

 

Looking at Wikipedia's color list at the bottom of this page, I can say that the Intellivision "light blue" color looks somewhere between "Lavender (floral)" and "Mauve" on many TVs, while a slight tweak of the tint knob can move it more toward "Wisteria" or "Periwinkle." Wikipedia calls these all "shades of violet."

 

Edited May 25, 2018 by intvnut

[carlsson]

Stupid question, but has any component inside the Intellivision aged in the past nearly 40 years so those would produce slightly different colours today? Would replacing said components then make a difference on what you see on screen?