OK so let's calculate a bit - correct me if I am wrong.

With direct generation of video in mcu, the mcu is occupied during the active display. For NTSC, there are 525 scan lines per field, so assuming you double the lines (don't interlace), active field is 2*192/525 = cca 73% in the vertical scale; assuming square pixels it means 0.73*0.73=cca 53% of the whole frame (it also means some displayed border, but that was the standard of those fun-8-bitters anyway). Of course the blank/sync generation takes up some time, too, but I think, overally we some 1/3 of the raw performance is still left.

This time might be enough for most of the applications, as for the 1-clocker DS89C4x0 my "mini-benchmark" gives a cca 22x performance enhancement compared to 12MHz plain vanilla 8051, so after the video-cut it has still has the power equivalent of a 30MHz 6-clocker or so (the SiLabs gave me extra 4x, but that does not take into account the jump cache misses, so it's probably slightly less).

This is only the raw power consideration. When it comes to "response", the main restriction is that during the active line the mcu cannot do anything else. This means that a minimum "tick" for any timing is around 64us; assuming, that only the most necessary processing will be performed during the rather short horizontal blanking period; and most of the computing will remain for the vertical blanking period occuring in a 60Hz pace. This also imposes limits for UART reception, but that seems to be quite OK, as the character time for 115200 bauds (8N1) is 87us so 2 characters should not occur during one horizontal line.
However, I2C/SPI slave is more-less excluded even if it would have hardware support (this is valid also for the faster SiLabs or anything else).

As the horizontal scan duration is around 64us, the square pixel and the 73% active field and 256 horizontal pixels give me some 5.5MHz pixel clock, which approximately can be generated as 1/6 of the maximum 33MHz (rotation takes 1 cycle and bit move takes 2, so 3 cycles are left for byte fetch etc. per pixel).

As for color, it is not impossible to produce some 2-bit, 4-bit or even 8-bit output per pixel at the given rate assuming fast external memory. However, this comes at a cost - not only the memory itself, but also the handling of it takes more time - 2, 4, 8 times (although some algorithms might come out faster for the 8-bit version...), and also the addressing space of the '51 is "eaten up"... (from 6kB for the monochrome version up to 48kB for the 8-bit "full color" :-) ).

All in all, I think this is doable and might work quite well; although later we migh find out that a hardware video would be better. And, this is still NTSC (ok I think PAL is not substantially differen); but for VGA, the horizontal scan rate doubles so that would be one order of magnitude harder to achieve.. maybe with the SiLabs, with some considerations?

Jan Waclawek