# Attempting to reconstruct a simple analogue video RGB->YUV matrix (digital logic)

I’ve recently been trying to crack a difficult problem without much luck.

I’m trying to re-create an early analogue video text generator device which generates text overlays and outputs as either RGB or YUV and (apparently) has a jumper to select between the two.

PROBLEM:

It appears to perform RGB->YUV matrix in two 22V10 PALs (programmable array logic). I do not have the code for them, nor do I have a working sample to study. But I need to re-implement them.

The design is quite curly. The bytes from the EPROMs are serialised, then converted back to parallel in the PALs somehow magically converted to YUV. Inevitably there will be compromises on colour space. The PALs and DACs also appear to be unsynchronised with the input data making it even more of a headache!

They must be performing some kind of arithmetic. I’ve experimented with various ideas but nothing I’ve tried to work as I’d expect.

I can re-implement the PALs but thus far I have not even been able to construct a theory as to how they may work. That is all I am hoping somebody can help with!

• Here are the formulas pcmag.com/encyclopedia/term/yuvrgb-conversion-formulas and this stackoverflow.com/questions/17892346/… Sep 1, 2023 at 8:34
• It is impossible to implement it like that with such a simple circuit, I'm trying to unravel what tricks or potential comprimises have been utilised to pull it off! Sep 1, 2023 at 8:44
• There is likely no need for formulas. There is just few bits of pixel data and color index coming in, and this is just used as lookup table to convert a certain digital input pattern to certain digital output code for DAC. Of course we don't know what the mapping is but it could be guessed based on many things. Sep 1, 2023 at 8:44
• @Justme something I had not thought of yet! Just looking for ideas here! I can experiment once I have them! Sep 1, 2023 at 9:11

The EPROMs most probably provide bytes that represent 8 distinct horizontally-adjacent pixels, and (from the names like PGn, PBn, and PRn) I guess they are resposible for the G, B, and R color components.

The "27M" signal seems to be the pixel clock of supposedly 27 MHz. EPROMs have not been fast enough to provide data with that rate, so the parallel read of 8 pixels from the EPROM, serialized to single pixels in the 74HC166 shifters.

At their Q7 outputs, there seem to be the single-pixel G, B, and R values, only in 1-bit, meaning 8 possible colors (black, green, blue, red, cyan, yellow, magenty, and white). Thes 3 bits get fed into the PALs.

What confuses me, is that the 74HC164s get the same pixel data, delay them by 8 pixels, and feed this result into the first PAL as well. There also is a jumper labelled DELAY, maybe this is somehow related.

The PAL outputs drive D/A converters, from the signal naming responsible for Y, W and U. Y has a 7-bit resolution, W and U only 5 bits, surely enough for only 8 distinct colors.

PALs are quite simple devices, they don't have any hidden state, so what you see at the outputs is most probably directy controlled by the currently sampled input values.

Leaving aside the unclear role of the delayed pixels, the PALs are responsible for providing the YUV or RGB intensities to the D/A converters, functioning as high-speed lookup tables that provide 8 fixed YUV values for the 8 possible G/B/R combinations, or 8 fixed RGB values depending in the jumper'S "RGB" setting. This mapping could have been done in an EPROM, had they been fast enough.

• 27M is 27Mhz. But the video bandwidth of this thing is 3Mhz at most which makes it weird. Each byte of the eprom appears to represent a full level of luminance so not sure this theory quite works? I think the delay is to for luminance/chromimance alignment adjustment. Sep 1, 2023 at 12:14
• @MatthewMillman Not sure what is weird about it. Even if it has 3 MHz video bandwidth, which itself would be weird since both PAL and NTSC broadcasts have wider than 3 MHz video bandwidth, the 27 MHz clock allows you to place e.g. a white bar with horizontal position and width given in 27 MHz clock units, which is about 1440 pixels per line. With 3 MHz clock you would have only 156 pixels. Sep 1, 2023 at 13:37
• @Justme. Yes, the PAL or NTSC broadcast bandwidth is around 5 MHz, but it carries Y, U, and V, with Y getting most of it (around 3 MHz), and U and V much less. So, modelling it as three channels with each (at most) 3 MHz bandwidth is quite plausible. Sep 3, 2023 at 13:35
• @RalfKleberhoff This equipment is not only used for broadcast TV, it could be used as a test generator at a TV studio or TV manufacturing plant. 3 MHz is not enough, as even NTSC broadcast has video bandwidth up to 4.2 MHz, and PAL up to 6 MHz depending on broadcast standard. And this generator does produce frequencies beyond broadcast TV, such as 4.8 MHz bars. And to create the narrow white grid, you surely need all the bandwidth you can get, at 3 MHz the sharp narrow grid would be a wide blob of blurry smear. And, as mentioned, it can output RGB. Sep 3, 2023 at 14:03

The PAL chips are just used as color look-up table (CLUT) for converting a digital code (used as index into the table) to a set of three digital codes representing the three DAC input for getting a specific RGB or YUV voltage triplet based on the given color index.

• An interesting idea. So just 8 possible values presented to the DACs? And what about when in RGB mode? How would you get an output with 1 bit of input? Sep 1, 2023 at 11:25
• I imagine the inputs are the same in both RGB/YUV mode (colour code + pixel values), and I assume that the output are from the same DAC converters, just connected with different cables. In that case, with RGB mode the 7 bit/ 5 bit parallel outputs to the DACs would most likely be 0 or 11111b (or perhaps some other fixed value to give the correct voltage level for the RGB signal) set according to whether the color code had a 1 or 0 in the relevant channel. (The greater DAC resolution is only needed for the more complex YUV encoding.) Sep 1, 2023 at 11:59

Rather than arithmetic, I'd strongly suspect it just uses a lookup table to convert the bit and colour data input into the required output values for the DAC.

This scheme is quite similar to some of the display logic used in the old ZX Spectrum, and you might get mileage from some of the converter modules which allow their connection to modern monitors ZX Spectrum PAL Composite Video to North American Monitor .