Wasn't there going to be a change so that any cog can send 8-bit DAC output to any group of 4 pins, not only the ones associated with it by the table?
I assume you mean the Cog Streamers. Even though the new Smartpin bus is fast enough now I think Chip has probably left the Streamer buses as they were so they can run concurrently without any contention.
PS: Even the idea of Smartpins didn't exist for a long time after the Streamers were first added. The Streamers go right back to before Chip put up the first FPGA image. Back then Cog pin access was just OR'd bit bashing like on the Prop1, so no contention to speak of there.
Just a minor note...
In the VGA 8-bit example, changing dot clock from 25.000 to 25.175 (the standard VGA frequency) causes slight flicker with some images (very hard to see with bird though).
Anyway, changing the visible line's xcont to xzero fixes that.
I believe the smart pin docs cover how to select a cog's DAC channel for streamer output. If I recall, the four lower P bits select the cog number, with the upper bits selecting %101 DAC mode.
I've modified the V13 VGA example be 4-bit color in one of four different resolutions:
VGA, SVGA, WVGA, WSVGA
There are sample bitmaps for each.
Just uncomment settings at top of file and bitmap name at bottom of file to test each one.
I haven't decided what resolution I want to use yet, so making a driver that supports several...
I believe the smart pin docs cover how to select a cog's DAC channel for streamer output. If I recall, the four lower P bits select the cog number, with the upper bits selecting %101 DAC mode.
I guess I just remember wrong...
Right now, it looks like the display driver has to be in Cog#0 so as to output to the P123's VGA connector, attached to P0,P1,P2,P3
I thought it was changed so that any cog could output on any set of 4 pins, but doesn't look like it was.
So, I'm copying the palette copy to LUT code from ozpropdev and see something I don't understand:
Shouldn't "orgh" force following data to start at least at $400?
It looks like orgh by itself does nothing...
I have to do "orgh $400" to make the following data start in the hub only area...
I generally use ORGH by itself to tell Pnut that the following code will be hubexec.
Also consider that the initial(main) cog code only has to be 256 longs in length to pass $400 hub address.
BTW. What code of mine were you referring to?
On a somewhat different line I was staring at the Streamer instructions in the Prop2Doc and was a little perplexed by the fact that XCONT, for example, has a syntax stating XCONT D/#,S/# (ie: With optional immediates). Looking at all the parameter requirements and thinking there is no way they can fit in 9-bit immediate operands ... I've seen that before but kind of ignored the confusion as just me not seeing the obvious.
I then ponder if maybe the obvious is a presumption of many applications of the ORGD/ORGS instructions? I guess so. /me wonders how many such hidden prefixes are implied in the documentation ...
On a somewhat different line I was staring at the Streamer instructions in the Prop2Doc and was a little perplexed by the fact that XCONT, for example, has a syntax stating XCONT D/#,S/# (ie: With optional immediates). Looking at all the parameter requirements and thinking there is no way they can fit in 9-bit immediate operands ... I've seen that before but kind of ignored the confusion as just me not seeing the obvious.
I then ponder if maybe the obvious is a presumption of many applications of the ORGD/ORGS instructions? I guess so. /me wonders how many such hidden prefixes are implied in the documentation ...
You mean AUGD/AUGS (Sounds the same with a Aussie/kiwi accent)
In most of the P2 video examples XCONT/XZERO are used with a pre defined long value for use with D.
Using the AUGD variant would make the code easier to understand as the relevant value is right there.
'copy color palette to lut ram
mov x,#0
loc ptrb,#@palette
rep @.loop,#16 '16 colors
rdlong y,ptrb++
and y,##$ffffff00 'make sure not messing with lower byte (hsync)
wrlut y,x
add x,#1
.loop
The problem is that ptrb++ requires the data to be above $400
My code is currently small enough that it wasn't.
Thought "orgh" by itself would ensure it was pushed to at least $400.
I think it would be convenient if it would...
Or, if there was another mechanism to do this...
Here's something else I don't understand, having to do with: "@"
This is cogexec code:
DAT 'Clear Screen
ClearScreen
mov gt1,gb 'make a byte with two 4-bit background colors
setnib gt1,gb,#1
movbyts gt1,#0 'make a long with eight 4-bit background colors
mov ptra,PA 'video bufferbuffer
rep @.loop,##w*h/8
wrlong gt1,ptra++
.loop
ret
I think the "rep" command should work with:
rep #.loop,##w*h/8
But it doesn't.
The instructions.txt file implies that "@" returns hub address, but this is cog code...
Try this simpler variant.
Note the use of the "\" symbol directing Pnut to use absolute adressing.
loc ptrb,#\palette
setq2 #15
rdlong 0,ptrb
from the instruction notes
For immediate-branch and LOC address operands, "#" is used before the
address. In cases where there is an option between absolute and relative
addressing, the assembler will choose absolute addressing when the branch
crosses between cog and hub domains, or relative addressing when the
branch stays in the same domain. Absolute addressing can be forced by
following "#" with "\".
Comments
In Async Tx/Rx smart pin modes the NCO formula/ configuration has changed. See Docs.
Example
This was done to allow baud rates with 6 bits of resolution below a clock period.
If it just sets all 4 bytes in the long to the same value, it seems like it would now take two or three instructions:
That's what SETBYTS did?
Edit: oh. yes. it is. (see https://github.com/Seairth/P2UnitTests/blob/master/test_movbyts.spin)
I assume you mean the Cog Streamers. Even though the new Smartpin bus is fast enough now I think Chip has probably left the Streamer buses as they were so they can run concurrently without any contention.
PS: Even the idea of Smartpins didn't exist for a long time after the Streamers were first added. The Streamers go right back to before Chip put up the first FPGA image. Back then Cog pin access was just OR'd bit bashing like on the Prop1, so no contention to speak of there.
In the VGA 8-bit example, changing dot clock from 25.000 to 25.175 (the standard VGA frequency) causes slight flicker with some images (very hard to see with bird though).
Anyway, changing the visible line's xcont to xzero fixes that.
It's just the "setdacs" that only goes to fixed pins depending on cog #
VGA, SVGA, WVGA, WSVGA
There are sample bitmaps for each.
Just uncomment settings at top of file and bitmap name at bottom of file to test each one.
I haven't decided what resolution I want to use yet, so making a driver that supports several...
I guess I just remember wrong...
Right now, it looks like the display driver has to be in Cog#0 so as to output to the P123's VGA connector, attached to P0,P1,P2,P3
I thought it was changed so that any cog could output on any set of 4 pins, but doesn't look like it was.
So, I'm copying the palette copy to LUT code from ozpropdev and see something I don't understand:
Shouldn't "orgh" force following data to start at least at $400?
It looks like orgh by itself does nothing...
I have to do "orgh $400" to make the following data start in the hub only area...
I generally use ORGH by itself to tell Pnut that the following code will be hubexec.
Also consider that the initial(main) cog code only has to be 256 longs in length to pass $400 hub address.
BTW. What code of mine were you referring to?
I then ponder if maybe the obvious is a presumption of many applications of the ORGD/ORGS instructions? I guess so. /me wonders how many such hidden prefixes are implied in the documentation ...
In most of the P2 video examples XCONT/XZERO are used with a pre defined long value for use with D.
Using the AUGD variant would make the code easier to understand as the relevant value is right there.
I borrowed this little snippet:
'copy color palette to lut ram mov x,#0 loc ptrb,#@palette rep @.loop,#16 '16 colors rdlong y,ptrb++ and y,##$ffffff00 'make sure not messing with lower byte (hsync) wrlut y,x add x,#1 .loopThe problem is that ptrb++ requires the data to be above $400
My code is currently small enough that it wasn't.
Thought "orgh" by itself would ensure it was pushed to at least $400.
I think it would be convenient if it would...
Or, if there was another mechanism to do this...
This is cogexec code:
DAT 'Clear Screen ClearScreen mov gt1,gb 'make a byte with two 4-bit background colors setnib gt1,gb,#1 movbyts gt1,#0 'make a long with eight 4-bit background colors mov ptra,PA 'video bufferbuffer rep @.loop,##w*h/8 wrlong gt1,ptra++ .loop retI think the "rep" command should work with: But it doesn't.
The instructions.txt file implies that "@" returns hub address, but this is cog code...
Try this simpler variant.
Note the use of the "\" symbol directing Pnut to use absolute adressing.
from the instruction notes
I see in Chip's VGA 8bpp example that he uses "@" with REP, so I guess that's how it's supposed to be. Seems a little strange though...