n00b question: hdmi spiral demo works on cogs 0 & 1, but not on any others...?
andrewmcv
Posts: 7
Hi all,
Got the HDMI example working using flexprop to run the HDMI PASM example. Wired a 1k resistor between the 5v lines on the digital video out connector, now have a lovely looking color spiral at 960x540 resolution over HDMI. Very impressive, particularly the conversion from rect to polar. Am about to try my hand at a tile driver, rather than using up 300k of RAM.
My newbie question is: if i start the hdmi feeding code on cog 1 (pgm_hdmi), and the spiral bitmap code on cog 0 (pgm_bmap), it works beautifully. However, if i start the hdmi code on cog 5, say, and the bitmap code on cog 4, i get the top 20% of the display either blank or corrupted. If I reverse the order of cog 0 & cog 1, i get just a static spiral with some corrupt pixels.
Why would this be the case? Are the bandwidth limitations on different cogs, or am i just doing something silly? e.g. If I set the cogs to 5 & 4, what does cog 0 (running the bootstrap code i guess) do? Does it drop down directly into the first label (pgm_hdmi), meaning cogs 5 and 0 are now trying to write out to hdmi?
Am a bit confused, anything obvious?
Andrew
Comments
ah, i've partially solved my own problem. if i put a loop at the end, i can run on any cogs in any order. e.g.
coginit #4,##@pgm_hdmi 'launch HDMI
coginit #5,##@pgm_bmap 'launch bitmap cog
.loop
jmp #.loop
However, i still can't get it working on cogs 0 for hdmi and cog 1 for bmap, and i have no idea why. I get a slightly corrupted spiral that stays static.
e.g. this doesn't work, but reversing it to cogs 1 and 0 does:
coginit #0,##@pgm_hdmi 'launch HDMI - doesn't work
coginit #1,##@pgm_bmap 'launch bitmap cog
.loop
jmp #.loop
Any ideas?
Andrew
Change the order as the cog doing the coginit is cog 0, so if you init cog0 last it'll be fine.
coginit #1,##@pgm_bmap 'launch bitmap cog
coginit #0,##@pgm_hdmi 'launch HDMI - doesn't work
Yes. You clobbered cog 0 before cog 0 started cog 1, as baggers said.
ah, makes complete sense! thanks!
Andrew
oh, while we are on this subject - does the HDMI output take up any more resources than a VGA output at similar resolution and color depth? does it chew up more hub bandwidth etc? I realize that's a very imprecise question - am writing a small game and was wondering if outputting HDMI would leave me with less resources.
Andrew
HDMI needs 3 more pins and a higher clock frequency. And without some linebuffer tricks, a line is min. 640 pixels wide, which may result in bigger bitmap buffers.
Andy
ah i can give up 3 pins, and clock frequency benefits the other cogs i guess.
i'll find this out fairly soon, but what's the bandwidth of the prop2 to be able to manipulate the linebuffer in real time - essentially creating a sprite / tile based architecture without using up so much bitmap memory?
also, do you have a reference to the linebuffer tricks? am interested...
Andrew
Andrew, if you look at my Space Invaders code, you will see a two line buffer being used for both HDMI and VGA displays, basically 640x480, then reduced to 320x240 using another cog to feed the dual 640 long line buffers they are 24bit so you can use any of the 16.7 million colours. :D
ah, many thanks jim, i'll have a look. the reason i was playing with the different cogs in the first place was to see if i could generate simultaneous (and independent) hdmi & vga but i keep getting the timings wrong. i'll have a look at your example