VDCdigitizer discussion

[c0pperdragon]

I made this thread specifically to discuss and coordinate the development of the VDCdigitizer (for C128's second graphics chip).

[c0pperdragon]

One of my greatest problems in developing the VDCdigitizer is the fact that I don't have a C128. As working machines are pretty hard to find and also very expensive, I really would need some help here. If someone with an oscilloscope is willing to probe some signals on the C128, please let me know here.

[c0pperdragon]

Lumacode for the 80-columns mode: With a 16MHz pixel clock and 16 colors, it first seems the VDC is outside the reach of a lumacode implementation. But as it turns out, it has some serious restrictions that can be exploited to get the data transfer rate down to 16 million lumacode samples per second (32Mbit/s). Like the ZX Spectrum the VDC uses attribute cells to specify one foreground and one background color for every 8 pixels. With 2x4 bit (16 colors to chose from) and 8 bit to select on of these colors per pixel, we need a total of 16 bits for every 8 pixels. There are some complications from the fact that the VDC allows horizontal per-pixel scrolling, but with a bit of extra information in the blanking region (like for the attenuation bits of the PPUdigitizer) , this should be possible.

[jdryyz]

Sounds great! Perhaps you can have a nice bundle for those who wish to purchase both the VICII and VDCDizer.

[c0pperdragon]

I have thought more about the details on lumacode for the VDC and this is the plan now: The VDCdigitizer will just use the 6 output pins (R, G, B, I, HS, VS) and the clock to construct the lumacode signal. Because it needs to have some knowledge of the data before doing the conversion, the output will be delayed by 1 line. This should make no real difference for upscaling as the added lag would be just 64us. Because basically all aspects of the video signal generation are under software control (line frequency, frame rate, sync pulses and much more), the lumacode format needs to be extremely flexible.

To keep the possibility to plug the lumacode into a composite TV and get some sensible (but black&white) picture form it, the individual bits of each lumacode sample are considered to belong to one of two layers. The most significant bit (which contributes most to the luminance) is taken to specify the bitmap value for each pixel and the least significant bit independently belongs to a bit-stream to specifiy colors.

This second bitstream is the more complex affair and I will specify it as such: During the bulk of the visible screen area, every block of 8 bits will specify a color A and color B to be used to select the colors for the underlying bitmap. Encoding of colors will follow the CGA standard (with high bits comming first). To allow for variances in color cell alignment and screen positioning, the visible area will be preceeded by a 16-bit long descriptor block (again only the lower bits of each lumacode sample are used for this). The first bit is '1' after only '0's on the current line to allow alignment of the decoder. The next 7 bits specify the number of 8-pixel blocks that will follow. The next 4 bits specify the number of pixels at the start of the very first block where color A is forced to black. The next 4 bits specify the number at the end of the last block where color A is foced to black. @IanSB What do you think if this encoding? Can the lumacode software be made to handle such a thing?

By the way: To keep the thing simple, there will be no integration for a pass-through from the VICIIdizer. The VDCdigitizer will just have the same direct output. It is then up to the user what to do with this signal. Using two RGBtoHDMIs, swapping plugs, using a switchbox either internally or externally, or even coming up with their own auto-switching circuitry.

[c0pperdragon]

Bad news: I did read up more on the capabilities of the VDC, and there are actually some ways to break out of the 8-pixel color cell scheme. There is the possibility to add additional spaces between characters or to repeat some pixels, so color cells may get wider. This makes it pretty much unfeasable to squeeze all possibilities into a comprehensive lumacode signal given its restrictions. So the VDCdigitizer is dead. Sorry.

[Purplegopher]

Thanks for investigating. I (personally) don't think, this is too much of an issue, having two RGBtoHDMI boards isn't too bad (I think).