WAITVID, HUB OPs and general PASM timing questions (Parallax & others)

dMajo

WAITVID

Propeller manual V1.1 (page 225)
... For VGA, each color value’s upper 6-bits is the 2-bit red, 2-bit green, and 2-bit blue color components describing the desired color; the lower 2-bits are "don’t care" bits. ...
·

Propeller datasheet V1.2 (page 12/13)
... For VGA mode, each 8-bit color value is written to the pins specified by the VGroup and VPins field. For VGA typically the 8 bits are grouped into 2 bits per primary color and Horizontal and Vertical Sync control lines, but this is up to the software and application of how these bits are used. ...

1) Which one is true? ·(I understand them in opposition to each other)
2) VGA mode, PLLA@80MHz, pixelclocks 1, frameclocks 5: can I say that at each systemclock cycle 8bits are delivered out:

waitvid   Data32N1,#0
waitvid   Data32N2,#0
waitvid   Data32N3,#0

Is the above code executed without wait penalties? What is output the 5th clock? is the 4th byte repeated?
3) One idea :

Propeller datasheet V1.2 (page 13) said...
... When FrameClocks cycles occur and the cog is not in a WAITVID instruction, whatever data is on the source and destination busses at the time will be fetched and used. So it is important to be in a WAITVID instruction before this occurs. ...

Is correct this: waitvid DestinationDataBus, SourceDataBus or is the above sentence referred to address busses?
If we look at this from an other point of view waitvid is not the only method to deliver data to the video hardware. Whatever instruction that places the right data on the right bus on the right time will fulfil the request ! If the plla is running the same frequency as system clock how much they differ in sync? How difficult is deliver data with an other instruction that beside delivering the data will also make something useful in the same time?
Has someone ever tryed something like this?

setup VGA mode, single ended PLLA@80MHz with pina on output pin (datastrobe), pixelclocks1 frameclocks 9713717 (one clock more or less then some pasm lines), VGA on P0..7, PinA on P8
 
 
- loop to get in sync
 
- set pixelclocks 4
 
mov buff1,buff1    ' just to be shure that both destination and source busses has the right value
mov buff2,buff2    'these instructions are synced with video hardware window (like the hub one)
mov buff3,buff3
mov buff4,buff4
 
 
result: data output at 80MB/s
 

Sorry, have to go now urgently (family problems), will continue tomorrow
PEDIT: Sorry, I am in the new house today, tomorrow will go on on these arguments
·········· @PhiPi: 1)I was sure I was posting to Propeller forum, 2) You are one of the ones who I want (hope) here to discuss with. I want to collect
······ ··· every guru's·experience and hopefully achieve new horizons, all together. So be openminded and keep tuned (watching over my spelling )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)

Post Edited (dMajo) : 9/13/2009 11:04:09 AM GMT

dMajo

Reserved

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)

Phil Pilgrim (PhiPi)

'Not sure why this was posted in the Sandbox, since it's a valid Propeller topic...

1) In describing the WAITVID instruction, I believe the manual erred in being so specific about how the bits are used, since "VGA" mode applies to any general purpose output to as many as eight bits at a time. In cases where the lower two bits are masked out in VCFG, the statement is correct. But this is just one example. One might also wish to have WAITVID drive an 8-bit data bus, for example, in which case all eight bits are used. In the statement cited from the datasheet, again, this is way too specific to be included in a definition of WAITVID and should serve more as an example of how it can be used or is typically used. If taken as examples, the two statements are not mutually contradictory. They merely illustrate two ways in which the eight available bits can be assigned.

2) In the example cited, byte 0 of Data32N1 would be output for five clocks, then byte 0 of Data32N2 for five clocks, and finally byte 0 of Data32N3 for five clocks. This is because the source field is all zeroes, specifying only the first "color" in the destination field. To output all four bytes of the destination, the source would have to look like this:

····%xxxxxxxxxxxxxxxxxxxxxx_01_11_10_01_00

This displays byte 0 of the destination value, then byte 1, byte2, and byte 3, followed by byte 1 again.

3) Based on the statement in the datasheet, something like what you propose might work:

        waitvid colors0,#%11_10_01_00        'Set colors0 and sync to vid.
        mov     colors1,#%11_10_01_00 nr     'Send additional colors
        mov     colors2,#%11_10_01_00 nr
        mov     colors3,#%11_10_01_00 nr
        mov     colors4,#%11_10_01_00 nr

There will be come pipelining issues to consider, and you will have to figure out how to terminate the sequence gracefully. This may be difficult, since the source and destination values of the terminating instruction will already be on their respective busses and output to the video, too ... I think.

-Phil

Addendum: This begs a rather interesting question: If the video hardware merely loads whatever happens to be on the source and destination busses when it runs out of data, what is actually happening during a WAITVID instruction? Theroretically, due to pipelining, the source and destination values of the next instruction should already have been fetched. For it to work as stated, wouldn't the pipeline have to stall? I know I'm not understanding this mechanism correctly. Maybe someone who actually knows can explain it.

Post Edited (Phil Pilgrim (PhiPi)) : 9/12/2009 7:06:29 PM GMT

potatohead

I think the other thread we had recently is part of the answer to this.

Once a waitvid has been initiated, the video generator just keeps cycling through frames, whether or not another waitvid is executed. This continues until VCSL is set to 0, at which point there is no action. What I can't remember is whether or not it stops right away, or if the frame in process is completed first. I think it completes the frame, because I think VCSL is latched when the data on the busses is latched.

When the frame counter hits 0, the data on the source and destination bus gets copied (latched) to an internal working register. This occurs whether or not a waitvid is executed.

The waitvid is all about making sure known data is present and accounted for so that each frame presents the right data, without having to worry about cycle counting.

Linus (that craft demo guy) had posted up some interesting code a while back. Before his demo, he was working on a nicely timed 800x600 @ 80Mhz vga image display demo. In that code, the timing all worked out such that it was difficult to get the frame data timing correct, and one artifact of that was being able to comment out some of the waitvids and still have the image display! There was noise in that video code that showed as "sparkles", and I believe at that time nobody had come to the realization that the latch of the data occurs when the frame counter hits zero. Eric Ball was the first one I recall suggesting this on a recent waitvid related thread.

Given some setup to synchronize things, I think it's totally possible to cycle count and have the data hit the bus at the right times. This would yield faster pixel clocks, or faster data bursts, depending on use. However, said code would be very clock speed and video timing dependent. One advantage I see to the above is getting full color (8bpp) display capability at faster pixel clocks. Most of the loops I've done and that I've seen others do, can't quite feed a Propeller to say, 640 pixels NTSC @ 80-Mhz. 512 is possible, but that's pushing it. Code done this way would yield higher pixel clocks, meaning a single COG could then drive a high resolution TV display, leaving other COGs to build graphics for it.

The dynamic in play regarding Propeller graphics color density is the waitvid loop. To get "full color", which is any pixel, any color, any scanline, it is necessary to run a 4 pixel frame on the waitvid, thus turning the "colors" data into pixels via the #%%3210 trick. At 80Mhz, this boils down to a pixel clock loop that needs to be larger than about 4 PLLA, and that happens to all shake out to about 512 "full color" pixels tops for NTSC color graphics.

If larger frame sizes are used, it's easy to drive very high resolutions. Higher than the best NTSC displays are capable of. The trade off though, is color density. Two or four colors per frame results, and that is basically where all the tile graphics drivers all have the same "color cell" properties. Four colors can be specified for a given frame, and all pixels in that frame then, share that color pool.

For TV, I don't think exceeding these limits are worth it because s-video displays top out right where the Propeller does. 512 pixels is right near the top of what an S-video display will render well.

For VGA, this might be a good trick! Higher color densities at higher resolutions, without having to worry about "tiles" might be worth doing. RAM is then a problem, or the building of dynamic displays where a frame buffer does not exist and images are drawn "on the fly" are required to make use of the output capability. At these resolutions, 32K isn't much of a frame buffer.

I've not done a lot of data output kind of code, but being able to burst at higher speeds is generally something people see use for. Sorting this issue out would play well there too, IMHO. Of course, multiple COGs synchronized is probably faster, at the expense of using COGs up.

Seems to me, a graceful ending to a loop like this could occur with just one final waitvid to render the last frame, or two frames, set VCSL to either 0, to end things, or another frame size to transition between signal states.

eg: Use ordinary "simple", latched waitvid techniques to build sync and blanking signals, then for the active pixel area, use this technique to achieve high pixel clocks with full color density, on the last frame or two, use a waitvid instruction so that VCSL can be changed at the right time.

As for the pipeline, a waitvid latches whatever is on the busses at frame counter 0. I think it latches VCSL too, but not VCFG. That can be changed mid pixel stream. We had a thread on that quite a while back. Changing the output pin, can happen right in the middle of output, for example. I was able to test that one with a video display

loop  waitvid colors, pixels
      nop
      nop
      mov VCFG, test_value
      nop
      nop
      mov VCFG, control_value
      ....  'update indexes and such
      jmp #loop

This kind of thing done with nice, fat pixels clearly showed partial pixels, right where the output was changed. Adding to the nops moved that transition point nicely enough. I don't know about the other VCFG options. It might be possible to change bits per pixel, or something too. Maybe some of that register gets latched at frame counter 0 as well.

Seems to me the pipeline has to stall. Waitvid takes more than 4 cycles to execute. Wasn't the final number observed 7 cycles? (goes off to find other thread)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 9/12/2009 8:37:28 PM GMT

dMajo

Moved to Propeller forum

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)

Post Edited (dMajo) : 9/14/2009 8:14:11 PM GMT