Making sure two cogs start at the same time.
potatohead
Posts: 10,260
Essentially, I've been running some tests with Dennis raster graphics driver, running two instances of it at the same time. That's two different video generators, looking at their own raster bitmaps, outputting to the same set of pins for video.
(got some prop time!!)
My primary goal is to explore video overlay capabilities, additional colors, and obtaining graphics behavior that more closely emulates hardware sprites. IMHO, graphics sprites, such as a mouse pointer, overlayed on top of text would be one possibility. Differing resolutions and color sets, co-existing would be another.
I managed to get it pretty well synced up once or twice (turns out it was largely luck though) and the results were very encouraging, leading me to believe this is possible to do. I took the Amazing Sand demo, and stripped it down to a single physics cog. Once that was working nicely, I defined another bitmap, duplicated all the TV driver parameters, and started two instances of that, each looking at their respective bitmap. I like this aspect of the raster driver. You simply need to define an array of the size necessary for the bitmap, and not worry about much else. This made setting up two screens easy.
With no significant changes to the TV driver, I was able to get them synced within one NTSC color clock. (Twice!) When this happened, the results were interesting. Both video generators added their signals together and the result was a nice overlay effect where graphics from one page were unaffected, for the most part, by graphics on the other one. Some color and intensity changes did occur where the two were both doing something with the same pixels. From what I can tell, the result will be quite useful, given the error can be removed from the process.
And that's where it stopped. I seem to be unable to get the two cogs to start at the same time. Given the same parameters, they appear to do exactly the same things, it's starting them right now that is the issue. ---or, this driver is exhibiting some different behavior I've not yet learned enough to account for.
I tried grabbing the counter, with the main spin program that starts them, adding a delta (80,000,000 = 1 sec), then passing it to the cogs, where they perform their init tasks, then wait for the counter to begin executing video frames. (The code attached, has a shorter delay, probably the result of me trying some different values.)
What I saw was either a 50 second or so wait, before they would run, or one would run, followed by the other at a later time. !?! Once in a while, they would just start up and run nearly together. (Close enough to preview the resulting effect) I am encouraged in that they appeared to stay in sync over a long time. On one particularly good run, I let them just do their thing for 20 minutes or so. Not a hitch!
Sorry, this is getting long. Does anybody have an example of doing this I could follow?
Here is the code I'm trying to make work!
This block of assembly code is the first thing executed. Essentially, the driver inits itself by doing a series of setup tasks all in one shot. While doing video, this block does not run, instead the tasks are done during spare moments while drawing the superfield. ---or so I think!
What I thought was gonna happen was both cogs would get their initial setup done, then sit and wait for the counter to reach whatever value makes sense. At that moment, both of them would just start generating their video signal. At 80Mhz, the error at any one time appears to be small enough to just let the both of them do their thing.
This has not happened, and I'm not sure why.
My intention is to have only one instance of the driver output sync, etc... For now, just having them run at the same time would allow me to continue exploring this idea.
I've attached the entire hack, if more lines of code matter. SandPhysics is unchanged at this time.
Edit: Warning! If you run this, be ready to reset your prop setup quickly. A majority of the time, the cogs will end up in a state where the resulting signal is just not gonna display on your NTSC display system. I'm not sure if damage could occur, but I suppose it could, particularly if your monitor/TV is an older one. I switched to a newer set, after hearing a loud pop or two on the older one!!
Post Edited (potatohead) : 3/12/2007 11:56:24 PM GMT
(got some prop time!!)
My primary goal is to explore video overlay capabilities, additional colors, and obtaining graphics behavior that more closely emulates hardware sprites. IMHO, graphics sprites, such as a mouse pointer, overlayed on top of text would be one possibility. Differing resolutions and color sets, co-existing would be another.
I managed to get it pretty well synced up once or twice (turns out it was largely luck though) and the results were very encouraging, leading me to believe this is possible to do. I took the Amazing Sand demo, and stripped it down to a single physics cog. Once that was working nicely, I defined another bitmap, duplicated all the TV driver parameters, and started two instances of that, each looking at their respective bitmap. I like this aspect of the raster driver. You simply need to define an array of the size necessary for the bitmap, and not worry about much else. This made setting up two screens easy.
With no significant changes to the TV driver, I was able to get them synced within one NTSC color clock. (Twice!) When this happened, the results were interesting. Both video generators added their signals together and the result was a nice overlay effect where graphics from one page were unaffected, for the most part, by graphics on the other one. Some color and intensity changes did occur where the two were both doing something with the same pixels. From what I can tell, the result will be quite useful, given the error can be removed from the process.
And that's where it stopped. I seem to be unable to get the two cogs to start at the same time. Given the same parameters, they appear to do exactly the same things, it's starting them right now that is the issue. ---or, this driver is exhibiting some different behavior I've not yet learned enough to account for.
I tried grabbing the counter, with the main spin program that starts them, adding a delta (80,000,000 = 1 sec), then passing it to the cogs, where they perform their init tasks, then wait for the counter to begin executing video frames. (The code attached, has a shorter delay, probably the result of me trying some different values.)
What I saw was either a 50 second or so wait, before they would run, or one would run, followed by the other at a later time. !?! Once in a while, they would just start up and run nearly together. (Close enough to preview the resulting effect) I am encouraged in that they appeared to stay in sync over a long time. On one particularly good run, I let them just do their thing for 20 minutes or so. Not a hitch!
Sorry, this is getting long. Does anybody have an example of doing this I could follow?
Here is the code I'm trying to make work!
(from SandDemo.spin)
PUB start | i, j, c, dx, gx, gy, landed, counter
'sync tv cogs
counter := (80_000_000) + cnt
tv_counter := counter
tv_counter2 := counter
'start tv
longmove(@tv_status, @tvparams, paramcount)
tv_screen := @display
tv_colors := @colors
tv.start(@tv_status)
'start tv2
longmove(@tv_status2, @tvparams2, paramcount2)
tv_screen2 := @display2
tv_colors2 := @colors2
tv2.start(@tv_status2)
'so far so good, both cogs start, looking at their own parameters!
'I added one to the parameter count, to pass the desired counter value into the tv-driver
'Dennis' driver works just like the Parallax one, in how things are passed
(From the tv-driver, this instance running in two cogs)
' Entry
'
entry mov taskptr,#tasks 'reset tasks
mov x,#10 'perform task sections initially
:init jmpret taskret,taskptr
djnz x,#:init
waitcnt _counter, #0 <---After getting setup, cogs should wait here!
This block of assembly code is the first thing executed. Essentially, the driver inits itself by doing a series of setup tasks all in one shot. While doing video, this block does not run, instead the tasks are done during spare moments while drawing the superfield. ---or so I think!
What I thought was gonna happen was both cogs would get their initial setup done, then sit and wait for the counter to reach whatever value makes sense. At that moment, both of them would just start generating their video signal. At 80Mhz, the error at any one time appears to be small enough to just let the both of them do their thing.
This has not happened, and I'm not sure why.
My intention is to have only one instance of the driver output sync, etc... For now, just having them run at the same time would allow me to continue exploring this idea.
I've attached the entire hack, if more lines of code matter. SandPhysics is unchanged at this time.
Edit: Warning! If you run this, be ready to reset your prop setup quickly. A majority of the time, the cogs will end up in a state where the resulting signal is just not gonna display on your NTSC display system. I'm not sure if damage could occur, but I suppose it could, particularly if your monitor/TV is an older one. I switched to a newer set, after hearing a loud pop or two on the older one!!
Post Edited (potatohead) : 3/12/2007 11:56:24 PM GMT
Comments
You can sync multiple cogs, all right, but syncing the video color modulators is more tricky. I've never tried to do it, so I don't have any code, but one of Andre's Hydra programmers came up with some technique.
I'm attaching here the 1024x768 VGA driver. You can see at the start of the program how the cogs are synced. A near-future value is determined in Spin, then written to a variable that the cogs will read. The cogs all·load that variable and do a WAITCNT on it. Then, a few steps are taken to lock all the cogs' PLLs. As I said, though, the modulators will be out of phase, and some extra steps would need to be taken to get them into alignment. What will be sync'd will be the subsequent WAITVID instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.