Wrong scanline on 240P (chroma not darkened)

[ArcheyChen]

I get a prebuild gbsc, and try using it to connect my ps1 to a CRT monitor with VGA input.

while there is an option to turn on the scanline, the line that was supposed to be black didn't go completely black.

It looks like a filter aiming to have a crt-like display on LCD, but display wrong on crt.

Any option to make the scanline completely black?

[ArcheyChen]

I look the code, and it seems like GBS::MADPT_VIIR_COEF::write(0x08); write some param to the VIIR filter.

I don't know what a VIIR filter is, but based on its name, it looks like a V-IIR filter, which will blend the lines.

That can explain why even I turn the scanlineStrength to zero, I still see colors at the line that suppose to be completely black

Am I correct?

[ArcheyChen]

also, with some google, I found that 240p@120 hz will make crt display scanlines( 240p@60hz can't display on many crts)

it can also increase the brightness.like: https://imgsli.com/MTE2MDQ

and dooklink/gbs-control repo has a double scan mode set.

don't know the relation between these two projects, but can you add 120hz support as well?

https://github.com/dooklink/gbs-control/blob/master/settings/RGBHV_320x240%40120Hz_RGB_240p60.set

[ArcheyChen]

        GBS::MADPT_VIIR_COEF::write(0x00);                     // 2_27 VIIR filter strength
        GBS::MADPT_Y_MI_OFFSET::write(0); // 2_0b offset (mixing factor here)

I turn these 2 params to 0, but it will still blend the colors.

I noticed that the white and yellow color seems fine, but red and blue will mix to blank lines.

Is this a software issue or a hardware issue?

Any chance to fix it?

[ramapcsx2]

Hey, please realize that these scanlines aren't an intended hardware feature, but an interesting exploit. :) And as such, feel free to tune anything you see to your liking, but don't expect any form of "correct" look or anything. Pick what looks fine.

[ArcheyChen]

Hey, please realize that these scanlines aren't an intended hardware feature, but an interesting exploit. :) as such, feel free to tune anything you see to your liking, but don't expect any form of "correct" look or anything. Pick what looks fine.

Can you tell me how does the scanline filter work?

I can't find any document, and I don't know what will happen if I change the registers.

I can only see the code that changes the registers, but didn't find a code that uses it.

I couldn't find the Vram either, dose gbsc use a Vram?

Like, what will I need to do if I want to draw something on screen?

I will be glad if you can provide some link to the document, thanks.

[ramapcsx2]

You have the right idea how this thing might work, but you're asking the wrong person to confirm or deny any details. I basically toggled bits when exploring the ASIC register space, and this register had an interesting effect. This is saying, I found this useful bug by accident, and some other registers would affect the scanline look. I can guess that the hardware is trying to blend fields, one of which would be from non-configured DRAM, and that one might be a black line.. but that's the best I can do as well :)

[nyanpasu64]

First you're probably better off switching to 1280x960 output and enabling "line filter" for (IMO) optimal scanline appearance. Then try pressing the "intensity" button next to "scanlines" until the dark lines become dark enough for your tastes.

[nyanpasu64]

Is the problem fixed and working to your satisfaction? If so, could you close the issue to avoid cluttering the issue list?

[ArcheyChen]

Is the problem fixed and working to your satisfaction? If so, could you close the issue to avoid cluttering the issue list?

Actually, no.

pressing the "intensity" button next to "scanlines"

this will dark the lines, but not completely black.

[nyanpasu64]

I did testing on 240p Test Suite's "Color Bars". Interestingly, with Scanline Strength: 0, I get colored lines between adjacent red lines, and adjacent blue scanlines (less so on green), but none on white areas. Is this consistent with your observations? (EDIT: Reading your earlier messages, it seems correct.)

I think this occurs because the dark lines (emulated scanline gaps)' luma is properly sourced from a black "virtual previous field" (producing dark lines between input lines), but chroma is incorrectly blended between adjacent lines on the current field (causing dark lines to pick up the dominant color of their adjacent lines). I don't know if this can be fixed, and don't have time to look into it at the moment.

[ArcheyChen]

and what about 240P@120hz? I see the dooklink version has a profile of 120hz, is is possible porting it to this repo?

[nyanpasu64]

I found that uncommenting both code blocks labeled by "following lines set up UV deinterlacer", fixes scanlines such that blue lines are properly darkened. The code was added in https://github.com/ramapcsx2/gbs-control/commit/81a0d53a17b1dafedc5fae9afd7ea2f8f755c27f, but commented out from the get-go.

I don't know if there are negative side effects to uncommenting these lines; for example rama mentioned something like 1 frame latency in chroma or luma deinterlacing? @ramapcsx2 do you remember why you commented-out this code initially?

• While doing slow-motion camera testing (PXL_20231030_115142583.mp4), I did not find any change in latency in 240p Test Suite between scanlines on and off (either way, after pressing a button to navigate a menu, there's 1 frame of no response, and the next frame had proper luma and chroma).
  • I did notice that the first frame's colors appeared to be slightly desaturated compared to the second, so I performed more testing:
• When switching between a white and blue screen (PXL_20231030_115938855.mp4), proper scanlines also appeared to appear immediately on the first blue frame, without blue light appearing in the gaps of the image.

        // following lines set up UV deinterlacer (on top of normal Y)
        GBS::MADPT_UVDLY_PD_SP::write(0);     // 2_39 0..3
        GBS::MADPT_UVDLY_PD_ST::write(0);     // 2_39 4..7
        GBS::MADPT_EN_UV_DEINT::write(1);     // 2_3a 0
        GBS::MADPT_UV_MI_DET_BYPS::write(1);  // 2_3a 7 enables 2_3b adjust
        GBS::MADPT_UV_MI_OFFSET::write(0x40); // 2_3b 0x40 for mix, 0x00 to test
        GBS::MADPT_MO_ADP_UV_EN::write(1);    // 2_16 5 (try to do this some other way?)

Looking at the register docs:

• [ ] I don't know what MADPT_UVDLY_PD_SP or MADPT_UVDLY_PD_ST mean.
• MADPT_EN_UV_DEINT probably enables UV deinterlacing.
• MADPT_UV_MI_DET_BYPS forces "deinterlacing" to use MADPT_UV_MI_OFFSET as an "is pixel moving" value?
• MADPT_UV_MI_OFFSET is a 7-bit register. When set to 0 or 64, I see scanlines in blue colors, and when set to 127, the scanlines vanish.

Apparently MADPT_UV_MI_OFFSET is a 7-bit "is pixel moving" index, where low values weave the previous "field" (black) with the current one (as if the scene was still), and high values interpolate adjacent scanlines on the current field (as if the scene was moving).

• To better test the GBS-C's deinterlacing algorithm visually, I set it to output a 480p signal (so I can resolve individual output scanlines after line-doubling).
• When I set Scanline Strength: 0 to hide faint lines in scanline gaps, when MADPT_UV_MI_OFFSET is set to 64 I can still see faint blue lines in between lit scanlines! DSC00942.JPG
  • For "proper" color output, I have to set MADPT_UV_MI_OFFSET to 0, which eliminates these mid-scanline colors entirely. DSC00943.JPG
• The problem is that now, when I set Scanline Strength: 50 (which produces visible colors in gaps between white scanlines DSC00945.JPG), I see no lit lines between blue scanlines! DSC00946.JPG
  • I guess there's just too little luma when multiplying a blue scanline by 50/128 and setting chroma to zero, to illuminate any phosphors on my monitor.
• [x] For consistency between luma and chroma, we need to set MADPT_UV_MI_OFFSET value based on the "Scanline Strength" value (MADPT_Y_MI_OFFSET, also 7 bits) rather than hard-coding a value! I will be testing this later when I have a chance.

...

• [ ] The final line GBS::MADPT_MO_ADP_UV_EN::write(1); // 2_16 5 (try to do this some other way?) sounds concerning, is this badly designed? It seems to work?

[nyanpasu64]

@ArcheyChen do you want to test #508? (git fetch && git checkout fix-chroma-scanlines)

[ramapcsx2]

Oh I don't remember any reasoning for any of the values. Try to make it look good, test it on some other displays and other source consoles, and it'll be fine? A lag test setup will be required to tell if the changes add any more latency.

[nyanpasu64]

Try to make it look good, test it on some other displays and other source consoles, and it'll be fine? A lag test setup will be required to tell if the changes add any more latency.

https://github.com/ramapcsx2/gbs-control/pull/508#issuecomment-1788758345