I've been looking to build an inexpensive IIGS video card for quite a long time. Building a IIGS video card isn't a problem. Building an inexpensive IIGS video card is. Unlike the IIe or the IIc which contain ports with digital video streaming signals, the IIGS does not have any of these. You can use this concept, but you need to solder directly to the motherboard, which I'm not fond of doing. This leaves sampling the RGB video port (which requires a method to work out the pixel clock and fast analog sampling, thereby being expensive) or digital sampling the 50 pin extension slot and recreating a copy of the IIGS video buffers. The last option sounded like the most practical approach. This is to be my next stepping stone. CheapskateDV is my first attempt at designing a video card based on the sampling of the 50 pin extension slot. I've done quite a bit of work already in developing the building blocks ie while developing the A2VGA Pico IIc/IIe cards (no relation to the other A2VGA cards derived from Mark Aikens work). This has allowed me to progress relatively quickly as opposed to having to start with a blank canvas.
Although I like the concept of using an FPGA over a microcontroller, the microcontroller option has a number of advantages, namely the ease of creating the user interface and of course the cost. I wanted to see how low I could go (cost wise) and still get a functional product. What surprised me the most was that this was able to be achieved with a budget of under $15 (AUD), using "off the shelf" parts and it was able to run efficiently ie without having to thrash the crap out of the microcontroller.
For this project I've chosen to go with the Raspberry Pico range but with a twist. We will get to that later. CheapskateDV is a prototype that is meant to iron out all the bugs before leading in into the XenithDV range of Apple II video cards. The goal is to first start off with a "Proof of Concept". There is still a lot of work to get done but the progress is coming along nicely. Without a doubt it can handle all the IIe video modes but to handle everything the IIGS can throw at it has yet to be determined.
The plan is to release:
XenithDVc - An Apple IIc video port based card. This is the DVI version of the A2VGA - Pico IIc card but using SMD components.
XenithDVe - A 60 pin IIe auxiliary slot based card. This is the DVI version of the A2VGA - Pico IIe card but using SMD components and integrating the extra IIe auxiliary memory.
XenithDV - A 50 pin slot sampling based card. The prototype I've called CheapskateDV. Using SMD components and catering for all the slotted Apple IIs.
The DVI prototype solution for the IIe/IIc is already done and working. To get this operational I hacked one of my "A2VGA - Pico IIc" cards and made it work using DVI. The conversion was rather simple but took quite a while because of having to swap over programming environments to handle the RP2350 as well as the RP2040 microcontroller. I figured this product would be better produced in SMD form instead of "through hole" so I'm currently discussing getting this implemented. Since I'm dependant on someone else's timetable, while waiting, I figured I'd get stuck into getting a IIGS video card solution working.
I looked into using DVI on the Pi Pico when it was first shown that it was possible. Amazing what can be achieved using a software solution. My curiosity in this was not just as a peripheral for the Apple II but for many other electronic projects. However, in terms of making this into a sellable product, for me, I came across two deal breakers. One was the fact that the RP2030 needs to be overclocked by around 100% (133MHz to 252MHz for 640x480 or 133MHz to 270MHz for 720x480). Maximum clock speed for the RP2030 is specified at 133MHz. Developing hardware outside of the manufacture's specifications typically tends to come back to bite you on the arse, just when you least expect it. For me, it's just not worth the risk. The second issue is that it doesn't conform to the DVI specification in terms of the TMDS encoding. I couldn't get my Pi Pico displaying a colour image on some TVs / monitors. Even after going through all the recommended work arounds. I suspect that over the years this part has been improved upon by creative work arounds. Like that done on the A2DVI card. However, it still has its limitations (only supporting a small colour set). Obviously, this was a big enough of a concern for the developers of the Pi Pico because they spent the effort, time and money on developing a dedicated hardware based peripheral called HSTX (High Speed Transmit) into their latest microcontroller, specifically to cater for DVI output. The RP2030 is great for VGA (when done well) but I can't ever see myself using it for DVI. Especially now that the RP2350 is available and DVI output is no longer a hack.
Colour Models:
Just like my VGA cards, CheapskateDV can output several different colour models that should satisfy users who want that sharp look (some call this the "perfect pixel" look while others call this the "Minecraft" look) all the way to those that want a more authentic emulated CRT look. It's hard to make out from these pictures but in person, it looks quite strange seeing an analog NTSC picture (for the HGR/DHGR video modes) being generated from the IIGS. I'll be adding in an RGB looking IIGS colour model to make it look more natural.
Are 1080p resolutions possible?
DVI resolutions of 1080p are possible but not practical. You would have to overclock the RP2350 from 150MHz to about 770MHz (funnily enough, this has been achieved) but even if you had the microcontroller sitting in a tub of liquid nitrogen, there is no guarantee that it would operate for very long. 1080p resolutions are practical when using the Pi Pico range for VGA solutions. They do however require the microcontroller to be slightly overclocked to 154MHz.
Colour depth:
The screen resolution is probably the largest factor that most people think about when considering picture quality. However, the colour depth (the number of possible colours) is probably just as important or even more important. The last of the Apple II 8bit machines contain 16 colours (15 if you consider the two greys are the same) so you only need 4 bits to represent all the different possibilities. However, each one of these 15 colours need to be represented on the screen. The more colours you have to pick from the closer you can get to displaying each of the Apple II colours to their ideal hue, saturation and shade values. I've gone with the maximum colour depth possible given the available hardware. My VGA solutions use a 16bit colour depth (RGB565) which allows for each Apple II colour to be matched very closely to it's ideal display. This level allows for a good colour range to handle CRT emulation ie representing the analog effects of colour at the fringes and the different shades and hues generated between the border of two adjacent Apple II colours. Most importantly for this project, the 16bit colour depth provides the range needed to encompass the 12bit Apple IIGS palette. Currently CheapskateDV is throttled back to a 16bit colour depth because I'm reusing code. I'm hoping there is enough memory left for converting over to using a 24bit depth (RGB888).
No level shifters:
You may have noticed that CheapskateDV does not contain any level shifters. Being a video card design, the signals are only going in one direction, Apple II to RP2350 or 5V to 3.3V. However, the RP2350 and its variants are not 5V tolerant so how is this possible? Well, the microcontroller was not designed to be 5V tolerant but a by-product of the improved ESD protection circuitry in the new chip allows for a 5V tolerance under certain conditions. By taking advantage of these conditions we can remove the need for level shifters and at the same time still conform to the hardware specification of the RP2350. One of the restrictions is that only some of the GPIO pins are 5V tolerant. The other restriction is that the RP2350's power rail needs to be stable at 3.3V. This means that the protection is from 3.3V to 5.5V and not from 0V to 5.5V. Another way of looking at this is that if the Apple II were to be powered up but the RP2350 was not then you have the potential of frying the RP2350's GPIO circuitry. In this application, I've compared the signals on startup and I can see that the 3.3V line comes up before any of the Apple II signals start talking over the 50pin Apple II port. This means that during operation and boot up of the Apple II, the RP2350 is fine. The concerning part is during the design stage when reflashing of firmware happens while keeping the Apple II powered up. The RP2350 is pretty durable but I may burn out a board or two during this development stage. I'm prepared to take that risk. While performing the analog tests I found that the bus signals on my IIe tend to only reach 4V whereas the signals on the IIGS go all the way up to the RP2350's specified 5.5V limit, meaning there is no margin of safety. I'm not sure if this is typical or a result of the power supplies that I am using for my two Apple II systems. More testing us needed.
The Pi Pico twist:
You may have also noticed that there are no multiplexers in this design. This is because the design actually uses the RP2350B microcontroller. The "B" represents a variant of the RP2350 that contains more GPIO pins. 48 of them in fact. If you can get your project over the hurdles of the GPIO input bug and the 5V tolerance issues, then the RP2350B is a retro computer designer's wet dream. This thing is a beast. With 2 x 32bit 150MHz cores, 12 small parallel processors (runnable at the system clock speed), 48 deterministic GPIO, 16 DMA channels and a dozen or so other industry standard peripherals including the HSTX, this thing is a powerhouse. A powerhouse that can be picked up for bugger all cost. A lot can be achieved before having to fork out the cash for a more expensive FPGA solution.
Testing equipment:
Thank you Dean for providing me your Apple II test card. It came in very handy when testing the power signals. For analysing the digital signals of the Apple II bus I built myself a 48 channel logic analyser. This is going to require a blog post all of its own. However, I haven't had the time to set this up properly. For now, I've been getting by with my old 8 channel Saleae logic analyser.
There a lot of things that I don't like about the CheapskateDV. Hence the need for a prototype to experiment with different options.
- High speed DVI signals running over several different breakout board connectors. Not ideal when transmitting signals at around the 250MHz / 270MHz mark.
- High speed DVI signals are not length matched.
- WeAct breakout board pin format is not compatible with other RP2350 breakout boards.
- Unlike the Pi Pico and Pi Pico 2 boards, the WeAct breakout board is not guaranteed to be manufactured for a given number of years.
- The WeAct board comes with extra circuitry that needs to be removed for this application.
- The pin location of the HSTX peripheral is in an awkward location and can't be relocated.
- There is no electrical barrier between the WeAct board and the Apple II bus. Badly written firmware could damage the Apple II. As a video card it's good that this solution only performs sampling of the signals and does not send any signals back to the Apple II.
- Tin plated edge connectors are fine for a prototype board but not ideal for a released product. All the little things start adding up when you start talking about quality.
These concerns will all be addressed when it comes to building the XenithDV board. There are many design decisions that go into building of Apple II cards. Even for the simplest of cards.
That's all for this update.