gbs-c incorrect aspect ratio

[mrchief]

using 1080p preset, one of two presets tv supports via HDMI, and 720p is messed up with scaling. But i get stretched image compared to my TV scaler. Tried to use scaling settings, but it maxes out (cannot correct more) and still is not perfect 4:3.

PAL PS2.

[NoAffinity]

Im not sure infollow the question but here's the basics as far as gbs-c processing:

1) 1080 P is a 4:3 image imposed on a 16:9 canvas (will have pillar boxes)
2) 720p is the only true 16:9 image

If you have a "direct" or similar aspect setting on your tv, this will pass through the image as it is output by gbs-c, and you can expect the above. The 720p profile is good for scaling 16:9 480p signals.

[mrchief]

Made some catpures. Discovered that GBSC crushes blacks. RGB ranges are matched. PS2 native captures is from component and RGB scart is for GBSC, i dont have PS2 component cables, my capture card has custom ones.

https://imgur.com/a/2ypPkEb

And aspect ratio thing, on TV looks Ok, bus image is shifted to the left. Probably LCD monitor had its own thing, even it was automatically set to 16:9. need doublecheck.

[mrchief]

ok, black crush was just color correction issue needed brightness +13, could be needed more. But shouldn't default setting be in tune with input signal? Will try to increase contrast to match brightness of direct capture. Very bizarre.
emulated sega captures (ps2) for comparison:
https://imgur.com/a/34BrqbP

[mrchief]

left - GBSC, PS2 PAL, RGB - HDMI (1080p preset, brightness gain +13). Right - direct component. Artifacts from compressed screenshot.

and scaling is incorrect.

[NoAffinity]

Do you have your gbs-c set to auto gain? You're supposed to set it to auto gain while in a lure white screen, leave it there for a minute or so, then leave gbs- set to auto gain. Aside from that, I've never seen perfect colors from gbs-c. It is, after all a budget scaler running a custom firmware which is no longer an active project. Output from different gbs units will vary as well.

[mrchief]

Do you have your gbs-c set to auto gain? You're supposed to set it to auto gain while in a lure white screen, leave it there for a minute or so, then leave gbs- set to auto gain. Aside from that, I've never seen perfect colors from gbs-c. It is, after all a budget scaler running a custom firmware which is no longer an active project. Output from different gbs units will vary as well.

Yeah, with auto gain, using "240p test suite" with sega emualation, and it does very quick. Colors inaccuracy could be a hardware oversight with capacitors, etc. But its a global thing with GBSC, could be programmed wrong. Someone should do a capture from stock GBS8200.

Checked .pdf manuals found scaling calculations.
VSCALE = 1024 * (Input V.active / Output V.active)
HSCALE = 1024 * (Input H.active / Output H.active)

So if i wanted integer 2x scale with overscan (768x576) targeting 1440x1080 (4:3 frame), i would need to use scale value of 512 for V and H scale, if i calculated correctly. 1080p preset values makes no sense, or my calculations are wrong.

Sad reality of open source, people who did nothing profits from it.

very close color accuracy to OSSC, 5725 has potential.
https://www.youtube.com/watch?v=tIsAeTEaZQA

[mrchief]

starting to figure out registers
0xFF, // s3_16
0x3, // s3_17
0x20, // s3_18

So, vscale value of 1023 in the registers equals input resolution of 1918,125, hscale value of 512 equals resolution of 540, if calculations used 1920x1080.

so input resolution is 1918,125x540, but how.

Pal resolution, 720x576 (3:2) > 768x576 (4:3)

[mrchief]

Hello,
couldn't figure out video scaling, so i made adjustments by eye to good enough.

trying to figure out colors. Starting from ADC. Voltage for RGB lines in scart specification should be 0.7V? So we calculate gain control: (0.7Vpp/1Vpp)*255(FF)= 178.5 [HEX] B2 or B3, but registers are 7B ( 0x7B, // s5_9, 0x7B, // s5_A, 0x7B, // s5_B) - calculates roughly to 0.4824V (in GBSC code and 1080p preset), this could explain dimmer image?. offset says to use 64, and it is, hex: 40.

Also in ADC there are hardcoded offset in GBSC code to mitigate hardware errors? from debug console after calibration, ADC offset [HEX]: R:40, G:43, R:40, this could explain tint?

GBS-C is pretty good, reduces input lag significantly, games are much more fun to play. Problem is scaling issues and colors (seems - correct, but lacking in color punch).

Edit:
Double checked the graph, i think my calculations were wrong, because I ignore the blue line. So values should be 0.5Vpp is 00H and 1Vpp is FFH, so calculated 0.7Vpp hex value is 66H. Problem is, i don't know how to test it, since i have a premade gbs-c and i dont want to mess it up.

current gain value: 123 (7BH), new value: 102 (66H). Comment in gbsc firmware says: // gain is actually range, increasing it dims the image.

[NoAffinity]

I don't proclaim to know the technicalities to your level @mrchief, or even half of what youre talking abour, but i've been an enthusiastic tester for past iterations of the custom firmware, and long-time user. Do you anticipate releasing a firmware update with your improvements?

[mrchief]

https://safenote.co/r/68ac8adf1c87f5@00831259 - expires in 14days, dont know where else to upload without account

i dont use github

changed value in gain registers (S5_9, S5_A, S5_B) in all in all presets:7BH to 66H. offset registers are fine - 40H

changed gain registers in gbsc code from 7BH to 66H, except in ADC calibration, i hope this will make colors pop like it shoud.
GBS::ADC_RGCTRL::write(0x66);
GBS::ADC_GGCTRL::write(0x66);
GBS::ADC_BGCTRL::write(0x66);

Changed offset value GBS::ADC_GOFCTRL::write(0x42); from 42H to 40H

I have no experience doing this. Trying to understand it by reading technical files and GBSC code.

Not sure if we need to disable auto gain and ADC calibration, since it uses 7BH register values.

[NoAffinity]

Very nice! I had a chance to test this build last night, briefly. It is immediately noticeable that the colors are sharper and more vibrant, and the image is overall much brighter). I want to say that the scaling is sharper too, but it was a brief test, I'll see if I can carve out some time this weekend to produce some side by side comparisons of rama final fw vs this build.

[NoAffinity]

Did some quick screen captures from a couple different systems. The differences are very minimal, to my eyes, but my opinion is that mrchief's fw provides slightly improved colors and a slight improvement to sharpness.

In all comparisons below, mrchief's fw is on the left, rama's is on the right.

What do you think?

Spoiler

[mrchief]

Did some quick screen captures from a couple different systems. The differences are very minimal, to my eyes, but my opinion is that mrchief's fw provides slightly improved colors and a slight improvement to sharpness.

In all comparisons below, mrchief's fw is on the left, rama's is on the right.

What do you think?

Spoiler

Nice. Calling it mrchief's firmware is wrong. :DD

Which setup you use to record? What consoles are captured? 4th gen consoles tend to output above 0.7Vpp RGB, so they can clip image with 66H gain value. Im targeting PS2 atm
It's kinda tricky to dial offset, since you need to measure output voltage from RGB lines and calculate LSB value accordingly when input is BLACK - nothing. Need to dig more into methodology. 8200 boards could be fairly equal. But with prebuilts, there can be differences affecting offset.

There is also a very different component input configuration compared to manual. Formula on the left. RGB to RGB, full range internal YUV. On the right YUV 4:2:2 16-235 to RGB

And tv5725 can accept and output digital video. Not sure why prebuilts chose to simply redesign the board only.

[NoAffinity]

Ps1 Street Fighter Ex 2 Plus
Genesis Model 2 Super Street Fighter 2
Genesis Model 2 Outrun
Saturn Night Warrirors

Scart RGBS output for all. Genesis is triple bypass modded with csync out. Saturn and ps1 are stock outputs with sunc on luma. Console -> GBS-C 960p profile -> OSSC pass through to Magewell HDMI capture in OBS.

[mrchief]

Ps1 Street Fighter Ex 2 Plus
Genesis Model 2 Super Street Fighter 2
Genesis Model 2 Outrun
Saturn Night Warrirors

Scart RGBS output for all. Genesis is triple bypass modded with csync out. Saturn and ps1 are stock outputs with sunc on luma. Console -> GBS-C 960p profile -> OSSC pass through to Magewell HDMI capture in OBS.

Nice. VirtaulDub2 is better, since it can capture in FFV1, it can detect input format so you can dial correct settings.

Can you capture outrun with OSSC, so we could compare GBSC "updated" firmware with OSSC.

[CrossMojonation]

I've got a similar setup, so happy to test the firmware as well. My capture card should arrive next week.

This isn't entirely selfless, as I think I might have aspect ratio issues with my GBS-C as well. 1280x960 and 480p are both narrower than what my OSSC outputs.

[NoAffinity]

Here we go. Updated firmware cap still on the left, OSSC on the right.

*OSSC dialed in for pixel sharpness

Spoiler

[mrchief]

Here we go. Updated firmware cap still on the left, OSSC on the right.

*OSSC dialed in for pixel sharpness

Spoiler

Thanks, strangely both OSSC and now GBS clips cloud detail - blue squares. Edited ADC gain and offset calibration values. Component sync was 0.25V, changed to 0.3V what manual suggests. Y is 1Vpp, -0.3V (sync) 0.7V (color) = 1Vpp, currently input gain value is set to 80H in "applyYuvPatches", 1Vpp should be FFH gain value.

Tested GBS with ADC disabled?

Changes:

Spoiler

GBS::VDS_SYNC_LEV::write(0x80); // 0.25Vpp sync (leave more room for Y)
80H to 132H (0.3Vpp)


void setAdcParametersGainAndOffset()
{
GBS::ADC_ROFCTRL::write(0x40);
GBS::ADC_GOFCTRL::write(0x40);
GBS::ADC_BOFCTRL::write(0x40);

// Do not call setAdcGain() and overwrite adco->r_gain. This function should
// only be called during startup, or during doPostPresetLoadSteps(), and if
// `uopt->enableAutoGain == 1` then doPostPresetLoadSteps() will revert
// these writes with `adco->r_gain`.
GBS::ADC_RGCTRL::write(0x7B); 7BH to 66H
GBS::ADC_GGCTRL::write(0x7B); 7BH to 66H
GBS::ADC_BGCTRL::write(0x7B); 7BH to 66H


}

void calibrateAdcOffset()

GBS::ADC_RGCTRL::write(0x7F); - 7F to 66H, not sure why 7F
GBS::ADC_GGCTRL::write(0x7F); - 7F to 66H
GBS::ADC_BGCTRL::write(0x7F); - 7F to 66H
GBS::ADC_ROFCTRL::write(0x7F);
GBS::ADC_GOFCTRL::write(0x3D); // start
GBS::ADC_BOFCTRL::write(0x7F);
GBS::DEC_TEST_SEL::write(1); // 5_1f = 0x1c

https://filebin.net/x4468t4a8gxlrgox/gbs-control.zip link is valid for 6 days

[NoAffinity]

FW updated, new screenshot added to the left.

As mentioned, the GBS-C (960p) output runs through OSSC in pass thru mode. OSSC is set to default settings. Not sure if that's having an influence on coloration, etc.

Spoiler

[mrchief]

FW updated, new screenshot added to the left.

As mentioned, the GBS-C (960p) output runs through OSSC in pass thru mode. OSSC is set to default settings. Not sure if that's having an influence on coloration, etc.

Spoiler

Found out that auto offset is used with 24bit YUV input:

Spoiler

Still looks better than previous GBS-C, brighter and less reddish, visible in outrun comparison. 4:2:2 my capture card limit

I put some emulated images (PC blastem and PS2 picodrive). updated GBS-C is fairly similar to emulation:

Spoiler

[mrchief]

Trying to flash my prebuilt. But i want to do a backup first, but its unclear for me. How?