Develop dual-Propeller "display" routine about jcap HOT 7 CLOSED

Satisfied by commit afe2b99

from jcap.

Just an observation. You issue 4 pixels with each rdlong/waitvid pair. The worst case time for this sequence is 30 cycles (23+7). But at 104MHz (and 25.175MHz pixel clock) that's 7.26 pixels you have to deliver.

from jcap.

I'm not exactly following. I'm rendering 4 pixels per waitvid but they're upscaled via vscl to 8 pixels. I've recalculated my frqa with 104 MHz and replaced the old value with the new.

I've also analyzed the video signal with an oscilloscope and the timings are almost nanosecond perfect.

30 cycles might be "worst case", but after the first rdlong, each following rdlong will only stall for 1 cycles (8 cycles to execute rdlong, 7 cycles to execute waitvid, leaving 1 cycle before the next hub access window).

Is there something I'm missing?

from jcap.

Sorry, my mistake. I was under the assumption that you go for full 640. With 320 that's perfectly OK. Somehow I missed the vscl setup. That said, 320 at 80MHz are possible.

from jcap.

Oh no problem haha, thanks for the oversight!

from jcap.

I'm getting old :)

Anyway, I'm glad you keep going (was a bit quiet over the holidays).

from jcap.

Yeah I was in limbo with the way forward on graphics. I was opposed to a dual-Propeller setup at first because I wasn't certain of its necessity, then I was opposed to running the Prop at 104 MHz because it seemed like a workaround instead of addressing directly the issue of reading and displaying longs back-to-back in time. But at the end of the day, two Props give me an outstanding amount of processing power and time to generate all of the graphics and contituent effects I want, and 104 MHz lets my display code be a lot simpler and gives me even more time to generate graphics. Parallax has tested and approved that frequency, and so far my own testing has confirmed its stability. So now that I've gotten over myself I can push forward haha.

from jcap.