video generation questions
Gennady
Posts: 34
2 questions related to video genaration:
1. Is there any way to figure out when VSU shift is over ?
2. After shift is finished, what are the levels on video output pins ? Are they the same as last pixel shifted out ?
Gennady·
1. Is there any way to figure out when VSU shift is over ?
2. After shift is finished, what are the levels on video output pins ? Are they the same as last pixel shifted out ?
Gennady·
Comments
1. If you know your pixel timing, a counter will do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
1. If I don't shut generator down, on the next shift I get a garbage on the output.
Question: if I do shut it down, when does it take effect?
Can I do it during the shift?·Will it finish the current shift or not? If it doesn't finish the shift, then I need exact timing to prevent noise.
Also far as I understand, shutting VSU down will bring DA pins to input (floating) state. I can prevent it probably but setting these pins as outputs low in some other cog.
And·if I turn VSU back on, I need to feed it.·What happens with outputs after I turn it on and before feeding data ?
Unfortunately there is very little information on this level of details for video generator. So I really appreciate all the advices or insights on a subject.
Gennady
They can however be relevant when you use the video logic as a general purpose DAC (I shall post some code in the sequence of my assembly thread during the next days)
I should propose you provoke the situations you described, have a look at your 'scope, and post the results
WRT to to pixel timing, Potatoehead was right: It is absolutely deterministic according your setting of VSCL. I know of no way to check "how far" the shifting process is from completion, as the pixel and color registers are transparent to the user and will only be loaded by the WAITVID instruction.
The only thing I accomplished so far is frying some io
Maybe it's just too late...
Ok, what did you guys do. I'm hammering the video generators hard right now, trying to get overlay to work on NTSC. Anything I should be watching for? Was it the scope probe, combinations of instructions? Curious minds want to know!
I've changed the pin group used for I/O, while drawing video. I thought this happened instantly, but I've been having horizontal pixel sync problems. Didn't think about these kinds of things potentially happening. This may not work like I think it does. That aside, here is some code:
:draw_pixels rdlong B, A 'get four pixels from hub waitvid B, #%%3210 'draw them to screen (four pixel mode, one byte per pixel) movd VCFG, #3 'direct video output to live pins (This happens right at start of shifting) add A, #4 'point to next pixel group djnz r1, #:draw_pixels 'line done? movd VCFG, #2 'redirect video output to not-connected pins, thus suppressing sync, etc... (This occurs mid shift, maybe mid pixel)The purpose of this code is to suppress video output for all but active video. It will be removed in final working driver. Did this originally to keep timing deterministic between the two COGs. So this COG is outputting video to the same pins as the main COG is. Didn't want two sets of sync, etc... on the pins at once. I've got timing loops done now, that essentially make one really long waitvid, and the SYNC waitvid can just be at level 0 and that's suppressed enough. While this is running, another COG is generating complete NTSC video on the same set of active pins. This was a quick test to see if video could be conditional, similar to what is being asked here.
The only latch you've got is right after the shifter has been loaded with the next dataset to be shifted. It makes best sense then, if you want nice even blocks of pixels, to issue any controls for the video generator, right after a waitvid, before there is time to get started drawing pixels. The first movd happens right as the pixels are drawn to screen. I've had zero problems with this. Perfect pixels end up on the screen. This question brought the second movd VCFG to my attention however.
I've not seen the last pixels from this generator! Was not really looking for them, but a quick check reveals they are not on screen.
Your query tells me why now. The second movd VCFG moves the video output to the other pins mid shift! I've not seen a partial pixel. That could just be timing related.
I'll have to move that second movd VCFG at some point, for my purposes. This behavior does suggest the VCFG is active while shifting. It's highly likely to respond to other requests too. What is not known yet is what can change and will it change mid pixel, just between pixels.
I've got a small bit of time this morning. I'm gonna try a mid pixel pin change, because it's easy. If that works, and I see a partial pixel, then we know the register is active all the time and not latched somehow. That will leave only the question of which other things can be changed on the fly, while shifting.
Never mind, just tried it!
Here is the unchanged video bitmap drawing loop. It's a low resolution one, leaving plenty of time to play mid-pixel tricks. Horizontal pixel clock is 40 pixels.
:draw_pixels rdlong B, A 'get four pixels from hub waitvid B, #%%3210 'draw them to screen add A, #4 'point to next pixel group djnz r1, #:draw_pixels 'line done?Here is a modified one, to effect changes mid pixel. In this case, I just changed the pin group, because that's easy.
:draw_pixels rdlong B, A 'get four pixels from hub waitvid B, #%%3210 'draw them to screen mov OUTA, #0 ' light up debug LED nop nop nop nop movd VCFG, #2 'mid pixel VCFG change nop nop nop nop movd VCFG, #3 'back to active pins add A, #4 'point to next pixel group djnz r1, #:draw_pixels 'line done?I've attached the two resulting images, clearly showing no timing issues and VCFG change occuring mid-shift. My gut says the shifter is not latched then, meaning you can make changes while the shift is occuring. May not be true for all elements, but is at least true for pin i/o.
The third picture is both video generators running on the same pins at the same time, not horizontally aligned just yet, which is what I'm working on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 8/14/2007 4:30:50 PM GMT
If your VSCL frame clocks / pixel clocks > 32 then the remaining pixels will be color 0.
If you execute WAITVID before the video generator has output (frame clocks / pixel clocks) pixels, then your code halts until the video generator latches the pixel data.
Updates to VSCL don't take effect until the next video generator latch.
@potatohead: I did not understand your explanation in your first posting why you switched the pins at all... If you don't want the sync signals, why do you generate them in the first place?
If you have personally observed otherwise, please let me know so I can verify and alter the datasheet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
The first condition was how the signals interact. If that was not favorable, then the rest of the efforts were not worth following through on. The signals interact in a favorable way, so then it was onto vertical timing. A quick hack to understand the signals made sense, given my time and access to both the Prop and a suitable display.
Got that done.
I've now eliminated the sync signals from the overlay generator, making the pin redirection unnecessary. Output is consistent with no timing issues. Could have went that route, but the timing matters were confusing, so eliminating them one at a time worked better for me.
I'm down to the overlay having three elements: A fairly long wait between active video frames VBLANK, the actual active video scanlines, and the brief HSYNC period. Those are now done with waitvids and VSCL settings calculated for the right timing. Output during these times is just having the level set to zero and it all appears to work just fine.
Now I'm struggling with horizontal timing. Been a bigger problem for me than I thought! I've tried a fair number of things, not there just yet...
When that's done, then I'll think about the PLLs and other subtle issues, depending on what I see. Lots of pixel color, size, intensity combinations to evaluate. In some cases I might be seeing things that are not what I think they are. Gotta find that out first, so that code changes actually are aimed at real problems. Right now it's all about getting the pixels to land on top of one another correctly. Their colors, etc... can wait.
There is learning for me on multiple fronts while doing this. So, discrete steps makes the best sense, that's all.
Anyway, back to what can be changed mid-shift and what cannot...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 8/14/2007 8:14:40 PM GMT
1. VSU can be stopped any time during·shifting pixels. It brings video out to 0 (at least in my case, since I have video pins driven low from another cog).
2. After reenabling VSU it shifts out the rest of pixels.·I couldn't find any way to flash VSU, if anybody knows the way, I will appreciate the information.
3. It's quite easy to figure out when shift·1 ends - it's happens right after next waitvid (shift2).·It's logical, since waitvid waits till generator is available.
4. If VSU hasn't been fed with video data, it outputs garbage. If·It's stopped at a start of 'no feed shift', the garbage will be output on a generator reenabling.
5. Caution ! I tried to use·pins from the·group 0 (0..7) for video debugging and found an interesting thing - if I set one of the above mentioned pins as output, it will be set to input at some point.·Example -·try to set pin to toggle at some point in each vertical interval.·I haven't tried to investigate further, but I think that during tasks execution VCFG (Vgroup field) gets zeroed (pins 0..7 set for video), then set to a needed (in my case group 1 as on a protoboard) value, what means configuring pins 0..7 as inputs again.
Again, I am not sure about the reason, but the fenomenon exists. So if using non-video pins in a video driver don't forget to set them as outputs every time, and don't assume it will keep it's state.
All the above·has been done for the purpose of synchronizing of TV driver to external video.·I had to use separate cog as external video loss detector, and now it works quite good.
Gennady
Gennady····
If it just stops, does it start from there, completing a partial pixel, or just begin with next pixel?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Be careful about your notion of VCFG somehow being changed by the chip hardware other than by an instruction that changes it explicitly. I think you'll find that something in your code is "clobbering" the VCFG location. The question that raises is "what is that instruction not changing that it should?"
I·use
test_mask·· long·· %00000000_00000000_00000000_00010000······ 'P4 is a test pin.
Below are tv.spin mods and observations:
entry·········· andn··· outa, test_mask·· 'preclear P4
················· or······· dira,· test_mask·· 'set P4 as output
=================
-·Experiment 1 - insert pin toggle at 'superfield label:
=================
superfield·· xor· outa, test_mask
- expected at P4:·50% duty cycle at a·quad frame period (~64 ms)
- result:·low level at P4
··········· I can probably try to understand that, since vcfg starts with Vgroup 0 before loading parameters, so P4 gets set as input.
=================
-·Experiment·2 - insert pin toggle at 'superfield label, setting it·as output every time:
=================
superfield····· or dira, test_mask
················· xor· outa, test_mask
- expected at P4:·50% duty cycle at a·quad frame period (~64 ms)
- result:·sharp positive pulses at expected rate of ~64ms, immediately descending to 0 during ~1ms (as if high output·changes to floating input)
··········· Changing order of instructions doesn't change result.
=================
-·Experiment·3 - set P4 direction at Superfield and toggle at Field:
=================
superfield·· or· dira, test_mask
...
field········· xor· outa, test_mask
- expected at P4:·50% duty cycle at a·frame period (~32 ms)
- result:·low level at P4
=================
-·Experiment·4 - set P4 direction and toggle at·Field:
=================
field···· or dira, test_mask·········
········· xor· outa, test_mask
- expected at P4:·50% duty cycle at a·frame period (~32 ms)
- result:·as expected
================================
Above results puzzle me. Probably I don't pay attention to something, but than even more I would like to figure out what is going on.
Gennady
Hmm... I wonder if I can use this behaviour to my advantage....
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I think part of reason I though it was zero shifted in is I typically use WAITVID src,#dst so the last 23 bits are zero and thus zero is always shifted in.
·