Let's make a Pi Pico 2 powered video card.
-
@gloriouscow keep in mind the descender behind the edge fingers will prevent this card from fitting in a 16-bit slot. you might want to pull that back.
@tubetime I mentioned that later!
-
-
I own a lot of ISA cards and I took measurements from several video cards, and there's no real standard - things vary a lot. You'll notice on this particular layout, the board edge dips down to give the most usable real estate after the end of the 8-bit ISA edge connector.
Unfortunately this means you can't plug an an original IBM CGA into your AT. We'll probably want to avoid that limitation. With a Pico replacing most of the logic on the board I don't really think we're going to need a full-length card in the first place.
@gloriouscow I’ve found the drawings in the EISA spec (https://picogus.com/docs/isa/EISA_Specification-v3.1.pdf) to be the closest thing to actual cards I’ve seen BTW
-
With a full board though, we could have a separate microcontroller that just handles the Wi-Fi. Maybe another RP2350? Maybe an ESP32? STM32 lol? I don't know. Worry about that later.
@gloriouscow I’m pretty happy with my decision to use an ESP32 on PicoIDE. It’s a little awkward dealing with a different SDK and toolchain but kind of fun?
-
Let's make a Pi Pico 2 powered video card.
This is going to be a long thread that either ends in glorious triumph or hilarious failure.
@gloriouscow let’s rather not buy stuff off the “surveillance cop, proud of it and silencing questioning voices” organisation
-
"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.
