Let's make a Pi Pico 2 powered video card.
-
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]);PIO is the secret sauce that makes Picos so good at interfacing with retro hardware. They allow you to react to pin changes instantly, and read and write busses, doing the sort of high speed bus interactions that were normally the exclusive purview of FPGAs.
-
PIO is the secret sauce that makes Picos so good at interfacing with retro hardware. They allow you to react to pin changes instantly, and read and write busses, doing the sort of high speed bus interactions that were normally the exclusive purview of FPGAs.
All in all, not too shabby for a $5 board. Let's see how our clock looks, right after I unbag this and hook it up.
-
All in all, not too shabby for a $5 board. Let's see how our clock looks, right after I unbag this and hook it up.
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.
-
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.
@gloriouscow Could that be a probe issue? Not all probes go up that high in frequency.
-
@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.
