GBS 8200/8220 CFW Project

[rama]

Latest update has the SOG Level button on the Development tab.
See if you can get it stable with it.

[Iraito]

https://pastebin.com/9sLbZzxZ

Just put everything back like it was before, fixing the SS made a mess out of everything scart related.

[rama]

You can easily go back to earlier revisions, but the sync problem remains.
To go back to earlier revisions, pick a commit here, then click on "Browse files", then "Clone or download".
Here is the commit with just the Saturn detection fix:
https://github.com/ramapcsx2/gbs-contro ... f10e55e6fe
This earlier revision has SP_H_PROTECT enabled, so instead of a jumping picture, you'll get other anomalies.

The log you posted shows the SOG level changing by 2 only. You should try the range from 0 to 16.
It's the "s:" in the log here (currently 12):
h: 431 v: 525 PLL:00 A:7b7b7b S:8f.00.02 I:00 D:0585 m:1 ht:2346 vt: 271 hpw: 171 u: 0 s:12 TF:0000 W:31
Just push the button a few more times and watch the behaviour.

If this button can't at least improve the situation, my next best guess is that the SOG0 input is damaged from overvoltage.

[Iraito]

It has not been solved
https://pastebin.com/X5WRxc1q

You mean the ps1\saturn input is damaged ? now i'm getting confused, surely not the one on the gbs because i have no such issue with PSP\WII\PS2 using component cables, also without the fix i had no anomalies, like not a single one.

I will test the dreamcast and ps2 with scart to see if i get the same issue, i would like to solve this problem and also to update GBS control instead of keeping an older version.

[Iraito]

Just tested dreamcast and an older ps1 i had with a broken laser (with the same scart cable i used for the other ps1), both are stable.

Dreamcast: https://pastebin.com/W5WuEerq

PS1: https://pastebin.com/umf8k9qh

Well damn, it seems to be the ps1, is this something i can fix ?

Even the saturn: https://pastebin.com/qB8nZikq is more stable than i thought, there's just a micro jump before a new video demo starts (the jump should be near the end of the log)

I'm starting to believe that the modchip installed on the ps1 is messing up the internal oscillator.

[Nuck-TH]

Just updated firmware in my setup to check if saturn works with it.
On lastest commit and NTSC-J Saturn image is good and rock solid stable.
But when i switch off saturn screen turn black with green vertical bar sweeping right. Can image freeze be returned?

I would bet Iraito has either saturn sync out or GBS sync input damaged.

Iraito, testing component input is no use, because it uses different pins of the chip and iirc sync processing is a bit different there.

[Iraito]

Just updated firmware in my setup to check if saturn works with it.
On lastest commit and NTSC-J Saturn image is good and rock solid stable.
I would bet Iraito has either saturn sync out or GBS sync input damaged.

Iraito, testing component input is no use, because it uses different pins of the chip and iirc sync processing is a bit different there.

I don't know how but you just missed my previous message where i explain that every console actually works well and stable in scart, it's 100% the modchip in my ps1 messing my sync signal.

I even tested my SNES and GC\gameboyplayer with my new scart cable and even those are stable, it's just the modded ps1

It's neither of the things you pointed out.

[rama]

The new logs don't look great either. The "PLL:" reading rarely climbs above 5 or so, which should occur at least some of the time between several consoles.
I think there is a problem with that PSX, and the GBS as well.
It may just be power, or bad RGB cables, or sometimes even bad electric wiring in the home.

This is my SCPH-7000 using CVBS sync directly into the GBS as an example:

Code: Select all

<reset>
Activity detected, input: RGB

Format change: <stable>
Old: 0 New: 1
ADC offset: R:41 G:45 B:41
coast ST: 0x3A, SP: 0x649  total: 0x6B0 ~ 428
HTotal Adjust:  0, source Hz: 59.826, output Hz: 59.834
clamp ST: 0xE, SP: 0x53   total: 0x1AC / 428
Phase: 13 SOG: 13
post preset done (preset id: 1) for 60Hz 
h: 427 v: 525 PLL:01 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 427 v: 525 PLL:02 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:03 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:04 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:05 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:06 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:07 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:08 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:09 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-58
h: 428 v: 525 PLL:10 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:11 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:12 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:13 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:14 A:7b7b7b S:8f.00.02 I:00 D:0594 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:15 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 427 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:16 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 427 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0594 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57
h: 428 v: 525 PLL:17 A:7b7b7b S:8f.00.02 I:00 D:0584 m:1 ht:2345 vt: 271 hpw: 170 u: 0 s:13 TF:0000 W:-57

This isn't the best GBS either, as I'm using the board with the worst sync performance that I have.

With regards to the PSX modchip, that shouldn't affect the sync, unless there is a mistake (short, etc).
A common video mod that I sometimes see is grounding a pin on the video encoder to force PAL color encoding.
This is bad practice and may lead to bad performance.

[Iraito]

Hey it looks perfect, after all the hassle i had i'm good with that.

Some chip seems to create problems https://quade.co/ps1-modchip-guide/mm3/

Also i'm getting a moire effect, my PSU is certainly not good, so the numbers you see are probably coming from a bad power source, not the cables.

For such special cases related to mod chips messing up with oscillators etc. i think the best option is to make that hack that messed with the saturn optionally selectable.

[rama]

What they mean with oscillator issues with PSX chips is just affecting the modchip, making it so that the modchip action doesn't work and the console needs a reboot.
It's where the old "boots every time" meme came from :p

I'm still experimenting with the Sync Processor features.
If I find a usable alternative processing mode, I'll either enable it automatically or offer it as an option, yeah.

[Iraito]

Then it's really strange how a ps1 has no issue but the other does, the models are similar and differ only in regards to the mod chip.

Thankfully it seems to work really well outside of the verbose log and you have an idea for a fix.

( •_•)
( •_•)>⌐■-■
(⌐■_■)

[rama]

Can image freeze be returned?

Yep, done!

[benryves]

The caching fix is out, along with that HTotal-- button and nicer readouts.
This should make it easier to dial in better HDMI accepted timings.

Perfect, thank you, I can confirm the caching fix works as do the HTotal-- button and the more detailed readouts are a real blessing. One thing I think noticed in a couple of places is confusion between sfr/ofr variables when retrying, like this:

Code: Select all

      if (ofr < 1.0f) {
        delay(1);
        sfr = getOutputFrameRate();  // retry
      }

(Should the second "sfr" be "ofr"?)

It's a bit Heath Robinson as I'm not sure of the best way to do it but I added a little helper function to try to snap timings to an integral frame rate:

Code: Select all

boolean snapToIntegralFrameRate(void) {

  // Fetch the current output frame rate
  float ofr = getOutputFrameRate();
  
  if (ofr < 1.0f) {
    delay(1);
    ofr = getOutputFrameRate();
  }
  if (ofr < 1.0f) {
    return false;
  }

  // Get the target frame rate.
  float target = round(ofr);

  // We'll be adjusting the htotal incrementally, so store current and best match.
  uint16_t currentHTotal = GBS::VDS_HSYNC_RST::read();
  uint16_t closestHTotal = currentHTotal;

  // What's the closest we've been to the frame rate?
  float closestDifference = fabs(target - ofr);

  // Repeatedly adjust htotals until we find the closest match.
  for (;;) {
    
    delay(1);
    
    // Try to move closer to the desired framerate.
    if (target > ofr) {
      if (currentHTotal > 0 && applyBestHTotal(currentHTotal - 1)) {
        --currentHTotal;
      } else {
        return false;
      }
    } else if (target < ofr) {
      if (currentHTotal < 4095 && applyBestHTotal(currentHTotal + 1)) {
        ++currentHTotal;
      } else {
        return false;
      }
    } else {
      return true;
    }
    
    // Are we closer?
    ofr = getOutputFrameRate();
    
    if (ofr < 1.0f) {
      delay(1);
      ofr = getOutputFrameRate();
    }
    if (ofr < 1.0f) {
      return false;
    }

    // If we're getting closer, continue trying, otherwise break out of the test loop.
    float newDifference = fabs(target - ofr);
    if (newDifference < closestDifference) {
      closestDifference = newDifference;
      closestHTotal = currentHTotal;
    } else {
      break;
    }
  }

  // Reapply the closest htotal if need be.
  if (closestHTotal != currentHTotal) {
    applyBestHTotal(closestHTotal);
  }
  
  return true;
  
}

I added an 'S' command as I don't believe that's currently used (for "snap") in the main loop:

Code: Select all

    case 'S':
    {
      SerialM.println("Snap to integral frame rate");
      snapToIntegralFrameRate();
      break;
    }

...as well as a button to the webui.html:

Code: Select all

                '<p>Snap to integral frame rate</p>' + 
                '<button class="button" type="button" onclick="loadDoc(\'S\')">Snap to integral frame rate</button>' + 

This now works for me, if I press the button I added to the UI it adjusts htotal in steps until it finds the output framerate that's closest to an integral value. Active FrameTime Lock needs to be disabled for this to work, naturally. What this means is that I can now just hook everything up, select the desired preset, and press that new button and it all works. A bit of a kludge and I'm sure you can think of a hundred better ways to achieve this but in the short term it's doing what I need it to!

[rama]

Good work!
I'll add this, if you don't mind?

Yep, ofr retries were wrong. My bad for using too similar, too short variable names there.
It'll be corrected with the next update

[benryves]

Of course, you're very welcome to use it if you think others might find it useful. Sorry for the lack of elegance!

[Ryoandr]

HOLY SHOOT, HTotal-- is life saver !
I could adjust refresh rate and a some point my receiver finally synced with no drops ! This is good as I have an event soon, and I was researching all possible solutions, the hdmi out port of the recorder now working simplifies everything !

Thank you all, this project is so underrated it hurts.

[AndehX]

Thank you all, this project is so underrated it hurts.

I know right? I'm still dropping comments on any GBS videos that pop up on youtube trying to get people to check the project out

Hey rama, over on the circuit-board.de forums, a guy named sanni made an updated 3D print case. Do you think you could ask him if he will release it? I don't have an account over there and I don't speak german

[rama]

Thanks guys,
it's great when gbscontrol can solve some real world troubles

Of course this isn't the ultimate fix. The tear line shows up more often, maybe to a point where it becomes distracting.
I don't know of any solution to that problem.
Even if we accepted additional lag for a field buffer, the result would be noticeable frame judder.
That's kind of similarly annoying as a tear line, in my opinion.
The trick of "stealing scanlines" in vertical blank time (used in Active Frametime Lock) can't be used here either, as that surely breaks HDMI timing constraints.

benryves:
I've added your code verbatim, but I'll push a small tweak later that fixes the target to either 50.0Hz or 60.0Hz.
That's what HDMI wants to see, as far as I'm aware.
I'll also constrain and allow a range of ~3Hz around the target, because some (arcade) hardware pushes the limits in that regard.
Thanks for coding it up. I think it fits right in with the rest of the code

AndehX:
Sure, will do!

[benryves]

The trick of "stealing scanlines" in vertical blank time (used in Active Frametime Lock) can't be used here either, as that surely breaks HDMI timing constraints.

Ah, so that's how that works? I was wondering about the implementation. Are those scanlines in "input" or "output" space, if that question even makes sense? I ask as when I've enabled the Active FrameTime lock the whole picture jumps up or down a line (in what appears to be "input" space, so multiple line on the scaled display) every few seconds which is somewhat more distracting than the tear line to me (through HDMI, that is, my monitors don't like 50Hz VGA so I can't test there directly).

benryves:
I've added your code verbatim, but I'll push a small tweak later that fixes the target to either 50.0Hz or 60.0Hz.
That's what HDMI wants to see, as far as I'm aware.
I'll also constrain and allow a range of ~3Hz around the target, because some (arcade) hardware pushes the limits in that regard.
Thanks for coding it up. I think it fits right in with the rest of the code

Thank you very much! As far as I understand it traditional 525-line "60Hz" is 59.94Hz (60*1000/1001) and this is also commonly supported over HDMI at higher resolutions (in Windows this is normally reported as "59Hz" as a separate refresh rate option to 60Hz) so it could be worth allowing for 50Hz, 59.94Hz and 60Hz - if 59.94Hz is closer to the source rate it could help reduce the tear line.

[AndehX]

it could be worth allowing for 50Hz, 59.94Hz and 60Hz - if 59.94Hz is closer to the source rate it could help reduce the tear line.

I know little to anything on the coding side of things, but I do agree this is probably a good idea if it helps eliminate any tearing lines

[rama]

Yeah, this isn't too hard to optimize. We only need to know what refresh rate is most compatible for what resolutions.

Regarding the case design, sanni is making them available here:
https://www.thingiverse.com/thing:3913273

[Ryoandr]

Integer framerate search only works downwards ? Using it made it lock around 59,018 with MVS which might be a bit low, although recorder box managed to lock on it...
It might be better trying to search upward also, as mentionned NTSC is 59,94, 60 is the more computer world refresh (all devices should sync fine as difference is minimal).

[rama]

This should be fixed in the latest revision

[Ryoandr]

Things are going too fast for me
And works perfect, record box syncs. And since I can select RCA input for audio, it also does HDMI mixing. The setup is close to ideal.
if you're wondering, it's the Avermedia Game Capture HD II


I'm mainly using it stand alone, but on some events I like having a control monitor on the HDMI out, and next weekend I was planning to use it for audience broadcasting (apparently there will be one hell of a video setup) on a convention.
You can find them used for 30-40€. It's a perfect companion for the HDMI GBS.

[Iraito]

Is there any news about that selectable fix ?

[rama]

Iraito:
To summarize, there is a hardware issue with your setup.
You found that the SP_H_PROTECT feature can make it work, and you want it to be optional.

My thought on that is, the feature requires a different sync processing strategy to be viable.
I don't currently have multiple strategies, and developing them requires me to at least be able to reproduce the problem.
So simply adding the option is a crap shot. It will do something, but probably not deliver a stable signal out of your hardware issue setup.

So yeah, please try debugging your hardware issue. Maybe talk with the person that built your sync stripper.
Is there even a 75 Ohm termination resistor on the LM1881 input?
Is there a 470 Ohm series resistor on the output?
Does the device run on 5V?

Once your hardware is proper standard (or properly sync stripper processed), gbscontrol will deliver a stable signal.
But without that, it can only do so much.

[Iraito]

The guy laughed in my face (lovingly) when i asked him again to check my setup, the stripper is 100% perfect and something that any electrical engineer should be able to put together while blindfolded. The cables are perfectly wired and the signal is clean, he indeed found i had a bad power supply which i'm going to change with a linear one used for hi-fi systems that he's going to buy himself to be sure i'm getting the best one.
Besides that all my consoles BUT only the modded ps1 suffer from visible issues and i mean:

Gamecube = looks perfect
GBA player + GBI interface = looks perfect
PS2 = looks perfect
Dreamcast = looks perfect
Non-modded PS1 = looks perfect
Sega genesis model 1 = looks perfect
PSP = looks perfect
Super famicom = looks perfect
WII = looks perfect
Sega saturn = It's perfect in games, only video demos start with a micro jump
PS3 through scart = looks perfect

If 11 consoles are totally fine and just one of them gives me this damn weird issue i would logically rule out the GBS and stripper, the chip is old (installed in the 90's) i didn't check yet but i'm betting my balls on the chip being the problem, making that option selectable
would still better than nothing at all, it's not like you are breaking something putting that option in, right ?

[maxtherabbit]

The guy laughed in my face (lovingly) when i asked him again to check my setup, the stripper is 100% perfect and something that any electrical engineer should be able to put together while blindfolded. The cables are perfectly wired and the signal is clean, he indeed found i had a bad power supply which i'm going to change with a linear one used for hi-fi systems that he's going to buy himself to be sure i'm getting the best one.
Besides that all my consoles BUT only the modded ps1 suffer from visible issues and i mean:

Gamecube = looks perfect
GBA player + GBI interface = looks perfect
PS2 = looks perfect
Dreamcast = looks perfect
Non-modded PS1 = looks perfect
Sega genesis model 1 = looks perfect
PSP = looks perfect
Super famicom = looks perfect
WII = looks perfect
Sega saturn = It's perfect in games, only video demos start with a micro jump
PS3 through scart = looks perfect

If 11 consoles are totally fine and just one of them gives me this damn weird issue i would logically rule out the GBS and stripper, the chip is old (installed in the 90's) i didn't check yet but i'm betting my balls on the chip being the problem, making that option selectable
would still better than nothing at all, it's not like you are breaking something putting that option in, right ?

is the working PS1 a different region from the one causing you problems?

[Iraito]

is the working PS1 a different region from the one causing you problems?

Same identical region and cables, PAL.

[rama]

The console may have this mod applied:



Back then (and even today still), many modders / guides leave out the part of lifting pin 157.
This shortcuts the NTSC/PAL selector driver in the GPU, which besides destroying the driver, probably also causes signal quality issues that could explain the problems here.

The next thing to check (replace) is the output coupling capacitor (220uF electrolytic, called C551 on many later models).
It has a tendency to go bad, and delivering a dark CVBS picture and obviously bad sync.