Understanding P2 streamer
ti85
Posts: 46
in Propeller 2
mov x,#480 'set visible lines
line call #hsync 'do horizontal sync
xcont m_rf,#0 'visible line
djnz x,#line 'another line?
m_rf long $7F080000+640 'visible rlong 8bpp lut
Above is code from the VGA 640x480 8bpp example
I have used the P1 to do VGA in the past, however, I am having a hard time understanding the code listed above. I know the xcont instruction
uses the streamer to output @ the DACs. How does the m_rf setup the streamer and how does the program know the address for the bitmap pixels?
line call #hsync 'do horizontal sync
xcont m_rf,#0 'visible line
djnz x,#line 'another line?
m_rf long $7F080000+640 'visible rlong 8bpp lut
Above is code from the VGA 640x480 8bpp example
I have used the P1 to do VGA in the past, however, I am having a hard time understanding the code listed above. I know the xcont instruction
uses the streamer to output @ the DACs. How does the m_rf setup the streamer and how does the program know the address for the bitmap pixels?
Comments
There's a rdfast command before the xcont that tells it where to read from...
Also, SETCMOD and its associated instructions defines how the streamer data gets formatted for output.
could someone please explain what the streamer is?
The docs do not tell me much.
Is there a thread about streamers for dummies?
Thanks
The streamer acts like a DMA controller and simply put can transfer data between hub RAM and pins in the background while the cog is executing instructions. The main streamer section of the doc is quite comprehensive.
That's the "Propeller 2 Silicon Document". It's been the gold reference from the start. Section is just called "STREAMER".
Also, the Cog's "FIFO" hardware provides the Streamer's hubRAM interface. So reading up on the FIFO is helpful too. Found in section "FAST SEQUENTIAL FIFO INTERFACE".
The streamer is crazy complex (not sure anybody could figure it out from scratch?) and yet, relatively easy once somebody makes working code to look at...
Probably a VGA driver is a good place to look for an example of basic operation.
Yes, the reference docs can be unclear on specific sequencing on occasion. One often has to experiment when learning how hardware should be configured. Diagnostic reporting of every detail at every step sometimes. Placing reference markers to know when a particular part of the code is executing. Which can be scope triggering of course.
And finally, documenting, in the source code, your understanding for later reading. Often it's just personal clarification of what one term in the reference docs may mean.
seems don't understand it yet either...
Am using this to set the VGA driver "basepin" into mode settings like this:
m_rf:=$BF010000 + basepin<<17 + 640 'visible 24bpp as longsbased on docs saying:
D/#[31:16] 0111 dddd eppp 0001and eppp like this:
In every mode, the three %ppp bits in D[22:20] select the pin group, in 8-pin increments, which will be used as outputs or inputs, for up to 32-pin transfers. The selection wraps around: %ppp : 000 = select pins 31..0 001 = select pins 39..8 ...But, just noticed that Chip's code seems to not be setting ppp and got no idea why it works without it.
Seems to be fine without though...
Guess it must be that if using DACs, don't need it. Guess the "every mode" threw me off...
Nice find for me. Now, can copy Chip and fix the driver basepin inside the assembly driver instead of in the Spin2 code...
Yes, the pin field in the streamer CMD only applies to digital in/out.
Also, the heavens will smite those who use magic hex constants. You want
X_DACS_3_2_1_0|X_RFLONG_RGB24 + 640.Hmm... Didn't know about those...
Guess Chip forgot too (from his Anti-Alias line over HDMI example):
m_bs long $70810000 + 4 'before sync m_sn long $70810000 + 8 'sync m_bv long $70810000 + 4 'before visible m_nv long $70810000 + xpix 'invisible m_vi long $B0860000 + xpix 'visible (rflong rgb24)I agree, now these constants exist and are recognized by PNut and Flexspin it makes really good sense to use them. I've been migrating some of my newer code to use these and while much longer to type they make sense to show what you are doing, also very handy for searching. I know some older code I've done was written before these were documented and is unfortunately still hard coded. Something to try to fix in the next release, whenever that will be.
m_vi long X_IMM_1X32_4DAC8 | X_PINS_ON + H_VISIBLE 'visible m_vi2 long X_IMM_1X32_4DAC8 | X_PINS_ON + H_VISIBLE 'visible-64 (for last sync line) m_rf long X_IMM_1X32_4DAC8 | X_PINS_ON + H_VISIBLE 'visible (patched per mode) m_brdr long X_IMM_1X32_4DAC8 | X_PINS_ON 'border pixels m_hubpkt long X_RFLONG_32P_4DAC8 | X_PINS_ON m_hubpkt2 long X_RFLONG_32P_4DAC8 | X_PINS_ON | 64 m_imm8 long X_IMM_1X32_4DAC8 | X_PINS_ON | 8 m_imm2 long X_IMM_1X32_4DAC8 | X_PINS_ON | 2 m_hfp long X_IMM_1X32_4DAC8 | X_PINS_ON + H_FP - 8 - 2 'front porch before sync m_hbp long X_IMM_1X32_4DAC8 | X_PINS_ON + H_BP - 2 'back porch before visible on blank line m_hbp2 long X_IMM_1X32_4DAC8 | X_PINS_ON + H_BP - 8 - 4 'back porch before video guard band@evanh
@Rayman
@TonyB_
Thank you all and every body else. Looks like a good read and thanks for the understanding that
the info is not obvious to someone starting from scratch.
I will probably have questions later.
The suggestion of a VGA driver? Is there one or something that is easy to follow with comments that explains
hopefully each step of the code to make it easy to read?
Again thanks.
Martin
The experimental Spin2 code generator can make one. Maybe easy to use?
Should be able to find with search..
Might be able to find with search for SimpleVga as well, not sure…
But nothing is really simple about the streamer…
Here's a version that should work, just change the basepin to match your setup.
But, now see can remove all the "basepin<<17" stuff at the beginning as not really needed.
Have to revise this so don't need to modify the assembly before starting up the driver...
@TonyB_
Thank you. I am looking that up.
Martin
Cleaned up VGA code. Much simpler now...