I've been out of action for a few days. Now I'm catching up with work and opening all the packages that came while I was distracted. Lots of fun components. I received a reel of digital video ICs and protection circuitry for them. This makes it very easy to have digital video out from the video chip. I do think it is important to support a 'modern' connection method for basic IO like keyboards and monitors. TTL RGB required a special monitor or an expensive or blurry upscaling device. I'd prefer to handle that upscaling in the digital domain. With 1080 or any of the commonly supported resolutions modern TVs display and with progressive scan.... Modern TVs and monitors can display down to 24P without any flicker and this hugely unloads the video IC's pixel clock compared to 56 or 60Hz frame rates. A SVGA or XGA resolution in 24P has 40% the pixel rate. This allows an order of magnitude increase in color depth at any given resolution. The digital video IC also allows pixel doubling and tripling so eg: 1024x768 can be a parent resolution to 512x384, 512x256, etc. Almost any TV or monitor with an HDMI/DVI input should support VGA 640x480, SVGA 800x600, DVGA 960x640, XGA 1024x768, and their 90 degree rotated equivalents.
One of the cool things about such a flexible video chip is the ability to use odd resolutions when it suits. 160x120 in 65,536 colors? Done! 1024x1024 in monochrome or 16 colors? Done!
Two people have asked me now "why not just use an RP2040 for digital video?" The Rp2040 is very capable of outputting low color VGA or hicolor DVI. With the VGA option, beyond single RGB per pixel, the available GPIO isn't sufficient to support very high resolutions in a flat memory mapped model. The device would have to be accessed through a register port, which puts a lot of requirements on the video driver. It not only has to maintain a shadow bitmap anyway, but also has to registerize the content for transfer to the RP2040. For reads there is no penalty, but for writes this imposes a doubling of write time. This becomes really apparent when EG: setting a whole screen to one color.
I further explored using a transparent cache on the CPU to reduce penalty for memory accesses. It seems not realistic, and not that helpful.
I was also asked about putting the CPU on a daughter card, and maybe having more than one CPU slot. The person is, like me, a RiscPC owner. I think this would be a wonderful place to end up. I think for getting started it's better to have simpler design goals. I am definitely open to this later on, though. Especially if asymmetric multiprocessing can be implemented, eg: a 68060 and a DX2/66 or StrongARM or etc.