Some good news on the video front: by modifying the pixel clock and playing with my LCD monitor calibration, video quality is dramatically improved. The pixel stretching stemming from my non-standard 512 pixel horizontal resolution is gone, and even the light/dark vertical noise bands are almost completely gone. Interestingly, it seems they both were manifestations of the same basic problem.

A standard VGA signal at 640×480 resolution has 640 pixels visible horizontally, but there are also an extra 160 “phantom pixels” not drawn on each line, which constitute the horizontal blanking interval. The duration of each line is therefore divided into 800 (640 + 160) equal time intervals of just under 40 ns each, and the continuously varying VGA voltage is sampled once during each of the first 640 intervals to determine the pixel color. In fact, the exact interval duration is 1 / 25.175MHz which is about 39.72 ns.

My problem was that I tried to generate a 512×480 resolution image (using a 20MHz pixel clock), which isn’t a standard VGA resolution. On a CRT monitor I think this would have worked fine: each line would be a continuously varying analog voltage, without any specific number of pixels horizontally. On an LCD monitor it mostly works too, as long as you’re not too picky about image quality, but I’m picky. The LCD monitor was sampling the VGA voltage every 39.62 ns, but I was changing that voltage every 50 ns (1 / 20MHz). So every few pixels, an output pixel’s VGA voltage would get sampled twice, and appear as two pixels on the LCD, creating this chunky stretching effect. And because the voltage sampling was out of sync with the voltage changes, I think the LCD monitor often “saw” voltage changes causes by transient switching noise, leading to the light/dark vertical bands.

I swapped my 20MHz pixel clock for a 25.175MHz one, reprogrammed the GAL that calculates the horizontal sync timing, and bingo! Text became nice and crisp, and the light/dark bands were much less noticeable. With a few minutes of fine-tuning the monitor calibration, I was able to nearly eliminate the bands entirely. So now the video was almost perfect.

I say almost perfect, because I’m still only generating 512 pixels, but now I’m using a 640 pixel clock. I fill up the other 128 pixels with black.  In the first attempt, this meant that the left 80% of the screen was filled with my image, and the right 20% was empty. It looked pretty dumb. My solution was to simply center the image, so now there’s a black column down the left and right 10% of the screen, with the image occupying the center 80%. It still looks a bit odd, but it’s not too bad. The improvement in overall image quality is definitely worth it.

One bonus side-effect of switching to a 640 pixel clock is that I now have square pixels. 640/480 = 4:3 which is the standard aspect ratio for regular (non-widescreen) monitors, so it works out that each pixel is perfectly square. That may not seem to matter much, but non-square pixels are a pain to work with. They make images look distorted, or geometric shapes like circles appear like ovals instead. With square pixels now possible, the main rationale for the 512×400 and 512×200 video modes was eliminated. (I originally included it because it was closer to 4:3 than 512×480 was.)  Those modes never worked quite right anyway– the monitor detected them as 720×400, leading to even more severe examples of the out-of-sync sampling problem I had earlier, with no solution other than to use a 720 pixel clock. I just eliminated those modes completely, and turned them into configuration options of the base 640×480 mode instead.

At the end of this all, I’m now generating a standard 640×480 VGA image, but only the center 512×480 is filled. The image can be configured one of four ways:

1. 512×480, with one common color depth / text setting
2. 508×480, with a separate color depth / text setting for every line
3. 512×240, same as #1, but every odd line is a copy of the previous line, and greater color depths are possible
4. 508×240, same as #2, but every odd line is a copy of the previous line, and greater color depths are possible

As soon as I can figure out what’s causing BMOW to sporadically freeze-up, I’ll put together some more interesting examples of mixed text and graphics, and post the screenshots up here.