Let's make a Pi Pico 2 powered video card.
-
"RAW binary" isn't one of Aseprite's export options, unfortunately, but we have BMP. The resulting BMP file is 240,022 bytes. That's an additional 1,078 bytes. That just so happens to be:
BMP file header: 14 bytes
DIB header: 40 bytes
palette: 1024 bytes (256 entries × 4 bytes)
------------------------------
final data offset: 1078 bytesone thing i've been struggling with all evening is how to restart the DMA buffer without inducing some sort of sync-killing delay or jitter
-
@gloriouscow let’s rather not buy stuff off the “surveillance cop, proud of it and silencing questioning voices” organisation
@mirabilos do you know how little that narrows it down
-
@mirabilos do you know how little that narrows it down
@gloriouscow the raspberry pi foundation, in this case (I have more grievances than just that one, too)
-
@gloriouscow the raspberry pi foundation, in this case (I have more grievances than just that one, too)
@mirabilos Cool! Why don't you go share those grievances in your own thread!
-
@mirabilos Cool! Why don't you go share those grievances in your own thread!
@gloriouscow already did
-
one thing i've been struggling with all evening is how to restart the DMA buffer without inducing some sort of sync-killing delay or jitter
@gloriouscow that was kind of a pain when I was doing a similar thing, are you chaining two dma channels? Iirc that's fast but I couldn't make it wait for the frame buffer to be ready so there was some tearing. I also didn't have a lookup table so that would complicate matters
Here is a writeup (not mine) of some PIO/DMA graphics gymnastics that does involve a lookup table, maybe some of the tricks will be useful: https://dmitry.gr/?r=06.%20Thoughts&proj=09.ComplexPioMachines
Good luck and I look forward to seeing the updates!
-
To simulate the OSC pin, I will program another Pico to just generate a 14.3181818 clock.
"What's my purpose?"
"You generate a clock."
@gloriouscow I’ve done the exact same thing for a VGA 25.175MHz clock.
-
one thing i've been struggling with all evening is how to restart the DMA buffer without inducing some sort of sync-killing delay or jitter
We have a picture. It isn't perfect - there's some flickery bits - I don't know if dot crawl is the right word. Not sure what's going on there.
Driving sync signals with a single image buffer was untenable - it's really difficult to have seamless, continuous DMA on the Pico. Every time you restart DMA there's a discontinuity, and if the thing you're DMA'ing represents every single clock cycle in a video field, inserting extra time messes up your picture.
So separate PIO programs generate hsync and vsync, and we restart our now image-only DMA in vsync, just like the OG Glyphblaster does, which we already know works.
I think the crawling may be that the color output is not perfectly aligned with the dot clock.
-
@gloriouscow I’ve done the exact same thing for a VGA 25.175MHz clock.
@bytex64 just out of curiosity what's the derivation of that how how did you drive it with a pico?
-
We have a picture. It isn't perfect - there's some flickery bits - I don't know if dot crawl is the right word. Not sure what's going on there.
Driving sync signals with a single image buffer was untenable - it's really difficult to have seamless, continuous DMA on the Pico. Every time you restart DMA there's a discontinuity, and if the thing you're DMA'ing represents every single clock cycle in a video field, inserting extra time messes up your picture.
So separate PIO programs generate hsync and vsync, and we restart our now image-only DMA in vsync, just like the OG Glyphblaster does, which we already know works.
I think the crawling may be that the color output is not perfectly aligned with the dot clock.
I'm starting to think a pico is not the appropriate thing to build a video card with.
all my fun ideas always end up with me concluding i should use an FPGA.
FPGAs are like the crabs of electronics projects. everything wants to turn into an FPGA if you give it enough time.
-
I'm starting to think a pico is not the appropriate thing to build a video card with.
all my fun ideas always end up with me concluding i should use an FPGA.
FPGAs are like the crabs of electronics projects. everything wants to turn into an FPGA if you give it enough time.
@gloriouscow is the pico generating the dot clock? EDIT: the same one generating the pixel data
-
@gloriouscow is the pico generating the dot clock? EDIT: the same one generating the pixel data
@ldcd Yeah. For the moment.
-
@gloriouscow is the pico generating the dot clock? EDIT: the same one generating the pixel data
@gloriouscow oh there's no clock on the CGA port just HSYNC VSYNC and it's an alignment issue?
-
I'm starting to think a pico is not the appropriate thing to build a video card with.
all my fun ideas always end up with me concluding i should use an FPGA.
FPGAs are like the crabs of electronics projects. everything wants to turn into an FPGA if you give it enough time.
I do have a de10 nano FPGA board. It's in my MiSTer. Which I never use!
-
@gloriouscow oh there's no clock on the CGA port just HSYNC VSYNC and it's an alignment issue?
@ldcd correct there's no clock line on the video connector. The monitor has PLLs to synchronize to vertical and horizontal frequencies within a certain range. A CGA monitor expects a 15.7kHZ hsync, for example. The signal, although digital in color, is put through analog circuit and so the monitor does not have to sample colors.
The Pi in the rgb2hdmi is sampling the color at a certain period within a dot window. If I am writing colors out of phase with the sampling then we will have various flickering going on. Why only in those specific areas? I am not really sure.
-
I'm starting to think a pico is not the appropriate thing to build a video card with.
all my fun ideas always end up with me concluding i should use an FPGA.
FPGAs are like the crabs of electronics projects. everything wants to turn into an FPGA if you give it enough time.
@gloriouscow I think it's easy to just default to implementing solutions in software. There are plenty of good reasons why - the tooling is usually better and more familiar, it requires less specialized knowledge, it's often easier to throw together the first PoC and to extend it later.
Often the "proper" solution is that you probably should be working at a lower level - whether that's FPGAs or discrete components. The classic example is using an Arduino to make a blinking light. I don't think there should be any shame in it no matter what solution one uses, but good engineering involves knowing when you've outgrown the current approach
-
@gloriouscow I think it's easy to just default to implementing solutions in software. There are plenty of good reasons why - the tooling is usually better and more familiar, it requires less specialized knowledge, it's often easier to throw together the first PoC and to extend it later.
Often the "proper" solution is that you probably should be working at a lower level - whether that's FPGAs or discrete components. The classic example is using an Arduino to make a blinking light. I don't think there should be any shame in it no matter what solution one uses, but good engineering involves knowing when you've outgrown the current approach
I didn't know how to program Picos a month ago, now I do. I will bet good money future me will not be afraid of FPGAs, but they scare current me a lot
-
@ldcd correct there's no clock line on the video connector. The monitor has PLLs to synchronize to vertical and horizontal frequencies within a certain range. A CGA monitor expects a 15.7kHZ hsync, for example. The signal, although digital in color, is put through analog circuit and so the monitor does not have to sample colors.
The Pi in the rgb2hdmi is sampling the color at a certain period within a dot window. If I am writing colors out of phase with the sampling then we will have various flickering going on. Why only in those specific areas? I am not really sure.
@gloriouscow hmm I wonder if you're seeing some crosstalk between the different lines? Breadboards tend to have a lot of parasitics
-
@gloriouscow hmm I wonder if you're seeing some crosstalk between the different lines? Breadboards tend to have a lot of parasitics
@gloriouscow hmm actually I don't think that would do it
-
@gloriouscow hmm actually I don't think that would do it
@gloriouscow dumb question but have you checked HSYNC and VSYNC with a scope? I've had some monitors (although HDMI so probably quite different) where I've inverted or neglected one or the other and the PLL still sorta locks and you get an image
