Let's make a Pi Pico 2 powered video card.
-
@gloriouscow Could that be a probe issue? Not all probes go up that high in frequency.
@casandro Nah, I've gotten a clean read from a 66MHz crystal on this probe from a 386 motherboard. This is probably a limitation of the Pico's GPIO drive strength. I'm not sure if that's something you can configure on a Pico, you can on an STM32, although I usually don't as it can produce overshoots which ends up being worse to deal with.
-
@casandro Nah, I've gotten a clean read from a 66MHz crystal on this probe from a 386 motherboard. This is probably a limitation of the Pico's GPIO drive strength. I'm not sure if that's something you can configure on a Pico, you can on an STM32, although I usually don't as it can produce overshoots which ends up being worse to deal with.
@casandro The real CGA also cleans up the OSC pin by immediately passing it through an 74LS04 which we will probably also do.
-
I'll use GPIO16 for this which conveniently puts it on the top right corner of the Pico 2 board.
Our PIO program is stupid simple:
let clock_program = pio_asm!(
".wrap_target",
"set pins, 1 [10]",
"set pins, 0 [10]",
".wrap"
);.wrap_targetis just a standard label for the PIO loop, which will be restarted at the end with.wrap. The value in brackets is how many cycles to spin - the set itself takes one cycle, then we spin for 10 after. This should give us the 11 cycles on, 11 cycles off behavior we want.'pins' here just targets GPIO16, via this:
let clock_pin = pio1.common.make_pio_pin(p.PIN_16);
clock_sm_config.set_set_pins(&[&clock_pin]);@gloriouscow the 2350 also has an extremely flexible clock tree for micro; each off the gpouts has an individual int/frac divider with duty cycle correction and coarse phase adjustment
The PLL can also run up to 1600MHz (don't think any of the IO buffers can manage that though) and you can input an external clock to it (I think this is what you're doing)
-
14.318MHz, baby.
Believe it or not, a sawtooth clock isn't that hideous. This is pretty much what the OSC pin looks like for realsies.
It's actually kind of silly how close we already are to outputting something on a real CGA monitor.
We could drive two additional PIO state machines with divisors to control HSYNC and VSYNC.
Now, if you just output color all the time, you have no idea whether your picture is actually synchronized - the monitor will just keep the beam on all the time, so if you just say, emit magenta forever, you'll just see a solid magenta screen even if the monitor has no vertical hold.
-
It's actually kind of silly how close we already are to outputting something on a real CGA monitor.
We could drive two additional PIO state machines with divisors to control HSYNC and VSYNC.
Now, if you just output color all the time, you have no idea whether your picture is actually synchronized - the monitor will just keep the beam on all the time, so if you just say, emit magenta forever, you'll just see a solid magenta screen even if the monitor has no vertical hold.
So we're going to have a color latch like the CGA does.
This is a 74LS174 flip-flop, that is fed our generated colors and is clocked by /OSC.
The CGA doesn't use the 174's clear input, but we can - another GPIO output of the Pico should be able to pull that low to blank the screen, I think. Having a vertical blanking area will let us tell if we have vertical hold.
-
So we're going to have a color latch like the CGA does.
This is a 74LS174 flip-flop, that is fed our generated colors and is clocked by /OSC.
The CGA doesn't use the 174's clear input, but we can - another GPIO output of the Pico should be able to pull that low to blank the screen, I think. Having a vertical blanking area will let us tell if we have vertical hold.
I can't overstate how useful it is to have a working digital simulation of the thing you are intending to make.
-
@gloriouscow the 2350 also has an extremely flexible clock tree for micro; each off the gpouts has an individual int/frac divider with duty cycle correction and coarse phase adjustment
The PLL can also run up to 1600MHz (don't think any of the IO buffers can manage that though) and you can input an external clock to it (I think this is what you're doing)
@ldcd The plan is to drive the ISA board version off OSC, yeah. Can you give a Pico 2 board an external oscillator?
-
@ldcd The plan is to drive the ISA board version off OSC, yeah. Can you give a Pico 2 board an external oscillator?
@gloriouscow you can clock the system off of GPIN yes, although I don't think you can clock the PLLs off of it.
(So like if you had an NTSC freq input you could clock a PIO SM off of it or the CPU off of it but you couldn't generate a multiple of it with the PLL unless you remove the crystal and solder a lead to one of the pads)
-
I can't overstate how useful it is to have a working digital simulation of the thing you are intending to make.
Time to start breadboarding!
-
@gloriouscow you can clock the system off of GPIN yes, although I don't think you can clock the PLLs off of it.
(So like if you had an NTSC freq input you could clock a PIO SM off of it or the CPU off of it but you couldn't generate a multiple of it with the PLL unless you remove the crystal and solder a lead to one of the pads)
@gloriouscow I wish you could clock them off of gpclk0/1 but that would have probably been a pain to route
-
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!
-
