GBS 8200/8220 CFW Project
Re: GBS 8200/8220 CFW Project
Finally, it works perfectly! the quality is the same i would get from a ps1.
https://streamable.com/0dl1b
Thank you rama
https://streamable.com/0dl1b
Thank you rama
Re: GBS 8200/8220 CFW Project
Sure, no probs. Thanks for providing a negative example to an assumption I had to make!
I sure wish I had proper documentation :p
I sure wish I had proper documentation :p
Re: GBS 8200/8220 CFW Project
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?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.
Re: GBS 8200/8220 CFW Project
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).
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).
Re: GBS 8200/8220 CFW Project
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
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.
Re: GBS 8200/8220 CFW Project
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.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.
Here's the circuit that I use (this image will only be hosted for 30 days from this source).
As rama pointed out, if you have 5 VDC available, that should work out of the box without noise issues.
Last edited by AtariBits on Mon Oct 07, 2019 7:10 pm, edited 1 time in total.
Michael from AtariBits
Re: GBS 8200/8220 CFW Project
AndehX:
That's very weird. All the last update did was change the initial SOG slicer level for activity detection.
Everything after this log:
Could you go back a few more revisions and make sure which update broke it for you?
That's very weird. All the last update did was change the initial SOG slicer level for activity detection.
Everything after this log:
behaves as before.Scanning inputs for sources ...
Activity detected, input: RGB
Could you go back a few more revisions and make sure which update broke it for you?
Re: GBS 8200/8220 CFW Project
sure, I'll update in a bit.rama wrote: Could you go back a few more revisions and make sure which update broke it for you?
Re: GBS 8200/8220 CFW Project
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
It appears to just loop that over and over
It appears to just loop that over and over
Re: GBS 8200/8220 CFW Project
Yeah, it sees VSync on the VS pin. Where is that coming from?
Re: GBS 8200/8220 CFW Project
Not a clue, there is nothing connected to the vsync pin.rama wrote:Yeah, it sees VSync on the VS pin. Where is that coming from?
The first commit that doesn't work for me is Sept 22 2019, the commit before this one works fine.
Re: GBS 8200/8220 CFW Project
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).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 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: Select all
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
Code: Select all
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
Code: Select all
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
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).
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
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...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.
Re: GBS 8200/8220 CFW Project
Understood, I've left it off for now whilst I'm trying to figure this out.rama wrote:benryves:
One thing you need to keep disabled with picky devices is Active FrameTime Lock.
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?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.
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.The bestHtotal routine adjusts the output timings in fine steps to match the detected input.
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.
Re: GBS 8200/8220 CFW Project
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
Re: GBS 8200/8220 CFW Project
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.
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.
Re: GBS 8200/8220 CFW Project
I don't think any documentation on the circuitry is available, at least not that I can see.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.
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.
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
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+Verticalrama 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.
The gscart products have comprehensive sync regeneration circuits, they are probably generating the V-sync output regardless of the source sync type
Re: GBS 8200/8220 CFW Project
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?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
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
I would hold off on thatAndehX wrote: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?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
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...
Re: GBS 8200/8220 CFW Project
Here is a typical description of how to deal with different sync types in a scenario similar to the GBS8200:
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
Spoiler
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
Re: GBS 8200/8220 CFW Project
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.
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.
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
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-syncrama wrote:If an LM1881 is used, don't connect the VSync line. We just need the CSync signal out of it.
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
IMO handling v-sync more elegantly is more important than accommodating people running CVBS-as-sync directly into the scalerrama 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.
Re: GBS 8200/8220 CFW Project
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
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
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
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.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
Re: GBS 8200/8220 CFW Project
Not gunna lie, I have no idea how to comment that out, or how much of it to comment outrama 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
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
change line 1152 to:AndehX wrote:Not gunna lie, I have no idea how to comment that out, or how much of it to comment outrama 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
//vsyncActive = GBS::STATUS_SYNC_PROC_VSACT::read();
Re: GBS 8200/8220 CFW Project
man, I tried that on the line above, and it didnt work, so I figured there was more to itmaxtherabbit wrote: change line 1152 to:
//vsyncActive = GBS::STATUS_SYNC_PROC_VSACT::read();