Let's make a Pi Pico 2 powered video card.
-
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.
-
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.
The goal of this card will initially be to implement CGA-compatible text mode.
Taking a page from the Seequa Chameleon, it will decode 16K of video memory from B0000-C0000, repeating it four times. This simplifies decoding. We may tighten that up later.
It will have a 4K region at AF000-B0000 where two soft fonts of 2K each can be written.
It will have IO addresses for a mode register, status register, color control register, CRTC registers, and eight palette registers.
-
The goal of this card will initially be to implement CGA-compatible text mode.
Taking a page from the Seequa Chameleon, it will decode 16K of video memory from B0000-C0000, repeating it four times. This simplifies decoding. We may tighten that up later.
It will have a 4K region at AF000-B0000 where two soft fonts of 2K each can be written.
It will have IO addresses for a mode register, status register, color control register, CRTC registers, and eight palette registers.
This may seem overly ambitious - but I have an ace up my sleeve.
I have all the decoding PALs from a Seequa Chameleon on sitting on my desk. Including one that just decodes address ranges AF000-B0000, B0000-C0000 and produces an active-low chip select. And including another that decodes all the CGA's IO ranges.
-
This may seem overly ambitious - but I have an ace up my sleeve.
I have all the decoding PALs from a Seequa Chameleon on sitting on my desk. Including one that just decodes address ranges AF000-B0000, B0000-C0000 and produces an active-low chip select. And including another that decodes all the CGA's IO ranges.
It's cheating, yes. But it's an amazing shortcut to be able to leverage those. They can be replaced later with GALs or some other kind of modern CPLD.
-
It's cheating, yes. But it's an amazing shortcut to be able to leverage those. They can be replaced later with GALs or some other kind of modern CPLD.
A CGA card does not need a crystal - thanks to IBM's penny-pinching design decisions, the entire system crystal was tuned for an NTSC display, driving a master clock of 14.31818MHz.
This clock was delivered to the ISA bus via the OSC pin.
Deep in your modern PC, somewhere in the guts of its highly integrated chipset, there's a clock ticking away at this frequency.
-
A CGA card does not need a crystal - thanks to IBM's penny-pinching design decisions, the entire system crystal was tuned for an NTSC display, driving a master clock of 14.31818MHz.
This clock was delivered to the ISA bus via the OSC pin.
Deep in your modern PC, somewhere in the guts of its highly integrated chipset, there's a clock ticking away at this frequency.
14.31818MHz is not a transcendental number. It happens to be 315/22.
Thanks to @polpo for pointing out if I'm already overclocking my Pico 2's to 300MHz, I might as well go to 315.
-
14.31818MHz is not a transcendental number. It happens to be 315/22.
Thanks to @polpo for pointing out if I'm already overclocking my Pico 2's to 300MHz, I might as well go to 315.
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.
-
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.
- 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?
-
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.
