You can modify the long that defines the Streamer mode for pixel output (m_rf) for every line. The bbbb field lets you choose between 16 colorsets in the LUT. SETNIB is the ideal instruction for that.
You can modify the long that defines the Streamer mode for pixel output (m_rf) for every line. The bbbb field lets you choose between 16 colorsets in the LUT. SETNIB is the ideal instruction for that.
Andy
You can do it MULTIPLE times on a scan line, if you want.
Very nice! You know, I've not explored indexing in the COG much. Was always slow on P1, HUB was faster.
This works out to a couple fewer instructions per character, no hub access waits, and that leaves room for the clever color attribute, and yes SETNIB shines there.
We are gonna learn a lot over the next few weeks.
BTW: On P1, Eric and I worked pretty hard to get "80 @ 80mhz", and it took two COGS. This is a nice speed boost, and it shows the flexibility of the streamer nicely. 80@50mhz and one COG, with attributes is one heck of a speed up, and there are 16 COGS!
Thanks to Chip, I now have a 1-2-3 A9 board. Is there an image available for it yet?
Actually, it looks like the A9 board powers up with an image already in it. Is that the most recent image? If so, I guess there is no rush uploading it to this thread.
Thanks to Chip, I now have a 1-2-3 A9 board. Is there an image available for it yet?
Actually, it looks like the A9 board powers up with an image already in it. Is that the most recent image? If so, I guess there is no rush uploading it to this thread.
Can you please run all_cogs_blink.spin and find out how many green LEDs blink? That might only have one cog.
Thanks to Chip, I now have a 1-2-3 A9 board. Is there an image available for it yet?
Actually, it looks like the A9 board powers up with an image already in it. Is that the most recent image? If so, I guess there is no rush uploading it to this thread.
Can you please run all_cogs_blink.spin and find out how many green LEDs blink? That might only have one cog.
All of the red LEDs light and one of the green ones flashes. I guess that means I only have one COG?
Thanks to Chip, I now have a 1-2-3 A9 board. Is there an image available for it yet?
Actually, it looks like the A9 board powers up with an image already in it. Is that the most recent image? If so, I guess there is no rush uploading it to this thread.
Can you please run all_cogs_blink.spin and find out how many green LEDs blink? That might only have one cog.
All of the red LEDs light and one of the green ones flashes. I guess that means I only have one COG?
Okay. I'm compiling for 16 cogs right now. This will take about 40 minutes.
Thanks to Chip, I now have a 1-2-3 A9 board. Is there an image available for it yet?
Actually, it looks like the A9 board powers up with an image already in it. Is that the most recent image? If so, I guess there is no rush uploading it to this thread.
Can you please run all_cogs_blink.spin and find out how many green LEDs blink? That might only have one cog.
All of the red LEDs light and one of the green ones flashes. I guess that means I only have one COG?
Okay. I'm comping for 16 cogs right now. This will take about 40 minutes.
Ariba had mentioned the wrapping pointers we had on P2-Hot. Those were great for circular buffers and FIRs. I found a really simple way to incorporate them into ALTI. Basic functionality is still expressed in the bottom 9 bits of S, which means 9-bit immediate values are normally adequate, leaving upper bits of S cleared. Now ALTI uses the next 9 bits up as a similar set of three 3-bit fields to constrain incrementing and decrementing:
ALTI D,S/#
S/# = %rrr_ddd_sss_RRR_DDD_SSS
%RRR_DDD_SSS = original purpose: result/destination/source modifiers; same/dec/inc, substitute into next instruction
%rrrr_ddd_sss = new wrapping limiters
rrr/ddd/sss now each have this purpose, where %f is the original field data in D and %n is the newly incremented/decremented value:
%000 --> %nnnnnnnnn, full 512-register range (default for 9-bit constant S operands)
%001 --> %fnnnnnnnn, 256-register range
%010 --> %ffnnnnnnn, 128-register range
%011 --> %fffnnnnnn, 64-register range
%100 --> %ffffnnnnn, 32-register range
%101 --> %fffffnnnn, 16-register range
%110 --> %ffffffnnn, 8-register range
%111 --> %fffffffnn, 4-register range
If you are using a 9-bit constant for S, you have the normal 512-register range for inc/dec. If you use a register for S, you can make wrapping buffers. This addition was very little logic:
This means that wrapping buffers must be 2^n, in size, and must exist on an integral buffer-size boundary (ie 16-register buffers can exist at $000-$00F, $010..$01F, $020..$02F, etc.) It's not as flexible as Prop2-Hot was, but gets the job done.
I had to change fclk = 50_000_000.0 to fclk = 80_000_000.0 to get the vga demo's to work on the A9 board
We've replaced all but two Prop123 -A7 boards with -A9 boards. Next compile, I'll bump all but the -A7 boards up to 80Mhz. 100Mhz may even be possible.
Comments
Chip says they are correct but I'm not seeing it...
For example, I think the value for 1/3 should lie between 1/2 and 1/4, right?
You may be right. Bit 31 is the 1.0 position and bit 30 is the 0.5 position. I'll review those.
You were right. I just fixed them all. Thanks for noticing this.
Maybe you'd want to do high resolution VGA or something without external RAM. Seems you'd want these modes for that...
Can one use a different LUT origin for each horizontal line?
That might be nice... Would let you show more colors on the screen...
You can modify the long that defines the Streamer mode for pixel output (m_rf) for every line. The bbbb field lets you choose between 16 colorsets in the LUT. SETNIB is the ideal instruction for that.
Andy
You can do it MULTIPLE times on a scan line, if you want.
It's an 80 colums texdriver with a color per character, without buffering of lines. All realtime modification of the streamer address and color field.
Andy
Are you keeping the font in the cog or the hub?
Wait... Are you pointing the streamer directly at the character pixels? Would have to be HUB, wouldn't it?
Seems you probably are. Doing things the old P1 way vs the new P2 way. Cool beans.
@Rayman: Well, that means you can do 2 or 4bpp, per tile, easy. Lots of colors. For a lot of images, that will do a very nice job.
Here is the code, I have also a 40 column variant that is more steady.
Andy
This works out to a couple fewer instructions per character, no hub access waits, and that leaves room for the clever color attribute, and yes SETNIB shines there.
We are gonna learn a lot over the next few weeks.
BTW: On P1, Eric and I worked pretty hard to get "80 @ 80mhz", and it took two COGS. This is a nice speed boost, and it shows the flexibility of the streamer nicely. 80@50mhz and one COG, with attributes is one heck of a speed up, and there are 16 COGS!
Yeah, I never thought that this will work with 80 characters when I startet.
With the tighter VGA timing I can do only 40 characters.
Andy
I will compile one now and post it.
Can you please run all_cogs_blink.spin and find out how many green LEDs blink? That might only have one cog.
Okay. I'm compiling for 16 cogs right now. This will take about 40 minutes.
If you are using a 9-bit constant for S, you have the normal 512-register range for inc/dec. If you use a register for S, you can make wrapping buffers. This addition was very little logic:
BEFORE: wire [8:0] alts = d[08:00] + {{8{s[1:0] == 2'b10}}, s[1]}; // s[01:00] --> s field: same, same, dec, inc AFTER: wire [8:0] altsx = d[08:00] + {{8{s[1:0] == 2'b10}}, s[1]}; // s[01:00] --> s field: same, same, dec, inc wire [8:0] altsm = 9'h1FF >> s[11:09]; // s[11:09] --> original/new sliding mask wire [8:0] alts = ~altsm & d[08:00] | altsm & altsx;This means that wrapping buffers must be 2^n, in size, and must exist on an integral buffer-size boundary (ie 16-register buffers can exist at $000-$00F, $010..$01F, $020..$02F, etc.) It's not as flexible as Prop2-Hot was, but gets the job done.
We've replaced all but two Prop123 -A7 boards with -A9 boards. Next compile, I'll bump all but the -A7 boards up to 80Mhz. 100Mhz may even be possible.
Guess i'm stuck with turkey, football and relatives tomorrow!
It will be impossible to use 16 COGS and 512KB of hub!!
(there, that should get the juices flowing!)