Need help debugging NTSC video driver

ericball

I'm hoping a another set of eyes will find the bug(s) in my code.

This is a brand new video driver which is radically different than anything based on TV.spin.

1. Sprite based - not tiles.· The driver works from a HUB-RAM sprite table (address of 8x8 byte/pixel graphics, xpos, ypos).
2. Graphics are copied to a COG-RAM based 240 pixel LineRAM, then the LineRAM is output using the Propeller video generator.
3. 2-5 cogs with interleaved execution (while cog[noparse][[/noparse]0] is generating output, cog[noparse][[/noparse]1]..cog[noparse][[/noparse]n] are populating LineRAM)
4. Artifact based color for (theoretically) a much larger color gamut than the native video generator.

So, is anyone out there willing to take up the challenge?


Post Edited (ericball) : 7/7/2007 1:53:32 AM GMT

RinksCustoms

I'll be following this thread, looks interesting

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! The average PC while browsing the internet typically uses less than 30% of it's potential, why not donate a portion of the rest for cancer resaerch?

ericball

Some observations by potatohead have caught one big bug - I'm not waiting for the PLL to settle so the first WAITVID delay is going to be incorrect.· I'm considering a couple of options:
1. Put a second WAITCNT after the CTRA/FRQA to let the PLL settle
2. Move the CTRA/FRQA before the first WAITCNT
3. #2 but add a MOV PHSA, #0 after the WAITCNT
The question is which option will yeild the smallest phase difference between cogs.
The code for #1 is easy:

:cont WAITCNT count2, l910     ' sync to other cogs
      MOV     CTRA, ictra      ' initialize registers
      MOV     FRQA, N2_PLLAFRQ ' start the counters!
      WAITCNT count2, #0       ' wait for PLL to settle

potatohead

When working with the high-color driver, Jasper_M pointed out the left overscan must be an even multiple of the pixel clock, or the phase stuff ends up happening. I've tried a second WAITCNT, and had no luck. Don't know about the other options. IMHO, the MOV PHSA has potential. For what I was trying to do, it ended up being a lot easier to just match up the overscans. In this context, it might be a solid option. Perhaps set it at a known place every scan line?

potatohead

For those looking this over, the best display so far is NUMCOGS = 3. On newer TVs it will sync well enough to display objects.

This change will cause the COGS to sync up right away:

count2 := 10000 + 1000 * N2_NUMCOGS ' synchronization CNT