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. | (http://www.ebay.co.uk/itm/160907450505?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
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!
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 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/gonbes-gbs-8200-vga-converter-with-cpc/msg100438/#msg100438)
Edit: oh, I missed reading the bit where you said you did this. Oops!
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 (http://shmups.system11.org/viewtopic.php?f=6&t=52172)
Quote from: pelrun on 05:10, 18 July 15
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 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/gonbes-gbs-8200-vga-converter-with-cpc/msg100438/#msg100438)
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!!
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 (https://ianstedman.wordpress.com/2015/01/25/gbs-82xx-experiments-part-2/)
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.
Good that I have a Pi just here! ;D ;D ;D
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 :)
Looks better than a c64 ever would. :-X
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.
Quote from: [[C|-|E]] on 23:32, 19 July 15
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?
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 :D).
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.
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 (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 :).
(http://thumbnails110.imagebam.com/36364/0cd173363630037.jpg)
:-\
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.
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.
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.
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.
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 (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).
(https://c2.staticflickr.com/4/3793/19845740726_b6828bfb1f_b.jpg)
The cables you just soldered need to be connected to the equivalent positions in the Pi.
(https://c1.staticflickr.com/1/265/19683942500_b8d95374e4_b.jpg)
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.
(https://c1.staticflickr.com/1/260/19876926481_74892265b1_b.jpg)
(https://c1.staticflickr.com/1/365/19683933738_0ed44a340a_b.jpg)
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:
(https://c1.staticflickr.com/1/266/19871952545_c0c993c335_b.jpg)
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 :) .
(https://c1.staticflickr.com/1/268/19845766166_6d783b4b6d_b.jpg)
(https://c1.staticflickr.com/1/399/19683942240_3fc4f06807_b.jpg)
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 :)
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.
It looks superb!
Quote from: Bruce Abbott on 06:36, 21 July 15
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!
Quote from: Bryce on 08:35, 21 July 15
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.
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 :).
Quote from: Bryce on 08:35, 21 July 15I'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.
Thanks, yes, I was about to ask why you chose the ATtiny861. I assume it was a case of "because I have one"? :D
Does it really need 8K ROM?? Is that just because it was done in C ? Surely it could be done in assembler in under 1K?
Bryce.
Edit: Just checked - from a price point it doesn't really matter which AT I choose, but I'd rather only have 8 pins to solder instead of 20!
He he he, place your orders for a Bryce VGA adaptor fixer ;)
If the adaptor could apply the changes automatically it would be really great as well, although I think that it would be necessary to keep a keyboard input at hand because configuration may need tweaking. Or, at least in my case, the pre-defined modes needed modifications to run properly with the CPC (the image was completely shifted to the left). I do not really know if this is CPC related, GBS related or screen related, but the possibility of switching "on the fly" and apply the changes in real time was really useful.
I'll have to wait until I have a working prototype to know that. There are several possibilities to tweak the settings, but I'd prefer a "plug and forget it's there" solution. As far as I can see from the data that Bruce uploaded, the device does everything automatically on boot-up without user input. The switch is only to choose between a 50hz tweak and a 60hz tweak which most likely has to happen before you power it up. The less it needs, the lower the price.
Bryce.
Let´s see what happens then :)
Today I was given a cheap VGA to HDMI converters and I am curious to see what happens if I try it with the VGA output from the GBS. The main chip of the converter is this one:
http://www.macrosilicon.com/info.asp?base_id=2&third_id=3 (http://www.macrosilicon.com/info.asp?base_id=2&third_id=3)
I wonder, although maybe this is completely stupid, if it will be able to clean the signal. If it applies some sort of noise reduction it could work well when the colors are so bright and flat. Anyway, it was for free so I have nothing to lose trying it :)
If it's sole purpose is to convert VGA to HDMI then I doubt it has any noise reduction built in. You don't expect a VGA signal to have much if any noise on the signal.
Bryce.
The thing is that I actually do not how it does the conversion. I know that the chip is popular converting the image from consoles like the Wii or the PS2, but I do not know what it does. I guess that I will just try and see what happens :) . HDMI audio output could be interesting, though.
According to the Datasheet of the MS9282, it's just a straight ADC which outputs HDMI, it doesn't even do scaling, so I doubt there's much in they way of noise reduction circuitry in it.
Bryce.
Indeed... I am testing it just now and it looks exactly the same. Good news is that it does not decrease the image quality at all (at least in a degree I can appreciate) so it could still be interesting as an option to have HDMI with audio output :) . Anyway, this is starting to be messy as hell :( , I really need to consider to make and enclosure or something.
[attachimg=1]
Why don't you just get a SCART to HDMI converter then and save yourself a module?
Bryce.
That is actually true... well, what I am going to do is to remove the HDMI converter because, as you say, it is an extra module and it does not improve the things. It was something I just wanted to try because I was given it for free and I was curious :) .
Quote from: Bryce on 13:20, 21 July 15
Thanks, yes, I was about to ask why you chose the ATtiny861. I assume it was a case of "because I have one"?
Correct. ;)
QuoteDoes it really need 8K ROM??
Unfortunately yes. The configuration data takes up 6726 bytes (3654 bytes for startArray, plus 1536 bytes for each resolution array). The rest of the code takes up less than 200 bytes.
QuoteSurely it could be done in assembler in under 1K?
No way - sorry!
QuoteI'd rather only have 8 pins to solder instead of 20!
An ATtiny85 should do it.
Oh, so it would. Maybe I'll make an SMD version with an ATtiny85 :) That should keep things extremely small. I'll probably keep the switch and LED though.
Bryce.
Quote from: Bryce on 08:16, 22 July 15
Oh, so it would. Maybe I'll make an SMD version with an ATtiny85 :) That should keep things extremely small. I'll probably keep the switch and LED though.
Bryce.
Please do. I'll have one!
Just messing about here. Done in SMD using an ATTiny85 it would be about 15mm x 20mm even if I keep the ISP header, switch and LED. The switch is made with solder bridge pads as many people will never need to use this. A switch could be soldered to the pads if needed. Removing the ISP/switch and header brings it down to 10mm x 15mm.
Bryce.
Wow, that is really tiny. Would it be possible to implement the switch as a jumper?
Yeah, a jumper wouldn't be a problem.
Bryce.
Edit: With simple jumper and further size reduction (in case the first one was too big :D )
That is great!
I don't have any ATTiny85s here, but I'll order a few and mess about a bit with this when I have a chance.
And before anyone asks, they would cost around €15 + postage.
Bryce.
It's not going to win any prizes for beauty. It's quick and dirty, but enough to push some I²C commands into the GBS and play with the Firmware :)
Bryce.
Really cool and small! And it has the charm of the hand-made circuits :) . It is funny that you are posting the picture today because I was just tiding my setup a bit this evening. Now it only needs a single power supply and it is much smaller but still, it cannot be compared with your tiny board!
[attachimg=1]
Glad you like it. I haven't got a switch on it yet. I need to tweak the C Code anyway for the different IC, so I will disable the switch routine for now while I'm at it. On the final version I think I'll add a disable jumper too in case there's situations where you'd want it completely disabled?
Bryce.
It could be a good idea! for the final user the jumpers are always an easy way of tweaking the boards without hassle and never bothers to have them around :)
Wow, what is that plastic mounting plate setup you're using there? I think I need to design/print something similar for mounting random things together...
Quote from: pelrun on 10:36, 26 July 15
Wow, what is that plastic mounting plate setup you're using there? I think I need to design/print something similar for mounting random things together...
Those plastics are used a lot for designing and prototyping robots and some other things. They allow you to put the sensors in different positions and try different configurations before the final robot is assembled :) . I have a big bunch of them because they also allow to put PCBs together, as you can see. Then, you only need to find an enclosure for the whole monster and you are done :D .
So you are the guy who builds the Terminators! :P
He was actually able to terminate himself pretty well when it fell down the stairs :D . After that, I put some sensors to detect if there where holes on the floor or not, but that is a different story :)
I've been doing some tests with the bare GBS and I don't really see anything wrong with the NTSC picture. Does the device really need an PAL/NTSC switch? I think I'd prefer to make it PAL only and then use the switch to disable the device completely when needed.
Bryce.
The guy that originally described the difference handling these two modes in the GBS said that the behavior was different between GBSs. Maybe my particular unit has the problem...
Due to the fact that almost all CPC users here are using PAL, I'll start with that. I can always flash a seperate NTSC version if someone needs one, but I doubt there are many users that will need to switch back and forth.
Bryce.
I think that it makes a lot of sense.
If that can help for tests, Pac-Man Emulator allow to switch 50/60Hz using the SPACE key.
(may be you need to do that from the TAB menu)
Thanks, I have real NTSC machines here to test it with. It's not just the frequency that matters, but also the colour values used by real hardware.
Bryce.