GBS 8200/8220 CFW Project

[Iraito]

[url=https:///][/url] upload

This is the one i'm using but without the VSYNC attached, i had no problems before the SS fix.

[rama]

Please take some photos of your GBS and/or describe how you built and connected the stripper.
The issue is going to be there.

Edit:
What is the power to the LM1881?
It should have 5V (not anything else).

Edit2:
The "SS fix" can only affect the signal detection phase / startup.
Once an image shows on screen, there is no difference to before.

[Iraito]

It's 12V, could that be the issue ?

I'm going to buy a 9V one, should i buy exclusively a 5V PSU ?

[rama]

Yes, that is definitely an issue.
I've never tested this, but I assume the LM1881 output something like 8Vpp or so with that supply
I've no idea why the diagram says "5-12V" ><

It's best if your power supply delivered 5V at 2A (1.5A also okay).

[Iraito]

I just tested with a 5V 2A PSU and it's even more unstable, the stripper has been constructed like in that schematic by a family member (electrical engineer for 30 years) i guess it's well done.

[rama]

Would be great if you could ask the builder whether the LM1881 has a signal output limiter, or some other method to restrict the output levels.
I don't think it does, and hence the output would scale with the Vcc it gets.

[Iraito]

Would be great if you could ask the builder whether the LM1881 has a signal output limiter, or some other method to restrict the output levels.
I don't think it does, and hence the output would scale with the Vcc it gets.

I will ask but if it isn't in the schematic i posted then there's no limiter.

[rama]

Quick check in the data sheet:


You've put 11Vpp sync signals into the poor 3.3V chip :p

As a test, would it be possible to remove the sync stripper, and just use the CVBS sync signal directly?

[Iraito]

I can but it's a pain in the ass to do it now, just in case, can you modify that schematic with a better one ?

Since i tested it with a 5V PSU shouldn't the stripper have worked in that case ?

[rama]

The schematic is just fine, but it's valid for Vcc = 5V only.

I think the dotted yellow line is VSync out. I would leave it off / not connect it (and the VSync out pin on the LM1881 left floating).

[benryves]

That's odd. Maybe something else is going on there, as I can't reproduce this here.
But sure, I can add that hack.
I liked get requests better as they produce far less traffic than posts.

The aggressive caching of GET requests from XMLHttpRequest certainly used to be a fairly common problem, to the extent that jQuery and MooTools provide a simple way to append a unique value in a query parameter for each request as per my suggested workaround so there is some precedent. I'm not sure why I was having issues in mobile Firefox on Android as the desktop browser was fine.

GET shouldn't really modify the resource, but at least it's not harmful in this case. I knew someone who used GET requests for a publicly-editable website (including "delete" links) who then lost a lot of data when Google crawled the site... Anyway, I'm here for the gaming so will take off my web developer's work hat!

[rama]

The aggressive caching of GET requests from XMLHttpRequest certainly used to be a fairly common problem, to the extent that jQuery and MooTools provide a simple way to append a unique value in a query parameter for each request as per my suggested workaround so there is some precedent. I'm not sure why I was having issues in mobile Firefox on Android as the desktop browser was fine.

GET shouldn't really modify the resource, but at least it's not harmful in this case. I knew someone who used GET requests for a publicly-editable website (including "delete" links) who then lost a lot of data when Google crawled the site... Anyway, I'm here for the gaming so will take off my web developer's work hat!

Haha, that's certainly a lesson learned :p
I have some basic web dev experience. I can use CSS and JS to do little things, but nothing more than just getting things to work, somehow :p

With gbscontrol, the web "rules" are changed up a little.
- The data source is always the current GBS8200 state, as cached or accessed on request by the ESP8266.
The web ui can request a change, but it's up to this "server" to comply. If it did comply, it will tell the web ui with the next websocket update.
- Traffic needs to be minimized. The problem here is that the connection isn't very reliable. If it's unstable, then it should help if the data bits that actually do something don't get missed in a see of header data.
- To that effect, maybe it'd be even better to use UDP for everything?

In any case, I'll add that random variable hack sooner or later.
Just have to work out the age old SOG issue first.

[rama]

Does that look okay now?
Is there a way to get the packet smaller, maybe?

[Iraito]

I tested without the sync stripper, now the picture is unstable as all hell, it's identical as how the saturn was before the fix.

[rama]

Well, now we don't know whether the SOG0 input is still okay.
I expect some sources to produce an unstable display, but after a short while the various auto adjust routines should settle.
This is where some logs would help.
You can enable verbose logging with the "Print Infos" button on the web ui "Development" tab.
( Those logs are huge though, so best if you paste them here: https://pastebin.com/ )

[benryves]

Does that look okay now?
Is there a way to get the packet smaller, maybe?

Looks good to me! I wouldn't want there to be a variable name conflict but you could always shave a few bytes by using &nc= and then an global integer that increments on every request rather than nocache and the current time. Considering you're already using a WebSocket to retrieve the current state (at least that's what it looks like is happening to me) could you not also send commands over that instead of using the overhead of an HTTP request? Unfortunately I don't believe there's a way to remove specific HTTP headers so I think you'll always have the default browser headers going over the wire.

It's difficult for me to say as I haven't really dug into what you're doing on the server side and I personally have found the web interface and networking to be very robust, I've never had a drop-out or connection issue with my setup.

Just have to work out the age old SOG issue first.

Of course. Thank you again for all you've done with this.

[Iraito]

https://pastebin.com/CNbDWu4z

With the 12V PSU the image is much more stable, it could be related to the fact that the 12V one is switching while the 5V is not.

[rama]

benryves:
Glad you like it

I think you've got the web ui figured out.
I use xhttp because of the browser built-in error handling.
Whenever there's a communication dropout + reconnect, the websocket lingers for a while (until the timeout function catches it).
This is okay'ish for the log text, but for the buttons, I'd like them to work as best as possible :p

The entire web stuff works well enough, as long as the ESP8266 radio (WiFi) can send data louder than the scaler chip horizontal PLL interference.
The H-PLL can land in a range where there's an EMI spike exactly on the current WiFi channel, which then drowns out all communication :/

I've seen some people hack the ESP8266 radio PLL recently.
This could potentially be used for some crude "spread spectrum" behaviour, and maybe allow the ESP8266 to transmit again :p

Iraito:
Oh, that's an unusual log.
The SOG input is apparently stable, but the H-PLL doesn't get a lock.
I'll have to think about it.
Could you try some other output presets and also the Development tab "Oversampling" button?

You can use your 12V supply, but only to power the GBS, not the LM1881 (if you use it).

[Iraito]

I tried all outputs, PSUs, oversamplings, it's always the same, the GBS can't lock into the H-PLL.

Do you have any idea for a solution ?

[rama]

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.

[rama]

Iraito:
I'll add another button to the web ui Development tab later.
This will change the SOG slicer level manually. Maybe this is what your setup requires.

But that behaviour is certainly odd.
I only ever see something like it with severely degraded sync (Master System CVBS sync with impedance mismatch), or when the H-PLL is out of specification.
It *may* indicate a power problem, too.

[Iraito]

Uhm it could be out of specification, i'm running an NTSC game on a PAL ps1 and it could also be a PSU issue (i will buy a 5V switching one of good quality)

The sync stripper is well made though and without, the signal goes crazy.

EDIT: Can i supply power to the stripper through the 3.3V i use for the arduino ?

[rama]

I've experimented with the LM1881 getting just 3.3V and it worked here.
The chip operates borderline unstable. I think at around 3.0V, it would drop out.
If you want to try this route, it's best if you get the 3.3V from anywhere on the GBS board.
C48 on the far left side of the board is a somewhat good spot to get 3.3V from.
Ground should then be taken from the other side of the capacitor, so to minimize the current loop.
Alternatively, the underside of the board has many electrolytic capacitor legs that all carry the 3.3V supply (but measure first).

Running an NTSC game on a PAL console and vice versa is just fine.
What I mean with "out of spec" is the programmed divider value falling out of what the hardware can do.
I know that the values in my presets are good on all GBS boards I've had.
If there was some disturbance however, either from power, ground bounce stuff, or very jittery sync, then it can fail to lock.

If you look around a bit, 5V mobile chargers are plentiful.
Most of them are good enough for this application. It doesn't have to be anything fancy

Edit:
Another quick test to try is the PSX PAL Bios menu.
Could you run that and post the same info mode log?
I use a lower H-PLL divider value for PAL, and if that's stable, we have a hint towards the H-PLL circuit itself being a problem.

[Iraito]

Do you think it could be a jittery sync signal ?
Take into consideration i had no problem whatsoever before the SS fix

[rama]

Yes, definitely.
It somewhat worked before because I had a Sync Processor feature enabled that evens out jittery sync (but that caused other problems).

[Iraito]

Given that the signal was extremely jittery without the stripper, can we exclude that from the equation ?

[rama]

Not sure. There is no reason for PSX (or Saturn) sync signals to be that bad to cause such issues.

Could you do that PSX test I mentioned a few posts up?

[Iraito]

Yeah it's just as unstable on the BIOS
https://pastebin.com/WfehfD9S


I find hard to believe that two consoles have an unstable sync that gives off the same identical problem.

[rama]

h: 431 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2340 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31
h: 430 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2338 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31
h: 431 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2341 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31

The "I:40" suggests VSync is connected and unstable. Is this the LM1881 VSync?
"ht" fluctuating shows the H-PLL failing to lock on, while the somewhat stable "hpw" value shows that the sync input is okay enough.
That's all I can say: It's a weird issue.

[Iraito]

I never connected the VSYNC, it has been disconnected since the beginning.

Is the issue solvable in any way ? at this point i prefer a non working saturn than this.