switching off video generation - timing

MagIO2

Has someone experience with switching off the video generation? Does video generation stop immediately or will it shift out the missing bits of a previous waitvid?

Eg.

... ' init ctra and vscl

mov vcfg, # %0_10_1_0_1_000_00000000000_001_0_00001111··· ' I know this does not work with an immediate, it's only to show what I mean
waitvid color, pixels
mov vcfg, # %0_00_1_0_1_000_00000000000_001_0_00001111



Post Edited (MagIO2) : 4/29/2009 11:45:06 AM GMT

kuroneko

Disabling ctra will almost certainly stop all video output for that cog.

As for vcfg, the data sheet for %00 says Disabled, no video generated, which could mean anything really [noparse]:)[/noparse] Personally I don't think that the pixel register is emptied before signal generation is stopped. To be sure you could link some free counters to the video output(s) and simply record any pulse after you switch off. Most of the missing or incorrect info from the data sheets has been gained or corrected by just measuring it (e.g. minimal delay for waitp?? and waitcnt is 6 cycles, not 5).

ericball

movi vcfg, #0 will stop the vscl counters (I tested this recently because I was curious as well).



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114

MagIO2

That's why I asked ... now I don't have the work ;o)

Thanks a lot.

Even if the news itself is no good news.

Phil Pilgrim (PhiPi)

Here is a thread that might help.

-Phil

ericball

Yeah, since VSCL is zero'd (along with the other registers) on COGINIT the first WAITVID has to wait for 4096 PLLA cycles before the pixel/frame counters are reloaded from the current VSCL value, the pixels & colors are loaded and execution continues. (On the plus side, that's enough cycles for the PLL to stabilize.)

A few more gotchas I've discovered so far:
1. The pixel counter doesn't automatically reset when the frame counter expires. Avoid problems by making PixelClocks an even divisor of FrameClocks. (Remember the last pixel will repeat indefinitely, so PixelClocks=1 is fine for constant output.)
2. If the frame counter expires before WAITVID the pixel & color registers will be loaded with random data.
3. Be very careful with WAITVID timing (especially mixing WAITVID and hub access). Even assuming worst case hub timing (22 cycles), I would get glitches assuming WAITVID took 6 cycles, while 7 cycles was 100% stable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114