Let's make a Pi Pico 2 powered video card.
-
Time to start breadboarding!
You know, I just thought of something - the same technique I use in GlyphBlaster of formatting video frames as 912x262 would work for a static test. Except we expand it to 8 bits. That's 238KB which will still fit in the Pico's RAM.
The lower nibble will drive the RGBI outputs, while two bits in the upper nibble can directly drive HSYNC and VSYNC. We just need to center a 640x200 image in a 912x262 black bitmap, then just paint the sync periods in the overscan.
Screw boring test patterns, lets go directly for graphics!
-
You know, I just thought of something - the same technique I use in GlyphBlaster of formatting video frames as 912x262 would work for a static test. Except we expand it to 8 bits. That's 238KB which will still fit in the Pico's RAM.
The lower nibble will drive the RGBI outputs, while two bits in the upper nibble can directly drive HSYNC and VSYNC. We just need to center a 640x200 image in a 912x262 black bitmap, then just paint the sync periods in the overscan.
Screw boring test patterns, lets go directly for graphics!
we can represent this with a 8-bit palette in Aesprite. We have our normal RGBI palette, then we have hsync (green), vsync (blue) and hsync-in-vsync (cyan).
Now I just need a good picture to use. The easiest thing is to take a 320x200 4bpp image from Tandy or EGA graphics, and horizontally stretch it 2x.
-
we can represent this with a 8-bit palette in Aesprite. We have our normal RGBI palette, then we have hsync (green), vsync (blue) and hsync-in-vsync (cyan).
Now I just need a good picture to use. The easiest thing is to take a 320x200 4bpp image from Tandy or EGA graphics, and horizontally stretch it 2x.
There sure is a lot of 320x200 pornography.
-
There sure is a lot of 320x200 pornography.
I'm gonna use the title screen from 1990's VAXINE by The Assembly Line, published by US Gold.
I don't remember anything about this game, but the title graphics are bangin'
-
- I've written a cycle accurate CGA emulation
- I've made a working simulation of the CGA in a digital logic simulator
- I've reproduced 80% of the original CGA PCB in KiCad (I really need to finish that)
- I've captured digital logic traces from the CGA running demanding demoscene productions
- I am intimately familiar with the ISA bus and bus timings
- I've designed several PCBs in KiCad already and some of them even worked
...so why not?
-
I'm gonna use the title screen from 1990's VAXINE by The Assembly Line, published by US Gold.
I don't remember anything about this game, but the title graphics are bangin'
this is our final 912x262 video signal bitmap. The graphics don't actually need to be centered, since we're not trying to sync to VSYNC - we're producing VSYNC, so it can happen whenever. In this case its easier to translate CRTC parameters keeping the active display area origin at 0,0.
Now we just need to save it as a raw binary.
-
this is our final 912x262 video signal bitmap. The graphics don't actually need to be centered, since we're not trying to sync to VSYNC - we're producing VSYNC, so it can happen whenever. In this case its easier to translate CRTC parameters keeping the active display area origin at 0,0.
Now we just need to save it as a raw binary.
"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 bytes -
This wasn't just a spur of the moment decision. I think ultimately, GlyphBlaster just makes more sense as an ISA card rather than being limited to living in the font ROM socket, and I've always wanted to make my own ISA card.
Designs for ISA cards in KiCad can be found all over the place, but they usually have other people's projects on them.
One thing I worked on previously is making a clean ISA card template in KiCad that you could start a new ISA card project with.
Credit to @tubetime as I basically took his EGA card project and scraped everything off of it, keeping the edge connector, and IO plate engineering drawings.
@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.
-
@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.
