shmups.system11.org

awesome! I'll give it a try. Any news on a possible 1080p preset?

Hm, not yet. I don't remember what I said last about it, but one concern is that it's quite a lot of lines.
I'll probably have to drop the VDS (DAC) clock a little for this.

Right now I'm battling CSYNC crap again. It's the old fight SNES versus Mega Drive!
One machine's sync requires a low'ish wrong pulse ignore value, the other a high value.
Serving both reliably is quite the pita :p

Oh, and the other day I found a CSYNC descrambler that should work!

@rama but in conclusion that does the same that a single ic does, is it worth the labour ? Even source stated that its cheaper alternative to the cost of AIO IC. But that part that it aligns ranges i think is kinda interesting.

I breadboarded the circuit but it didn't work out right.
Maybe it absolutely requires its particular input clamp setup, as I've omitted that and just fed it an inverted LM1881 signal.

It's still pretty interesting though.
VSync generation worked correctly but it didn't seem to cancel that many serration or equalizing pulses.
Tweaking the resistor values, I could get it to maybe half of the bad pulses removed.

Oh well, learned something new

@rama
https://www.google.lt/amp/s/ianstedman. ... gines/amp/
I believe you have seen this

Nice work rama, now it's very tempting to buy one of these gbs boards to use with the Amiga since many users have lcd:s with native resolution 1280x1024
It's really just the flickering for PAL 50 Hz interlaced modes that holds me back for the moment.

redcatex:
If you're about trying LMH1981, I think this type of adapter would make life easier when soldering.

https://www.ebay.com/itm/1-2-4-SOP14-SS ... 3175268216

@jblander yes ssop adapter would be helpful, but soldering direct for me is not a problem. Bigger problem is price of seperator itself, its not like lm which you can get a lot for few dollars

Edit. Btw already started prototyping a manual control with oled display in proteus. All my hw is back at hometown, so I have to simulate arduino and oled. So far so good. Started design a menu and program functionality, created few pull up buttons over 1 analog input.

Oh yeah, definitely try minimizing additional wires at all cost!

The need to solder stuff is, in my opinion, the biggest issue that holds back more people from using this project.
People can excuse adapters and bare PCB (mostly), but soldering is too much.

And well, I honestly consider an entire wire per button a huge waste as well ;p

Small update:
I was working on more debug bus features. One of the extra modes puts a digital representation of the output video onto the bus.
The result: There'll be an auto gain feature again. It'll automatically find the correct ADC gain for each different source

@rama yeah using whole input for one button is a waste for sure, and esp only have one analog pin. so using resistors is the only way to have this feature.

On the other hand regarding wires and all that stuff, still my board is heavily missing components, cause was using my own headers, just to create addon board, later on thinking to create PCB with all stuff in one place, which plugs into headers, and that's it, user plugs in esp8266, flash it and it's done. The idea is like a daughter board, ofc to have daughterboard you need to solder everything in place, but I think it's easier if I will share PCB design and users can just ask someone skilled to do everything and just plug to GBS. maybe that way your work + ease of hardware preparation will get more attention. Cause gbs-control is a solid piece, and I can imagine all the effort and time you put on it. Plus I suppose upgrading previous guys work, and sharing it with the world is not that you want to keep it for yourself.

Sorry if my thoughts are hard to understand.

How can I find the correct http gbscontrol address once I'm connected to my local network.
I can find the ip address on my box network status page, but I have to look out each time in case the address changes.
I get 403 forbidden if I just use http://gbscontrol

If you're lucky, your router provides some kind of lookup service. On mine, the device replies for "http://gbscontrol.fritz.box/".
I also added some mDNS stubs, which is the only other way I know for this to work as expected.
MDNS requires some extra software on Windows to work (and something else on each other OS).
People recommend Apple's Bonjour or iTunes (apparently?), but the pure printer discovery drivers do the job as well:
https://support.apple.com/kb/DL999?viewlocale=en_US

With that installed, you can now use "http://gbscontrol.local/" and the device will respond.

Thank you Rama, that worked fine.

I did some tests.

First, on a Mitsubishi XC3730C aka Megaview. The monitor is multiformat and able to display a very wide range of resolution, including 15khz range. MD2 with NTSC crystal running at 60hz.
1st test is 1280x1024 with scanlines. Looks very clean. Small defaults, changing back and forth between 320 and 256 wide can result in a resync attempt from the monitor (rare occurences) ; 256 wide res is also a bit higher, see 2nd pic.



Then tested Sync passthrough, it worked, you can see the size of OSD corresponding when 15khz content is displayed. However the image is completely shifted to the left, I had to push Hphase to the max. I also had some sync jumps every 5-10s.


Second, test on a JVC DT-V 1710, it's also multiformat, but it's much less flexible in the higher resolutions. The advantage over multiformat PVMs / BVMs is that the RGB card allows RGBHV input so a simple VGA-BNC can be used. The monitor serie is known to have skewed upper image with malformed sync (MVS can be seen, direct to monitor, apparently PCEngine is pretty much unusable).


Note that the MVS is currently under consolization, using non shielded thin wire ; there's color bleed on right side of objects and the GBS amplifies that defect by a huge factor, do not use these for quality rating. The MD above has a good cable and comes excellent.


640x480 worked ok, but my focus was on sync passthrough. It had a bit of trouble syncing put at some point it managed to. Image was a bit on the left side but not as much as with the XC3730.


There was some sync jumps every 6-8s, managed to capture one, as you can see it's an horizontal rolling.


However the big new is that the upper skew is actually gone, moved the image on monitor controls and you can see the upper right corner is perfectly straight.


If the sync can be secured it would be great news for the various upper skew troubles.

These are some nice test results!

The shift towards the left in passthrough mode is from me guessing where HSync should be placed.
My scope can't resolve an entire field with enough detail to see the relations.
Anyway, the fix is to just move the recovered HSync position. Now that I know, I can fix it

Mega Drive's mode changes are drastic retiming. This is the console itself doing something pretty bad.
The horizontal sync width for example changes by 30%! I suppose TV sync processors are more robust?
I use this switch myself, to optimize for worst case timing changes.
However, no amount of coasting or glitch protection seems to stabilize an MD mode change.
I'm always working on improvements though, so fingers crossed

By the way, you need to optimize your sync connection for each console as well.
Ideally, you'll have 75 Ohm terminated CSYNC with > 0.3Vpp (but less than ~ 3.6Vpp) amplitude.
An LM1881 type sync stripper is a good alternative, but here the input needs to be within 0.5Vpp and 2.0Vpp while the output has the same requirements as before.

As a small test, type these commands and see if sync is stable across the range:
wsog 1
wsog 16
wsog 31
The range is 0 to 31.
If you can go to 31 without issue, you have good CSYNC.
If it's stable until you hit ~16, you have properly terminated video as sync source (Luma or Composite Video).
But if you're stuck at very low levels, then check your setup! Your sync tip is very weak, probably because the termination is wrong (or Mega Drive's weak CSYNC).

I tend to use Luma as Sync, by either rewiring console composite pin, or using luma if directly available on the avout, that way the cables are still universal and preventing accidents (ie, euro SNES with 12v on Csync pin), and signal is still in specs without a noisy 3/4mhz subcarrier. The GBS has an LM1881 circuit either way.

Will try the wsog command later when I have time.

Luma sync to an LM1881 is a very good choice.
Just make sure the LM1881 input termination is right (75 Ohm), and that it's being fed 5V.
Unfortunately, there's no reliable 5V source on GBS boards, but the 3.3V will work okay.
With just 3.3V, the output CSYNC will have slow flanks, but the GBS can still work well with that.

At 3.3V you also won't need an output series resistor.
At 5V (and up to ~8V max), a 470 Ohm series resistor needs to be added, to form a voltage divider into the scaler chip.

By the way, I'm currently working on ironing out sync issues.
Check the development branch. It might fix some issues, it might make them worse :p

no worries about 5V, all boards and the LM are supplied with 5V.
Added the 470R and checked wsog command, only wsog 1 had unstable, up/down display. Gonna try dev branch now.
OK so passthrough is still too much on the left, however I haven't yet seen a horizontal roll and 320 / 256 transitions are instant, at least the mitsubishi doesn't resync at all (OSD popups on resync so it's very obvious if it happens).
Now to try the DT-V

DT-V works perfectly with MD, no jumps, no rollings. MVS had no rolling, but there was some flicker going around every 2-5s. Also for some reason picture was near perfect with no bleeding, may I had a bad connection last time (or did you apply some magic ?).

One thing I forgot to try is MD with SMS games, known to produce upper skew, gonna try that.

WAIT !
After about 20-30s, display stabilizes on the DT-V ! Image is perfect asides from horizontal position, no bleeding, no skew, AMAZING.

Perfect, same as my setup! (important to me, I need to aim for consistency across setups)


I haven't pushed my changes on that yet. Keep watching the branch


Well, these keep cropping up. It seems I can't get sudden clock skews fully stable.
Oddly enough, progressive / interlace switches are less of an issue than horizontal timing changes.
I wonder how devices like the OSSC deal with them..

Don't hold your breath for that fixed DT-V display (yet). It might be a fluke that it worked, it might get broken by my next commit (huge one).
I hope it'll be fine, of course ;p

Hi to everyone!

I followed this thread from the beginning, recently I got all the stuff (GBS8200 v4, Wemos D1R2, Arduino IDE, etc)

my only concern it's about how to interact with the Wemos (not to programming).
how can I access to webiu?
the Wemos works automagically after been programmed?

thanks in advance

Dev branch has what's basically a rewrite now. It'd be great if some CRT users could report on new issues!

I suppose I figured out how the chip was meant to deal with PAL / NTSC equalization pulses.
Instead of the tedious masking via the ignore short HSync register, I now look at every HSync pulse.
The bad ones are now masked by an extended coasting range (this is what was so confusing when reversing the chip and docs!).

All the presets will be vertically shifted, and due to other improvements, horizontal shift is also possible.
It'd be great to know how CRTs deal with it now.
Once the presets are corrected, gbs-control will work much better, due to the improved program flow

Edit:
Oh, and the ADC auto gain feature from the early days is back, too!
This uses the test bus to read back the ADC input levels, and adjusts the gain until it doesn't clip anymore.
Unfortunately, the method causes colors to be clipped at first. The feature needs a short while to adjust to final levels.
(Displaying a 100% white screen makes the transition instant, so "show it" bright colors.)
On the plus side, it corrects each color independently and therefore normalizes the color balance and evens out different source levels (SNES!).
The feature is working well now, but I still want to improve it

manuelink64:
The ESP8266 works automatically, yes.
It starts talking to the scaler chip, just like the original chip would do (but we disabled it with the jumper).
Automatic functions include:
- input selector (3 plug RCA, VGA connector, pin headers for RGBS)
- source format detection, including sync extraction for combined sync types
- applying a default 1280x960 preset (for 50Hz and 60Hz separately, output will be 50Hz or 60Hz as well)
- automatic ADC gain adjustment (only on the development branch, it's still being worked on)
- various sync optimizations, to allow a broad range of input conditions to sync up
- power down mode if the source is turned off, back to active mode if the source returns

The web ui can be used to select different presets, adjust image position or ADC gain, etc.
It is available in AP mode (use your mobile for example, and connect to the WiFi AP "gbscontrol", then open any website to be redirected).
Alternatively, after you connected in AP mode, there is a button to configure station mode.
In station mode, you enter your home WiFi credentials and from then on the ESP8266 will connect to your router and be available in your network.
This mode isn't perfect though. Many people will have to address the device using its IP address directly.

Source passthrough is broken with MVS
Doesn't work on the DT-V and show flickering image on the mitsubishi.

Passthrough with MD still works, image still too much on the left.

BTW do you prefer feedback here or on the git ?

I check Git more often ;p

Okay, could I have a log of the MVS failing? I'm particularly interested in how many vlines both detectors see.
So the startup log + 4 lines of the information mode readout ('i') would be best.

For the horizontal shift, try 's5s45s30 s5s47s40' and see if that shifts the picture more.
If it does, then try 't5t57t6'.
If nothing works, I'll have to work on bypass mode more.
The feature is brand new anyway ;p

Hi rama and crew- I'm running a quite old build from last Jan/Feb on an Arduino Uno. I haven't checked on this thread since then, and there has been quite a flurry of development since then which is great!

Would it be possible to summarize on the github project page perhaps current and targetted features? It's not clear to me what the actual goal is. My use case was different than others in this thread- I have an arcade cabinet that only supports 31khz- I'm using that build with a custom preset to scale 15khz output from an MVS up to 480p using RGB input.

is 240p RGB in to 480p VGA out a standard supported output resolution, or is it only 720p and higher? I'd like to know before I attempt updating, which looks like it will require swapping out my Uno for a Wemos or NodeMCU, correct?

A diagram of how I have things connected and for what purpose can be found here if anyone is curious: https://falz.net/wiki/Neo_Geo_Arcade_Cabinet#Display

WAIT NOW IT WORKS...
Wtf, I just changed positions for using the Mitsu and now passthrough works, and better centered to boot..

Last time I did various power cycles to be sure, and now worked fine... gotta go back to the D-TV and try the MD again, but damn it's random...

ok so on reset, it is decently centered, only needs to go up to HPhase 47 (32 being middle setting). The command you told me didn't really change much but the 3rd made the picture vertically squish. Anyway now to test the MD.
MD is reasonably centered as well, 256-320 are still instant with no resync, this is looking good honestly. Now to go back to the DT-V.

OK I GOT IT !
When comming from 640x480 preset, enabling sync passthrough results in flickering and unstability (and no sync on the DT-V). I have to use 640x480 for the DT-V so I set it on default load, which when coming back on the mitsubishi did the error.
Gonna set 1280x720 and try again on the DT-V.

So this still doesn't work on the DT-V even not comming from the 640x480. I can have it working on the Mitsubishi, unplug the video cable, plug the DT-V and no image (well OSD says no Sync)

Hey rama,

Finally got my esp82 board. The first one I ordered has been lost by USPS since 9/3, so I re-ordered, and it came today.

Loaded the esp support in arduino IDE, downloaded current sketch from your github, and am getting the following message when trying to compile. Thoughts?

:edit: nevermind, I was making a handful of mistakes. I'm still getting an error while compiling, albeit a different one. I'll spend some more time on it before posting for help.

Hey rama,

Okay definitely need some help here. I'm probably doing something dumb. Compiling the latest sketch from your github, it's getting very near to completion, but errors out with the below:

@NoAffinity
What is your ESP8266 core version? Try to update your Arduino IDE installed boards + libraries.
Edit: This is a great guide, if you need some pictures
https://github.com/toblum/McLighting/wi ... stallation


@Ryoandr
I'll try to work through the issues you posted on Github.
Bypass mode for example should really just bypass the incoming signal. There should be minimal influence from the loaded preset.
This is an easy fix ;p

Hi falz,
I'm sorry that there's no comprehensive overview yet. The project is perpetually in beta, with the features becoming clear only after a while.
Fortunately, a 240p/480i input to 480p output mode is implemented and will be supported in the future as well!
You want to use the "640x480" preset.
As with the other presets, it will automatically adjust for 50Hz / 60Hz sources, so most use cases are covered.
Using the web ui, you can tell gbs-control to "prefer default 640x480 preset", so it always defaults to it.
You can customize the presets as well, if you want, and then have those customized presets loaded by default.

I hope this helps?

I just fresh installed arduino. Esp core 2.3. Updated/installed all esp libraries. Manually updated the hash libraries (copy and paste code text from github, I'm sure theres a better way but I dont know it). Still, same result. I found the sample code for setpasswordhash and see that it is identical to what is in gbs-control sketch.

Sent from my SM-G955U using Tapatalk

The ESP8266 core is at v2.4.2 already.


Make sure you have this additional board manager url (in Arduino IDE File > Preferences):


Edit:
And if that solves it, could you tell me what you did to get the outdated version? ;p