Crappy VGA image quality.

[||C|-|E||]

Soo... today I had some time and I decided to connect the 6128 to a 17" TFT screen using this board from ebay:

replace Amstrad CPC 464 664 6128 old Monitor to LCD video converter , in UK. |

This is the provisional setup. Both the Amstrad and the converter are powered with the same PSU (5V an 8A).

[attachimg=1]

As you can see (I hope) I made a cable that is connected to the PSU and has a dual output, one for the Amstrad and another one for the converter.

[attachimg=2]

[attachimg=3]

And everything works. The problem is that I am having quite a lot of flickering noise, specially noticeable when the border is set to 0. Moreover, the background is also not clean, with some static vertical stripes. I think that you can see it in these pictures.

[attachimg=4]

[attachimg=5]

And it seems that the noise is coming from the computer video signal, because when I switch the Amstrad off the flickering and the noise disappear. So, I wonder if I need to filter the signal or if it is a problem with the earth. To make the video cable I connected the pins number 4, 2, 5 (RGB), the number 8 (GND) and the number 1 (Sync). The luminance is not connected (3) and the same is true for the audio (6 and 7). On the other hand, all the cables are loose, just kept together with plastic ties.

Any suggestions ? 

Thank you!

[pelrun]

Bryce mentioned getting improvements by ensuring all the vga port ground pins were connected to the CPC monitor output ground: Gonbes GBS-8200 VGA converter with CPC


Edit: oh, I missed reading the bit where you said you did this. Oops!

[pelrun]

Oh, and I just found this other link, that claims the noise is specifically from poor handling of 50Hz mode by the converter firmware, and 60Hz mode is noise-free:


http://shmups.system11.org/viewtopic.php?f=6&t=52172

[||C|-|E||]

Bryce mentioned getting improvements by ensuring all the vga port ground pins were connected to the CPC monitor output ground: Gonbes GBS-8200 VGA converter with CPC


Edit: oh, I missed reading the bit where you said you did this. Oops!

Well, to be honest the converter has two ground pins next to each other and only one is connected with the ground from the CPC. I could connect the other as well and see what happens I am going to read the other thread as well, thank you!!

[pelrun]

There's also the following link that fixed the root cause of the noise issue by adjusting the SDRAM clock speed:


GBS-82XX experiments part 2 | Something interesting is under way


At the moment the only way to do that fix is to attach a microcontroller/raspberry pi/bus pirate or other to inject the appropriate I2C command after startup, which is a bit crap.

[||C|-|E||]

Good that I have a Pi just here! 

[||C|-|E||]

OK, I managed to connect the PI to the board and enter into programming mode. So, I may be able to fix the problems now, I just need to play with the different settings. I will keep you updated

[TFM]

Looks better than a c64 ever would. 

[||C|-|E||]

I am checking and the Raspberry Pi method actually works very well, I can fix all the flickering, the picture is very sharp (because I can set the native resolution of the screen) and I only have some vertical strips left. The problem is that it seems that I need to keep the Pi plugged all the time when using the Amstrad because I think that I cannot save the settings to the board. It is not a big problem, though.

[CraigsBar]

I am checking and the Raspberry Pi method actually works very well, I can fix all the flickering, the picture is very sharp (because I can set the native resolution of the screen) and I only have some vertical strips left. The problem is that it seems that I need to keep the Pi plugged all the time when using the Amstrad because I think that I cannot save the settings to the board. It is not a big problem, though.

I am intreagued with this Raspberry Pi solution. The links above seem to only reference arduino, care to elaborate?

[||C|-|E||]

Not problem, it is very easy if you have a Pi around. I can post some pictures and a little explanation, adapted for the Amstrad and my 17" screen tomorrow . I am still messing with the software, though, and I am not familiar with many parameters. What I did was to load a mode with the native resolution of my screen and manually fine tune it to make things better.  Now the flickering is completely gone, and same with all the other artifacts besides some vertical lines that are still there. However, it is starting to look very decent, probably it would look already great if playing a game (I still do not have the HXC and I did not buy a game just to try this ).

[Bryce]

Some interesting solutions there. Has he released any code for the Pi or Arduino to automatically make the changes after boot-up? That would be handy. I have an Arduino Nano gathering dust here, then I'd use it to have "System buttons", ie: CPC button, Amiga Button, Spectrum Button etc, to set things exactly right for each system.

Bryce.

[||C|-|E||]

So, what I basically did was to follow the instructions given by dooklink in this forum:

http://shmups.system11.org/viewtopic.php?f=6&t=52172

he was was also coding the hardware, so he deserves all the credit 

And everything worked very nicely after guessing a couple of things. The problem is that as far I know you cannot permanently flash the board, so the solution is always Raspberry Pi dependent. This is actually not a big problem, but makes the overall approach more expensive and there are also more cables around. I need to finish the setup and think about making a proper enclosure. I will post detailed pictures in the evening and, if you are interested, I can also describe you, step by step, what I did. Maybe you will come up with a better solution than me .

[VincentGR]

[Bryce]

That's why I'd prefer to use a crappy €3 Arduino Nano. Soldered permanently to the GBS board. Then I don't care whether it's being reprogrammed on boot every time.

Bryce.

[||C|-|E||]

My setup is much more simple anyway, but I agree Bryce, it would be better to have something smaller, cheaper and more permanent (problem is that you would need to re-write the software). Anyway, if you put the board plus the Pi in a case and they share the power supply (as in the picture) it should be completely transparent to the user. The Pi loads the script at the beginning and the whole process takes less than one minute. It should be also possible to further process the VGA signal, remove all the artifacts and convert to DVI. I mean, this can be difficult when you display thousands of colors at the same time but for the Amstrad I would say that it is just the opposite case: a few colors that are completely flat. How difficult could be to create a program that performs this calibration? The problem is that we would be adding another board to this whole mess and that is beyond my skills.

[Bryce]

I'm not sure post-processing would be possible, because the additional hardware (Pi or Arduino) is only changing settings, not actually handling the video data. Converting the script to AVR or even PIC assembler shouldn't be a problem. After getting it working on an Arduino or some other dev-board it would make sense to make an even smaller custom device that would have the right footprint to mount directly on the GBS.

Bryce.

[||C|-|E||]

I was thinking to do the post-processing with a completely different board, using the GBS VGA signal as the input. With the Pi or the Arduino is not possible because, as you said, they only make the board to run a custom program  .  This board could be calibrated using some screenshots from an emulator that should be completely free from artifacts and setting them as the target. Then, the same VGA images but coming from the Amstrad would be analyzed and modified to match the target. Finally, this post-processing would be applied in real time to the VGA signal.

[||C|-|E||]

So... here are the pictures and a short explanation of what I did. It is basically what dooklink described in the other forum, only that adapted to an Amstrad.

First you need to make the cable to connect the GBS to the CPC. Assuming that it is made and the computer connected, you should be able to work with the computer in VGA, although image quality will be, most likely, substandard (apparently this depends on the board as well).

The next step is to take the Raspberry Pi and install a fresh vanilla Raspbian. You do not need the desktop at all and it is better to use the command line for all the stuff. Once Raspbian is installed it is necessary to connect the Pi to internet and execute this command:

curl https://raw.githubusercontent.com/dooklink/gbs-control/master/install-gbs-control.sh | bash

The software will be downloaded, installed and configured automatically. You can test it rebooting the Pi, although since the GBS is still not connected it will give you an error, it does not matter because you only want to check that everything works. Exit the software and shutdown the Pi with:

sudo shutdown -h now

Now you need to solder a couple of cables to the GBS, one to the SDA and another to the SCL. You also need to connect the ground, either soldering another cable or, as I did, using a ground pin from the board and a cable with a socket for the pin (the black one in the picture).



The cables you just soldered need to be connected to the equivalent positions in the Pi.



and you also need to connect the composite out from the Pi to the Green RCA Luma input of the GBS (I am sure you know, but it is the big cable in the picture). You are almost there but it is still necessary to use a jumper and short the P8 in the GBS to put it in programming mode (blue jumper in the picture). Finally, you will connect the Amstrad to the GBS.




About the power, it is possible to use a separate power supply for the GBS and the Pi or use the Pi to power the GBS. At the moment I am using two separate power supplies but I will probably power the GBS with the Pi in the future.

Ok, now you need to turn the Amstrad and the board on, that will enter into programming mode automatically although you will only see a black screen. Then, you will turn the Raspberry Pi on and it will automatically load the scripts and connect to the board. After a few seconds, this menu will appear on the screen:



If you go to the option number 10 you will be able to choose between a lot of video modes that the author of the soft already prepared and were not available before, but you will probably need to tweak something by yourself. You can load one particular mode and, pressing F2, the board will display the Amstrad video signal using it. If you press F1 you will return to the menu, where you can modify settings or load a completely different video mode. In my case, I chose 1280x1024, something that was originally not supported by the GBS. The are 4 of these with different setups and I chose the one that was described to work best with a 50 hz signal. Then, I manually adjusted the geometry and the canvas scaling. When you are happy with the results you can save your custom mode for the next time. On the other hand, with the provided software you can also create completely new video modes from scratch, although this is very technical and out of my reach.

And this is how it looks now, although I plan to tweak it further. I wanted to do it today but I had to replace the belt of the disc drive and it took me a little bit (it was supposed to be new and it was, but the guy that changed it did a horrible job). I also installed a second external drive to use 3.5 inch discs and save my programs. Oh well, back to the topic, the image is very stable, very sharp and the flickering noise has completely disappeared. I still see some vertical stripes and a little bit of ghosting, but it is very nice overall. I was writing a program that displays some graphics in the screen and they all look as they should .





Now, the only thing you need to remember is to properly switch the Raspberry Pi off every time you finish your session with the CPC 

[Bruce Abbott]

Here is my implementation of GBS-Control, using an ATtiny861A. I chose an output resolution of 1280x1024  to match the resolution of my VGA monitor. The switch, LED and ISP header are not strictly necessary - the only essential parts are the MCU itself, a 0.1uF bypass capacitor, and the 4 pin plug.

With the stock GBS8200 I could not get a stable picture from my 6128, but with this simple mod it is perfect! Next step is to see if I can turn the sharpness down and eliminate the artifacts that occur in red areas. 

   

[||C|-|E||]

It looks superb!

[Bryce]

Here is my implementation of GBS-Control, using an ATtiny861A. I chose an output resolution of 1280x1024  to match the resolution of my VGA monitor. The switch, LED and ISP header are not strictly necessary - the only essential parts are the MCU itself, a 0.1uF bypass capacitor, and the 4 pin plug.

With the stock GBS8200 I could not get a stable picture from my 6128, but with this simple mod it is perfect! Next step is to see if I can turn the sharpness down and eliminate the artifacts that occur in red areas. 

   

That's exactly what I mentioned doing above, but I see it's already done. Can you possibly share the code you've used on the ATTiny. I'd like to make myself one of these. If there's enough interest I'll run off a batch of them for others.

Bryce.

Edit: Ok, just saw that the code is in the zip file, thanks!

[CraigsBar]

That's exactly what I mentioned doing above, but I see it's already done. Can you possibly share the code you've used on the ATTiny. I'd like to make myself one of these. If there's enough interest I'll run off a batch of them for others.

Bryce.

Edit: Ok, just saw that the code is in the zip file, thanks!

I won't say no, if you are doing a batch Bryce.

[||C|-|E||]

Me probably neither, I do not have any other use for the Pi right now, but it would be cool to have something smaller attached to the board .

[Bruce Abbott]

I'd like to make myself one of these. If there's enough interest I'll run off a batch of them for others.

Here's the Eagle schematic file.  Note that some of the components are not the correct size/type (I didn't intend to make a board so I just chose parts that looked right in the schematic).

You don't have to use an ATtiny861. Any AVR that can run at 8MHz on 3.3V and has at least 8K ROM should work (perhaps with minor changes to the startup code). I compiled the source with AVR Studio 4 and WinAVR gcc.