A2VGA - Pico Cards - High Definition

A2VGA - Pico IIe/IIc cards are now capable of displaying HD/WUXGA resolutions ie 1920x1080 60Hz and 1920x1200 60Hz. All this while amazingly still running the Pi Pico at the video pixel clock frequency. The importance of this will be explained shortly.

What's the big deal with a HD (high definition) resolution I hear you ask? Well it has nothing to do with modern monitors or digital video. It's all to do with having a more detailed picture / a more realistic look. By using a VGA resolution (640x480), the Apple II display 560x384 (lines doubled to give a squarish look) fits in nicely to give you one LCD pixel for every Apple II bit/pixel. However, by using HD you get three LCD pixels for every Apple bit/pixel. Including the complementary 16bit (RGB565) colour range, I'm hoping this is going to make a big improvement to the picture display.

While waiting to finalise the hardware for the next revision of the A2VGA cards I worked on the firmware issues that I knew needed addressing. I also wondered how far the Pi Pico board could be pushed. I didn't know if it could do what I wanted it to do but I took the gamble anyway and it paid off. The Pi Pico has impressed me with its performance.

The first firmware revision worked by using the Raspberry Pi foundation's video driver. The Pi Pico does not have enough memory for a VGA display buffer (using RGB565). This would require a buffer size of 600kB but the Pi Pico only has 264kB of RAM. Therefore, a line buffer is used and each line is constructed on the go. This driver was not fast enough to process just one line at a time. 128 pre calculated lines were required just to make VGA work. This is a great driver and for certain applications it is ideal, however, because it is so generic it is only just capable of handling the Apple II video application in the VGA resolution. I went looking for other VGA drivers to use. There are plenty out there and they all look terrific at first but when you get down to the details they all have their limitations (only works in QVGA resolution, limited colour range, needs to be encoded into the data stream, needs to be overclocked by over 100% etc). This is great because they are all customised to their specific application, but for the Apple II video application they are unwanted road blocks. What caught my interest was the driver written by Hunter Adams. It was simple and fully contained within a single PIO block. A Pi Pico PIO block only contains 32 instructions and this VGA driver used up 31 of these instructions. An amazing feat to get it all in there. Even though the PIO was basically all used up I still went ahead and converted over to use this new driver. It was a great improvement for the A2VGA. It resulted in being able to speed up the data processing from 128 lines to under a single line. This gave me hope that a HD resolution was within reach. Actually, I knew HD was possible however all the examples I came across required the Pi Pico to be overclocked from its maximum speed of 133MHz to over double that ie around 300MHz. That might be fine for a demo, but it is not going to work for a reliable product. Going from a VGA 60Hz pixel clock (25.175MHz) where the Pi Pico runs at roughly 5 times the pixel clock ie 125MHz to HD 60Hz (148.5MHz) / WUXGA 60Hz (154.0MHz in reduced blanking mode) is a big jump and practically would only work if the Pi Pico was able to send out a pixel every clock cycle. That is a tall ask. But with the PIO fully loaded where was the extra processing to come from? The break through came from first having to optimise the VGA driver to buggery then having enough room to implement outputting the pixel every clock cycle. The system then became scalable. Up scalable to reach HD resolutions or down scalable to better match VGA frequencies for older monitors. Yes, it still requires overlocking but only just over 10%. From speculation the 133MHz limit was based on the flash speed but A2VGA runs the code from memory instead so I'm not concerned with the small amount of overclocking needed. The problem now becomes having to process the data in time and transfer it between buffers. By using two whole CPU cores the data processing now becomes borderline capable. It is still a work in progress since I need to find some more room for little things like extra video modes.

I don't have any demos to show off because currently the display is just the scaled image of the VGA driver which can be seen in my previous blog post. I have contacted a few people in getting some assistance with generating a finer colour model worthy of display. I'll include an example then. In the mean time I will be displaying the results at the upcoming Brisbane Apple II gathering (this weekend - 22/07/2023).