Question about vid generator-
andrewsi
Posts: 59
Hey folks-
I posted a blog in the blogs section about a scrolling full RGB blinky matrix I built. Right now i have the final output PASM cog calculating PWM values for a row of pixels and then bit banging the output to the shift register to display it. Ericball was nice enough to comment on the idea of using the vid generator to handle shifting out the data, thus parallelizing the calculation work with the output, and achieving higher refresh rate as a result.
I'm fairly new to the prop and haven't used the vid gen for anything yet. I need to set three lines to one of 5 total states to drive the shift registers, each of which seems like it would correspond to a "color" in a single pseudo-pixel output. Based on my reading the manual, though, each frame can only output at most 4 unique colors. I had the idea of pumping up the PLL clock higher than necessary and outputting multiple equivalent pixels to redivide the rate back down, but thus outputting more frames and thereby circumventing the limitations on number of simultaneus colors within a single frame.
Anyone have any experience doing something like this, or is there an easier solution that I'm missing to outputting one of 5 bit patterns within a single frame?
Thanks guys!
I posted a blog in the blogs section about a scrolling full RGB blinky matrix I built. Right now i have the final output PASM cog calculating PWM values for a row of pixels and then bit banging the output to the shift register to display it. Ericball was nice enough to comment on the idea of using the vid generator to handle shifting out the data, thus parallelizing the calculation work with the output, and achieving higher refresh rate as a result.
I'm fairly new to the prop and haven't used the vid gen for anything yet. I need to set three lines to one of 5 total states to drive the shift registers, each of which seems like it would correspond to a "color" in a single pseudo-pixel output. Based on my reading the manual, though, each frame can only output at most 4 unique colors. I had the idea of pumping up the PLL clock higher than necessary and outputting multiple equivalent pixels to redivide the rate back down, but thus outputting more frames and thereby circumventing the limitations on number of simultaneus colors within a single frame.
Anyone have any experience doing something like this, or is there an easier solution that I'm missing to outputting one of 5 bit patterns within a single frame?
Thanks guys!
Comments
Use "waitvid colors, #%%3210"
What this does, is output each of the "colors" in the order specified in the "pixels" argument, thus allowing any bit pattern, any time, with the restriction of a 4 pixel frame.
Essentially, you run it backwards. Pixels are fixed, and colors become pixels.
1) What's the double % mean, or is that just a typo? I'm particularly confused by the "#%%3210" notation here.
2) I get that the colors parameter represents 4 8-bit output patterns. (Right? I really only need 3 pins total but there are 5 possible combinations I'd use on those 3 pins.)
3) I don't quite understand how to use the pixels parameter to output those 4 patterns in sequence to create a 4 pixel frame.
An example of setting up VCFG and VSCL and a frame of output would really help here. The docs talk about Pixels representing either a 16x2 frame or a 32x1 frame, but I'm just not quite understanding how to "reverse" things to get the result youdescribe.
%010 = 2, %011 = 3, %100 = 4
%% = two bits per digit, so it's 0, 1, 2, 3
%%02 = 2, %%03 = 3, %%10 = 4.
Or. %1100_0110 = %%3012
A byte in binary is 8 digits. %1111_1111, that same byte at two bits per pixel is, %%3333, and at 4 bits per pixel is $FF.
Hope that helps!
Let me go grab some full color driver code, and post it.
mov r1, #40 '40 times 4 pixels = 160 pixels output :draw_pixels rdlong B, A 'get four pixels from hub (one byte per pixel, color = pixels) waitvid B, #%%3210 'draw them to screen with fixed pixel data add A, #4 'point to next pixel group djnz r1, #:draw_pixels 'line done?In this loop, you see a long being fetched from the hub. That long contains four color values, and gets drawn to the screen by the waitvid command, in the order shown by the #%%3210 argument normally assigned to pixels.In most video drivers, it's the reverse of that. The colors are loaded, and the pixels are fetched from the HUB, or sometimes both are.
If you set up the waitvid in VGA mode, you basically can store bit patterns as bytes in the hub, and output them one longs worth at a time, just as shown in that loop above.
I'll try to get some setup data here in a bit. Time constrained at the moment. (hate that)
Thanks for code - I appreciate the help quite a bit. The video generator documentation is a tiny little bit opaque.
For what it's worth, the HYDRA book covers this in good, basic detail, up to this example level.
I think the other part of the documentation problem lies in the fact that a lot of people don't understand video systems very well. I see some other video related devices presented with some core video introduction. IMHO, that would help some here too.
The output can either be VGA, in which case the 8 bit color selected by the pixel bit(s) is output to the pins directly (via the VCFG & DIRA output masks) or composite output which is three pins with optional 16-PSK.
The input either has a sequence of 1-32 or 1-16 of 2 or 4 distinct outputs or a sequence of 1-4 distinct outputs (as described by potatohead).
As per your blog, you only need 4 distinct outputs for each 8 bits you shift out, so you can use the "normal" input method.
I was able to realize a modest improvement in throughput over the old algorithm, such that I can now double my PWM resolution to 64 steps and still maintain a framerate just shy of 60fps with 2 LED modules. Now that I understand how it works, I see how you do the "reverse" trick you were originally talking about - tell me if I'm wrong here - but you just chop the VCFG frame clocks down to measure out a 4-pixel frame rather than the documented 16 or 32-pixel frames, and then put any old pattern you want in each of the colors bytes, and then just output them in sequence with a literal pixels param rather than a full 32 bit one. The docs had me confused there since it really only talks about 16/32 pixel frames, and I was kinda wondering what would happen if you only gave it the 9 bit literal to work with, but now I think I see. Anyway, I think this will help me improve throughput even a bit more, since my current 16-pseudopixel frames waste about 7 possible bitplaces of output time at the end of a full sequence where I have to toggle the shift register's RCLK to display the new data. This way I can knock it down to just one wasted bit place (each takes two pseudopixels of output.)
I was originally hoping to be able to do this "manually" outside of a vidwait, but after thinking about it for a minute I realized you can't do that, because it would need to take place after the last WAITVID finishes shifting out but before the next one starts, which doesn't seem possible since you already need to be suspended in the next WAITVID when that occurs.
The other thing that caught me a little off-guard at first is that the pixels are shifted out from the LSB end first (which makes sense, given the possibility of a literal pixels parameter), which is the opposite of how my external shift registers work, they want the MSB first. So far as I can see, that aspect of the direction of the pixel shift-out is not documented anywhere in the Prop manual.
Anyway - neat trick, I've learned something new, and now I have a handle on using the hardware in the Prop as a shift register! Thanks guys!
IMHO, the variable frame rate is implied in the functional description of the effect of VSCL. Glad it's working for you.
We do have the REV instruction, if you have time for it, and need it. And you are right on the 4 pixel frame. Just specify ANY output order with your literal argument. Quite nice.