Bench-testing AY-3-8915

[JohnPCAE]

I'm trying to get the ground truth on what the AY-3-8915 actually outputs on the color lines for each color for the purpose of color matching. To that end, I've cobbled together a little circuit where I toggle its OSC IN pin with a button and a pulldown resistor, and I have LED's (with inline resistors, of course) connected to its four outputs. However, I'm not getting anything out, nor am I seeing anything on it's clock-out pin. Has anyone else bench-tested one of these chips? I'm wondering if there's anything special that I need to do to get it to output with a clock input instead of using a crystal.

[walldog1]

4 hours ago, JohnPCAE said:

I'm wondering if there's anything special that I need to do to get it to output with a clock input instead of using a crystal.

You could buy a frequency generator, but to get to 3.579545Mhz, you'll have to spend $100 or more. Probably easier just to use the crystal circuit from the Logic Board.

 

Do you have a picture of your set-up? I think myself and others would like to see that.

[JohnPCAE]

It's nothing too complex, just the chip with a button to send pulses to the osc in pin, jumpers for the 5 inputs, and LED's on the four outputs. I get power and ground from an Arduino that I can plug into my USB port. I suppose I could write some Arduino software to try driving it and reading the outputs but I'd prefer to just clock it manually.

 

[walldog1]

2 hours ago, walldog1 said:

but to get to 3.579545Mhz

I typed an error. 7.15909Mhz is needed as the color chip divides that in half for the clock output. I would take the crystal & capacitors from a spare board and work that into pins 2 & 3.

[JohnPCAE]

I could do that, but my eyes can't read the LED's at that rate ? The point of this exercise is to determine what the output values actually are.

[walldog1]

1 minute ago, JohnPCAE said:

I could do that, but my eyes can't read the LED's at that rate ? The point of this exercise is to determine what the output values actually are.

I misunderstood then. Can the chip work without anything connected to pins 2 & 3? When you say output values, what type of measurement are you after? Or, what are you expecting to happen with the LED's?

 

Maybe this is beyond my scope of understanding.

[JohnPCAE]

The LED's are there simply to read out the outputs. The reason for all of this is because there is conflicting information as to what the chip actually outputs to video: the datasheet says one thing and an internal Mattel document says something else. I'm working on generating calibrated color values for my video overlay project and I want to be able to numerically compare it to what the Inty outputs, but for that I need an accurate representation of what the color chip actually outputs. Long story short, I need to know which is right: the chip's datasheet, the Mattel document, or if they're both incorrect, what the true outputs from the chip are.

[walldog1]

6 minutes ago, JohnPCAE said:

I need to know which is right: the chip's datasheet, the Mattel document, or if they're both incorrect

Ahhh, I did not know there was conflicting info. Schematic says Pin 9 = Luminance, Pin 10 = Color, Pin 11 = Horizontal Pin 12 = Vertical.

 

I have never read the chip's datasheet, only Mattels description of color chip operation & what the electrical schematic says.

 

My last job sometimes involved measuring color absorption, and graphing the visible wavelength spectrum and the amount of absorption at each individual wave length. So when I hear color value, I am thinking about the ROYGBIV and corresponding wavelengths. This is obviously not what you are after, I wouldn't think. So what does "value" mean in terms of a measurement name? This is where I am losing your thought process.

 

I probably can't be of any help, so hopefully someone else reads this topic and can help you out. I am interested about this though, and will continue to follow and learn something new.

[JohnPCAE]

The chip has four digital outputs that are used to generate color on the Intellivision. They get fed into a resistor ladder that does the D-A conversion, but there is conflicting information as to what the output values are based on the color selected and the clock cycle. The datasheet gives one set of values and the Mattel document gives a slightly different set. And, to top it off, both documents have mistakes in them. So I want to get to the truth of the matter so I know what I'm comparing my outputs to.

 

In another life I was responsible for interfacing X-Rite spectrophotometers so a certain well-known chemical and textiles company could market their inks and paper as supremely accurate, but that doesn't really apply here (well, it could, if I had a spectrophotometer,  but I have to rely on letting my video capture hardware give me color output results instead). At this point I just want a known baseline for the Intellivision color chip. For the past couple of nights I've been hip-deep in YIQ <--> RGB color conversion math but I first need a known baseline.

Edited February 6, 2022 by JohnPCAE

[+5-11under]

I don't have it any more, but at one point I plotted the output waves for each color, using Excel. The time shift I could grossly match to the color. I seem to recall one of the browns or tans or oranges was not what I expected, but everything else looked good.

 

A few considerations... you could set up the Arduino to clock the chip, and handle the inputs. You should be able to vary the frequency to some reasonable level. The "Test" color might be helpful. Debounce/noise might be an issue if you're using a switch to do the clocking. The resistor values are also going to be key. Did Mattel follow the Datasheet? Tolerances might be 5%. Also, in the data sheet, the values don't exactly double/half.

 

Do you have a link to the Mattel data?

[JohnPCAE]

https://papaintellivision.com/pdfs/CCF10232011_00012.pdf

 

The document is 112Mb as it contains a ton of different things, but the pertinent info is on page 96. The values listed differ quite a bit from the datasheet, and the values for brown (color 12) are clearly wrong. 9-9-5-5 gives a blue color, you have to invert the phase to 5-5-9-9 to get brown.

 

The way NTSC color works is that each pixel gets modulated by a single sine wave at 3.579545 MHz, and the phase of the sine wave denotes the hue. For each color listed in the table, the four values represent four points on the sine wave 90 degrees apart. The amplitude denotes color saturation, and the bias at the center of the wave denotes brightness. So if you want to calculate the color it's really important to know what the chip is really outputting.

 

The four values therefore represent the outputs during the four timeslices in the sine wave, for an effective output frequency of 14.31818 MHz.

Edited February 6, 2022 by JohnPCAE

[walldog1]

26 minutes ago, JohnPCAE said:

For the past couple of nights I've been hip-deep in YIQ <--> RGB color conversion math but I first need a known baseline.

Yes, this is way beyond my knowledge. You did mention you had an Arduino in first post, but I had no clue what it was and what it can do. What "5-11under" mentioned sounds like you can generate varying frequencies with it. His suggestion sounds like it makes sense. I'll just stay in the background and watch.

 

And I did not know the outputs were digital...... but makes sense in that it is where we tap off of to the Mod boards. Thanks for explaining that all to me! I like learning continually!

[+Lathe26]

Just as a heads up, I'm working on measuring and computing the real RGB values based off of YIQ measurements from a vectorscope for the Intellivision.  Getting close-ish is easy but nailing down with precision is much harder and currently in progress.

[walldog1]

2 minutes ago, Lathe26 said:

Just as a heads up, I'm working on measuring and computing the real RGB values based off of YIQ measurements from a vectorscope for the Intellivision.  Getting close-ish is easy but nailing down with precision is much harder and currently in progress.

I thought there was another post on this subject. I remember you mentioning this not too long ago.

[walldog1]

34 minutes ago, JohnPCAE said:

The four values therefore represent the outputs during the four timeslices in the sine wave, for an effective output frequency of 14.31818 MHz.

Now I know why OSSC's inputs are 15Khz for lower pixel ratings! The maker of the Mod kits could not answer my question about the output Hz. That whole post was very informative and I understood all of it, as I understand all the electrical theory behind it. Keep my brain going guys (& gals)!

[JohnPCAE]

Okay, I got it. It appears that you can't drive the color chip at any frequency you like. If you drive it too slowly it freaks out. I had to have the Arduino drive it as fast as possible, cache the results in memory, and send them over the serial port to my PC when all the data was collected. Attempting to send the data as I read them causes the process to slow down too much for the chip to handle. It turns out that the internal Mattel document is almost correct (it gets Brown backwards) and doesn't account for an additional set of output values.

 

I also learned that the outputs of the color chip are open-collector: for a logic 1 it puts a pin in high-impedance mode and does NOT drive it high. So if you want to read them like this in a bench test you have to use a pullup resistor. Conveniently, the Arduino has those built in and I can just enable them in software. Below is the table of my findings.

 

Note: Outputs are open-collector

V5	V4	V3	V2	V1		+Q	-I	-Q	+I	Color
---------------------------------------------------------------------------------------------
0	0	0	0	0		4	4	4	4	Black
0	0	0	0	1		8	12	7	1	Blue				
0	0	0	1	0		10	4	7	14	Red
0	0	0	1	1		10	8	12	12	Tan
0	0	1	0	0		3	9	12	7	Grass Green
0	0	1	0	1		5	11	13	8	Green
0	0	1	1	0		10	7	15	15	Yellow
0	0	1	1	1		13	13	13	13	White
0	1	0	0	0		9	9	9	9	Gray
0	1	0	0	1		8	13	12	7	Cyan
0	1	0	1	0		10	6	11	14	Orange
0	1	0	1	1		5	5	9	9	Brown
0	1	1	0	0		14	6	4	12	Magenta
0	1	1	0	1		13	13	7	7	Light Blue
0	1	1	1	0		6	10	14	11	Yellow-Green
0	1	1	1	1		12	7	4	9	Purple
1	0	0	0	0		4	4	4	4	Blanking
1	0	0	0	1		0	0	0	0	Sync
1	0	0	1	0		2	2	6	6	Color Burst
1	0	0	1	1		15	15	15	15	N/A
1	0	1	0	0		4	4	4	4	Blanking
1	0	1	0	1		0	0	0	0	Sync
1	0	1	1	0		2	2	6	6	Color Burst
1	0	1	1	1		15	15	15	15	N/A
1	1	0	0	0		4	4	4	4	Blanking
1	1	0	0	1		0	0	0	0	Sync
1	1	0	1	0		2	2	6	6	Color Burst
1	1	0	1	1		15	15	15	15	N/A
1	1	1	0	0		4	4	4	4	Blanking
1	1	1	0	1		0	0	0	0	Sync
1	1	1	1	0		2	2	6	6	Color Burst
1	1	1	1	1		0	15	0	15	Test

 

[JohnPCAE]

2 hours ago, Lathe26 said:

Just as a heads up, I'm working on measuring and computing the real RGB values based off of YIQ measurements from a vectorscope for the Intellivision.  Getting close-ish is easy but nailing down with precision is much harder and currently in progress.

I don't know if this helps, but in my attempts to calculate RGB from the QI values given in the chip's table, I had to apply a phase advancement of about 23 degrees to get the hues to match. I'm at a loss to explain why. Also, for some reason I've so far been unable to calculate accurate brightness levels using the standard YIQ to RGB conversion coefficients. Some are too bright, some are too dark, and a few are dead on.

Edited February 6, 2022 by JohnPCAE

[+nanochess]

Your tables are very similar to what intvnut got some years ago (post #12)

The values you require for Y R-Y B-Y are available in a Papa Intellivision document (see page 4) http://papaintellivision.com/pdfs/CCF10242011_00001.pdf

 

 

 

 

[JohnPCAE]

2 hours ago, nanochess said:

Your tables are very similar to what intvnut got some years ago (post #12)

The values you require for Y R-Y B-Y are available in a Papa Intellivision document (see page 4) http://papaintellivision.com/pdfs/CCF10242011_00001.pdf

 

 

 

 

Thanks. I've calculated new RGB colors from those, and of course those are very different from what I'm seeing on-screen. What a mess. I'm beginning to understand why NTSC is sometimes called Never the Same Color.

 

Part of my problem is that I have a lot of noise in my composite output. Yesterday I redesigned my composite mod board and ordered new ones, and I'll try to score a shielded cable for getting the signals to it.

Edited February 6, 2022 by JohnPCAE

[walldog1]

53 minutes ago, JohnPCAE said:

and I'll try to score a shielded cable for getting the signals to it

Shielding and grounds are sooooo very important, although you probably know this. In the industrial manufacturing field, I solved many non function equipment just by grounding the shielding & ground wires correctly. Never skimp on cables!

[First Spear]

On 2/6/2022 at 12:27 PM, nanochess said:

Your tables are very similar to what intvnut got some years ago (post #12)

The values you require for Y R-Y B-Y are available in a Papa Intellivision document (see page 4) http://papaintellivision.com/pdfs/CCF10242011_00001.pdf

 

 

 

 

This also exists in an OCR'd searchable format at https://media0101.intvprime.com/ba4ef/intellivision-echo/References-Unsorted/papaintellivision.com/pdfs-searchable/CCF10242011_00001.pdf

[Walter Ives]

On 2/5/2022 at 5:02 PM, JohnPCAE said:

The reason for all of this is because there is conflicting information as to what the chip actually outputs to video: the datasheet says one thing and an internal Mattel document says something else. ... I need to know which is right: the chip's datasheet, the Mattel document, or if they're both incorrect, what the true outputs from the chip are.

The color chip has two parts, a clock oscillator and a high-speed ROM. Anybody could buy the chip set from GI and GI would program that ROM to their liking, so the values in the catalog were just GI's suggestions. The document you later cite as https://papaintellivision.com/pdfs/CCF10232011_00012.pdf, p. 96 is a "Customer Procurement Specification" explicitly written as an attachment to the Mattel contract. The color values in it are Mattel's proprietary custom selection. GI was contractually obligated to meet this specification for the chips it delivered to Mattel. It was prepared with meticulous attention to detail and, with so much on the line, is less likely to contain an error than a published data sheet, so you can pretty much rely on it. Well, except that the values for the color Brown are wrong, and who knows what else. After all, it was hurriedly prepared by an engineer with better things to do.

[Walter Ives]

On 2/5/2022 at 7:07 PM, Lathe26 said:

Just as a heads up, I'm working on measuring and computing the real RGB values based off of YIQ measurements from a vectorscope for the Intellivision.  Getting close-ish is easy but nailing down with precision is much harder and currently in progress.

Cool. Just remember that the user was expected to use the TINT and COLOR controls on his TV set to rotate and stretch your pattern to get the colors he liked for the particular game he's playing. He could also adjust the luminance, but that won't show on your vectorscope; for that you'll have to switch to the waveform monitor.

Also, note that the resistors in the A-to-D converter are 2% resistors, so there will be some variation from unit to unit. So to really nail the colors down to the precision of 24 bit RGB you'd have to sample a statistically significant number of units.

Furthermore still, remember that the Astec modulator's filters modify the shape of the signal output by the resistor ladder, so you really have to look at the signal after it's been decoded by a TV tuner.

Sound like a lot of work? Life is hard, and then you die. Be thankful you don't live in Ukraine.

On 2/5/2022 at 9:19 PM, JohnPCAE said:

I don't know if this helps, but in my attempts to calculate RGB from the QI values given in the chip's table, I had to apply a phase advancement of about 23 degrees to get the hues to match. I'm at a loss to explain why. Also, for some reason I've so far been unable to calculate accurate brightness levels using the standard YIQ to RGB conversion coefficients. Some are too bright, some are too dark, and a few are dead on.

The values in the table are only first order approximations of the actual Q and I delivered to the TV set color decoder circuitry. The color chip is being clocked every 70 ns, once on each edge of the 7.16 MHz oscillator clock. That was kind of fast for the time and is part of the reason color generation wasn't integrated onto the STIC. The access time of the ROM is a significant fraction of the clock period. The chip outputs are possibly open collector, in which case they only drive down and you get asymmetric rise and fall times (check this). The value of C33 is a compromise. Brown and light blue change level twice per pixel, yellow and tan change level three times, the other colors change level four times. You really can't expect your calculations to yield "accurate" values unless they take all this asymmetry, filtering and sampling into account.

 

 

[JohnPCAE]

Ah. I can see how the ROM access time could create a phase delay, and C33 would definitely induce a phase delay. I suppose the combination of the two results in the 23-degree advance that I saw. The fact that C33 has a 10% tolerance is really striking.