GBS-C sync issue with Neo Geo

[amerika13]

I recently integrated the GBS-C into my main capture chain and I am having a bit of an issue with my Neo Geo. It, for some reason, won't sync correctly. You can see that easily in this video. I also added the debug terminal into the capture so you can see what is going on there. https://www.youtube.com/watch?v=6pWeF0ECJFc

Neo Geo description: Neotropolis modded Neo Geo that adds, via jacks, composite, svideo, component and stereo to the back of the unit. This is it: http://www.neotropolis.net/33401.html. It is specifically a 3-6 and it is hooked up via component out.

I do have another Neo Geo 3-5 that is completely stock and fixed up recently that I can hook up via HD Retrovision cables to test, but that will probably be another day or so due to my time being pretty limited at the moment.

Thanks

[ramapcsx2]

Hey, this is a known problem with the current sync watcher code when using certain MVS board revisions. I need to debug it, but I don't have the time..

[amerika13]

This is an AES unit if that matters. And I hear you on the time thing. Never enough of it to go around.

Sorry to re-post a known issue. I did search for open AES/MVS bugs but found nothing. Do you want me to close this or keep it open?

Thanks Rama and take care!

[Ryoandr]

I tested several AES and MVS, and in my results some MVS are unable to sync and all AES were unable. I sent Rama 2 MVS, one that worked and more recently one that didn't. Hopefuly he manages to look at it soon. :) So be patient all ;)

[PunchMSX]

My Neo Geo CD also has issues with sync, I get "heatwaves" coming out of it (basically a jittery image), but at least with some patience turning the sync signal physically on and off again multiple times it seems like it does eventually sync "correctly" (you can see subtle scanline drift if you pay attention but it's minimal). How do we bribe you to look into it? (:

[jboffel]

Hello, I can confirmed the two AES I tried could not sync properly, a lot of skipping on the video and top of the screen always lagging. I used stock RGB with board 3-5 & 3-6. For info the voltage for stock RGB of AES is offset by +2V. I assembled the GBS-C following Voultar tutorial on YouTube.

Here a Debug view of the serial while trying to hook a neo geo AES JPN

01:23:54.969 -> Scanning inputs for sources ... 01:24:00.660 -> Activity detected, input: RGB 01:24:02.319 -> 01:24:02.319 -> 2345678 01:24:02.469 -> Format change: 1 01:24:03.218 -> ADC offset: R:42 G:40 B:42 01:24:03.218 -> clock gen reset: 108000000 01:24:03.469 -> (debug) ign. length: 0x6D 01:24:03.654 -> (debug) ign. length: 0x6E 01:24:03.800 -> (debug) ign. length: 0x74 01:24:04.195 -> (debug) ign. length: 0x78 01:24:04.783 -> to1 is: 1515 01:24:05.619 -> 01:24:05.619 -> preset applied: 1920x1080 for NTSC 60Hz (set your TV aspect ratio to 16:9!) 01:24:05.619 -> 01:24:05.731 -> 01:24:05.731 -> . (debug) ign. length: 0x6A 01:24:06.229 -> . (debug) ign. length: 0x68 01:24:06.690 -> . (debug) ign. length: 0x1A 01:24:07.121 -> . (debug) ign. length: 0x69 01:24:07.617 -> . (debug) ign. length: 0x69 01:24:08.074 -> . (debug) ign. length: 0x69 01:24:08.541 -> . (debug) ign. length: 0x69 01:24:08.922 -> . (debug) ign. length: 0x68 01:24:09.321 -> . (debug) ign. length: 0x68 01:24:09.785 -> . (debug) ign. length: 0x69 01:24:10.253 -> . (debug) ign. length: 0x69 01:24:10.830 -> . (debug) ign. length: 0x69 01:24:11.287 -> . (debug) ign. length: 0x67 01:24:11.798 -> . (debug) ign. length: 0x69 01:24:12.257 -> . (debug) ign. length: 0x68 01:24:12.606 -> . (debug) ign. length: 0x69 01:24:12.962 -> . (debug) ign. length: 0x6A 01:24:13.359 -> . (debug) ign. length: 0x69 01:24:13.713 -> . (debug) ign. length: 0x69 01:24:14.074 -> . (debug) ign. length: 0x6A 01:24:14.464 -> . (debug) ign. length: 0x69 01:24:14.825 -> . (debug) ign. length: 0x69 01:24:15.192 -> . (debug) ign. length: 0x68 01:24:15.583 -> . (debug) ign. length: 0x64 01:24:16.016 -> . (debug) ign. length: 0x65 01:24:16.482 -> .***** 01:24:22.129 -> no signal 01:24:22.388 -> h: 427 v: 773 PLL:0 A:7b7b7b S:07.10.10 I:00 D:0008 m:0 ht:2557 vt: 203 hpw:2939 u: 96 s: 0 S: 7 W:-47 01:24:23.519 -> **************************** 01:24:43.109 -> no signal 01:24:43.356 -> h: 511 v: 2 PLL:0 A:7b7b7b S:02.18.00 I:10 D:0028 m:0 ht: 0 vt: 0 hpw: 0 u:384 s: 0 S: 5 W:-49 01:24:43.894 -> ********************************* 01:25:05.523 -> no signal 01:25:05.773 -> h: 393 v: 2 PLL:0 A:7b7b7b S:02.1a.10 I:10 D:0028 m:0 ht: 0 vt: 0 hpw: 0 u:708 s: 0 S: 5 W:-41 01:25:06.098 -> ********* 01:25:11.735 -> 01:25:11.881 -> Scanning inputs for sources ...

[jboffel]

I've a setup that allow me to input command to the serial while running the AES on a screen. I'm not knowledgable enough to know what I'm messing with but if you get me what command you need to generate some valuable output to understand the issue, I can try to reproduce them.

[jboffel]

Trying out more things, I realized the skipping is due to the syncwatcher activity probably trying to figure out the optimal setting. But for some reason it seems to fail to do so. When I run ! command in the serial I see the return value for sfr is 0 as well as pll (because getPulseTicks returning 0?). The AES use a C sync at 15.75khz at stock. Can it be a reason here for not being able to get the pll? Sorry I might say non sense as I'm just experimenting with my limited understanding of video signal.

I've no real idea why but since I tried a hack in the getPulseTicks, I faked a return value that will lead to have a more or less sfr and llp of 64 as well as source Hz and out of 64.0 When I do that and I disable the syncwatcher using the m command, I will often get a near perfect image. Most of the time it will at least clear the top of the screen from the unsync lines and sometime even give a perfect image without skipped line at all.

static uint32_t getPulseTicks() {
    uint32_t inStart, inStop;
    //Comment the return to rollback
    return 10000000/4;
    if (!vsyncInputSample(&inStart, &inStop)) {
      return 0;
    }
    return inStop - inStart;
  }

02:06:39.390 -> source Hz: 64.00000 new out: 64.00000 clock: 108000000 (+0) 02:09:59.287 -> sfr: 64.00 02:09:59.287 -> pll: 64

[ramapcsx2]

The problem is complex. You can read all about it here: https://www.hdretrovision.com/blog/2018/10/22/engineering-csync-part-1-setting-the-stage This machine is going to have one of the mentioned sync issues, and the sync processor / gbscontrol can't figure it out.

[jboffel]

I've been running a few extra tests just to try eliminate possibilities, I've wired a LM1881N in between the AES 3-5, 3-6 stock to see what would happen if I feed a H sync and V sync. Based on my understanding it is not supposed to be necessary actually for the AES. But anyway, I thought maybe there is a signal issue from what the AES is outputting at stock and what the GBS-control like.

I'm still forcing the getPulseTicks() output to force a close by value of what the AES Jap is supposed to do (59.18Hz), this return value 2703616 gives: "source Hz: 59.18000 new out: 59.18000 clock: 108000000 (+0)"

I also need to toggle on Low Res: Use Upscaling, otherwise I don't have video output at all (also attached the log of the initial sync in that case)

But then with RGB/HV (CSync) and RGB/HV upscale mode I get the video signal reliably (mean each time I activate this setup it shows up). However I can still see this weird horizontal black line between each video line, as like it is skipping half of the horizontal lines. I can't find a setting that would avoid it. I attached the picture of the pattern from one corner of the screen.

Complete sync log with upscaling: 00:55:54.344 -> ext clockgen detected 00:55:54.379 -> 00:55:54.417 -> Chip ID: 1A 1 00:55:54.417 -> G: 3E G: 3F G: 40 00:55:54.706 -> R: 3E R: 3F R: 40 R: 41 R: 42 00:55:54.964 -> B: 3E B: 3F B: 40 B: 41 B: 42 00:55:55.253 -> 00:55:55.286 -> Activity detected, input: RGB 00:55:55.502 -> VSync: present 00:55:55.502 -> HSync: present (with CSync) 00:55:56.140 -> RGB/HV (CSync) 00:55:56.140 -> clock gen reset: 81000000 00:55:56.863 -> RGB/HV upscale mode 00:55:56.863 -> 59.18 00:55:56.897 -> ADC offset: R:42 G:40 B:42 00:55:56.897 -> clock gen reset: 108000000 00:55:56.968 -> 00:55:56.968 -> preset applied: 1920x1080 for scaling RGB (CSync)(set your TV aspect ratio to 16:9!) 00:55:57.005 -> Note: scaling RGB is still in development 00:55:57.005 -> 00:55:57.324 -> source Hz: 59.18000 new out: 59.18000 clock: 108000000 (+0)

Without upscaling: 00:16:26.868 -> ext clockgen detected 00:16:26.941 -> 00:16:26.941 -> Chip ID: 1A 1 00:16:26.978 -> G: 3E G: 3F G: 40 00:16:27.260 -> R: 3E R: 3F R: 40 R: 41 R: 42 00:16:27.518 -> B: 3E B: 3F B: 40 B: 41 B: 42 00:16:27.803 -> 00:16:27.840 -> Activity detected, input: RGB 00:16:28.060 -> VSync: present 00:16:28.060 -> HSync: present (with CSync) 00:16:28.688 -> RGB/HV (CSync) 00:16:28.688 -> clock gen reset: 81000000 00:16:29.996 -> (SP) HS active low

[ramapcsx2]

So what I take from this is that it helps to hardcode values for 59.18Hz resulting Vfreq?

[jboffel]

Well to be honest I don't know if this is the reason. I just forced this value because it's supposed to be the expected input freq. But truly, it also works similarly with hard coded frequencies even up to 64Hz. The main things being that if I don't force a returned value then vsyncInputSample() will return false then forcing getPulseTicks() to return 0, therefore failing completely to find a source Hz...

[Ryoandr]

AES refresh rate is not the same as MVS. AES have a slightly higher crystal to be closer to NTSC (only the earliest AES are the same as MVS). 3-5, 3-6 have the higher crystal for sure. https://wiki.neogeodev.org/index.php?title=Framerate

[jboffel]

Thanks for the link, I'll try to force value that closely match the 59.599 to see if it makes any difference

[jboffel]

Well, I made a fool of myself I'm afraid! After diving more into the source code, I realized the debug pin used for the vsyncInputSample() seems to be exclusively use for that. So I started to think what if my wiring is wrong and I actually did not soldered properly the PIN D6. And guess what, of course it was that... After soldering properly, I can say for sure that neo geo JAP NTSC 3-6 is working like a charm and is auto-detecting best setting: "source Hz: 59.60177 new out: 59.60181 clock: 161263664" I was not so far with my manual setting previously from the truth, I'm ashamed to admit that the black lines was just the scanlines filter with low intensity, if I deactivate it the image is really nice. However it is still my setup with LM1881N, I'm yet to test without the chip in RGB (Csync)...

[jboffel]

Ok so I tried bypassing the LM1881N, and it is same result as before, unable to sync in RBG (Csync) without the V sync signal. Is it only a software issue or a problem with the signal out of a stock AES I'm not sure, but it can't sync ATM without the LM1881N

[Ryoandr]

So I tried an LM1881 on both the sync line and the csync out of the CXA1145 and I still couldn't get a stable picture. However, it made me look at AES video circuit, and It has a whole circuit that adjust system frequency to better set composite encoding. https://wiki.neogeodev.org/index.php?title=Video_PLL

Jboffel, I'm assuming you did the 1881 sync stripping on the composite video line, so maybe it's the only solution.

That still wouldn't explain why some MVS also have sync problems...

[jboffel]

If I remember correctly I just wired straight RGB cables to the upscaler then wired the composite video provided by the aes to the lm1881 video input then wired the vsync output to the vsync entry of the upscaler. Then use the upscaler with the RGB/HV instead of CSync... Of course I used usual resistor and capacitor with the lm1881 as well.

[Ryoandr]

ah ok, you used 1881 Vsync output too, I didn't, gonna try

[Ryoandr]

Ok so i tried lm1881 vsync, while still on cxa1145 csync output, even tried with a pot to see if a load changed something. Couldn't get a stable and reliable pic. So then I tried the 1881 on the composite video line... It worked instantly... Kinda annoying since I try to use clean signals to avoid crosstalk in cables... So now I have to think about an LM1881 implementation, in either the console or the gbs.

[jboffel]

Personally I just added it in the scart cable gap back of the pins to avoid touching the upscaler or the console...

[davince72]

Ok so i tried lm1881 vsync, while still on cxa1145 csync output, even tried with a pot to see if a load changed something. Couldn't get a stable and reliable pic. So then I tried the 1881 on the composite video line... It worked instantly... Kinda annoying since I try to use clean signals to avoid crosstalk in cables... So now I have to think about an LM1881 implementation, in either the console or the gbs.

Could you share schematics maybe or more detailed description. I recently bought the GBS-C and the new 161-in-1 multi cart.....just to find lot crap TV output ;-) In my case the screen output seems slowmotion with lots of scrambled output and the screen (if picture can be seen for a moment) it's shifted horizontally about 2/3. First I was shocked and thought my AES was broken ;-) Luckily my TV has scart input and that worked flawless.

[Ryoandr]

@davince72

                                        LM1881
                          HS---470R---1         8-----+---+5V
Neogeo AV Out Pin 3 ---+---------||---2         7     |
                       |   VS---------3         6---+ | 
                      75R           +-4         5   | |
                       |            |               | |
                       +------------+-------+--680K-+ |
                       |                    +---||--+ |
                      GND                   +---||----+
			    
All caps 100nF			   
HS and VS can be either on the VGA or the JST 

[Hendrix900]

Hello, I had the sync problem on my Japanese AES 3-6. (It has RGB Bypass with csync) I have managed to solve it without having to add lm1881.

The steps are: =GBSC= 1-NEO GEO AES compatibility mode = off 2- Sync on Green pressed =GBSC UI= 3-Activate developer mode 4-In the developer option, disable SyncWatcher

This will make the image run correctly. When you disable SynWatcher, sometimes there may be some wrong horizontal lines at the top. playing to activate and deactivate the SyncWathcer end up disappearing.

I hope this can help All the best

[ramapcsx2]

Right, it's clear that the syncwatcher code is seeing something it thinks is wrong. If someone can figure it out, they can surely tweak that variable and fix it properly :)