EricBall's Tech Projects - cog coding

[RSS Bot]

I've been doing a bunch of think-coding over on potatohead's Blog trying to work though making Propeller code capable of generating a 240x240 resolution sprite display.

 

For those not familiar with the Propeller, it's an 8-way SMP processor in a very low cost ($13 each) package. Each processor (or cog) has 496x32 bits of RAM which functions as registers and code & data storage (self modifying code is almost required), with 32K of shared RAM accessed in round-robin fashion (very deterministic once it gets going). Code is either written in a high-level interpretted language called Spin, or in native cog assembly. Guess which one I'm using...

 

Each cog also has a video generator, which leads to some interesting possibilities. The concept I'm working on is to use 240 entries of cog RAM as line RAM which gets written out in a very tight loop. Then once the line is displayed, the cog fetches sprite graphics for the next line while another cog is busy displaying the current line. The big advantage is each pixel is stored as a long and has the capability of covering the entire NTSC color gamut. The downside is I'm discovering how few sprites the system can actually display.

 

The last straw was clearing the line RAM:

CODELineRAM EQU $100

D1 LONG 0000_0000_0000_000000001_000000000

Black LONG $01010101 * 7.5IRE

 

MOV count1, #240

MOVD ZeroLR, #LineRAM

ZeroLR MOV LineRAM, Black

ADD ZeroLR, D1

DJNZ count1, #ZeroLR

This simple bit of code chews up 2892 cycles, or over half of the time per line. Ugh!

 

The solution is obvious - use 3 cogs for video. That doubles the number of cycles available for the write Line RAM routines.

 

I'm hoping is also will even out the overall output timing. The plan is for the output routine to finish after writing a set of synch pulse pixels. This should set the output bits to 0 so it won't interfere with the output of active cog. But I'm guessing the video generator is still running, even though the cog isn't feeding it any new pixel data. Which means when the code goes back to writing, it's going to resynch back to the video generator clock. So because the pixel clock is 4.77MHz, that means there will be 303 pixels per line, which is 1/3 of a pixel short versus the spec. (Not a huge crime, but it's better to be in spec if possible.)

 

But since I'm using 3 cogs for video, then I can accumulate that extra 1/3 pixel across the 3 lines sequence. So the cog generates 303 pixels of output, and then spends 607 pixels of time generating the next line of output. And we're back in spec.

 

I'm also hoping I can figure out how to synch the 3 cogs together so they are all starting together. Then I can use the round-robin access delay to start each cog 1/3 pixel from each other.

 

 

http://www.atariage.com/forums/index.php?a...;showentry=3347