GBS 8200/8220 CFW Project

[Stremon]

Hey guys,
I've been trying to make my NodeMCU connect to my wifi network, but so far I had no luck.
I first searched for a solution here but couldn't find any working one.
The AP mode is working fine, I can access the webUI without any issue.
I see my wifi network in the wifi settings, but when I try to connect to it, it seems to fail and to go back to AP mode.
What could be causing that?
My wifi network settings are the following:
2.4GHz
g/n mixed
autoselect radio channel
WPA2-AES
Region code Japan (channels 1-13)

can it be the region code?
I can't really change it since my other devices won't work on the network anymore.
Do you have an idea on how to solve that?

Edit: changed the region code to US, still not working

[NoAffinity]

How are you connecting to the web ui? The easiest way is to use a smart phone, and with the gbs/esp powered on, connect your phone to the 'gbscontrol' network. Then use a web browser on your phone to connect to the gbs/esp at 192.168.4.1.

Sent from my SM-G955U using Tapatalk

[Stremon]

How are you connecting to the web ui? The easiest way is to use a smart phone, and with the gbs/esp powered on, connect your phone to the 'gbscontrol' network. Then use a web browser on your phone to connect to the gbs/esp at 192.168.4.1.

Sent from my SM-G955U using Tapatalk

As I said the AP mode is working fine, I can access it.
The wifi setup to connect the nodemcu to my wifi network is not working.

[rama]

No idea here. It always worked fine on my network, and there's nothing special going on anyway.
You need to provide the correct password, of course, and your router has to be recent enough to recognize the device (probably anything made after 2005 or so?).

If you can, check your router logs for clues.

[NoAffinity]

Got bored, did some screen grabs, per previous request to see GBS vs. OSSC. Not perfect apples to apples comparisons, but close enough without multiplying the time involvement 2x or more.

Download the images so you can open them side by side on your screen of choice. Attempting to paste them into a side-by-side image has too much risk of influencing the quality of the images.

Genesis Sonic (SCART 240p) - OSSC @ line4x 320 optimized mode, GBS @ 1280x1024 profile
Street Fighter Alpha 2 PS1 (SCART 240p) - OSSC @ line4x 4:3 generic, GBS @ 1280x1024 profile
GT3 PS2 (Component 480i) - OSSC @ BOB 2x, GBS @ 1280x1024 BOB, GBS @ 1280x1024 Use Motion Adaptive

Below, OSSC is first in line, GBS is second in line.

Draw your own conclusions, but I'll continue to opine that for the money, GBS w/ CFW is a great contender in the low-lag retro console scaling and deinterlacing arena.

Spoiler

[/url]

[rama]

Color reproduction is something I'm still working on, by the way ;p

I've come to recognize Mega Drive / Genesis pictures by their low amplitude RGB.
It's really the weakest RGB out of all the usual sources. Maybe our cables are all wrong? There has to be a reason.

Anyway, the GBS would look much better with auto gain enabled in that comparison ;p

[NoAffinity]

Auto gain was enabled. With auto gain, I get some overly bright brights. I also do some minor correction at the capture card. Also have tried adjusting gain + and - on the gbs, but never can get it quite right. But even with some minor overbrightness, it looks great. Maybe there's something I could be doing better on the gbs?

The ossc has more granularity for color adjustments - individual rgb offset and gain adjustments as well as a coarse adjustment pre-adc gain. I typically fine tune the individual color offsets, get black to be perfectly black with no color in it, then adjust the coarse pre-adc gain. Individual gain adjustments typically aren't needed. I can get it absolutely perfect and stunning on my TV, and about 95% perfect on capture devices.

Sent from my SM-G955U using Tapatalk

[rama]

Oh, really? Then it's not working right, I think.
The main effect of auto gain is that "intended to be white" areas are indeed white, yet nothing is overblown and clipping.
Going further, an auto gain feature actually also requires an auto offset, to balance the 3 ADC channels at black = ADC code 0.

I've already added some code for the auto offset, but it's not enabled yet.
Hopefully I can add this soon. It should help doing a better job overall

[NoAffinity]

Oh, really? Then it's not working right, I think.
The main effect of auto gain is that "intended to be white" areas are indeed white, yet nothing is overblown and clipping.
Going further, an auto gain feature actually also requires an auto offset, to balance the 3 ADC channels at black = ADC code 0.

I've already added some code for the auto offset, but it's not enabled yet.
Hopefully I can add this soon. It should help doing a better job overall

Great, looking forward to that!

And then of course I'll probably need to swap those SOG caps, which I've been trying to avoid but well worth it if the gain feature gets that slight improvement to perfection.

On a side note, I picked up a nice Extron MVX44 on ebay for $40 shipped. It's a great little device for sending the GBS VGA output to a screen and capture card simultaneously, and if you get deep into VGA like I have recently, also for matrix'ing other sources across various screens. Highly recommended for anyone trying to solve similar problems in their chain. :p

[maxtherabbit]

Oh, really? Then it's not working right, I think.
The main effect of auto gain is that "intended to be white" areas are indeed white, yet nothing is overblown and clipping.
Going further, an auto gain feature actually also requires an auto offset, to balance the 3 ADC channels at black = ADC code 0.

I've already added some code for the auto offset, but it's not enabled yet.
Hopefully I can add this soon. It should help doing a better job overall

Great, looking forward to that!

And then of course I'll probably need to swap those SOG caps, which I've been trying to avoid but well worth it if the gain feature gets that slight improvement to perfection.

On a side note, I picked up a nice Extron MVX44 on ebay for $40 shipped. It's a great little device for sending the GBS VGA output to a screen and capture card simultaneously, and if you get deep into VGA like I have recently, also for matrix'ing other sources across various screens. Highly recommended for anyone trying to solve similar problems in their chain. :p

+1 on the extron MVX VGA series, absolutely adore mine

[Ryoandr]

I've come to recognize Mega Drive / Genesis pictures by their low amplitude RGB.
It's really the weakest RGB out of all the usual sources. Maybe our cables are all wrong? There has to be a reason.

this is mentioned in md 240p suite help pages, it can only do like 96 IRE max.

[rama]

Just had to check what anyone means when they talk IRE today :p
So 100 IRE is black to fully white (fully ignoring the sync tip). In that regard, 96 IRE is quite fine.

What I often see though is that Mega Drive RGB is particularly dark. It shows in captures on Youtube, in my own consoles and cables, etc.
Combined with the unusual RGB input configuration to the CXA1145, I really start to question whether the Sega design is "correct" (or our understanding of it today?).

Also: Probably unrelated to any video levels, but the 75 Ohm series should be right at the CXA1145 outputs, not 3 meters away in the SCART plug! ><

[maxtherabbit]

Just had to check what anyone means when they talk IRE today :p
So 100 IRE is black to fully white (fully ignoring the sync tip). In that regard, 96 IRE is quite fine.

What I often see though is that Mega Drive RGB is particularly dark. It shows in captures on Youtube, in my own consoles and cables, etc.
Combined with the unusual RGB input configuration to the CXA1145, I really start to question whether the Sega design is "correct" (or our understanding of it today?).

Also: Probably unrelated to any video levels, but the 75 Ohm series should be right at the CXA1145 outputs, not 3 meters away in the SCART plug! ><

nothing like source terminating at the destination!

[rama]

Yeah. Any considerations regarding output driver ringing or such are discarded. It's just about getting system impedance right'ish then.
But hey, it's not just Sega. The others like to do it, too.

It really needs a Neo Geo or similar to include these pricey resistors in the console :p

[rama]

Ooh, I found out what makes the Sync input be so difficult on some boards and not others!

It wasn't an SOG ADC difference between different TiVo ASIC's, but the unused Myson controller instead!
The "S" and "V" signal both go to the TiVo and the Myson, each doing some judgement on the signal.
The Myson is disabled via jumper, but its input pins apparently aren't quite as high impedance as expected.
Basically, even when disabled, the Myson distorts the sync signal!

But how come it's only bad on some boards?
Well, some boards have 1k series resistors on the "S" / "V" signals, others use a direct connection.
Boards with the resistors have good sync, boards without have difficult sync.

I completely missed this up until now :p

The inline resistor (on the board that has it) is designated R54 and is placed close to the Myson / original firmware MCU.
With this present, there is no need to do anything.
With no R54, a quick hack to fix the issue is just cutting the "S" / "V" traces.
(This will prevent the original firmware from seeing any sync, of course.)
https://i.imgur.com/mZFsjCO.jpg
Here "S" and "V" are cut. "S" is the left trace. The missing R54 resistor should be where "R35" is in this picture.

There is no immediate need to modify your boards, but if yours is affected, trace cutting improves the margins for sync tip detection by about 50%.
Maybe I'll find some other fix later, but this can't be changed by software.

[NoAffinity]

So is there actually no pad for r54, on boards that dont have that resistor? Possible to do a wire jumper or such with the 1k resistor inline, to reinclude it?

Sent from my SM-G955U using Tapatalk

[rama]

Nope, it's a continuous trace S pin to the Myson input pin.
You either break the trace or lift the pin on the Myson. Can't think of another method.

If you don't have sync issues, then don't worry about it :p

[rama]

Quick way to test your board using a multimeter:
Measure resistance between "S" and the 4th pin to the left of the original MCU.
If it's continuity, you have a problem board and may want to consider cutting the trace.
If it's 1kOhm, your board is fine.

I think they realized that putting this signal onto the Myson without attenuation was a problem for Composite Video sources.
It distorts the signal, no matter if the Myson is active or not.
No problem with high level arcade syncs, but CV sync degrades quite a bit.

[fluxcore]

Dang, so not only am I missing that resistor (exactly the board in your picture which requires the cut traces), but I had replaced the C33/C35 capacitors... and threw out the originals.

Do you have the exact specs needed for the original caps?


I'm also not very keen to cut the traces at this stage, since I need the original firmware to function properly to use with my UMK3 board (until the CFW supports it... )

[rama]

These hardware mods all contribute to make the sync detection work better or worse, but they're not staggered linearly.

I think the capacitor change is a very good thing for all boards, but it affected some boards negatively with the refined sync processing code.
So keep the changed capacitors and then judge if the sync works well, or not.

If there's never a sync loss, no problems with white to black transitions, etc, then you're set. Leave everything as is.
If there's occasional drops, particularly white to black transitions (on your missing R54 board), cut the trace or entirely remove the Myson (that works well!).
To that end (removing / disabling the Myson), what was the problem with the UMK3 board again?

Edit:
Oh, the entire work of last month is now merged. The firmware is now much more decisive and does what it can to correct sync problems quickly.
If it doesn't seem to want to sync, the blame is now almost surely with the hardware or because of unknown (to me :p) timings.

[fluxcore]

To that end (removing / disabling the Myson), what was the problem with the UMK3 board again?

See viewtopic.php?p=1352885#p1352885 - couldn't sync with the timing, but stock firmware can

Thanks for the other notes, I'll update when I get a chance and see how it goes.

[rama]

Native game res is 400x254 at 53.20Hz, so it's pretty wacky.

Happy to help debug, just let me know what info etc you need

Wellll
A Teamviewer connection to your pc, with the arcade board running and the GBS/ESP8266 connected to the pc via USB to allow sending commands via terminal :p

Basically, there's far too many variables to check, so I really need to do it "live".
You'd just have to tell me when your display starts coming up, while I tweak the registers :p

Edit:
The latest update "okays" the initial detection loop in case of failure, so it gets a better chance of displaying something with unknown sources.
So give it a try, maybe something more happens now.

[tbender]

A friend hooked me up with a Datapath card so I can make dank analog captures.

Here's how tag looks with the 1280x960 preset. I'm still kinda new to configuring both this thing and the capture card but it looks great so far. I'm having a lot of fun.

Spoiler

Once I figure out how to dial in the horizontal size and all this other technical stuff to capture the JVS video natively I can make a cool little comparison to the source video.

Thanks for all the hard work you've put into this project!

[rama]

Cheers :>

That's a good capture indeed.
I bet it'd save me lots of eye strain if I had screen grabs like these.
Just zoom into areas of interest on the PC :p

Anyway, the quality seems about right. I spot slight jailbars in the health bars, that might come from insufficient TiVo 5725 output filters for RGB.
Some boards seem to have these stronger than others, but I think all could use a little stronger ferrite beads.
I mean, I can get a PC source at 1600x1200 pretty sharp, so there's definitely some headroom for stronger filters.

[tbender]

If I understand correctly, I might be able to iron out the jailbars on the capture card’s end. The retro guys streaming with this Datapath dial in the exact horizontal resolution and tweak this other setting named phase to make the anomalies go away. I’m already happy I don’t have to fiddle so much with the defaults with this GBS.

I’ll report my findings if I have any.

[tbender]

My apologies for double post.

Is there a ferrite bead location and type you’d suggest? I can’t unsee the jailbars now :c

[Syntax]

220ohm@100hz right next to the inputs termination (75r) resistors.

[rama]

It depends on where these bars originate.
If it's the source or cables, input filtering could help.
If it's the TiVo (display or SDRAM clock perhaps), then the output filters could be changed.
Inputs are R55, R56, R57 and outputs are L4, L5, L6.

You can test different output presets to see if they significantly change the jailbars.
Also try the bypass mode.
If the jailbars stay the same, the problem is with the source / cables.
If they go away or look very different, it could be the output.

[rama]

ADC offset calibration is now available
The feature will be used automatically when ADC auto gain is enabled.
It measures the 3 individual color channels and determines the correct offset for the particular board / TiVo chip.

If you use the auto gain feature, please check the logs for the offset values.
Anything from 0x3e to 0x4a or thereabouts is possible. Most boards will be around 0x3f or 0x40.
I have one particularly red hue board here and that auto offsets to R = 0x46 now.
The picture is good after that, so that's something

[Heraz]

Hi, I just would like to thank all the people that worked hard on this project.
It is an amazing improvement. I have a (PAL) version MSX2 from 1987 and the video never looked better!
I used an old ESP01 (that was what I had available) and with a few modifications it worked.
Now back to Metal Gear...