iLoveThisMonitor - Repurposed iPad - IIc Monitor

While working on developing the A2VGA Pico IIc/IIe video cards (not to be confused with the other Apple II video cards with the A2VGA name which work in a completely different way) I had a small project in mind that would be good to have around so as to show off the video cards. I'd been slowly collecting the main components and I figured it would be a reasonably quick build. As it turned out, I was able to knock it over in a weekend (for the most part). No prototype project is complete without issues. However, I was able to get around the few issues that popped up pretty quickly.

I've been looking at using an iPad as an Apple IIc monitor, on and off, for over a decade but my previous attempts were focused on doing this by trying to feed a video signal into a working iPad. This is much easier to achieve now than it was in the past (due to newly available iPad Apps and new hardware) but this time around I had an alternate option. I had a well-used iPad3 in the cupboard whose battery had been stripped out years ago due to it swelling up and cracking open the case. If I repurposed just the LCD screen, then I could produce a more efficient solution with less display lag. As a bonus I would have the opportunity to test out a retina display, since the iPad3 was the first iPad generation to contain one.

The result is iLoveThisMonitor, a repurposed iPad into a funky IIc monitor. It turned out better than I had envisioned (for both the aesthetics and the display quality). The 9.7 inch screen is a nice fit with the dimensions of the IIc and the round corners of the screen/stand don't take away too much from the stying. It's not the best period correct looking solution out there but for the ease of construction I'm happy with it for now.



The iPad case came with plenty of scratches and dings as a result of being dropped a few times. I had no reservations about defacing it to suit my purposes. I could have found a case that enclosed the electronics, but I wanted a quick build and I also wanted the A2VGA Pico to be visible. Reusing the existing iPad case resulted in not having to worry about mounting and positioning the LCD screen in an enclosure. I like how the openness shows the functional parts of the monitor. It gives it an industrial looking edge. Especially when viewed from behind. I've left enough space so that I can easily remove the current VGA cable and use this monitor to display any other VGA or HDMI input.

This is not the first iPad to be repurposed into a monitor. There are dozens of examples online of various custom conversions to get tips and inspiration from. However, in my situation, I wanted a compact solution with an attached IIc video card, and I wanted to see how the A2VGA Pico performed when matched with a retina display. I was not disappointed.

It was difficult to get pictures of the resultant outcome. The iPad screen is very reflective and to get some decent shots of the system I resorted to taking pictures in low light. The IIc comes up ok but the screen background appears as if it is bright and glowing (not dark like it really is). I tried taking shots of just the screen in darkness and although it comes out ok, the photos I manage to get come out oversaturated. I can't get the shots of how nice it looks in person. This is probably due to my inexperience in photography and not having the right tools for the job. I guess people will get to see it when I attend Apple II enthusiast gatherings. If I do manage to work it out then I'll post some pictures at the end of this blog.


Construction:

The first step was to obtain an iPad LCD screen. I didn't need to do anything here except look in my spare parts bin. The well-used iPad was just waiting there, ready to be repurposed. I decided to reuse the case as well. Since there was not going to be enough room inside the case to mount the electronics, they would all need to be mounted externally. I was considering placing acrylic sheets over the top of the electronic boards but then decided they were going to be too much work and not really necessary for my purposes.

The most critical part came next i.e. sourcing the correct LCD controller board. To do this I took the iPad LCD screen's model number (LTN097QL01-A01) and searched online for a matching controller board. AliExpress and eBay are the main sources for these boards. Since LCD screens come with various connections and resolutions it is important to get the right controller. In my situation I came across two controllers that would do the job. The older one was made up of four PCBs (video processing board, LED power supply board, menu push button board and LCD connector board) and the new one was made up of three PCBs (the LED power supply was integrated into the LCD connector board). I chose the newer model. It was more expensive but resulted in having less components to mount.



I connected up all the electronics to make sure I could get a working device. There would have been no point in continuing if this had not worked. At first, I had the backlight working but no picture and no menu. It turned out I didn't have the tiny LCD connector cable in far enough into the adapter plug. This was my first attempt at performing this task. Luckily it did not take me long to work out what I had done wrong and I'm happy that I didn't fry anything.

Once I confirmed that I had a working system, I stripped out as much as I could from inside the iPad case (except for the LCD screen of course). This helped in making the case very light. It also resulted in the magnets being removed which is a good thing since I still use floppy disks with the IIc.

The panel needs to be powered using its own power supply. The video output port on the IIc can supply 12 volt power but it is only rated to 3.6 watts. This is enough for the A2VGA Pico card which consumes 0.3 watts however it is not enough for the LCD panel which uses roughly 5 to 9 watts depending on the brightness level.



It took me a while to work out how I was going to position the components on the case. This included the consideration of where the stand was going to be attached and hence the type of stand I was able to use. Once I committed to a layout there was no going back. The holes were drilled, and the parts started to be attached. Initially I had planned on hiding the menu push button board inside the iPad case but as I connected it up, I found that it did not fit. It may have fit if the switch bases stuck through the case but putting in small square holes into the case sounded like too much effort. I ended up mounting the board on the outside instead. I used polycarbonate screws to attach the PCBs to the iPad case. This made it very easy to trim their lengths. Trimming the lengths was important because there was not much clearance space inside the iPad enclosure.



For supporting the iPad, I picked up a tablet stand from Umart (a local PC supplier). I only needed the base and the arm so the top part was removed. It's connected to the middle of the iPad case via the Apple logo which is comprised of a thinner sheet of aluminium and a bit of plastic/acrylic. It's very flimsy so at some stage I plan on adding in a thicker aluminium sheet to obtain a sturdier fit.

I used a VGA gender changer to join the A2VGA Pico to the LCD controller. However, I didn't end up using this in the final build. This was because I could not find a version of the VGA gender changer that allowed both boards to be facing in the same direction. I ended up building a custom cable instead. This custom cable resulted in some electrical interference i.e. a small wavy pattern. The wavy pattern does not show up when using the VGA gender changer or when using a proper VGA cable. I attempted to fix the issue by adding in an alfoil shield but that did not help much. It's not a big deal but I will try and make up a better quality cable at some stage.

To finish it all off, a custom IIc video port cable was made to suit. I chose a rainbow coloured cable in this instance to keep with the retro look.


Conclusion:

Combining a premium video card with a premium LCD panel has fulfilled my goal of creating something that is going to give me the quality I was after without having use my CRT monitors. I also think the monitor will do a great job in promoting the A2VGA Pico IIc/IIe (the video cards that I have been working on for the past few years). I'm really happy with this build.

Take it easy and happy hacking.

A2VGA - Pico Cards - Available

The A2VGA (Pico IIc/IIe) is a video card that reads Apple IIc/IIe serial video signals and translates those into the VGA format. The difference with this card is that it attempts to preserve the unique Apple II look of analog and artifact colour that is so entwined in how the Apple II was designed and how it was displayed on the technology of the day ie CRT monitors/televisions.

I still use CRT monitors when using my Apple IIs. However, I know that this is not going to last forever. With their bulky size and the worry of breaking something every time I transport them, I wanted to find an alternate solution. I couldn't find a product with the video output that I was after, so I built my own. I've been tinkering with colour models and Apple II video for years and I have tried various cheap options with mixed results. After playing around with the Pi Pico I instantly saw its potential for it being a great fit for this solution. I couldn't resist trying it out and I'm extremely happy with the results.

The other motivation came from the Apple IIc model. On this side of the world, we received Apple IIcs (PAL) which did not come with colour output via the RCA connector. To get colour out you need a special adapter which fits into the IIc video port. These are not easy to come by. So, having an inexpensive colour solution for the IIc is greatly sought after. I'm happy to be finally helping fulfil that need. These cards allow me to cover the IIc and IIe models that I have. The IIgs is a different kettle of fish. It will require something totally different but that's a story for a future project.




Here is a screen shot comparing the currently supported colour models (HGR and DHGR). For more information please see details in the user manual.https://docs.google.com/open?id=1qFpSw4YKwObCCJ-Tfzo8wFwJZxIsIUu5

I would like to thank all those involved in helping out with this project, be it with advice on logo design, supplying equipment for me to test on / allowing me to compare competing products or with testing the final solution and helping improve it.

At the moment the cards are only available via the "Lukazi's Loot" website https://lukazisloot.blogspot.com/. The IIe version will be available shortly. As a late addition, it requires a PCB change (selection of signals for the 80COL/AN3 colour killer option).

A2VGA - Pico Cards - Progress

Even after being on the second run of prototype PCBs at the last Apple II OzKFest event in Oct 2023 there was still a lot of work to be done in getting this into a consumer product. The OzKFest event was great for getting help with things that otherwise would have been difficult for me to do. Like borrowing a bunch of other video cards to compare against, being able to borrow an NTSC IIe and spending time on a high quality Apple II CRT video monitor for comparing with CRT emulation. I wasn't able to bring these back home with me, so I spent as much time as possible making the best use of the borrowed items. What was clear to me was the fact that I needed NTSC machines to test over a long period (hobby time is sporadic). I also didn't want to be using someone else's pride and joy to be testing my electronic projects (in case I damaged something). Luckily up to this point I've only fried a simple step-down power regulator and two Pi Pico boards which have been cheap and easy to replace. Oh, the joys of working on projects into the early hours of the morning and, hence making simple mistakes. Mainly due to shipping costs, it wasn't a cheap exercise to source two NTSC machines (a IIc and a IIe) but it had to be done. Thanks goes to the "Apple Rescue of Denver" for having the machines that I was after. I organised this to happen over the Christmas vacation so that it did not feel like I had to wait a long time for the machines to arrive.

Due to a new PCB layout and having to fix a few traces (also thanks to late night work) I was then able to use the VSync signal line as opposed to a timer based on the HSync. This fixed most of the NTSC related issues. Then that was PAL, International NTSC and NTSC motherboards covered

I played around with getting the 12V to 5V step down regulator working on the IIc version. I stuck with using the 7805 linear voltage regulator, instead of the switch mode regulators due to the amount of electrical noise on the power rails. Video and sound cards are more susceptible to noise over other cards so the cleaner the power supply the better.

On the subject of generating clean signals, there were many hobby projects that I looked into which involved generating VGA signals using non dedicated hardware ie FPGA / bit banging from a microcontroller. What I found surprising was that I could not find a single project where the developer went through the trouble of designing the DAC (Digital to Analog Converter) to be impedance matched as per the VGA specification. I didn't follow everybody else's lead but instead implemented a better solution. You just never know what quality of equipment the end user is going to have. Once a product is released, hardware issues are very difficult to deal with. You can't test your hardware with every possible outcome so you want the biggest margin of safety that you can get. I do believe this is not only going to result in a better performing product but I'm sure that in the long run it will save me time in dealing with specific support issues.

The last big hardware headache was with a ground loop issue on the IIc. A ground loop is formed from the earth wire going into the IIc power supply, through the ground of the IIc, through the ground of the video card, through the ground of the VGA cable, through the ground of the monitor, through the earth wire and back to ground. If the equipment does not protect against it then it can induce a ripple from the power mains onto the ground plain and cause humming. In this case it results in a high-speed flicker on the monitor. It is barely noticeable if using the IIc normally (varies based on the monitor) however you can make it out when you have a large area of a single colour on the screen that is non-black. I tested this with other video cards and the A2VGA was not the only card with this problem. I don't know how big of an issue this is since I have not been able to find any references to it online. I got my hands on a dozen or so IIc power supplies and about half of them had this problem. I suspect this issue was addressed at some stage and it was resolved in later power supply designs. I was torn as to whether this issue should be fixed on the A2VGA. There are devices such as the "Ground Lift Adapter" which remove the earth wire from your circuit, but I would never recommend these being used. The earth is there for a good reason. It is there to save your life in the event of an unlikely but possible, worse case electrical fault scenario. The option of modifying the IIc power supply was out of the question. Alternately, you could purchase a device such as the "humno" but they are rather expensive. This could be fixed by using some modern reproduction IIc power supplies which don't contain an earth wire, or you could run the signal to your monitor via a "VGA to HDMI converter". None of these sounded like good options to me. As a last resort, I tried to break the ground wire and inserted a very small valued resistor in series. Doing this on the output stage of the A2VGA caused the video to display lots of ghosting however doing this on the input stage of the A2VGA removed the flicker without any noticeable effects. Having the resistor in series on the good power supply did not look to affect the video image either. I added a bypass switch for the resistor just in case. Now you have the option to clean up the high-speed flicker or go with the authentic flicker feel.


The IIc power supply on the left causes a ground loop issue while the one on the right does not.

The rest of my time was spent on software and administration. There was plenty of work here too. I consolidated the best of the colour models into one package. I worked on adding in the "NTSC-CRT", "Lukazi YIQ" and "DHGR COL140 mixed" colour models. I added Grayscale and Green/Amber monochrome CRT options. I generated the user interface which involved setting up fonts, logos and a "Save to Flash" function. Oh, and I also had to generate a user manual.


Showing the output from the "DHGR COl140 Mixed" colour model.

The Pico IIc and Pico IIe variants had their own individual issues which needed sorting out. However, I didn't want to release one card before the other. That way both cards were able to be updated concurrently and I could keep the same firmware for both variants. Only time will tell if I'm able to keep it that way.

I've attached a link to my PowerPoint presentation from the OzKFest event. https://docs.google.com/open?id=1Q_sV2tWVUSiUlgc5VDFb8NSSEZ1Ohwq5

As a summary, this is how the A2VGA works. There is limited processing power on a microcontroller such as a Pi Pico to perform the maths that is involved in converting a monochrome image into a CRT emulated image on the fly. Hence, we do all the maths externally. The Pi Pico is there just to perform the conversion using a table lookup. This is much faster than doing the maths on every pixel or group of pixels. This lookup table is 4096 entries long (12 bits) and each entry holds the value for 4 coloured pixels (VGA) / 12 coloured pixels (WUXGA). Hence this becomes just a simple streamer. 12 monochrome bits are read from the Apple II which are then used to look up 4 coloured pixels and those 4 pixels are sent to the VGA screen. We read the next 4 monochrome bits, keep the 12 bit window by pushing these 4 onto one side and discarding the 4 bits from the other side. The process then just repeats itself. The trick is deciding on what actual colours the 4 coloured pixels are going to be made up of. Each colour model calculates these 4 coloured pixels differently. There are two approaches in generating this 4096 entry lookup table. One way is to send every possible 12bit monochrome combination through a CRT emulation engine such as "OpenEmulator" or "NTSC-CRT" and then sample the middle 4 pixels. The alternate way is to go through every 4096 entry (programatically of course) and perform some rules. Step 1 is to go through and colour in each monochrome bit that is an "on" bit. You then have have a coloured image with gaps of 1, 2 or 3 pixels in the "off" state that you have to deal with. Step 2 is deciding what colours to allocate to these gaps. The more black you leave in, the more sharp and stripy the image looks while the more you fill in, the more smooth and fuzzy the image looks. In a nutshell, that is it.

The next revision of boards has been manufactured and I'm now just waiting on their delivery. I'll be able to start sending these cards out for testing shortly.

A2VGA - Pico Cards - Colour Models - OpenEmulator Like Display

Are the photos above taken of an LCD or CRT monitor screen? Hard to tell? That's the challenge. The challenge of making the LCD display resemble that experience we had growing up with CRT technology. Is it authentic enough? Everyone is going to have a different opinion. I find it impressive, even though it's work in progress and there is always room for improvement.

There has been a substantial amount of work done in recent times in relation to Apple II video hardware. There were two video hardware based presentations at this year's KFest event ("VidHD-style HDMI solution with Ethernet-out bus card to Pi" by John Flanagan and "Yet Another Video Converter with Tang Nano 9K FPGA" by Rob Kim). The "AppleII-VGA" and "∀2 Analog" cards have been improved upon and used at the KFest solder session. The one that sparked my interest the most was ushicow's "Tang Nano 9K Apple II Card". You may have noticed his post in the KFest Discord environment. In the meantime, I've been making progress with my own solutions, the A2VGA IIe and IIc cards. This time it's been on the display quality side of things.

I've been playing around with Apple II colour models for several years and I've tried to understand how the colours relate to each other. When I say colour model, I mean converting the 560x192 monochrome video display (which at its core is what the Apple II really is) into the most visually pleasing coloured display. I started off by using digital models. By this I mean each resultant pixel is one of the sixteen possible Apple II colours. A sixteen colour palette is used to lookup the colour to be displayed. The AppleWin - Color (Composite Idealized) is one of these models and was the first model I implemented into my projects, back in 2015. Recently I've been trying to get my head around analog models. This is what I call a model where instead of picking a colour from a palette, mathematics is used to calculate the required colour. The full range of system colours can be used (A2VGA uses a 16bit / RGB565 colour system).



In this blog entry I'm not going to go into detail as to how composite video works. What is worth noting, however, is that colour on the Apple II revolves around a four pixel block. The reason for this has to do with the pixel clock frequency. When the Apple II requires colour to be output, it sends out a colorburst signal of approximately 3.58MHz. Colour is generated as a phase difference from this signal. If the Apple II's pixel clock was the same frequency as the colorburst then the "ON" part of that signal would output the entire colour spectrum in one bit. This is just a monochrome signal. If the Apple II's pixel clock was 3 times the colorburst frequency, then the colour spectrum would be divided into three pixels. This is basically red, green and blue. However, the Apple II's pixel clock is four times the colorburst, meaning that four pixels cover the colour spectrum. Each pixel is treated as being ninety degrees away from its neighbour. The "ON" or bright parts of the monochrome signal determine which parts of the colour spectrum are added together to form the resultant colour.

Colour spread can be adjusted by an aperture knob on a CRT monitor / TV. Turning the knob one way spreads the colour out giving you a nice uniform colour but the picture looks smooth and fuzzy. What this is doing is covering up the "OFF" or dark pixels (gaps of up to three pixels) that come from the monochrome picture. Turning the knob, the other way shortens the colour spread and results in a sharper looking picture. However, if you go too far you will start seeing these dark pixels gaps appear and these cause the picture to look stripy. This same affect can be achieved by using different models or changing the parameters that generate those models. You'll see this contrast in the models below.

The next part of this blog will show a comparison of these various models as best as I can. Please note that these are going to be photos taken of the display screen so it's not going to be the same as viewing these results on a monitor with one's own eyes. I've used a lot of zoomed in images to give a feel for the differences between the models. Some of these zoomed in images might look a bit trippy but that's not necessarily how they look when viewed on a whole screen.

I used the game Vindicator for the capturing of High Resolution Graphics (HGR) and Airheart for Double High Resolution Graphics (DHGR). If you have read any of my previous blogs, then you may have noticed that I use Airheart a lot for testing. For one, it runs in DHGR mode and DHGR is less forgiving than other Apple II modes. Problems tend to stand out more. I do use other Apple II video modes but only after I'm happy with the DHGR results first. Secondly, Airheart allows me to test all the points below in one go.

1. Display of the single width pixel and how colour spreads into the dark pixels. Look at the blue lines at the bottom of the screen. I like them being as thin as possible.
2. Uniformity of solid objects. Look at the red, green and blue squares at the bottom of the screen and the screen borders. This varies from a smooth even look to a sharp stripy look.
3. Moving white objects. The compass text as it spins about should only change the faint glow around the font and have minimal effect on the font colour.
4. Double pixel width fill ins. Look at the score board for digit contrast, fill in colour and colon between digits.
5. Clarity of DHGR text.
6. End tips of the blue water wave lines can show off the oval gaussian pixel spread typical of analog type signals (hence my preference of VGA over DVI/HDMI when available).


Digital models:



Every colour model takes its source from the monochrome data. The simplest model takes four pixels, determines the colour from the palette of sixteen and then outputs that colour as four pixels. That model is called the RGB model (displayed by some RGB expansion cards). It's very blocky and does not look anything like an Apple II output. This model helps us see that setting the correct pixel location is also important.



Generating a digital model can be broken down into two stages. The first stage is colour mapping the pixel locations where the monochrome pixels were "ON" or bright. The above diagram shows four different ways in which the source data can be read. Each way results in a slightly different output. The second stage involves filling in the gaps between the coloured pixels. Only gaps of one, two and three pixels need to be filled in. Again, there are multiple ways in which one can choose to fill in the colours.

The result is a model such as AppleWin - Color (Composite Idealized). This model has a very thin fringe of colour around white objects. I played around trying to increase the fringing colour but that just made things worse. It makes it look like the colour is part of the font instead of making it look like the colour is a faint glow around the font. This model is very sharp, but it comes at a price. Sometimes it creates anomalies like on the number 8 in the HGR example above or less than ideal sharp colours between the letters in the HGR example above.


Analog models:



Kris helped me with the understanding of how his ii-pix model worked. I converted the code to be used for the A2VGA cards. Playing around with the model parameters I got great results.

I then tried converting over the OpenEmulator code and I had success there as well. Due to the Pi Pico being limited in resources and only being able to run up to 133MHz ish, unlike other video solutions that are running in the GHz range and contain multiple more cores, there is obviously limitations with this model ie no barrel or shadow mask effect, limited integer scaling and 16bit colours. Even still, the results are outstanding.



Here is a good comparison of DHGR text. On the left we have the sharp AppleWin Color (Composite Idealized) and on the right we have the smooth but authentic OpenEmulator with a luma bandwidth set at 2.0M. If you find that the OpenEmulator picture is too smooth, then you may be accustomed into thinking that CRT displays were sharper and looked more like today's emulators. You can adjust the OpenEmulator output to be sharper by upping the luma bandwidth but at a value of 2.5M you will start to see the picture become stripy and by the value of 3.0M it is well defined. I've played around with the Chebyshev and Lanczos windows which OpenEmulator uses in its mathematical calculations to see how the output changes and I've also added a tweak to clean up solid lines.

A link to the video example of the OpenEmulator Model.https://drive.google.com/file/d/1MkWuSuV-nNTKfjn8OiW6IyQbo_N3P9YP

During a discussion a question was asked on how an analog model would look like on hardware that had a lower colour range. Specifically 9bit / RGB333. I did a simulation and it came up pretty well. Much better than I had expected. However, it did struggle with colours that were similar ie in Airheart the noticeable colours were red, orange and brown.


Using high definition (WUXGA):



The above chart shows how much difference there is on a 1:1 pixel translation colour spread vs a 1:3 pixel translation. However, since the OpenEmulator's output model is very smooth, using high definition does not improve the output on a standard size monitor. Where high definition may become advantageous is when trying to smooth out a digital model or where each pixel becomes large and blocky ie when viewing the image on a large screen. It's something I have not needed as much as I thought I would but it's there now in case I need it.

I'm not a fan of the 1920x1080 / 1080p / Full HD resolution. It doesn't allow for a nice integer scaling of the Apple II display. Therefore, I haven’t spent much time in getting this resolution to work.


Conclusion:

All my equipment is PAL based and the best composite output I have is from a IIc Modulator/Adapter. Hence, I'm not in the best position to be comparing results to actual hardware and fine tuning the results. If you are interested in Apple II colour models, below are a few good links to resource material.

OpenEmulator
https://observablehq.com/@zellyn/apple-ii-ntsc-emulation-openemulator-explainer
https://zellyn.github.io/apple2shader/
https://github.com/gabrieldiego/tg/blob/master/ref/Keith%20Jack%20-%20Video%20Demystified%20-%20A%20Handbook%20for%20the%20Digital%20Engineer%204e.pdf

ii-pix
https://www.youtube.com/watch?v=JpyGDqhcFlA
https://github.com/KrisKennaway/ii-pix

Stephen A. Edwards method
https://www.cs.columbia.edu/~sedwards/papers/edwards2009retrocomputing.pdf

AppleWin - Color (Composite Idealized)
https://lukazi.blogspot.com/2017/03/double-high-resolution-graphics-dhgr.html
https://lukazi.blogspot.com/2015/05/a2-video-streamer-colour.html

Other
https://nerdlypleasures.blogspot.com/2021/10/apple-ii-composite-artifact-color-ntsc.html
https://www.kansasfest.org/wp-content/uploads/2009-ferdinand-video.pdf
https://www.kreativekorp.com/miscpages/a2info/munafo.shtml
https://docs.google.com/spreadsheets/d/1rKR6A_bVniSCtIP_rrv8QLWJdj4h6jEU1jJj0AebWwg/edit#gid=0

Thanks goes to Kris for his help on the ii-pix conversion, Marc for implementing OpenEmulator and Zellyn for making the OpenEmulator code more accessible.

Who knows where this will go? I've been playing around with my own digital and analog models. To date, they have not been as impressive as the models detailed in this blog. To me the A2VGA is more than just an Apple II video card. It's a system that allows me to play around with various Apple II colour models. Now, all I need is more play time. I plan on covering how the A2VGA works and how all this was implemented in a session at the next OzKFest event in late October 2023.

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).

A2VGA - Pico IIe Card

The A2VGA - Pico IIe is an Apple IIe specific VGA card for the budget conscious user. This card like many of the Apple II RGB video cards uses the raw video signals from the Apple IIe auxiliary slot. It's constructed from easy to obtain, through hole and relatively inexpensive components. These include the Pi Pico microcontroller, a level shifter, a diode, several resistors, sockets and some optional buttons. This is a product of my previous video investigations. Since I've had bugger all hobby time in quite a while I’ve only managed to get this knocked out because it’s been a small task. I guess you can say this is picking the low hanging fruit from the possible video cards I could have tackled.

Since the card uses the same signals which are available on the Apple IIc video port, The A2VGA - Pico IIc will be available at a later stage. This will contain the same firmware but will have a different form factor plus a 12V to 5V step down converter.

The card is super simple to build, super simple to use and super simple to update the firmware on. No special tools are needed for updating the firmware. Connect a USB cable from your PC to the Pi Pico and when a new drive pops up, you just copy to it the latest/desired firmware. Done. That's it.

The card can be used by itself if the Apple II only needs to run with 64kB. Extra memory needs to be plugged into the piggyback slot to run more memory hungry software and to use the DHGR video mode. The AIIE 80COL/64K MEMORY EXPANSION card works well as extra memory however, taller memory cards may have issues fitting under the lid. Once the memory card is inserted into the piggyback slot it is difficult to remove. I use a small screwdriver to gently lever the memory card out using the provided PCB holes.

I tested the card's display lag (see a previous post of mine if you are interested in how this is achieved) and on the Samsung SyncMaster 740N monitor I found that it was one frame behind the CRT monitor while on the DELL U2410 monitor it was two frames. I believe most of this delay comes from the monitor itself since the A2VGA does not have a video frame buffer as such. An internal A2 monochrome buffer is updated after every 32 bits that are read from the A2 bitstream. Independently the VGA generation part just processes and spits out a line at a time and performs this as fast as it can.

The card works by using the following video signals:

The required signals:
- 14M : Apple II video clock.
- SEROUT* : Luma part of the video signal ie the monochrome pixel bitstream.
- WNDW* : Start of line being displayed or SYNC* - Start of line at the left border. I provided a logic analyser screen shot showing the difference between WNDW and SYNC in my last video post.

Optional signals that are nice to have.
- GR : Sets up each line to display in colour or monochrome.
- LDPS : Not implemented on this project. Each Apple II display line is 560 pixels long (it does not matter what video mode is being used by the Apple II) however the starting location on the screen changes based on the video mode. For example, the 80 column text mode starts at a different location on the screen compared to 40 column text mode (four pixels of difference). LDPS can be used to align these video modes. Using a typical monitor, you get a black border around the displayed picture so most people will never notice this effect. I used this signal in my video streamer project because the display was in a 560 pixel window, meaning that without this signal I would have resorted to either chopping off one of the modes by 4 pixels or adding an unwanted vertical bar to the left or right side of the picture depending on which mode was selected.

How it works:
The input PIO section of the Pi Pico records the accessory bits (GR, LDPS if needed) and then 560 screen pixels into a 32bit aligned structure for each line. The monochrome A2 buffer needed is just over 14kB. This is a fraction of the 256k Pi Pico RAM available. The VGA generation code runs independently. Each VGA line is pre calculated based on a specific A2 colour model (AppleWin’s Composite Idealized) before being sent to the output PIO section. This section drives the VGA resistor DACs (Digital to Analog Converters) and Sync signals. The A2 display area 560x192 is displayed within the standard 640x480 resolution. The lines are doubled to produce a squarish look. When in scanline mode, every second line is blacked out making this appear as if the monitor contains scanlines. The colour model is a two-stage transformation. First, using a twelve-bit scrolling window, where the middle four bits are translated into four coloured pixels (each coloured pixel being 4bits ie the 16 Apple II colours). Then the second transformation converts each of these coloured pixels into the closest matched Apple II display colour using 16 bits (RGB565).

I’ve implemented the best looking colour model that I have at the moment. I’ve also turned on the scanline effect. I have not used any of the buttons yet. The board can output RGB565 however I got the project working using RGB555 since that was what the example project was configured for. I’m sure it is not going to make much difference, so I 'm not in a rush to fix it. I’ve still to test several options like the resistor values used for the DACs. I’ve used precise resistors ie 500k, 1k 2k, 4k, 8k and 16k however, resistors do not normally come in these values. They are obtainable but I would like to see how much of a difference it would make to the display if standard resistor values were used instead.

I’m looking at making some changes to the next PCB revision. These changes include:
1. Add an option for the VGA socket to be PCB mounted or externally connected via a cable.
2. Fix ribbon cable pinouts. Currently they are very close together making it horrible to wire on the cable.
3. Use 74LVC245 instead of the 4 line MOSFET level shifter. This will allow more signals to be added. I want to add Sync in case someone wants to rewrite my firmware using a different method. If you have any other signals you wish to add (which are available on both the Apple IIe aux slot and the Apple IIc video port) then let me know. I'll consider adding them as well.

Concerns
1. The NTSC Apple IIe aux port is in a different location to a PAL aux port. I don't have a NTSC IIe motherboard to test on. I’m estimating clearances by going of pictures of motherboards.
2. Electrical interference. VGA is analog so you may experience noise from electrical interference, especially if a ribbon cable is going to be used for routing the VGA plug to the rear of the case. I can see slight interference effects on the display when looking for them. This is on one of my monitors while the other monitor looks totally fine. I get a different effect when using the IIe vs using the IIc. For example, I tried to locate a small shimmer that I am seeing when using the Apple IIc. I have tracked this down to being caused by the IIc power supply on the ground line. Not sure what I can do to mitigate this. More testing is needed.

The VGA generation pretty much uses an entire core and one of the PIO modules. The Raspberry Pi SDK VGA generation code could be replaced by an alternative, much simpler model (there are a few of these around) if more processing power is required. The second PIO is partially used up with importing the A2 video stream. Currently, the second core is only being used by one interrupt which occurs at the end of each line (handles the A2 horizontal and vertical sync processing).

The Pi Pico runs much slower than then Raspberry Pi Zero so I found that the colour model needed more optimisation to make it work. I'm happy that I was able to get it running without having to overclock the processor. To obtain better colour models (where higher screen resolutions are required and larger colour ranges ie RGB888) I suspect something more powerful than Pi Pico is needed. If efficiency was of no concern and money no object then we could throw a 3GHz processor at the problem and have something running that looked like OpenEmulator. However, I believe that there is a middle ground where FPGAs or Pi Zero like devices could be used to generate great colour models.



I've been tesing on the IIc for the most part because it is much easier to access the card.

Project files will be provided once the final card design is worked out, a schematic generated and the code cleaned up.

Here is a video of the cards output. https://docs.google.com/open?id=1ZbibOvvSFw8lRugwCkTYdhJfkaTdboKr


Update: 6th June, 2023.


Display of 80 Column Text. Note: scan line emulation is turned on.


Colour Killer testing, Mixed Mode (monochrome and colour) testing - VIDD7 mask, Power regulator testing.

Apple IIGS to RGB Adapter

On my hobby desk I usually keep my 9inch Sony monitor sitting around as it does not take up a lot of room. It supports composite as well as RGB so I can quickly connect up any of my Apple II variants. For the IIGS I've been using a bogey custom cable that I knocked up a long time ago. It's always been a pain for the times when I need the cable to be just a fraction longer. So it's been on my to do list for a while to put together an adapter so that I can use any of my various length component RGB cables. I recently put in to get a bunch of PCB boards made up and took the opportunity to include a PCB for a IIGS video to RGB adapter. I've allowed for a spot to attach an extra RCA socket in case I ever have a monitor which requires an external Sync signal.