cga to vga converter uPython

this card is documented that not working with industrial equipment even if its advertised that it should, i bought one similiar card recently and nothing

How about this R-Pi Zero + CPLD based one:

https://github.com/hoglet67/RGBtoHDMI/wiki

You would need an HDMI monitor or a HDMI to VGA adapter.

However it has options to create custom timing profiles or alternatively the design is there to roll your own.

Yeah i started it because i think its doable but as using my logic analyzer and looking at different boards and different codes, the signal processing looks pretty erratic for me and the stated cycle clocks are usually different in reality as in theory

Regarding:

with micropython i was able to reach 62MHz freq with PICO 

Could you share the code you used to achieve that?

I see vastly different results with a simple speed test; 28 kHz, and with significant jitter. That's a world apart from 62 MHz, so it would be good to see what you meant by that.

For reference, here is the code I used:

import time
from machine import Pin


# GPIO
in_pin = Pin(16, Pin.IN, Pin.PULL_UP)
out_pin = Pin(15, Pin.OUT)

# main function
def app_main():

    print("starting..")

    for i in range(0, 1e5):
        v = in_pin.value()
        out_pin.value(1)
        v = in_pin.value()
        out_pin.value(0)
    print("done.")

Note: if you achieved 62 MHz by using SPI, that's actually using the PIO (or a hardware peripheral inside the microcontroller in question). All I can conclude from my test, shown above, is that micropython on it's own won't achieve anywhere near the speeds you're mentioning; it will require PIO coding.

There is a PIO based implementation of a VGA driver discussed here if anyone is interested:

https://www.youtube.com/watch?v=ZXMdZGQzrWg

throught PIO and it was stable, the regular programmed solution is comparable with arduino uno with original library. pico is running at 125mhz and that 62 was exactly the half of it.

now and even before i had a problem with interrupts, i thought they are instant but not at all it takes up some useconds to act as i have measured in some tests. do you have some info about which board has what kind of latency for interrupts?

xvga adapter was ordered already it should work but as a curiosity i would be interested to play a little more with this problem

bitluni has some fast libraries for esp32 but still hesitating if some interrupted input, or what kind of input could read the original displays pixels well. possibly it would take 2 microcontrollers or a 2core system like the pico. one reading the other one writing the output.

the hsync and vsync by warming up the cnc machine changes a little bit so synchronizing to that signal i think is out of question especially as interrupt isnt that fast as i thought

I didn't understand most of that I'm afraid. Interrupts are still not going to help with MicroPython, regardless of ESP32 or Pico. And the comment about 62 MHz being half of 125 MHz is irrelevant when using MicroPython.

You don't need to use interrupts if you use the PIO (at least, not for the content per raster line, maybe you might want to use interrupts for some other purpose, but you probably need to sketch out what you would implement in code in the PIO and what would be elsewhere (e.g. in C).

To me, it seems straightforward at a high level; read in data samples asynchronously, triggered on the sync signal (possibly without interrupt, just using PIO,but it's up to your design of it all), and then when you've got one raster of data (or when you've got one picture frame of data - depending on how much memory there it, I've not done the sum), you'd output two lines, or drop every other sample, to increase the output raster line speed.

You still have not really decided on a path forward though, if you're contemplating ESP32 (ESP32 doesn't have PIO), and at some point you need to decide to prototype up a few things, to answer a few unknowns, to see which processor, and which method is worth investing more time into, and just accept that some of the initial prototyping might get thrown out of the window if/when you need to switch approach. 

An FPGA approach is also a very good one. Lots of VGA example code out there to reuse. Depends on what the OP is comfortable with.

i was thinking about it. im an enthusiast who started on arduino, but in school always loved logic circuit design and fpga is something like that, but i would need some pinpointing:

- is there any arduino like reprogrammable fpga board for learning?

- what kind of programming languages FPGA-s using to program them and what is the whole approach to make it work?

what you concluded i already worked out in my mind and the implications:

- async read of 400bits with only one sync signal not gonna work

- synced read of pixels at around 6MHz could work, but i still have to sync up the picture to not be shifted, reading 2 lines then writing one gonna be shifted over because of the shifting frequency of the original equipment and storing only one line of data do not really gives place to start the display from the beginning and messing up the sygnal with the orignal one could desynchronize the vga output. my first approach was to only double the HSYNC to at lest see if the cnc is sending out data or not

as i dived into it firstly looks like easy math, but because of the speed of signals and timing its a pretty hard task to accomplish, but i still think its doable and yes im not fully decided if i could find a code halfway working already im going with that board. with a perfect code possibly even an arduino uno could drive it on the edge, but esp and pico are both capable boards both i just have to learn them better