GBS 8200/8220 CFW Project
Re: GBS 8200/8220 CFW Project
Power needs to be in a loop and it is that loop area that should be kept short and direct.
But that's a generalisation and has many exceptions.
In this case, the long 5V input wire is good:
It acts as a weak inductor and shields the ESP8266 board a little from the noisy power at the GBS input (caused by the GBS switcher).
The ground return should ideally be shorter, so that current for powering the ESP8266 doesn't prefer to go through any of the other wires.
This is just theory though, and in my setups with external ESP board, I also use a similar connection.
So I noticed another thing:
There don't appear to be any ground connections for the RGB on the SCART socket?
I spot a single ground wire, probably Sync return.
You should populate the 3 x ground wires for RGB and terminate that ground near the analog section.
If you want to conserve wires, you can tie the 3 ground pins together on the SCART socket, then use one wire for termination.
I'd recommend using all 3 though.
If you must have the sync stripper in that location, try powering it from the GBS board.
And whatever you do, do not use Vcc or ground from the ESP8266 on the LM1881! (It will open the path for creepage currents.)
Edit:
To remove the old SMD caps, you can add a bit of solder on each side of the device, then alternate heating each side.
The capacitor will quickly come off, especially if you push it slightly with the solder tip, once both sides are heated.
When pushing, make sure the capacitor will only move directly forward, and not touch any other devices.
This is to prevent it sticking to other parts, which is a little harder to fix.
Tip: Practice it 3 times on an old board. Once you know how it works, it's super easy
But that's a generalisation and has many exceptions.
In this case, the long 5V input wire is good:
It acts as a weak inductor and shields the ESP8266 board a little from the noisy power at the GBS input (caused by the GBS switcher).
The ground return should ideally be shorter, so that current for powering the ESP8266 doesn't prefer to go through any of the other wires.
This is just theory though, and in my setups with external ESP board, I also use a similar connection.
So I noticed another thing:
There don't appear to be any ground connections for the RGB on the SCART socket?
I spot a single ground wire, probably Sync return.
You should populate the 3 x ground wires for RGB and terminate that ground near the analog section.
If you want to conserve wires, you can tie the 3 ground pins together on the SCART socket, then use one wire for termination.
I'd recommend using all 3 though.
If you must have the sync stripper in that location, try powering it from the GBS board.
And whatever you do, do not use Vcc or ground from the ESP8266 on the LM1881! (It will open the path for creepage currents.)
Edit:
To remove the old SMD caps, you can add a bit of solder on each side of the device, then alternate heating each side.
The capacitor will quickly come off, especially if you push it slightly with the solder tip, once both sides are heated.
When pushing, make sure the capacitor will only move directly forward, and not touch any other devices.
This is to prevent it sticking to other parts, which is a little harder to fix.
Tip: Practice it 3 times on an old board. Once you know how it works, it's super easy
Re: GBS 8200/8220 CFW Project
Sorry to hear that, but no - I'm connecting it to the VIN pin (and powering the board with 5V), not the 3V3 input.NoAffinity wrote:Sadly no new improvement with the 100uh inductor in line on the esp8266 3v3 input. Just to be certain, you guys are routing gbs p5 header vcc pin to esp8266 3v3 input?
Re: GBS 8200/8220 CFW Project
NoAffinity:
You should do the same. Power the ESP board via it's VIN port, instead of sharing the GBS 3.3V.
It is more robust this way and prevents some potential problems if there ever is a USB device connected.
Funnily enough, it literally is a (voltage) potential problem ;p
You should do the same. Power the ESP board via it's VIN port, instead of sharing the GBS 3.3V.
It is more robust this way and prevents some potential problems if there ever is a USB device connected.
Funnily enough, it literally is a (voltage) potential problem ;p
-
NoAffinity
- Posts: 1034
- Joined: Mon May 07, 2018 5:27 pm
- Location: Escondido, CA, USA
Re: GBS 8200/8220 CFW Project
Okay, did hte following, and good a pretty good result:
Went back to a 5V PSU, a quality Novatel Wireless 5V 2A power supply
Now powering ESP from P9, which I assume is pass-through from the barrel plug
Moved 470uf cap to P9
Moved power input at ESP, to 5V pin
-left the 100uh inductor in place
It got rid of the constant, slowly upward rolling wave that was persistent in the image. I'm pretty happy about that.
Grabbed some quick 1080p footage. Looking pretty good, imho. Some clarity loss due to youtube compression but still pretty sharp.
https://youtu.be/6OBO_3BWw9s
Side note, wrt the 5V power supply. I metered this Novatel power supply, and it is dead on at 5.01V, never budges. I metered the one I had been using previously, which is a cheap $5 power supply they sell at the local electronics store, as a pi power supply. The thing is all over the place - bouncing around constantly between 5.04V and 5.17V. No wonder it was introducing additional noise and resulting in sync drop-outs. It's a Rhino brand PSU, if anyone wants to know what to stay away from.
Went back to a 5V PSU, a quality Novatel Wireless 5V 2A power supply
Now powering ESP from P9, which I assume is pass-through from the barrel plug
Moved 470uf cap to P9
Moved power input at ESP, to 5V pin
-left the 100uh inductor in place
It got rid of the constant, slowly upward rolling wave that was persistent in the image. I'm pretty happy about that.
Grabbed some quick 1080p footage. Looking pretty good, imho. Some clarity loss due to youtube compression but still pretty sharp.
https://youtu.be/6OBO_3BWw9s
Side note, wrt the 5V power supply. I metered this Novatel power supply, and it is dead on at 5.01V, never budges. I metered the one I had been using previously, which is a cheap $5 power supply they sell at the local electronics store, as a pi power supply. The thing is all over the place - bouncing around constantly between 5.04V and 5.17V. No wonder it was introducing additional noise and resulting in sync drop-outs. It's a Rhino brand PSU, if anyone wants to know what to stay away from.
Re: GBS 8200/8220 CFW Project
I didn't address this previously - I didn't connect the other ground connections because I was being as lazy in my prototyping as the SCART cable manufacturers. Most of my cables only connect pin 17 for video ground (though one uses pin 18 for some reason, so I connect ground to both 17 and 18). None of my cables make use of pins 5, 9, or 13.rama wrote: So I noticed another thing:
There don't appear to be any ground connections for the RGB on the SCART socket?
One change I will make at the very least is to join pin 4 (audio ground) to 17 and 18 as one of my Saturn cables doesn't connect this to anything and I get nice 50Hz hum out of my speakers with that cable (my other Saturn cable connects pin 4 for audio ground so I've been using that for now).
Re: GBS 8200/8220 CFW Project
Ground returns for RGB are required. If they're missing, the current will use the next best thing, which is the Composite Video return path.
There'll be lots of noise and it'll be quite random as well.
If the cables are already missing ground returns for RGB, you should replace them.
There'll be lots of noise and it'll be quite random as well.
If the cables are already missing ground returns for RGB, you should replace them.
Re: GBS 8200/8220 CFW Project
Hello rama!
I use GBS-8220 (RGBS2VGA) with your firmware. I connect the adapter to two different Soviet computers:
1. Computer "Soyuz-Neon PK-11/16", which uses 300 visible lines in a video frame (50Hz, 15.6259kHz) and this does not fit well with television standards. As a consequence, the GBS-8220 with factory firmware shows an image, but it twitches. GBS-8220 with your firmware does not detect the synchronization signal at all, what is reported in the logs.
Is it possible to fix something in the firmware to capture synchronization from this computer? The framemeister does this without problems.
2. Computer UKNC (MS0511), the resolution of the video frame 640 * 288. There are two problems. First: horizontally, the entire frame can fit into the screen only in adapter mode 640 * 480. In other modes, no settings help, the frame goes left or right. 640 * 480 is also a good result, but in this mode the image is blurred in some places. Is there any way to fix this for all modes? The second problem is that since the firmware version 01/28/2019, the background of the image of my UKSC has become permanently green. I managed to fix it by replacing in the latest firmware version in the line 4818 in file gbs-control.ino:
4818: updateClampPosition (1);
I replace unit to zero, and then the background turned black again. Can this be taken into account in further development?
I use GBS-8220 (RGBS2VGA) with your firmware. I connect the adapter to two different Soviet computers:
1. Computer "Soyuz-Neon PK-11/16", which uses 300 visible lines in a video frame (50Hz, 15.6259kHz) and this does not fit well with television standards. As a consequence, the GBS-8220 with factory firmware shows an image, but it twitches. GBS-8220 with your firmware does not detect the synchronization signal at all, what is reported in the logs.
Is it possible to fix something in the firmware to capture synchronization from this computer? The framemeister does this without problems.
2. Computer UKNC (MS0511), the resolution of the video frame 640 * 288. There are two problems. First: horizontally, the entire frame can fit into the screen only in adapter mode 640 * 480. In other modes, no settings help, the frame goes left or right. 640 * 480 is also a good result, but in this mode the image is blurred in some places. Is there any way to fix this for all modes? The second problem is that since the firmware version 01/28/2019, the background of the image of my UKSC has become permanently green. I managed to fix it by replacing in the latest firmware version in the line 4818 in file gbs-control.ino:
4818: updateClampPosition (1);
I replace unit to zero, and then the background turned black again. Can this be taken into account in further development?
Re: GBS 8200/8220 CFW Project
Sorry if i don't read 58 pages yet.
1. If i connect a Amiga with this to a VGA monitor, will i have scanlines?
2. Does it work with S-Video (C64)?
3. Does it work with RPi emulation (SCART, VGA)?
It's hard to find a small CRT TV with good picture.
Also the small ones do not have potentiometers for all the settings (Size, Position...).
1. If i connect a Amiga with this to a VGA monitor, will i have scanlines?
2. Does it work with S-Video (C64)?
3. Does it work with RPi emulation (SCART, VGA)?
It's hard to find a small CRT TV with good picture.
Also the small ones do not have potentiometers for all the settings (Size, Position...).
Re: GBS 8200/8220 CFW Project
1. Depends on the monitor (if you're talking CRT) If you're talking about an LCD monitor, GBScontrol has a scanline enable feature.Paradise wrote:Sorry if i don't read 58 pages yet.
1. If i connect a Amiga with this to a VGA monitor, will i have scanlines?
2. Does it work with S-Video (C64)?
3. Does it work with RPi emulation (SCART, VGA)?
It's hard to find a small CRT TV with good picture.
Also the small ones do not have potentiometers for all the settings (Size, Position...).
2. No. RGB/Component only.
3. If it's outputting RGB, then yes, it should work.
Re: GBS 8200/8220 CFW Project
1. Sure i talk about CRT Monitors.
2. That means i need to build a Y/C to RGB converter.
3. Sure the adapters output RGB:
http://arcadeforge.net/Pi2Jamma-Pi2SCAR ... ::264.html
https://uk.pi-supply.com/products/gert- ... spberry-pi
2. That means i need to build a Y/C to RGB converter.
3. Sure the adapters output RGB:
http://arcadeforge.net/Pi2Jamma-Pi2SCAR ... ::264.html
https://uk.pi-supply.com/products/gert- ... spberry-pi
Re: GBS 8200/8220 CFW Project
Voland:
I replied on Github
https://github.com/ramapcsx2/gbs-control/issues/60
Paradise:
If your source conforms to NTSC/PAL or the common EDTV / HDTV standards, it will work.
Slight deviations are okay. I certainly expect the RPi to work.
You'll have to build one to appreciate the features on offer.
Notable is that there is a scaling mode with high res output, and a bypass mode with the original timings.
The board becomes a signal adaptor in bypass mode.
I replied on Github
https://github.com/ramapcsx2/gbs-control/issues/60
Paradise:
If your source conforms to NTSC/PAL or the common EDTV / HDTV standards, it will work.
Slight deviations are okay. I certainly expect the RPi to work.
You'll have to build one to appreciate the features on offer.
Notable is that there is a scaling mode with high res output, and a bypass mode with the original timings.
The board becomes a signal adaptor in bypass mode.
Re: GBS 8200/8220 CFW Project
I just realized that it does not make any sense on the RPi since there is already VGA with the VGA board.
I had the 15kHz from the Amiga/C64 and the PI2SCART in my mind.
I had the 15kHz from the Amiga/C64 and the PI2SCART in my mind.
Re: GBS 8200/8220 CFW Project
Amiga has been reported to work. I think it was PAL.
Re: GBS 8200/8220 CFW Project
AMIGA (500 & 1200) work really well.
rama - I was going to ask if you had an AMIGA as with the CFW the AMIGA's high res modes look really stable and does not flicker.
The AMIGA has a really cool feature where it can output 2 different resolutions at the same time. I think this can be seen on the 'Workbench' (think Windows Desktop) screen. If I select high-res mode, the background is high-res but the mouse pointer still is low res (320x256). This does give an effect like the standard GBS-. The background is pretty solid, but when you move the mouse pointer there is some flickering, I guess due to the 2 different resolutions outputted.
Its pretty good though and allows you to run a high-res Workbench for writing & productivity then when you run games the system drops back to the full low res (320x256) mode which +90% games ran at.
Paradise - C64 is Composite or S-Video (forget RF) so I don't think that can be connected to the GBS- I hope I am wrong (also my UK N64 is only S-video at best without modding).
I also have a Raspberry Pi Pi2SCART but I have not yet plugged that into the GBS.
rama - I was going to ask if you had an AMIGA as with the CFW the AMIGA's high res modes look really stable and does not flicker.
The AMIGA has a really cool feature where it can output 2 different resolutions at the same time. I think this can be seen on the 'Workbench' (think Windows Desktop) screen. If I select high-res mode, the background is high-res but the mouse pointer still is low res (320x256). This does give an effect like the standard GBS-. The background is pretty solid, but when you move the mouse pointer there is some flickering, I guess due to the 2 different resolutions outputted.
Its pretty good though and allows you to run a high-res Workbench for writing & productivity then when you run games the system drops back to the full low res (320x256) mode which +90% games ran at.
Paradise - C64 is Composite or S-Video (forget RF) so I don't think that can be connected to the GBS- I hope I am wrong (also my UK N64 is only S-video at best without modding).
I also have a Raspberry Pi Pi2SCART but I have not yet plugged that into the GBS.
Re: GBS 8200/8220 CFW Project
Since the monitors internally convert S-Video to RGB ist should be possible to build a external circuit.
The Commodore monitors use some TDA chips.
With a quick search i found this:
https://www.amazon.com/Composite-S-Vide ... B01GW8UE18
The Commodore monitors use some TDA chips.
With a quick search i found this:
https://www.amazon.com/Composite-S-Vide ... B01GW8UE18
-
maxtherabbit
- Posts: 1763
- Joined: Mon Mar 05, 2018 4:03 pm
Re: GBS 8200/8220 CFW Project
I need to rig up a VGA to component transcoder for some testing - does the YPbPr output of the GBS work in pass-through mode currently?
Re: GBS 8200/8220 CFW Project
Hello Guys,
I have some questions to ask:
Can I connect the ports as follows?
SDA >D4
VCC >3V
GND >G
SCL > D5
Is it necessary to connect the debug port?
I have some questions to ask:
Can I connect the ports as follows?
SDA >D4
VCC >3V
GND >G
SCL > D5
Is it necessary to connect the debug port?
Re: GBS 8200/8220 CFW Project
Hi Rama!
Regards,
Hmmm... I didn't, but that is a good tip. I will check as soon as I have the opportunity (the machines affected are from friends, not mine) and will let you know. I DID notice this happening once or twice on the Mega Drive, but thought it was a bad connection somewhere, since I could not reproduce it.Glad to hear that so many machines work fine.
Did you check the terminal when a video "hickup" is produced? If the terminal / web ui console prints a dot ( . ), then the issue was with the sync processor.
If there's nothing, then the issue is with the digital processing, maybe the IF unit.
I've seen those, by the way, but could never reproduce them reliably enough to even begin debugging :/
Yes, SYNC to GND. Sorry, I do not have access to an oscilloscope. We settled on the 3V3 Zener + 4K7 resistor by "reverse engineering": the machines that would not show a signal on the GBS worked fine on a 15-KHz compatible monitor (LG M1721A), so we pulled up the monitor schematics to have a look, and noticed the same Zener + Resistor Combo on all sync inputs. We thought "Well, if it works for LG...". All I know is that it works, but not exactly how or why.Your diode is from Sync to Gnd, I assume?
What would the effect of this diode resistor chain be.. I find it hard to predict how the waveform would change. Got any scope results?
Regards,
Re: GBS 8200/8220 CFW Project
Unfortunately it looks like Midway arcade games (in this case Ultimate Mortal Kombat 3) aren't currently working. Output says:
I know this game worked before on the same GBS, and indeed, disconnecting the SDA pins and removing the jumper make the GBS successfully sync in the stock firmware and display the game correctly.
Native game res is 400x254 at 53.20Hz, so it's pretty wacky.
Happy to help debug, just let me know what info etc you need
On the plus side, the Taito F3 which is another finicky customer works great!
Code: Select all
found: 5 getVideoMode: 0 input: 1
Auto SOG: retry #1
Auto SOG: retry #2
Auto SOG: retry #3
SOG level: 1
lost..
Native game res is 400x254 at 53.20Hz, so it's pretty wacky.
Happy to help debug, just let me know what info etc you need
On the plus side, the Taito F3 which is another finicky customer works great!
Re: GBS 8200/8220 CFW Project
Oh gee, another odd timings machine that I can't test.
It's too many things that can go wrong, so I need you guys to help debugging.
Try older gbscontrol versions, try enabling the information mode logs and post the output here.
It's surely a software limitation, but unless I know what these sources need, I can't fix it.
It's too many things that can go wrong, so I need you guys to help debugging.
Try older gbscontrol versions, try enabling the information mode logs and post the output here.
It's surely a software limitation, but unless I know what these sources need, I can't fix it.
Re: GBS 8200/8220 CFW Project
I have exactly the same situation with the Soviet computer "Союз-Неон ПК-11/16", the exact same messages in the logs, but with the factory firmware videoimage from computer appears. Correspondence on the problem is here:fluxcore wrote:I know this game worked before on the same GBS, and indeed, disconnecting the SDA pins and removing the jumper make the GBS successfully sync in the stock firmware and display the game correctly.
Native game res is 400x254 at 53.20Hz, so it's pretty wacky.
https://github.com/ramapcsx2/gbs-control/issues/60
fluxcore, if your problem is solved earlier than mine - let me know please.
The parameters of the video frame in my case are as follows: 640x300, 300 visible lines in a video frame, 50Hz, 15.6259kHz. There is a logical simulation of the signal to obtain its temporal characteristics: https://ibb.co/61b9wDw
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
It might be helpful to setup a CRT_emudriver PC to tackle those weird timings. That way you could test UMK3 with groovymame, right?
Re: GBS 8200/8220 CFW Project
Oh yeah, that's right!
And I even have a retro gaming rig handy that I can use.
It's equipped with a Radeon 9600 Looser Edition (RV360). Can you guys link me to the easiest guide for that?
And I even have a retro gaming rig handy that I can use.
It's equipped with a Radeon 9600 Looser Edition (RV360). Can you guys link me to the easiest guide for that?
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
Which OS are you using? XP still or Windows 7?
Re: GBS 8200/8220 CFW Project
The machine has 98 and XP on it. I also have a couple other (AGP) cards available.
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
I think you should use version 1.2b then. It can be downloaded here:
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=65
Calamity, the developer, can be reached via arcadecontrols.com
This is the official documentation page:
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=47
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=65
Calamity, the developer, can be reached via arcadecontrols.com
This is the official documentation page:
http://geedorah.com/eiusdemmodi/forum/v ... .php?id=47
Re: GBS 8200/8220 CFW Project
This seems pretty advanced / mature. I think I'll give it a go
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
Oh, it's the best!
I do remember having to fiddle with the drivers a bit under Win XP though. You might want to download the Catalyst Removal tool to really get rid of the old driver. I think it's called AMD Cleanup Utility nowadays, but the XP version maybe called something different.
Under Win7 oder Win10 I one time managed to lock myself out of Windows: As soon as it booted the OS and loaded the driver I got a bluescreen. Only option to repair this was to remove the Radeon Card and boot the system with a spare NVidia card I had laying around, then removing CRT_emudriver.
So it's not without its quirks, but once it runs, it is really great for cabinets and pro CRTs.
I do remember having to fiddle with the drivers a bit under Win XP though. You might want to download the Catalyst Removal tool to really get rid of the old driver. I think it's called AMD Cleanup Utility nowadays, but the XP version maybe called something different.
Under Win7 oder Win10 I one time managed to lock myself out of Windows: As soon as it booted the OS and loaded the driver I got a bluescreen. Only option to repair this was to remove the Radeon Card and boot the system with a spare NVidia card I had laying around, then removing CRT_emudriver.
So it's not without its quirks, but once it runs, it is really great for cabinets and pro CRTs.
Re: GBS 8200/8220 CFW Project
Okay, got the uninstaller tool as well.
I can imagine what sorts of trouble to expect. I have an S3 SomeThing PCI card ready
I wonder whether CSync will work on this 9600XT based Radeon. That'd make it lots simpler, not having to do extra hardware and all.
I can imagine what sorts of trouble to expect. I have an S3 SomeThing PCI card ready
I wonder whether CSync will work on this 9600XT based Radeon. That'd make it lots simpler, not having to do extra hardware and all.
-
- Posts: 320
- Joined: Sat Mar 17, 2018 2:49 pm
- Location: Germany
Re: GBS 8200/8220 CFW Project
I haven't used the 1.2b drivers in a while, but the newer 2.0 build does have the option.
I seem to remember that you could enable CSYNC in the official Catalyst Control Center on 1.2b. I'll see if I can dig up a source for that...
I seem to remember that you could enable CSYNC in the official Catalyst Control Center on 1.2b. I'll see if I can dig up a source for that...