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

[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]

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)

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?

[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]

wouldn'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.

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.

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]

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.

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]

I 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]

I 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.