News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

VGA through rpi pico - How many colors possible on border?

Started by gregg, 15:46, 15 April 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gregg

@eto I managed to load Relentless, and I think I can see that issue. It is just shaking and I agree it makes it unplayable. I think I know where the issue is, and I will try to fix it. As I understand, what they do is a combination of actually shifting pixels on screen and changing the duration of hsync (the one the is part of c-sync on GA's output, not the one on GA's input). My problem is that I shift twice too much when duration of hsync changes. As a result, instead of shifting one pixel per frame, it shifts by 1 pixel, 2 pixels, 1 pixel, 0 pixels. I probably messed up something with timing when waiting for csync to end.

gregg

@eto Does relentless look OK on this video, or do you see the same issue that you have seen on scan doublers? (Sorry I made a video with phone so it may be a bit shaky)




One more horizontal scroll test with Skate Wars:



eto

Quote from: gregg on 08:16, 04 May 24Does relentless look OK on this video, or do you see the same issue that you have seen on scan doublers? (Sorry I made a video with phone so it may be a bit shaky)
I haven't played it for quite some time now so I don't know if it's 100% accurate but it definitely looks better than anything I have ever seen on a LCD.

This is absolutely awesome. 


McArti0

@gregg

How did you make the ADC input? Anything additional than the 2040 PCB?
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

gregg

@eto That's great. Thanks a lot for checking it! Actually there are two things still to do. One is that I have 60hz output and I can see it is not 100% smooth (even if not visible on this video), because it doubles the frame from time to time. I am just experimenting with 50.08hz output. It is 100% smooth then but there are other issues and it only works on one monitor out of 3 that I have. Still, I could add a switch so it would be possible to have 60hz that works on every monitor, or 50 that is 100% smooth.
Other thing is how I handle shorter hsync at this point. I need to start scanning .5us earlier for each 1us that hsync is shorter. I only handle 3 and 4 us vsync at this point. After csync goes down, I wait 3.5us whatever csync value is and then wait until csync goes up. If it was 3us hsync, then it is already up, and I start scanning, but if it was 4us, then I wait until full 4us (.5us longer). That gives me .5us shift and makes scroll smooth. But from what I read, there are options (not recommended but I believe still used) to have even shorter hsync. I will need to handle them, too. 

@McArti0 I Just used voltage comparators. There are only 3 possible levels of each color in Amstrad so I just made use of it. Of course this solution will be Amstrad only. I tried a couple comparators to find something cheap and fast enough. At this point I sticked to 3x TLV3202. They are $1.50 each and they are fast enough. I had a lot of noise on output but I managed to filter out most of it with capacitors. Some of it may be because I still have it on a some shitty breadboard when comparator's docs say a lot about how accurately it has to be placed on a pcb to avoid noise.
First I wanted to use ADCs in RP2040, but they are just too slow.
The output from comparators (and input to RP2040) are two pins for each color. One is high if there is full brightness, and other is high if there is half or full brightness. That is also how I keep it in memory.

andycadley

It does look pretty impressive. The 60Hz thing was always going to be a bit of an issue but not insurmountable. 50Hz would be nice and is supported by a lot more displays these days (due to the panels being the same as in TVs).

The colour issue does mean it wouldn't work on a Plus machine though, which is a shame. Although the GX does have Scart output and a slightly adjusted PAL friendly clock, so hooking one of those up to a modern display is less problematic most of the time (especially since Plus only software is probably less likely to use HSYNC hacks).

eto

Quote from: andycadley on 10:15, 05 May 24wouldn't work on a Plus machine
for a Plus version it would probably required to attach the scandoubler internally before the DAC like the RGB2HDMI does.

Quote from: gregg on 03:03, 05 May 24Still, I could add a switch so it would be possible to have 60hz that works on every monitor, or 50 that is 100% smooth.
that would be absolutely amazing. 

gregg

Guys,

Thanks for all the advices, but I need one more :)
I am just trying to design PCB, and I have no good idea how to make connection to Amstrad. VGA is simple - I will just put a socket. The same with power - micro usb on pico. But connection to Amstrad is more problematic. I was looking for male din-6 socket (or even din-5 because I don't need luma signal) to install on pcb and plug it directly to Amstrad and I think it just doesn't exist :) Other possible options are:
1. Female din-6/din-5 socket on pcb that would be connected to amstrad with male-male din-6 cable. Simple, but when I looked for such cables they are like $10-$20 so IMO a bit expensive.
2. Some other type of socket - maybe "din-6 to something else" cable would be cheaper.
3. Just connect cable with DIN-6 plug directly to pcb (solder it to pcb, or use terminal block or some socket like on GBS), and mount cable it with some clips to make it more stable. Then the pcb would have 2 sockets - power and vga and a cable with a plug that goes to Amstrad. That would look a bit ugly, but that would be cheap.
4. Some other option?

Besides that I am getting close to finish this project, so I hope I will publish it in a couple weeks. In the meantime I managed to get rid of most of the artifacts - flickering pixels, screen moving a bit to the sides. I no longer use Vsync/Hsync but only CSync. There is a 50/60 hz switch. I tested it on 2 different monitors and old tv and it works in both modes on monitors and 60hz only on TV (so not 100% smooth scrolls). I also tested it on couple more games. Prehistorik II was problematic, but now scrolls are 100% smooth at least in standard mode. There is still a couple small issues to fix, and of course much more testing that will probably find more issues.
Thanks for all the help, Guys.

eto


4) I recently made a CPC2VGA adapter that plugs into the monitor port: https://www.cpcwiki.eu/forum/hardware-related/cpc2vga/msg235888/#msg235888

I used a male DIN plug and just made sure, the holes in the PCB are big enough to make it fit ;-) Works fine for my use case with such a small PCB however, for a version with a Raspberry Pico that setup might be too large.

For this project, I would prefer option 3. Especially when the PCB is inside a 3D printed case, it shouldn't matter that the cable is soldered directly and I can decide the optimal length of the cable for my personal set-up. However 1) is also fine as I would expect that I always can solder the cable directly to the footprint of a connector. 

gregg

Quote from: eto on 16:24, 21 May 244) I recently made a CPC2VGA adapter that plugs into the monitor port: https://www.cpcwiki.eu/forum/hardware-related/cpc2vga/msg235888/#msg235888

I used a male DIN plug and just made sure, the holes in the PCB are big enough to make it fit ;-) Works fine for my use case with such a small PCB however, for a version with a Raspberry Pico that setup might be too large.

For this project, I would prefer option 3. Especially when the PCB is inside a 3D printed case, it shouldn't matter that the cable is soldered directly and I can decide the optimal length of the cable for my personal set-up. However 1) is also fine as I would expect that I always can solder the cable directly to the footprint of a connector.
Awesome. Thanks! 4 sounds like a perfect solution. RPI pico is not so big.
If PCB is going to go vertically on the back of Amstrad, then I just need to design PCB in such a way that it does not interfere with other ports on the back of Amstrad, but that should be doable. Overall pcb size will be about RPI pico x 2. Usb cable may just be in some weird place, like on the top. Maybe I can just add separate power port in more convenient place, and use usb only for software update.
If not then maybe I could also go with something like 1+3, I mean female din-6 socket, plus some solder pads to easily solder cable if needed.


eto

Quote from: gregg on 16:35, 21 May 24I just need to design PCB in such a way that it does not interfere with other ports on the back of Amstrad,
don't forget that there are at least 3 different CPC versions that you need to consider: 464, 664 and 6128. Not sure if the different PCB versions for the 464.

Especially the 6128 does not have a lot of spare area around the monitor port. And the US/German version with its Centronics port is even slightly worse as the Centronics clamps need some extra space. 

gregg

Quote from: eto on 17:03, 21 May 24
Quote from: gregg on 16:35, 21 May 24I just need to design PCB in such a way that it does not interfere with other ports on the back of Amstrad,
don't forget that there are at least 3 different CPC versions that you need to consider: 464, 664 and 6128. Not sure if the different PCB versions for the 464.

Especially the 6128 does not have a lot of spare area around the monitor port. And the US/German version with its Centronics port is even slightly worse as the Centronics clamps need some extra space.
Yep. I just took a look at the photos of each model, and 6128 + centronics is for sure the hardest one. It would actually need to have the width of rpi pico with nothing on the sides. Maybe it would be possible to squeeze everything on the other side of pcb. Other option is to design own minimal rp2040 board and place everything conveniently, but I think that would be too hard for me at this point.
One more tempting option would be to make pcb that covers both video port and power socket. They look to be placed in the same distance in all models (or at least in very similar). There would be two plugs on the pcb so it would be plugged into both - video port and power. Then on the other side I would have vga socket and power adapter socket. Power adapter goes to my board, and through it to Amstrad. Two pros are - I don't need separate power adapter for my pcb, and pcb can be much wider. But I think there would be a lot of troubles, like aligning my plugs to sockets in Amstrad.

McArti0

Maybe Pimoroni PIM577?
Or Seeed Xiao RP2040
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

gregg

Quote from: McArti0 on 13:55, 22 May 24Maybe Pimoroni PIM577?
Or Seeed Xiao RP2040
Yep. I was considering some other options, but there is always one of two issues. Twice more expensive (like Pimoroni), or not enough GPIO pins (like Seeed Xiao). So I think the only reasonable options are RPi Pico or just own design based on RP2040.

McArti0

Quote from: gregg on 15:52, 22 May 24not enough GPIO pins (like Seeed Xiao)
How many pins do you need?
2040 Zero has a little more.
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

gregg

Quote from: McArti0 on 17:11, 22 May 24
Quote from: gregg on 15:52, 22 May 24not enough GPIO pins (like Seeed Xiao)
How many pins do you need?
2040 Zero has a little more.
20 at this point, but maybe I will need a bit more:
6 for RGB input
6 for RGB output
2 for csync inputs - one for pio one for host, looks like can't be shared
2 for v/hsync outputs
1 for input hsync being extracted from csync by pio
2 for the same hsync going into second pio and host
1 for 50/60hz switch

Actually 2040 zero looks cool. Small, just enough pins (exactly 20), and same price as pico. It has some components on bottom so when installing on a pcb I would have to use pins to install it a bit above, or just make hole in my pcb.
Thanks for advice!


SerErris

If you anyhow design it, just design a new PICO with the correct ports on the port. It is not very difficult and you then purchase the RP2040 directly and solder it to the board. That would save the space for the large PICO pcb, as you simply do not need it. The only thing you actually need is a 5V to 3.3V converter, so that you can power the RP2040 correctly. And then whatever your PCB design anyhow needs.

Ah and for sure you need a FLASH chip to read the program from. That is more or less it. 

Check out this video:
Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

eto

That approach makes it harder to be a DIY project. Sure you can order assembled PCBs but they are more expensive and you rely on the availability of all the components. Maybe as an alternative but I would prefer if there is a DIY solution for home-soldering.

gregg

@SerErris That is a great idea and I was already thinking about it and read some documentation and looked at existing RP2040 projects. With my shitty skills in electronics I would rather first use RPI Pico, and maybe try to do that in the next step.

@eto Yes I want to make it DIY project, but to be clear - there is no way to avoid using SMD components and do it TH. The comparators are only SMD, and they say in documentation to not use any adapters but put it directly on PCB. I have a plan to use SMD, but not some crazy small. Something that even with my lack of skills and the cheapest 10x microscope is possible to easily build.

In about a week or two I should start putting it on Github. The plan is that first I will put a code and my current schematics. Later I will follow with PCB. In terms of code, I need only to fix VGA part and clean up the code to have some very first testing version. VGA part is crazy. There is a couple timing standards from VESA - DMT, GTF, CVT, CVT RB, and it looks like monitors usually expect the specific one, so I will add one more switch. So far it looks like after testing with my monitors it works like that:
Old Viore TV - Supports only 60hz DMT and says "no support" in every other case
Not so old HP monitor - Supports 60 and 50hz, but GTF only. If I use CVT or DMT the screen is shifted about half the screen to the right
Newer ASUS monitor - Supports 60 and 50hz. Should support CVT and CVT RB v1 according to documentation. DMT is slightly shifted. GTF and CVT is detected as 720x576 (rather than 800x600) so screen is cut a bit and shifted. Sometimes it says it is 1280x600 and is only shifted. That is the last thing I need to fix, and hopefully will works with most monitors then.


SerErris

Quote from: gregg on 15:49, 28 May 24With my shitty skills in electronics I would rather first use RPI Pico, and maybe try to do that in the next step.
This is the absolute right way to do it. First proove it works, than build a simple prototype and then optimize from there. 

I assume proove has been done with breadboarding. Simple prototype will be with PICO. And then optimized would be small pcb just based around the RP2040 chip itself. 
Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

McArti0

CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

gregg

That would be great to avoid having comparators but I have no idea how to do it. Overall what I need is to have two pins for each color that have full brightness encoded as 11, half brightness as 10 or 01 and 00 in other case. So I need some very simple ADC. I was trying to do it just with a bunch of resistors and capacitors, to have original signal converted to two signals where one gets just above level considered high by pico when it is full brightness only, and other signal is just above level considered high when it is half or full brightness. The problem was (even when Pico documentation says something different) that I really need to get close to 3.3V for pico to consistently consider signal as high, and close to 0 to be consistently low. There is a really huge voltage interval in the middle, that is interpreted by Pico quite randomly. I always ended up with a lot of random results.
Other option I considered was to use Pico ADC, but it is just too slow. No way to analyze each pixel separately.
If you Guys know any simpler solution then comparators, that would be awesome.

So far I plan to make use of the fact that Pico board is totally flat on bottom side, so I am trying to make small board where pico would be on one side and comparators on other. I don't know if it will work, but that would make it quite small. Board would be the size od Pico + vga connector on a side and something to connect to amstrad on other side.

On some positive note, the code is almost cleaned up. I plan to publish it this weekend on GitHub and follow with the schematics in a day or two. I finally solved the problem with finding output modes that work with most monitors. 800x600x50 was really hacky and monitors had often detected it as 576p, so I ended up with supporting just two modes:
800x600 60hz with DMT timings - works actually on everything even my old TV, but it is not 50.08hz so not 100% smooth
720x576 very close to 50.08hz with horizontal resolution scaled down from 800 to 720 and CEA-861 timings. - It should work on every monitor that supports 50hz. Scaling in horizontal (just using faster clock) makes horizontal overscan work, we don't lose any pixel. In vertical resolution I lost 8 lines on top, but looks like they are always black, I think it is just a back porch.
And I should finally get real Amstrad 6128 in a couple days, so I can do much more testing then. I plan to start with Edge Grinder and other than standard mode in Prehistorik II as I did not manage to load them so far and a bunch of demos that require 128k ram or are disk only.

gregg

I published the code: https://github.com/grzegorz-gr/vga4cpc It has a lot of comments, so I hope it is easy to understand. There is also a built uf2 file there.
I know it is quite useless without schematics, but schematics should be there in a couple days once I clean it up.

gregg

And here is schematics: https://github.com/grzegorz-gr/vga4cpc/blob/main/schematics_draft.pdf
It is not a final version, but rather what I have on a breadboard now, and what works for me.
I know you Guys have much more knowledge in electronics than me, so please let me know if you see something wrong that I should fix.
Thanks!

gregg

Hey Guys,

I have a first version that works quite well. PCB was just a couple dollars in JLCPCB + $15 for all the parts in DigiKey. I put everything on github: https://github.com/grzegorz-gr/vga4cpc - Gerber files, Kicad project, schematics, BOM, instructions, source code and compiled uf2 file.
The board looks like this:




Here is one more demo:



I tested it on all the games you Guys recommended. I had issues with a couple demos, but besides that it worked fine.

Thanks for all your help!


Powered by SMFPacks Menu Editor Mod