shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Tue Oct 15, 2019 1:01 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 2316 posts ]  Go to page Previous  1 ... 71, 72, 73, 74, 75, 76, 77, 78  Next
Author Message
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 1:45 pm 



Joined: 24 Aug 2019
Posts: 47
Finally, it works perfectly! the quality is the same i would get from a ps1.

https://streamable.com/0dl1b

Thank you rama


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 2:08 pm 



Joined: 08 Mar 2017
Posts: 996
Sure, no probs. Thanks for providing a negative example to an assumption I had to make!
I sure wish I had proper documentation :p


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 2:38 pm 



Joined: 27 Jan 2019
Posts: 17
rama wrote:
I don't have a lot of experience with HDMI and can't tell why the capture box doesn't like the signals.
One thing that comes to mind is the slight deviation from 60Hz vertical frequency that all game consoles produce.
It's possible to force 60Hz but it'll be hard to dial in. The web ui "HTotal++" button should decrease the vertical frequency a little each time.
If you use a SNES (that starts out at 60.08Hz), it may get recognized at some point.

Thank you for the idea. What frequency does the force PAL to 60Hz button in the UI output when enabled? (I'm using PAL consoles so everything is 50Hz by default - which I know the capture box does support). I assume that would have been closer to a true 60Hz as it's not locked to the console's output refresh rate?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 2:59 pm 



Joined: 08 Mar 2017
Posts: 996
I've seen generally worse 50Hz support across different resolutions.
The "Pal to 60Hz" option loads NTSC presets and then doesn't apply any HTotal corrections.
It should produce 59.83Hz, iirc (the PSX non-interlaced 60Hz mode).


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 4:30 pm 



Joined: 18 Oct 2015
Posts: 687
After updating to the latest version, Im just getting a rolling image now (as if there is no sync signal)

See here: https://www.dropbox.com/s/a9rjsmah8g3rj ... 7.mp4?dl=0


Last edited by AndehX on Mon Oct 07, 2019 5:28 pm, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 5:16 pm 


User avatar

Joined: 31 Aug 2019
Posts: 16
Location: North America, California
rama wrote:
Iraito:
12V is quite a lot for the GBS 3.3V converter.
It will work, but I recommend you switch to something between 5V and 9V soon.


Not to derail the current discussion, but I felt this might be of importance for some people wishing to run their GBS-8200 from a 12 VDC wall wart style PSU (the type normally manufactured in China).The built-in filtering on these PSU's is usually very minimal, but they can be made to work noise-free with additional filtering between the PSU and the GBS. Without good filtration you will see switching noise overlayed with the image that appear as moire like patterns randomly moving across the screen. I would assume that this would not be an issue with a high quality well filtered linear or switch regulated PSU. As for over heating the GBS components... I never saw a problem with the internal switcher on the GBS-8200 when being run from 12 VDC, not sure if that would also be the case with the GBS-8220.

Here's the circuit that I use (this image will only be hosted for 30 days from this source).

Image

As rama pointed out, if you have 5 VDC available, that should work out of the box without noise issues.
_________________
Michael from AtariBits


Last edited by AtariBits on Mon Oct 07, 2019 7:10 pm, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 6:33 pm 



Joined: 08 Mar 2017
Posts: 996
AndehX:
That's very weird. All the last update did was change the initial SOG slicer level for activity detection.
Everything after this log:
Quote:
Scanning inputs for sources ...
Activity detected, input: RGB

behaves as before.

Could you go back a few more revisions and make sure which update broke it for you?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 6:49 pm 



Joined: 18 Oct 2015
Posts: 687
rama wrote:
Could you go back a few more revisions and make sure which update broke it for you?

sure, I'll update in a bit.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 7:15 pm 



Joined: 18 Oct 2015
Posts: 687
ok I've tried a few different commits from september, and they all show the same thing. I can't select any presets. Output basically looks like this

Image

It appears to just loop that over and over


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 7:26 pm 



Joined: 08 Mar 2017
Posts: 996
Yeah, it sees VSync on the VS pin. Where is that coming from?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 7:59 pm 



Joined: 18 Oct 2015
Posts: 687
rama wrote:
Yeah, it sees VSync on the VS pin. Where is that coming from?

Not a clue, there is nothing connected to the vsync pin.

The first commit that doesn't work for me is Sept 22 2019, the commit before this one works fine.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 8:14 pm 



Joined: 27 Jan 2019
Posts: 17
rama wrote:
I've seen generally worse 50Hz support across different resolutions.
The "Pal to 60Hz" option loads NTSC presets and then doesn't apply any HTotal corrections.
It should produce 59.83Hz, iirc (the PSX non-interlaced 60Hz mode).

I can confirm that the "PAL to 60Hz" mode seems to work with my capture box, though of course the picture quality is not great (e.g. motion judder and wobbly deinterlacing).

I had been using the 240p Test Suite on my Dreamcast and had been experimenting with switching between 240p and 288p. At some point (and I'm not sure what I'd clicked on, sorry) it started working somewhat reliably at 50Hz, though the picture would lose sync every 10-20 seconds until I switched off the "Active FrameTime Lock". I then tried my Mega Drive which had some small green strips to the right of the picture. At this point I was able to view and capture 720p50 just fine. When unplugging and reconnecting the console I was getting these messages in the log:

Code:
Format change: <stable>
ADC offset: R:3F G:3F B:3F
HTotal Adjust: -10, Fieldrate: 50.003
post preset done (preset id: 13) for 50Hz

Format change: <stable>
ADC offset: R:3F G:3F B:3F
HTotal Adjust: -10, Fieldrate: 50.004
post preset done (preset id: 13) for 50Hz


I clicked on "Resynchronize HTotal" and lost the picture and have not been able to get it back at 720p50. After making these changes the log messages take this form:

Code:
Format change: <stable>
ADC offset: R:3F G:3F B:3F
HTotal Adjust: 3, Fieldrate: 49.700
post preset done (preset id: 13) for 50Hz


I also tried a full reset and restart with the default settings, after which the messages took this form:

Code:
Format change: <stable>
ADC offset: R:3F G:3F B:3F
HTotal Adjust: -7, Fieldrate: 49.920
post preset done (preset id: 13) for 50Hz


It looks like when it was working the "Fieldrate" was just over 50Hz and when not working the "Fieldrate" was just under 50Hz. If this ties into your previous theory (and considering it stopped working for me after clicking the "Resynchronize HTotal" button) I tried the HTotal++ button but this didn't seem to have any effect. I edited the web UI to include an HTotal-- button but that doesn't seem to have any impact, either. I'm afraid I don't really understand the HTotal system, sorry! :(

The one preset that does seem to work more reliably at 50Hz is 1280x1024, however though my capture box passes this through fine it is unable to capture at this resolution. 720p50 would be ideal as the box will capture this at 50FPS (higher resolutions are captured at 25FPS).


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 8:34 pm 



Joined: 08 Mar 2017
Posts: 996
AndehX:
How are your systems connected?
I noticed you swapped consoles within seconds and the picture passed through.
Are you sure that your mixing device cannot put signals out the (VGA) VS pin?
I'm literally asking the chip whether it sees valid VSyncs, that need to be above 1.8Vpp or so and regular.

benryves:
One thing you need to keep disabled with picky devices is Active FrameTime Lock.
Then you need to know that most retro sources that have interlaced and non-interlaced video modes output a different vertical refresh, depending on which mode they're in.
I think interlaced is more often on target for 50Hz.
The bestHtotal routine adjusts the output timings in fine steps to match the detected input.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 9:23 pm 



Joined: 18 Oct 2015
Posts: 687
rama wrote:
AndehX:
How are your systems connected?
I noticed you swapped consoles within seconds and the picture passed through.
Are you sure that your mixing device cannot put signals out the (VGA) VS pin?
I'm literally asking the chip whether it sees valid VSyncs, that need to be above 1.8Vpp or so and regular.

Well not that you mention it, the gscartsw does have a switch to pass csync or h/vsync, although it's set to csync... so I'm not sure why the GBS would still detect a vsync signal...


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 9:24 pm 



Joined: 27 Jan 2019
Posts: 17
rama wrote:
benryves:
One thing you need to keep disabled with picky devices is Active FrameTime Lock.

Understood, I've left it off for now whilst I'm trying to figure this out. :)

Quote:
Then you need to know that most retro sources that have interlaced and non-interlaced video modes output a different vertical refresh, depending on which mode they're in.
I think interlaced is more often on target for 50Hz.

625 lines total per frame in interlaced mode instead of 312*2=624 for progressive? I thought that would result in a higher field rate for progressive and I'm seeing lower ones - is the "Fieldrate" value reported in the log the measured one from the source or the one driving the output?

Quote:
The bestHtotal routine adjusts the output timings in fine steps to match the detected input.

Is that triggered by the "Resynchronize HTotal" button? Is there some way to override this (e.g. by clicking the HTotal++/-- buttons?) Sorry if I'm missing something obvious, I'd like to try to force the output to be as close to 50Hz as possible in case that's what's needed to placate my capture box. Thanks again. :)

EDIT: Having done some further testing with my PS2 I noticed that it would work if I started with the console at the main browser menu before launching the game, but if I restarted the scaler once in a game it would never recover. As long as I start from a 576i signal and then switch to the 288p one everything seems fine. This even works with the Mega Drive, if I set everything up with the PS2 outputting 576i and then quickly yank the SCART cable out and plug the Mega Drive in before the scaler notices a loss of sync I can then capture the Mega Drive just fine. I took a couple of test captures (Ridge Racer Type 4, Zero Wing) and though YouTube's compression does a good job of hiding the PlayStation's dithering it's there in all its gory detail in the capture. :) The audio buzz and chroma interference is definitely more visible through my cheap and nasty cables than it was on my CRTs, too, but that's an easy fix - I'd still love to figure out a way to being able to start from a 288p source rather than having to start with a 576i one and quickly switch.


Last edited by benryves on Tue Oct 08, 2019 3:39 am, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Mon Oct 07, 2019 9:43 pm 



Joined: 18 Oct 2015
Posts: 687
Ok yeah, it's the CV/HV switch on my gscart switch that must be the problem. I have my SNES connected directly to the GBS now and its working fine. This is a problem, as I seemingly can't use my gscart switch now :mrgreen:


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 1:03 pm 



Joined: 08 Mar 2017
Posts: 996
AndehX:
Can you point me to some documentation on how the gscart sync stuff works?
A sync source should not output VS if the intention is to use CSync, as exactly this problem can happen.
Sinks look at all incoming signals and try to determine what the source is, then set themselves up to process it.
If the source delivers VS, consoles with a form of NTSC or PAL become rather unlikely.

I suppose I can work around it, but without a gscart, it will be a ton of guesswork.

benryves:
I'm not sure what each source does, but it manifests in slightly different vertical refresh times when decoded.
I'll look into adding htotal adjustments to aid in dialing in accepted HDMI timings.
When you get a "Fieldrate" log, that's the source, yep.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 1:45 pm 



Joined: 18 Oct 2015
Posts: 687
rama wrote:
AndehX:
Can you point me to some documentation on how the gscart sync stuff works?
A sync source should not output VS if the intention is to use CSync, as exactly this problem can happen.
Sinks look at all incoming signals and try to determine what the source is, then set themselves up to process it.
If the source delivers VS, consoles with a form of NTSC or PAL become rather unlikely.

I suppose I can work around it, but without a gscart, it will be a ton of guesswork.

I don't think any documentation on the circuitry is available, at least not that I can see.

From what I can gather though, it's not the CV/HV switch on the gscart that's the problem. All that does is swap pin 13 of the VGA port between CSYNC and HSYNC. Pin 14 (VSYNC) must be active regardless, which explains why my GBS is constantly detecting a VSYNC signal.

I've very tempted to just cut the VSYNC trace on the GBS, as I never use an RGBHV source (only RGBS) or maybe install a switch to enable/disable VSYNC.

This could be something to mention on the Wiki for people using an older model gscartsw (with the VGA port)


Last edited by AndehX on Tue Oct 08, 2019 1:48 pm, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 1:46 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
rama wrote:
AndehX:
Can you point me to some documentation on how the gscart sync stuff works?
A sync source should not output VS if the intention is to use CSync, as exactly this problem can happen.
Sinks look at all incoming signals and try to determine what the source is, then set themselves up to process it.
If the source delivers VS, consoles with a form of NTSC or PAL become rather unlikely.

I suppose I can work around it, but without a gscart, it will be a ton of guesswork.

benryves:
I'm not sure what each source does, but it manifests in slightly different vertical refresh times when decoded.
I'll look into adding htotal adjustments to aid in dialing in accepted HDMI timings.
When you get a "Fieldrate" log, that's the source, yep.

I'm just guessing here but since the switch on the gscart is labeled "CV/HV" I'm going out on a limb and assuming it means Composite+Vertical / Horizontal+Vertical

The gscart products have comprehensive sync regeneration circuits, they are probably generating the V-sync output regardless of the source sync type


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 1:50 pm 



Joined: 18 Oct 2015
Posts: 687
maxtherabbit wrote:
I'm just guessing here but since the switch on the gscart is labeled "CV/HV" I'm going out on a limb and assuming it means Composite+Vertical / Horizontal+Vertical

The gscart products have comprehensive sync regeneration circuits, they are probably generating the V-sync output regardless of the source sync type

Yeah exactly, which is why I am considering just cutting the VSYNC trace on the GBS and maybe putting a switch on it. Unless Rama has any other ideas?


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 1:57 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
AndehX wrote:
maxtherabbit wrote:
I'm just guessing here but since the switch on the gscart is labeled "CV/HV" I'm going out on a limb and assuming it means Composite+Vertical / Horizontal+Vertical

The gscart products have comprehensive sync regeneration circuits, they are probably generating the V-sync output regardless of the source sync type

Yeah exactly, which is why I am considering just cutting the VSYNC trace on the GBS and maybe putting a switch on it. Unless Rama has any other ideas?

I would hold off on that

I have never been super happy with V-sync presence detection playing the role that it does in the GBS CFW, and I doubt rama is either, but it was a necessary stopgap. Any sync stripper based on an LM1881 is going to have a similar issue, since they all output composite and vertical sync...


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 2:45 pm 



Joined: 08 Mar 2017
Posts: 996
Here is a typical description of how to deal with different sync types in a scenario similar to the GBS8200:
Spoiler: show
Image

Some assumptions have to be made, and going by the presence of VSync = PC VGA like source is reasonable.
If an LM1881 is used, don't connect the VSync line. We just need the CSync signal out of it.

I wouldn't cut the VS line in any case. Simply commenting out the VSync detection here is enough:
https://github.com/ramapcsx2/gbs-contro ... .ino#L1151


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 2:52 pm 



Joined: 08 Mar 2017
Posts: 996
What I could do here is adding additional steps to look for "NTSC / PAL" on the SOG / HSync pin regardless of VSync status.
It comes at the price of longer detection times and potentially some detection mistakes, particularly with regards to weak (crappy CVBS) sync.
I'll think about it.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 3:14 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
rama wrote:
If an LM1881 is used, don't connect the VSync line. We just need the CSync signal out of it.

that's all fine and good if you are implementing one yourself, but there are myriad pre-built LM1881-based devices that are wired for v-sync


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 3:16 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
rama wrote:
What I could do here is adding additional steps to look for "NTSC / PAL" on the SOG / HSync pin regardless of VSync status.
It comes at the price of longer detection times and potentially some detection mistakes, particularly with regards to weak (crappy CVBS) sync.
I'll think about it.

IMO handling v-sync more elegantly is more important than accommodating people running CVBS-as-sync directly into the scaler


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 4:08 pm 



Joined: 08 Mar 2017
Posts: 996
It's kind of silly to wire up an LM1881 to provide VSync.
The device can only generate CSync + VSync, so any receiving device has to support sync separation to get valid HSyncs.
At that point, providing the additional VSync signal can only serve to confuse the receiver.

CVBS-as-sync or pure CSync (or SOG on the Component input) is the main operation mode of gbscontrol.
The other modes are extras :)


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 4:22 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
rama wrote:
It's kind of silly to wire up an LM1881 to provide VSync.
The device can only generate CSync + VSync, so any receiving device has to support sync separation to get valid HSyncs.
At that point, providing the additional VSync signal can only serve to confuse the receiver.

CVBS-as-sync or pure CSync (or SOG on the Component input) is the main operation mode of gbscontrol.
The other modes are extras :)

There are a sizable amount of RGBHV displays that require separate H/V sync signals to work, but will tolerate c-sync as h-sync.


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 4:35 pm 



Joined: 18 Oct 2015
Posts: 687
rama wrote:
I wouldn't cut the VS line in any case. Simply commenting out the VSync detection here is enough:
https://github.com/ramapcsx2/gbs-contro ... .ino#L1151

Not gunna lie, I have no idea how to comment that out, or how much of it to comment out :oops:


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 4:37 pm 


User avatar

Joined: 05 Mar 2018
Posts: 910
AndehX wrote:
rama wrote:
I wouldn't cut the VS line in any case. Simply commenting out the VSync detection here is enough:
https://github.com/ramapcsx2/gbs-contro ... .ino#L1151

Not gunna lie, I have no idea how to comment that out, or how much of it to comment out :oops:

change line 1152 to:
//vsyncActive = GBS::STATUS_SYNC_PROC_VSACT::read();


Top
 Offline Profile  
 
 Post subject: Re: GBS 8200/8220 CFW Project
PostPosted: Tue Oct 08, 2019 4:59 pm 



Joined: 18 Oct 2015
Posts: 687
maxtherabbit wrote:
change line 1152 to:
//vsyncActive = GBS::STATUS_SYNC_PROC_VSACT::read();

man, I tried that on the line above, and it didnt work, so I figured there was more to it :mrgreen:


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2316 posts ]  Go to page Previous  1 ... 71, 72, 73, 74, 75, 76, 77, 78  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group