Reenigne blog

The original IBM Color Graphics Adapter has a curious quirk - it won't by default display colour on the composite output in 80-column text mode. By looking at the schematics, I've figured out why this is, and what the CGA's designers could have done differently to avoid this bug. The following diagram illustrates the structure of the various horizontal and vertical sync pulses, overscan and visible areas in the CGA.

There are two horizontal sync pulses - there's the one generated by the 6845 (the 160-pixel wide red/grey/yellow band in the diagram) and there's the one output to the monitor (the 64-pixel wide grey band within it). The CGA takes the 6845's hsync pulse and puts it through various flip flops to generate the output hsync pulse (delayed by 2 LCLKs and with a width of 4 LCLKs) and also the color burst pulse (in yellow, delayed by 7 LCLKs and with a width of 2 LCLKs).

The 6845 can generate an hsync pulse anywhere from 1 to 16 clock ticks in width. The IBM's BIOS sets it up at 10 ticks (as shown in the diagram). However, in 80-column text mode those ticks are only half as wide, so only extend 3/4 of the way through the output hsync pulse. The 6845's hsync pulse ends before the color burst pulse gets a chance to start, so it never happens and the display will show a monochrome image.

By changing the overscan color to brown, one can create one's own color burst signal at the right point in the signal, and this was the usual way of working around the problem (possibly the only way that works reliably)

By changing the 6845's pulse width to the maximum of 16, one could generate the first half of the color burst pulse (I think) and some monitors might recognize this as a color burst.

If the CGA's designers had started the output hsync pulse at the beginning of the 6845's hsync pulse (or delayed by only 1 LCLK instead of 2) then using the maximum pulse width would have been sufficient to generate the correct color burst. I guess they were just trying to center the output hsync pulse and the color burst within the 6845 pulse, without thinking of the high-res case.

The diagram also shows why interlaced mode doesn't work on the CGA - the output vertical sync pulse is generated in a similar way to the output horizontal sync pulse, only it's 3 lines instead of 4 LCLKs. It always starts at the beginning of an output hsync pulse, so a field can't start halfway through a scanline.

Here is a little known trick that a genuine IBM Color Graphics Adapter can play, that I noticed when looking at its schematic recently. There are two ports (0x3db and 0x3dc) which are related to the light pen. A read to or write from 0x3db clears the light pen strobe (which you need to do after reading the light pen position so that you'll be able to read a different position next time). A read to or write from 0x3dc sets the light pen strobe - what's the point of that? One possibility might be to implement a light pen that signals the computer in a different way (via an interrupt) rather than being connected directly to the CGA card. That wouldn't work very well though - the interrupt latency of the original IBM PCs was extremely high.

Another possibility is to allow the programmer to directly find the position of the beam at any moment, to an accuracy of 2 scanlines (in graphics modes) and one character width (1/40th of the visible screen width in graphics modes and 40-column text modes, 1/80th of the visible screen width in 80-column text modes). Read from 0x3db and 0x3dc and then read the light pen CRTC registers to find out where the beam was when you read from 0x3dc. This technique is so obscure it probably won't work on non-IBM CGA cards, so its usefulness is rather limited. Might be useful for an oldskool demo, though. I'll be sure to implement this technique when I finally get around to making my extremely accurate PC emulator.

For my TV emulation, I wanted to render scanlines nicely and at any resolution. xanalogtv does vertical rescaling by duplicating rows of pixels, which unfortunately makes some scanlines appear wider than others. Blargg's NTSC filters don't do any vertical rescaling at all.

The first thing I tried was a sinc interpolation filter with the kernel scaled such that the scanline only covered 70% of the pixels vertically (essentially modelling the scanlines as long thin rectangles). This worked great except that it was far too slow because of the sinc function's infinite extent (I was doing a multiplication for each combination of horizontal position, vertical position and scanline). So I windowed the kernel with a Lanczos window. I got annoying aliasing effects using less than 3 lobes. With 3 lobes it was still too slow because each pixel was a weighted sum of 3-4 separate scanlines. Also, because of the negative lobes I needed extra headroom which meant I either had to reduce my colour resolution or use more than 8 bits per sample (which would also be slow).

The next thing I tried was a Gaussian kernel. This has several nice features:

1. The Fourier Transform of a Gaussian is also a Gaussian, which is also a better approximation of a scanline than a rectangle (the focussing of the electron beam isn't perfect, so to a first approximation their distribution around the beam center is normal).
2. It dies off much more quickly than the sinc function.

The Gaussian kernel also gave a good image, so I kept it.

The next thing I wanted to do was improve the speed. I still had several scanlines contributing to every pixel. However, that doesn't make much physical sense - the scanlines don't really overlap (in fact there is a small gap between them) so I figured I should be able to get away with only using the highest coefficient that applies to each pixel. I tried this and it worked beautifully - no difference in the image at large sizes and it speed the program up by a factor of several. The downside was at small sizes - the image was too dark. This is because the filter was set up so that each pixel would be the average of several scanlines, but if only one scanline is contributing then then the brightness is 1/several. To fix this I just divided all the coefficients by the largest. There's no mathematical justification for this, but it looks fine (apart from the fact that some of the scanlines don't contribute to the picture at all).

If each pixel is only in one scanline, lots more optimizations are possible - for example, one can generate the image progressively, a scanline at a time, which helps keep data in the caches.

Finally, I still needed it to be faster so I moved all the rescaling (vertical and horizontal) to the GPU. I came up with a devishly clever hack to implement the same scanline algorithm on the GPU. No shader is needed - it can be done just using textures and alpha blending. There are two passes - the first draws the actual video data. The second alpha-blends a dark texture over the top for the scanlines. This texture is 1 texel wide and as many texels high as there are pixels vertically.

One other complication is that I wanted the video data texture to be linearly interpolated horizontally and nearest-neighbour interpolated vertically. This was done by drawing this texture on a geometry consisting of a number of horizontal stripes, each of which has the same v-texture-coordinate at its top as at its bottom.