Let's make a Pi Pico 2 powered video card.
-
Despite my fundamental lack of electronics background, I'm probably better equipped to make a bespoke CGA card than most people on the planet. At least that's my internal pep talk.
@gloriouscow Perhaps your project would be a good starting point for a modern PCIe text only video card that can be remotely accessed. I’m surprised that something like that for servers doesn’t exist, except for ridiculously expensive devices. -
- 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?
This project will live on a breadboard for a while. The first milestone should be emitting some sort of test pattern on a standalone circuit to a real CGA monitor.
To do this we need to control five pins to start - the colors red, green, and blue (we'll ignore intensity, or pin it high), and the two sync signals, horizontal and vertical.
-
This project will live on a breadboard for a while. The first milestone should be emitting some sort of test pattern on a standalone circuit to a real CGA monitor.
To do this we need to control five pins to start - the colors red, green, and blue (we'll ignore intensity, or pin it high), and the two sync signals, horizontal and vertical.
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."
-
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."
Internally, the Pico will run MartyPC's CGA emulation, including my implementation of the Motorola 6845.
To cheat a bit, we'll tweak it a bit so it starts up with the register values pre-set for the PC's 80 column text mode, so it won't require programmatic set up.
-
@gloriouscow Perhaps your project would be a good starting point for a modern PCIe text only video card that can be remotely accessed. I’m surprised that something like that for servers doesn’t exist, except for ridiculously expensive devices.
@AnachronistJohn Isn't that what stuff like iDRAC does?
-
Internally, the Pico will run MartyPC's CGA emulation, including my implementation of the Motorola 6845.
To cheat a bit, we'll tweak it a bit so it starts up with the register values pre-set for the PC's 80 column text mode, so it won't require programmatic set up.
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.
-
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.
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.
-
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 can you just use a PIO for that?
-
@gloriouscow can you just use a PIO for that?
@petrillic That's the plan, overclock to 315MHz, then just have a PIO running to twiddle a GPIO every 11 cycles.
-
@AnachronistJohn Isn't that what stuff like iDRAC does?
@gloriouscow Sorta, but iDRAC / iLo / IPMI are proprietary (there are some attempts to make an open replacement for the software), insecure, expensive and require an additional machine / network to access it. This would likely also require an additional machine, but it’d be so much more flexible.
Plus, it’d be cool as hell to output / capture composite video or CGA line doubled to VGA. -
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.
On GlyphBlaster currently, I fight a lot with bus contention between the two ARM cores. Embassy, the USB-CDC connection and the network stack live on Core 0, whereas GlyphBlaster's video routines run on Core 1, so you might assume they could run independently.
-
On GlyphBlaster currently, I fight a lot with bus contention between the two ARM cores. Embassy, the USB-CDC connection and the network stack live on Core 0, whereas GlyphBlaster's video routines run on Core 1, so you might assume they could run independently.
But they still contend for the same flash - if I add some intensive video effect, I can starve Core 0 and it will stop responding to network requests or my USB debugging session.
The solution is to tag routines on Core 1 with
#[unsafe(link_section = ".data.ram_func")]to force it to run out of RAM instead of flash, but this compounds my already dire RAM situation. -
But they still contend for the same flash - if I add some intensive video effect, I can starve Core 0 and it will stop responding to network requests or my USB debugging session.
The solution is to tag routines on Core 1 with
#[unsafe(link_section = ".data.ram_func")]to force it to run out of RAM instead of flash, but this compounds my already dire RAM situation.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.
-
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.
We'll definitely be using an RP2350B directly instead of soldering on a Pico 2 board. But I guess it's okay to still call this a Pico.
We basically double the number of available GPIO pins, meaning I no longer have to make compromises. Light pen? Sure. Capture every address line? You betcha. QSPI PSRAM? All day long.
Raspberry Pi is nice enough to provide a reference KiCad project, so you can more or less copy and paste a RP2350 into your project.
-
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 glad we're not at the state of vibe hardware yet where we need to convince it to actually do that
-
We'll definitely be using an RP2350B directly instead of soldering on a Pico 2 board. But I guess it's okay to still call this a Pico.
We basically double the number of available GPIO pins, meaning I no longer have to make compromises. Light pen? Sure. Capture every address line? You betcha. QSPI PSRAM? All day long.
Raspberry Pi is nice enough to provide a reference KiCad project, so you can more or less copy and paste a RP2350 into your project.
@gloriouscow If you're making a whole ISA card, then you're overlapping with #PicoMEM, #PicoGUS, and #PicoIDE which could be a good place to steal from / ask about!
-
@gloriouscow If you're making a whole ISA card, then you're overlapping with #PicoMEM, #PicoGUS, and #PicoIDE which could be a good place to steal from / ask about!
-
We'll definitely be using an RP2350B directly instead of soldering on a Pico 2 board. But I guess it's okay to still call this a Pico.
We basically double the number of available GPIO pins, meaning I no longer have to make compromises. Light pen? Sure. Capture every address line? You betcha. QSPI PSRAM? All day long.
Raspberry Pi is nice enough to provide a reference KiCad project, so you can more or less copy and paste a RP2350 into your project.
Okay, first priority - let's make our Pico OSC pin simulator.
Raspberry Pi has a very nice Pico development plugin for Visual Studio Code. We just choose "New Rust Project," name it, and click create.
-
Okay, first priority - let's make our Pico OSC pin simulator.
Raspberry Pi has a very nice Pico development plugin for Visual Studio Code. We just choose "New Rust Project," name it, and click create.
This gives you an rp-hal project, and GlyphBlaster is currently written against Embassy, and I don't really feel like rewriting all the overclocking code, so I'm just going to switch this to Embassy too and copy-paste that stuff.
I would like to thank FreddyV of PicoMEM for giving me the tips on how to stably overclock a Pico. It requires tweaking the on-board flash timings in a way I never would have figured out for myself.
The key do doing this in Embassy is this bit:
const PICO_SYS_CLOCK_HZ: u32 = 300_000_000;
const FLASH_QMI_TIMING_UPDATE_THRESHOLD_HZ: u32 = 280_000_000;
const FLASH_QMI_TIMING_HIGH_SPEED_HZ: u32 = 380_000_000;
const OVERCLOCK_FLASH_QMI_CLKDIV: u8 = if PICO_SYS_CLOCK_HZ > FLASH_QMI_TIMING_HIGH_SPEED_HZ {
4
} else {
3
};
const OVERCLOCK_FLASH_QMI_RXDELAY: u8 = if PICO_SYS_CLOCK_HZ > FLASH_QMI_TIMING_HIGH_SPEED_HZ {
4
} else {
3
};
//...
let timing = embassy_rp::pac::QMI.mem(0).timing();
timing.modify(|w| {
w.set_clkdiv(OVERCLOCK_FLASH_QMI_CLKDIV);
w.set_rxdelay(OVERCLOCK_FLASH_QMI_RXDELAY);
}); -
@gloriouscow With your graphics card, all that's needed is an Pico 8086 emulator and you've got an "Oops, all Pico!" IBM PC
