The code I wrote is very simple – I am only displaying a few large “pixels” per line (maybe 7 or 8, I’d have to look back at the code).

I can’t remember what the limit for my program was, but it wasn’t very good because I didn’t optimize the code very much. It was not very impressive, maybe a dozen pixels at most.

The ~300 pixel limit you refer to is based on clock speeds alone and is not easily achievable because many clock cycles are wasted with housekeeping tasks. Simple things like pointer or loop counter increments eat up precious cycles. Take a look at the code and start counting cycles – you’ll see what I mean (and maybe come up with some improvements!)

I don’t think C is well suited for generating video because of the timing requirements. You could write the higher level functions in C and then write an interrupt handler in assembly that actually toggles the IO lines. This is what is done on some more sophisticated projects – take a look at the Fuzebox. It uses an AVR but you might get some ideas for the PIC.

What kind of resolution can you get with this? For example if the total time of a horizontal line (of 262) is 62.us, how fast can you change the output?

I suppose in theory with a 20Mhz clock (.2us/inst), the pic could change the dac 325 times during the 62us… or with a 64mhz clock you could have 900 transitions. Obviously though, there is no way your eye could see “pixels” like this, so what in practice can be the resolution?

Also, if you did run the pic at 64mhz, could the code be done in ‘c’?