Yes, you should use VSync from VGA2.
I need to see / measure VSync that the GBS outputs.
GBS 8200/8220 CFW Project
Re: GBS 8200/8220 CFW Project
rama,
Thanks for the warning. I did some research and found that with the external pullups voltage will be a little high on the bus, but it *should* be fine. Well, if I fry a board, lesson learned. I tried using a level translator before, but no dice.
Anywho, I thought I had already tried what you suggested, but just to be sure, I did it again, and now I'm getting this on the monitor:
It will just repeat with one of the two above variations. I think I'll test again later with the SNES instead of the Genesis and possibly the Arduino Uno (after I free it from its current job).
Thanks for the warning. I did some research and found that with the external pullups voltage will be a little high on the bus, but it *should* be fine. Well, if I fry a board, lesson learned. I tried using a level translator before, but no dice.
Anywho, I thought I had already tried what you suggested, but just to be sure, I did it again, and now I'm getting this on the monitor:
Code: Select all
input scanline us: 16680
Start HTotal: 1353
1: 860
1C: 528
2C: 332
36: 208
3D: 120
41: 72
43: 48
45: 24
46: 12
47: 0
48: 16
HTotal: 1351
No Sync!
using RGBS inputs
Unknown timing!
PLL reset
input scanline us: 16680
Start HTotal: 1353
1: 864
1C: 532
2C: 336
36: 208
3D: 120
41: 72
43: 48
45: 24
46: 12
47: 0
48: 12
HTotal: 1351
No Sync!
using RGBS inputs
Unknown timing!
Re: GBS 8200/8220 CFW Project
@zerosigea
Your log looks like the VSync signal is working as it should. There is a problem with the Genesis sync though.
Are you using a sync stripper, the console's csync or any other signal?
One issue with stock GBS boards is that they terminate the RGBS sync input in non-standard ways.
Some boards use 500 Ohm to GND, some use 2 kOhm to GND. Typical and expected for most sources would be 75 Ohm.
As a test, try to install a ~100 Ohm resistor between the "S" sync input pin and ground. Chances are, that it helps with the problem.
Try to make the install not too permanent. Sometimes it helps not to have the correct termination. It depends on what exactly the source signal is.
Software settings can also correct for a huge variance in sync signal quality.
Since I have a few reports with similar issues, I'm thinking of ways to measure and adjust those automatically.
Your log looks like the VSync signal is working as it should. There is a problem with the Genesis sync though.
Are you using a sync stripper, the console's csync or any other signal?
One issue with stock GBS boards is that they terminate the RGBS sync input in non-standard ways.
Some boards use 500 Ohm to GND, some use 2 kOhm to GND. Typical and expected for most sources would be 75 Ohm.
As a test, try to install a ~100 Ohm resistor between the "S" sync input pin and ground. Chances are, that it helps with the problem.
Try to make the install not too permanent. Sometimes it helps not to have the correct termination. It depends on what exactly the source signal is.
Software settings can also correct for a huge variance in sync signal quality.
Since I have a few reports with similar issues, I'm thinking of ways to measure and adjust those automatically.
Re: GBS 8200/8220 CFW Project
As a PSA (:p):
I've come across one of the updated (2017) GBS models. They have some significant changes on them but will still work fine with gbs-control.
One such change is the 1.8V LDO control capacitor that is supposed to keep the LM1117 in check.
As I learned in Ian Stedmans blog, this LDO has very specific requirements for its output capacitor.
The ESR must be in the right range and the capacitance must be at least 10uF.
With the redesigned boards, they changed this capacitor from 10uF SMD (already not ideal) to 100nF SMD (very bad).
As a result, these board's LDO oscillates wildly, which causes a lot of visible noise on the screen.
There are better suited capacitors further down the line. Thus, a simple fix is to simply remove the 100nF SMD capacitor.
This makes the remote electrolytic capacitor the load capacitor, which brings the ESR roughly in-line with what it should be.
I've documented it here: https://github.com/ramapcsx2/gbs-contro ... 50-or-2017
I've come across one of the updated (2017) GBS models. They have some significant changes on them but will still work fine with gbs-control.
One such change is the 1.8V LDO control capacitor that is supposed to keep the LM1117 in check.
As I learned in Ian Stedmans blog, this LDO has very specific requirements for its output capacitor.
The ESR must be in the right range and the capacitance must be at least 10uF.
With the redesigned boards, they changed this capacitor from 10uF SMD (already not ideal) to 100nF SMD (very bad).
As a result, these board's LDO oscillates wildly, which causes a lot of visible noise on the screen.
There are better suited capacitors further down the line. Thus, a simple fix is to simply remove the 100nF SMD capacitor.
This makes the remote electrolytic capacitor the load capacitor, which brings the ESR roughly in-line with what it should be.
I've documented it here: https://github.com/ramapcsx2/gbs-contro ... 50-or-2017
Re: GBS 8200/8220 CFW Project
rama,
I have a sync strike hooked up to the RGBS input, but I also have a SCART to DSub adapter that I can use to bypass the sync strike. I tried the Genesis with both, and the result was the same either way. EDIT: To clarify, the Genesis RGB cable I have uses csync.
I also attached a 100Ohm resistor between the csync and ground connections on the sync strike and still no change. Now the serial output even says "VSYNC not connected" when connected to the Genesis. But I know that the line didn't suddenly get disconnected, because I have a SCART switch in the input path and can quickly switch over to the SNES to verify that it's reading VSYNC.
On the SNES, it works either way (with or w/o resistor).
Here's the output from both.
SNES w/sync cleaner:
Genesis w/sync cleaner:
I have a sync strike hooked up to the RGBS input, but I also have a SCART to DSub adapter that I can use to bypass the sync strike. I tried the Genesis with both, and the result was the same either way. EDIT: To clarify, the Genesis RGB cable I have uses csync.
I also attached a 100Ohm resistor between the csync and ground connections on the sync strike and still no change. Now the serial output even says "VSYNC not connected" when connected to the Genesis. But I know that the line didn't suddenly get disconnected, because I have a SCART switch in the input path and can quickly switch over to the SNES to verify that it's reading VSYNC.
On the SNES, it works either way (with or w/o resistor).
Here's the output from both.
SNES w/sync cleaner:
Code: Select all
starting
PLL reset
PLL reset
resetDigital
using RGBS inputs
NTSC timing
PLL reset
MCU: 16000000
scaler set up!
input scanline us: 16632
Start HTotal: 1353
1: 812
1A: 504
2A: 304
34: 180
3A: 108
3E: 56
40: 32
41: 24
42: 8
43: 4
44: 16
HTotal: 1347Code: Select all
No Sync!
using RGBS inputs
Unknown timing!
PLL reset
input scanline us: 16685
Start HTotal: 1353
1: 865
1C: 533
2C: 333
36: 209
3D: 125
41: 73
43: 49
45: 21
46: 13
47: 1
48: 15
HTotal: 1351Re: GBS 8200/8220 CFW Project
Okay, this narrows it down to the Genesis cable. Could you open the SCART plug and check which, if any, components are on the sync line?
Re: GBS 8200/8220 CFW Project
There is only a 200uF capacitor on the sync line. EDIT: Also a 470ohm resistor, according to this page: https://retro-access.com/collections/vi ... cart-cable
Re: GBS 8200/8220 CFW Project
Genesis csync is weird. I had cases where a 220uF + 470 Ohm would not work. I changed the capacitor to 10uF and that fixed it.
Definitely check if the cable has that 470 Ohm resistor though. You can check by connecting a multimeter to the console side csync pin and the SCART end pin 19/20 just where it enters the 220uF capacitor.
You should see 470 Ohms then.
If you have 470 Ohms, then try replacing the capacitor with a 10uF one.
For testing, please bypass the Sync Strike and go into the GBS directly.
You should at least get some terminal prints that suggest there is sync.
Definitely check if the cable has that 470 Ohm resistor though. You can check by connecting a multimeter to the console side csync pin and the SCART end pin 19/20 just where it enters the 220uF capacitor.
You should see 470 Ohms then.
If you have 470 Ohms, then try replacing the capacitor with a 10uF one.
For testing, please bypass the Sync Strike and go into the GBS directly.
You should at least get some terminal prints that suggest there is sync.
Re: GBS 8200/8220 CFW Project
Rama, if I was to spend the money on this set up again, which GBS version would you recommend? the HDMI isn't important this time round since it will be going directly into my projector, which has VGA in. Also, which arduino would you recommend?
Re: GBS 8200/8220 CFW Project
Yo,
get any GBS version other than the one with the yellow buttons (called V or something).
In case they send you the V, you'll have to fix the oscillating voltage regulator.
https://github.com/ramapcsx2/gbs-contro ... 50-or-2017
Other than that, I don't have a particular preference yet.
They're all built okay and as good as the budget allows.
So far I haven't seen one that has an improved analog / digital area separation.
That would be great, if they did that.
For the Arduino, it depends on how neat you want it to be.
It's certainly the easiest to get a regular Uno. Easy to program, easy to debug, but a larger extra board.
If you don't expect to look at the terminal much, then get a Pro Mini and glue it to the GBS.
It'll be harder to reprogram, of course.
get any GBS version other than the one with the yellow buttons (called V or something).
In case they send you the V, you'll have to fix the oscillating voltage regulator.
https://github.com/ramapcsx2/gbs-contro ... 50-or-2017
Other than that, I don't have a particular preference yet.
They're all built okay and as good as the budget allows.
So far I haven't seen one that has an improved analog / digital area separation.
That would be great, if they did that.
For the Arduino, it depends on how neat you want it to be.
It's certainly the easiest to get a regular Uno. Easy to program, easy to debug, but a larger extra board.
If you don't expect to look at the terminal much, then get a Pro Mini and glue it to the GBS.
It'll be harder to reprogram, of course.
Re: GBS 8200/8220 CFW Project
yeah the oscillating voltage thing doesn't bother me, I can fix that easy enough. I guess I'll just order the cheapest of the none HDMI models (cheapest I can find in the UK that is. Screw waiting 5 weeks from china)
I'm not really familiar that much with the terminal interface. I can follow instructions fine, but debugging things on my own is probably not my forte, so I guess I should go with the smaller mini.
The goal is a cheap solution to get my consoles on my projector (and not look like shit) for when friends come round, which is why this seems like the best solution. I like tinkering with stuff too so its a win-win
Edit: These should work fine right?
https://www.ebay.co.uk/itm/Genuine-GBS- ... 1438.l2649
https://www.ebay.co.uk/itm/UNO-R3-ATmeg ... 1438.l2649
I'm not really familiar that much with the terminal interface. I can follow instructions fine, but debugging things on my own is probably not my forte, so I guess I should go with the smaller mini.
The goal is a cheap solution to get my consoles on my projector (and not look like shit) for when friends come round, which is why this seems like the best solution. I like tinkering with stuff too so its a win-win
Edit: These should work fine right?
https://www.ebay.co.uk/itm/Genuine-GBS- ... 1438.l2649
https://www.ebay.co.uk/itm/UNO-R3-ATmeg ... 1438.l2649
Re: GBS 8200/8220 CFW Project
Rama,
Yes, it does have the resistor. I did some digging after my last post and found out how to check. Also, unloaded the csync line reads 4.3 volts post-cap on my multimeter, but when I have it connected to my PVM, it reads very little voltage post-cap. So my next question is, would swapping caps affect compatibility with the PVM?
Yes, it does have the resistor. I did some digging after my last post and found out how to check. Also, unloaded the csync line reads 4.3 volts post-cap on my multimeter, but when I have it connected to my PVM, it reads very little voltage post-cap. So my next question is, would swapping caps affect compatibility with the PVM?
Re: GBS 8200/8220 CFW Project
zerosigea:
Not sure, just try it.
AndehX:
Yep, they're fine. Though I never actually got a V3 when shopping for one.
The V3s have a linear main voltage regulator. Not that I expect a difference :p
Not sure, just try it.
AndehX:
Yep, they're fine. Though I never actually got a V3 when shopping for one.
The V3s have a linear main voltage regulator. Not that I expect a difference :p
Re: GBS 8200/8220 CFW Project
rama,
Ok, swapped caps and still doesn't like sync from the Genesis (still wouldn't print sync timings). On the other hand, the PVM still works, so there's that.
However, I've found one exception: Sonic 3D Blast. The opening "cutscenes" (and TT logo) in that game sync just fine (with no line warping as well) and the ardunio gives the sync timings on the console, but only during those cutscenes (though the sync timings stay around until a reset). Once it gets to the title screen, sync goes all wacky again and the top 10-20 lines are warped, just like usual. I have no idea if this worked with the old cap, because I hadn't tested this specific game until just now.
After some more quick testing, I found that one other game (so far) works: Championship Pool. This is weird. I think I'm gonna try firing up the 240p test suite next. EDIT: Ok, the 240p test suite confirmed my suspicions, it's the resolution of the VDP that seems to be the culprit. If the VDP is set to 320x224, picture is unstable, but if it's in 256x224, picture is stable.
Ok, swapped caps and still doesn't like sync from the Genesis (still wouldn't print sync timings). On the other hand, the PVM still works, so there's that.
However, I've found one exception: Sonic 3D Blast. The opening "cutscenes" (and TT logo) in that game sync just fine (with no line warping as well) and the ardunio gives the sync timings on the console, but only during those cutscenes (though the sync timings stay around until a reset). Once it gets to the title screen, sync goes all wacky again and the top 10-20 lines are warped, just like usual. I have no idea if this worked with the old cap, because I hadn't tested this specific game until just now.
After some more quick testing, I found that one other game (so far) works: Championship Pool. This is weird. I think I'm gonna try firing up the 240p test suite next. EDIT: Ok, the 240p test suite confirmed my suspicions, it's the resolution of the VDP that seems to be the culprit. If the VDP is set to 320x224, picture is unstable, but if it's in 256x224, picture is stable.
Re: GBS 8200/8220 CFW Project
Keep checking new gbs-control updates. I'm reworking the sync processor section.
Update:
Okay, I verified issues with my Mega Drive that I didn't have earlier.
It's a long game of whack a mole with this project :p
The horizontal sync pulse is unusually long. The SOG detection isn't well suited to that.
Working on it.
Update:
Okay, I verified issues with my Mega Drive that I didn't have earlier.
It's a long game of whack a mole with this project :p
The horizontal sync pulse is unusually long. The SOG detection isn't well suited to that.
Working on it.
Re: GBS 8200/8220 CFW Project
Ok, some good news and some bad news.
Good news, downloaded the latest sketch, and now the output is stable for the Genesis/Mega Drive. It's slightly off center to the left (fixable with 6 shift right's) and there's still a noticeable screen tearing every few seconds, but I think that was previously mentioned. Other than those minor things, the picture is pretty good. Well done.
Bad news though, auto detection for SNES is broken. Picture keeps "jumping" so that the top of the frame is in the middle for a fraction of a second, then it jumps back to normal and repeats this very rapidly. But I think the code doesn't consider the sync invalid, as it isn't looping through the vsync detect code (pll reset doesn't happen). Forcing the ntsc preset by pressing 'e' results in a stable image with a small rolling wave in the picture.
And I can understand about the whole whack-a-mole situation. Lol
Good news, downloaded the latest sketch, and now the output is stable for the Genesis/Mega Drive. It's slightly off center to the left (fixable with 6 shift right's) and there's still a noticeable screen tearing every few seconds, but I think that was previously mentioned. Other than those minor things, the picture is pretty good. Well done.
Bad news though, auto detection for SNES is broken. Picture keeps "jumping" so that the top of the frame is in the middle for a fraction of a second, then it jumps back to normal and repeats this very rapidly. But I think the code doesn't consider the sync invalid, as it isn't looping through the vsync detect code (pll reset doesn't happen). Forcing the ntsc preset by pressing 'e' results in a stable image with a small rolling wave in the picture.
And I can understand about the whole whack-a-mole situation. Lol
Re: GBS 8200/8220 CFW Project
It's horrible, let me tell you! :p
Without fully understanding the relationship between all those settings, all I can do is fix one console's sync and then test whether the others still work.
This was okay when I assumed clean sync (boosted csync from an LM1881) only.
But now I'm trying to work with all kinds of sync inputs and it seems the variance is too big.
I'd really like to know how other scalers are set up in this regard.
Does something like the OSSC use any external sync processing?
Anyway, the big factors appear to be:
- S5_02: sog slicer voltage setting (no expert here, but this is generally no issue with LM1881 sync but a big thing with other sync's. automatic with the sog test tool)
- S5_35 + 36: sync pulse width threshold (this needed to be larger to support luma or composite video sync)
- S5_38 + 39: pre and post coast lines (this is recommended to be 3 for both, but here the console variance plays out)
- S5_3e: 2 option bits: h-overflow protect and sub-coast disable (wtf is sub coasting, never explained anywhere. these 2 bits currently kill either SNES or Genesis)
- the entire range S5_20 to s5_34 and some option bits in S5_55 to S5_57 (countless options with some effect)
I will need some help with these things, or fall back to demanding LM1881 sync.
It would be a shame though, since the chip supports every console just with composite video sync, once I fiddle around with the registers for a while.
Oh, and one more teeny tiny problem:
I'm running out of flash space on the AtMega358 ><
Without fully understanding the relationship between all those settings, all I can do is fix one console's sync and then test whether the others still work.
This was okay when I assumed clean sync (boosted csync from an LM1881) only.
But now I'm trying to work with all kinds of sync inputs and it seems the variance is too big.
I'd really like to know how other scalers are set up in this regard.
Does something like the OSSC use any external sync processing?
Anyway, the big factors appear to be:
- S5_02: sog slicer voltage setting (no expert here, but this is generally no issue with LM1881 sync but a big thing with other sync's. automatic with the sog test tool)
- S5_35 + 36: sync pulse width threshold (this needed to be larger to support luma or composite video sync)
- S5_38 + 39: pre and post coast lines (this is recommended to be 3 for both, but here the console variance plays out)
- S5_3e: 2 option bits: h-overflow protect and sub-coast disable (wtf is sub coasting, never explained anywhere. these 2 bits currently kill either SNES or Genesis)
- the entire range S5_20 to s5_34 and some option bits in S5_55 to S5_57 (countless options with some effect)
I will need some help with these things, or fall back to demanding LM1881 sync.
It would be a shame though, since the chip supports every console just with composite video sync, once I fiddle around with the registers for a while.
Oh, and one more teeny tiny problem:
I'm running out of flash space on the AtMega358 ><
Re: GBS 8200/8220 CFW Project
If this is only a problem when you're not using the LM1881, then thats not so bad I guess. What happens when you run out of flash space? (apart from the obvious) Have to find a different device with more space?
Re: GBS 8200/8220 CFW Project
Once I run out of flash, it'll become much harder to develop new features or do new attempts at fixing old ones.
I still don't have any kind of user interface (besides a PC / USB connection). Once I add a couple buttons, I will want to use EEPROM for storage.
All that will be nicer with some libraries, which again take up flash.
There's a lot of space saving potential in the current sketch but that requires optimization that someone has to come up with.
All that is quite demanding on a one man team :p
It'd be much nicer to just have more resources.
(Come on Atmel, where is the ATmega648?)
Regarding the syncstripper problem:
I've only been at it (a fit all solution) for a few days. I might still find the trick I need.
If not, I will revert the wide pulse width threshold and tighten the other timings again. This will require an LM1881 or good direct csync again.
Do note that some direct csync sources are not "good", ie Sega Genesis without the exactly perfectly right components in the cable.
Having an LM1881 makes life so much easier, especially since it's also an amplifier that produces a known sync level with okay slopes.
This is important for image quality later on. (Some filters need to be on/off, depending on the sync quality.)
I still don't have any kind of user interface (besides a PC / USB connection). Once I add a couple buttons, I will want to use EEPROM for storage.
All that will be nicer with some libraries, which again take up flash.
There's a lot of space saving potential in the current sketch but that requires optimization that someone has to come up with.
All that is quite demanding on a one man team :p
It'd be much nicer to just have more resources.
(Come on Atmel, where is the ATmega648?)
Regarding the syncstripper problem:
I've only been at it (a fit all solution) for a few days. I might still find the trick I need.
If not, I will revert the wide pulse width threshold and tighten the other timings again. This will require an LM1881 or good direct csync again.
Do note that some direct csync sources are not "good", ie Sega Genesis without the exactly perfectly right components in the cable.
Having an LM1881 makes life so much easier, especially since it's also an amplifier that produces a known sync level with okay slopes.
This is important for image quality later on. (Some filters need to be on/off, depending on the sync quality.)
Re: GBS 8200/8220 CFW Project
Well, i'm glad my gscartsw has a toggle for the built in LM1881. I can simply enable it when the GBS requires it xD
Re: GBS 8200/8220 CFW Project
Yea, okay. I will stop trying to sync to this leisurely :p
(Master System playing an Alex Kidd stage, Composite Video)
I already changed the code back to more regular levels and it helps a lot.
(Master System playing an Alex Kidd stage, Composite Video)
Spoiler
Re: GBS 8200/8220 CFW Project
Update:
And committed.
Quality and general behaviour of the default presets should be back to normal.
Please use a sync stripper or good direct csync from now on!
(Good quality particularly means Sega Mega Drive csync should have 470 Ohm and 10uF in series, as in currently sold good quality RGB cables.)
And committed.
Quality and general behaviour of the default presets should be back to normal.
Please use a sync stripper or good direct csync from now on!
(Good quality particularly means Sega Mega Drive csync should have 470 Ohm and 10uF in series, as in currently sold good quality RGB cables.)
Re: GBS 8200/8220 CFW Project
Hi everyone. I got something different scan converter from korea arcade parts shop.
Have anybody ever seen this board? I have no idea to control this board by arduino.
This board has no menu, only just adjust the position or change the H/V size. And
no port found for control or firmware upgrade. The chip size is completely different rather
than GBS 8200 series. Can I improve this board?
Have anybody ever seen this board? I have no idea to control this board by arduino.
This board has no menu, only just adjust the position or change the H/V size. And
no port found for control or firmware upgrade. The chip size is completely different rather
than GBS 8200 series. Can I improve this board?
Re: GBS 8200/8220 CFW Project
The layout is similar to GBS boards but it seems to be a different chip, just by the size of that heatsink.
It's probably possible to access it but the software won't do the right things, I bet.
It's probably possible to access it but the software won't do the right things, I bet.
Re: GBS 8200/8220 CFW Project
II haven;t updated my code in a bit, will likely do so later today to test.
rama, are you aware of any preset that will let it simply pass through video?
Sounds silly, but I have the need to make a 2:1 switcher where one device (a pi) can output VGA natively (vga666) and the other device is RGBS. Trying to see if I can wire this to simply be the switcher where it would upscale 240p but more or less leave VGA alone. It certainly has enough inputs and outputs, as well as the stock firmware lets you switch inputs.
rama, are you aware of any preset that will let it simply pass through video?
Sounds silly, but I have the need to make a 2:1 switcher where one device (a pi) can output VGA natively (vga666) and the other device is RGBS. Trying to see if I can wire this to simply be the switcher where it would upscale 240p but more or less leave VGA alone. It certainly has enough inputs and outputs, as well as the stock firmware lets you switch inputs.
Re: GBS 8200/8220 CFW Project
You probably want what they call Bypass mode. I think it might be possible, yea.
It would take me a while to get this working though, so it's going to be lower priority for now.
It would take me a while to get this working though, so it's going to be lower priority for now.
Re: GBS 8200/8220 CFW Project
I'm sure the cases are far and few between to actually want said mode outside of my use case. Glad the chip supports it at least. Looks like the programming guide 5.8 mentions bypass w/ appropriate registers.
I updated to your latest git code as of yesterday, did same that I did before, which is force it into a specific mode (240p->480p) and it works fine on my end. With the code I was previously running from about a month ago, when I sent it a signal from my Neo Geo board it was great, but when I sent it from a JAMMA rpi (pi2jamma) it would continually lose sync or something and the serial logs showed it looping.
It now seems to work fine, so good enough. Bypass mode would be used in the future where I could put my pi natively at 480p without mucking with an external physical switch.
I updated to your latest git code as of yesterday, did same that I did before, which is force it into a specific mode (240p->480p) and it works fine on my end. With the code I was previously running from about a month ago, when I sent it a signal from my Neo Geo board it was great, but when I sent it from a JAMMA rpi (pi2jamma) it would continually lose sync or something and the serial logs showed it looping.
It now seems to work fine, so good enough. Bypass mode would be used in the future where I could put my pi natively at 480p without mucking with an external physical switch.
Re: GBS 8200/8220 CFW Project
Working on some other detail atm but I had the PC attached (outputs 640x480). I tried bypassing that signal.
It looks like we can only bypass all the sync processing directly to the output.
The RGB information has to run trough the ADC and using the H-PLL. At least that's how far I got.
This means resolutions won't be stellar. The GBS seems a little memory starved and the limit seems to be at about 800x600.
Also, it does sample the video, introducing some loss.
It looks like we can only bypass all the sync processing directly to the output.
The RGB information has to run trough the ADC and using the H-PLL. At least that's how far I got.
This means resolutions won't be stellar. The GBS seems a little memory starved and the limit seems to be at about 800x600.
Also, it does sample the video, introducing some loss.
Re: GBS 8200/8220 CFW Project
The bypass function is important to switch the multiple sources for CRT monitor.
But I’d like to have a upscale function from 480p to higher (1280x960 or more) resolution.
Although it will be complicated code, can I request the build option such as bypass or upscale presets?
But I’d like to have a upscale function from 480p to higher (1280x960 or more) resolution.
Although it will be complicated code, can I request the build option such as bypass or upscale presets?
Re: GBS 8200/8220 CFW Project
Just got my GBS8200 today from Aliexpress. It's a standard one with black buttons made in 2017. Before I get started, are there any hardware modifications you would still recommend doing?