Hehe, nice try!
However the PB3/AD725 clocking incurs no overhead to the execution speed as this pin automatically toggles when a hardware timer attains a target value (in this case "1", or each other clock).
Yeah, I thought something like that might be the case. That's too bad
it was a nice idea...
I've already been messing with SCART as a hardware interface. As you may know, SCART is a multi-purpose interface that carries practically all signals. Theoretically it can carry RGB, composite and S-video, but only one at a time and it depends on the TV which ones it accepts. I've wired and used it with both composite and S-video signals without any problems, but it seems my TV refuses to accept RGB with any timings other than PAL. This may well be because the CSYNC signal is optional in SCART RGB. Many consoles that support SCART RGB output (PAL SNES and PAL Gamecube for sure) merely send +12V across it at all times. Cheaper (older) TVs may not read the SYNC at all in RGB mode and simply assume PAL timing.
I'll be testing it on a newer TV shortly and if I get that working, I'll report back my findings in another post. I was thinking of drawing up a schematic that wires a SCART connector for all 3 signals with a switch to decide which one you want. Stay tuned for more on that
However, if you're suggesting I try to get an RGB signal across the SCART directly and eliminate the AD725 (and thus the need to run at exactly twice the NTSC clock), that might be a bit trickier (though not impossible). I'd need to find a usable speed for the MCU that can generate the output at PAL timing. As stated above, a SYNC signal isn't needed at all when using SCART RGB and some TVs may not even support it.
That being said, I don't think it'd be wise to run the Uzebox at a significantly reduced speed. The PAL color burst is 4.43361875 MHz, opposed to the NTSC one at 3.579545 MHz. Running at roughly the same speed (26.6017125 MHz for instance) would only give you 6 cycles per color burst instead of 8. In order to get 8 cycles (like with the NTSC one), you'd need to run at 35.46895 MHz and then we're back to the original timing problem.
Would it be doable to run the Uzebox with 6 cycles per burst instead of 8? Would it require significant rewrites? You might even get it to output composite PAL across the AD725 if you use a secondary stand-alone clock at 17.734475 MHz.