I'm wondering about the SoG and YPrPb thing. In SoG mode with NeoYume the sync is definitely working as I have a stable image. It appears that red and blue colour channels are present in the image where expected, but there's just no green channel video on screen, and what is meant to be white is coming out purple (red+blue), instead of red+blue+green. I still wonder if the levels are setup right or if this thing expects negative 0.3V on green for sync and the different P2 DAC offsets are messing it up. Perhaps the DC restoration during the horizontal blanking intervals is not doing the correct thing to setup the DC levels...? The ADC's are AC coupled on each channel so I would have thought they can work independently but who knows. It could also potentially require i2c access to fully enable SoG perhaps via registers, although I'd imagine it should be possible to detect automatically - and it's already dealing with the lack of sync on H&V on its own too.
I also probed the input impedance of the SOG pin when unpowered and its like 28 mega-ohms, same as each video input. I guess I could probe it with a scope to see if anything is pulling down the green signal on the ADC side while running..?
EDIT: Yeah, on the scope, the green input pin (GIN in schematic) is pulled down to zero voltage at the blanking level after the input coupling cap. So DC restoration is happening and the sync tips go negative. On blue and red channels at BIN, RIN, they actually rise by about 0.2V, same with the SOG pin, surprisingly.
Yeah it's definitely doing something weird. If we had the datasheet we'd know better.
Here's the test that shows RGB levels increasing independently in SOG mode and what is displayed on the monitor. Red and Blue seem okay but green behaves like luminance Y.
Lighting here is bad for the photo but you can see red and blue channels are okay, in real life the green bar is actually a grey scale, and the white bar is actually magenta. Maybe YPbPr really does this although I thought Pb/Pr were colour differences not real red and blue. EDIT: actually they would be the difference if Y=0 when green is not present.
@Rayman said:
Maybe feed the full green signal to the sog pin? Just a thought. Maybe it’s looking there for video and sync…
I do actually feed green into SOG via a capacitor. I also wondered whether SOG was a logic level input that puts it into SOG mode and takes the data from GIN. GIN behaves differently to SOG as far as that DC restoration step.
I told you, it's trying to do YPbPr->RGB conversion. Just use YPbPr then. It's free. (In my driver SoG and YPbPr have the same code path, it's just the matrix settings that are different).
The reason you see the red/blue bars instead of the perhaps expected cyan-gray-red and yellow-gray-blue is because the Pb=Pr=0 white point is calibrated during blanking (that DC restoration circuit at work). Pb/Pr would blank at roughly mid level, so when it needs to it can go negative. R/B blank at zero, so they can never go negative. Also notice that the red/blue bars in your picture saturate at roughly the half way point.
@Wuerfel_21 said:
I told you, it's trying to do YPbPr->RGB conversion. Just use YPbPr then. It's free. (In my driver SoG and YPbPr have the same code path, it's just the matrix settings that are different).
We can certainly use component, I'm just trying to figure out what's actually wrong with SoG operation and why it's not working at all. This chip advertises having that capability with the SOG pin input and also automatically distinguishing between VGA and YPrPb (probably only possible via hsync/vsync/sog signals?). I may not be feeding in the signal in correctly, or its SOG pin might be a logic level input or its expecting a separately decoded external sync etc. In the block diagram the ADC is attached to the green channel which is doing DC restoration for sure unlike the other channels - although it would need to do that too for YPrPb. SOG seems to feed into the sync logic block only. If I remove this 1nF capacitor on my board feeding SOG I could try pulling it high or low via a resistor or feeding via another cap to the green input pin GIN directly perhaps to see if that does something else with the already clamped input level. I may try that today.
Much more likely: this is configured using that EEPROM business and the default is auto detect on sync type, because that way you can use the same bare chip for both VGA and YPbPr converter boxes. Consider the fact that sync-on-green basically does not exist as an output format in consumer electronics.
@Wuerfel_21 said:
Much more likely: this is configured using that EEPROM business and the default is auto detect on sync type, because that way you can use the same bare chip for both VGA and YPbPr converter boxes. Consider the fact that sync-on-green basically does not exist as an output format in consumer electronics.
It could also be via an i2c register, but then why even need the separate pin?
Yeah I think so. I just patched NeoVGA SOG to setup the colourspace converter like this and this was the result. It's a nicer ramp in real life, photo exposure makes it look too bright at lower ramp levels. This was also possible with true component in the past using just the Y signal IO pin IIRC for analog video setups.
A setup with a converter like this could allow HUB RAM based monochrome 1080p to an HDMI monitor with a ~254kB framebuffer (if that's useful - maybe for large signage apps etc). Over time as component & VGA options disappear even more something like this will become useful when you need high refresh rate HDMI or DVI output at resolutions higher than VGA. With external RAM we can get 1080p60 and 256 colours.
cmode_sync_on_green ' RGB SoG mode
long $00_00_00_00 ' DAC blanking value
long Y_BLANK ' Blanking color
long Y_SYNC ' HSync color
long Y_SYNC ' VSync color
long Y_BLANK ' HSync+VSync color
long 0 ' Color burst color (NTSC/PAL only)
long 0 ' Color burst frequency (NTSC/PAL only)
'long $5A_00_00<<8 + BLANK_LEVEL ' CY
'long $00_5A_00<<8 + BLANK_LEVEL ' CI
'long $00_00_5A<<8 + BLANK_LEVEL ' CQ
long $00_00_00<<8 + BLANK_LEVEL ' CY
long $00_5A_00<<8 + BLANK_LEVEL ' CI
long $00_00_00<<8 + BLANK_LEVEL ' CQ
long 0 ' CQ XOR value (NTSC/PAL only)
@Wuerfel_21 said:
The reason you see the red/blue bars instead of the perhaps expected cyan-gray-red and yellow-gray-blue is because the Pb=Pr=0 white point is calibrated during blanking (that DC restoration circuit at work). Pb/Pr would blank at roughly mid level, so when it needs to it can go negative. R/B blank at zero, so they can never go negative. Also notice that the red/blue bars in your picture saturate at roughly the half way point.
You are right about the levels. When I generate real YPbPr in NeoVGA then the colour ramp is equal for R,G,B channels on the 240p tests. But if I choose SoG output in NeoVGA then the blue and red ramps are offset higher to begin with and saturate early. So it does appear that SoG is just mistaken for component in this device, and some other mechanism would be needed for true VGA SoG operation with 3 pins. Guessing it's in the register settings which potentially may be read in via an I2C EEPROM. My Simplecom CM201 has an empty I2C EEPROM location on the board for that (separate from the local EDID EEPROM to VGA), although that product uses a MS9288 not an MS9288A and may have a different pinout and/or functionality again.
Few other data points. If I ground either the GIN or SOG pins during operation then sync drops out and the picture disappears for NeoVGA's SoG and YPrPb modes. However in RGBHV modes, grounding SOG has no effect and grounding GIN just drops the green channel from the display but sync remains. Grounding blue or red just drops that colour channel from the display regardless of the mode. So the SOG pin seems to need to be wired for YPrPb operation as well as also having Y going to GIN - it's probably using the same circuitry to get at the sync on that channel.
Comments
Interesting that font is readable, but the character sprites suffer from the classic "uneven eyes" syndrome.
I'm wondering about the SoG and YPrPb thing. In SoG mode with NeoYume the sync is definitely working as I have a stable image. It appears that red and blue colour channels are present in the image where expected, but there's just no green channel video on screen, and what is meant to be white is coming out purple (red+blue), instead of red+blue+green. I still wonder if the levels are setup right or if this thing expects negative 0.3V on green for sync and the different P2 DAC offsets are messing it up. Perhaps the DC restoration during the horizontal blanking intervals is not doing the correct thing to setup the DC levels...? The ADC's are AC coupled on each channel so I would have thought they can work independently but who knows. It could also potentially require i2c access to fully enable SoG perhaps via registers, although I'd imagine it should be possible to detect automatically - and it's already dealing with the lack of sync on H&V on its own too.
I also probed the input impedance of the SOG pin when unpowered and its like 28 mega-ohms, same as each video input. I guess I could probe it with a scope to see if anything is pulling down the green signal on the ADC side while running..?
EDIT: Yeah, on the scope, the green input pin (GIN in schematic) is pulled down to zero voltage at the blanking level after the input coupling cap. So DC restoration is happening and the sync tips go negative. On blue and red channels at BIN, RIN, they actually rise by about 0.2V, same with the SOG pin, surprisingly.
Maybe feed the full green signal to the sog pin? Just a thought. Maybe it’s looking there for video and sync…
Yeah it's definitely doing something weird. If we had the datasheet we'd know better.
Here's the test that shows RGB levels increasing independently in SOG mode and what is displayed on the monitor. Red and Blue seem okay but green behaves like luminance Y.
Lighting here is bad for the photo but you can see red and blue channels are okay, in real life the green bar is actually a grey scale, and the white bar is actually magenta. Maybe YPbPr really does this although I thought Pb/Pr were colour differences not real red and blue. EDIT: actually they would be the difference if Y=0 when green is not present.
I do actually feed green into SOG via a capacitor. I also wondered whether SOG was a logic level input that puts it into SOG mode and takes the data from GIN. GIN behaves differently to SOG as far as that DC restoration step.
Think Chip said he used AI on the datasheet and got something…
I told you, it's trying to do YPbPr->RGB conversion. Just use YPbPr then. It's free. (In my driver SoG and YPbPr have the same code path, it's just the matrix settings that are different).
The reason you see the red/blue bars instead of the perhaps expected cyan-gray-red and yellow-gray-blue is because the Pb=Pr=0 white point is calibrated during blanking (that DC restoration circuit at work). Pb/Pr would blank at roughly mid level, so when it needs to it can go negative. R/B blank at zero, so they can never go negative. Also notice that the red/blue bars in your picture saturate at roughly the half way point.
We can certainly use component, I'm just trying to figure out what's actually wrong with SoG operation and why it's not working at all. This chip advertises having that capability with the SOG pin input and also automatically distinguishing between VGA and YPrPb (probably only possible via hsync/vsync/sog signals?). I may not be feeding in the signal in correctly, or its SOG pin might be a logic level input or its expecting a separately decoded external sync etc. In the block diagram the ADC is attached to the green channel which is doing DC restoration for sure unlike the other channels - although it would need to do that too for YPrPb. SOG seems to feed into the sync logic block only. If I remove this 1nF capacitor on my board feeding SOG I could try pulling it high or low via a resistor or feeding via another cap to the green input pin GIN directly perhaps to see if that does something else with the already clamped input level. I may try that today.
Much more likely: this is configured using that EEPROM business and the default is auto detect on sync type, because that way you can use the same bare chip for both VGA and YPbPr converter boxes. Consider the fact that sync-on-green basically does not exist as an output format in consumer electronics.
It could also be via an i2c register, but then why even need the separate pin?
Can one do white on black with just one p2 pin?
Yeah I think so. I just patched NeoVGA SOG to setup the colourspace converter like this and this was the result. It's a nicer ramp in real life, photo exposure makes it look too bright at lower ramp levels. This was also possible with true component in the past using just the Y signal IO pin IIRC for analog video setups.
A setup with a converter like this could allow HUB RAM based monochrome 1080p to an HDMI monitor with a ~254kB framebuffer (if that's useful - maybe for large signage apps etc). Over time as component & VGA options disappear even more something like this will become useful when you need high refresh rate HDMI or DVI output at resolutions higher than VGA. With external RAM we can get 1080p60 and 256 colours.
That sounds great. I do have an old 1080p color text driver that might also be useful…
You are right about the levels. When I generate real YPbPr in NeoVGA then the colour ramp is equal for R,G,B channels on the 240p tests. But if I choose SoG output in NeoVGA then the blue and red ramps are offset higher to begin with and saturate early. So it does appear that SoG is just mistaken for component in this device, and some other mechanism would be needed for true VGA SoG operation with 3 pins. Guessing it's in the register settings which potentially may be read in via an I2C EEPROM. My Simplecom CM201 has an empty I2C EEPROM location on the board for that (separate from the local EDID EEPROM to VGA), although that product uses a MS9288 not an MS9288A and may have a different pinout and/or functionality again.
Few other data points. If I ground either the GIN or SOG pins during operation then sync drops out and the picture disappears for NeoVGA's SoG and YPrPb modes. However in RGBHV modes, grounding SOG has no effect and grounding GIN just drops the green channel from the display but sync remains. Grounding blue or red just drops that colour channel from the display regardless of the mode. So the SOG pin seems to need to be wired for YPrPb operation as well as also having Y going to GIN - it's probably using the same circuitry to get at the sync on that channel.