I got an interesting (if not to be taken seriously) question on my Mastodon feed today: 8K VDC-II when?

For now, let's focus exclusively on the CRTC capabilities, and completely ignore the logistics of getting pixels onto the screen.  The latter implementation details will necessarily have to change regardless, so I take it as a given that the VDC-II as I'm currently envisioning it cannot support anything greater than a 1K display.

So, let's look at what the current VDC-II's CRTC registers can do, in regards to 8K, 4K, 2K, and 1K displays, respectively.  (By comparison, a 640x480 VGA display is 0.8K.)

The Original Question: 8K VDC-II When?

I'm pretty sure the CRTC interface of the VDC-II will need to be changed to support an 8K display.  An 8K display resolution seems to be 7680x4320, at least that's what Wikipedia tells me.  The VDC-II CRTC supports a maximum character cell width of 16 pixels; 7680/16=480, which is too wide for the 8-bit horizontal displayed register to hold on its own.  Thus, the VDC will need either adjunct registers or an all-new 16-bit interface to cope with the additional bits needed for horizontal timing.

So, at present, the VDC-II is not able to handle 8K displays.  Sorry.  It probably can be made to support these large resolutions with relative ease; but, it'll require more investment in the hardware description, an FPGA fast enough to cope with the insane dot clock speeds, and testing with compatible display hardware.

What about 4K Displays?

It's so close!  While the vertical resolution is achievable with relative ease, the horizontal direction proves to fall just short of the minimum required functionality.

A typical resolution for a 4K display with consumer hardware is 3840x2160, so I'll use that for my calculations.  3840 can be divided into 256 characters at 15 pixels each.  The VDC-II, as I've currently defined it, does not support 256 characters; it only supports 255.  However, a revision can be made to the hardware description where plugging a 0 into the horizontal displayed register (R1) could be interpreted as meaning 256 characters.  It would require redesigning the display-enable circuit to be a bit more clever than "assert display enable as long as the display counter is non-zero."

The bigger problem is the horizontal total register (R0), which is used for HSYNC timing pulse generation.  This requires more than 256 characters; if you think about it, the 256 characters discussed above are those which are the visible part of the display.  So, unfortunately on this basis alone, the VDC-II cannot support a 4K display.

Things are a bit better in the vertical dimension, however.  At 2160 pixels, we can reasonably fit 216 10-pixel tall characters on the screen, 135 16-pixel tall characters, or 108 20-pixel tall characters.  All of these configurations are well within the realm of possibility for the current VDC-II design.

What about 2K, then?

2K video is a different matter.  According to Wikipedia, the largest recognized 2K resolution is 2048x1080.  From the point of view of the VDC-II's current CRTC implementation, this resolution is a cake walk.

With 16-pixel wide characters, the horizontal displayed register would be set to 128, which (if you follow the rule of thumb that active video takes 75% of the horizontal display time) means the horizontal total register would probably be somewhere in the vicinity of 170.  These are all easily within the range of the 8-bit character counters as currently found on the VDC-II.

Similarly, in the vertical dimension, we're looking at a vertical displayed setting of 135 (for an 8px tall font), 90 (for a 12px tall font), or 67 (for a 16px tall font).  Note that the CRTC supports up to 32px tall fonts.

What Else is Needed?

One problem with 2K displays and higher is the need for 16-pixel wide fonts.  Commodore's VDC only supported 8-pixel wide font data.  I wasn't planning on supporting double-width fonts until I had a real need for them, but it is (as can be seen above) a pretty obvious extension that can be made to a future revision of the VDC-II core.

Obviously, with increased resolution comes the need for increased numbers of bits to hold the required numbers.  Horizontal total and displayed registers are 8-bits wide presently.  To support 8K, they'll need widening to 10- and 9-bits, respectively.  It's possible similar expansion will be needed for the vertical direction as well.

It's unknown how wide the sync widths (in either axis) are for these video modes, so it's conceivable we'll need to add more bits to hold that information as well.

Finally, you'll need enough video memory to support your preferred display mode.  Assuming a 16x16 pixel font for an 8K display, character mode screens will take up 259.2 kilobytes just to hold the character and attribute data!  Contrast that with the VDC's original memory compliment of 16KiB (64KiB possible).  Moreover, the font data alone will need to be 16KiB in size for 8- to 16-pixel tall fonts, and 32KiB for anything bigger.

Conclusion

Is it technically feasible that a VDC-II can be synthesized to support an 2K, 4K, or 8K display?  Yes!  These are not insoluble problems, and perhaps surprisingly, very little resources are required to pull it off.  The biggest concern will be in how the VDC-II fetches from memory, how the advanced features are exposed in the CPU-visible register set, and in supporting the breakneck speeds required for these high resolutions.

But, will I be the one to produce a VDC-II that can support an 8K movie theater display?  Almost certainly not.  Sorry!