Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 68 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

16566687071160

Comments

  • cgracey wrote: »
    David, are your problems resolved now?
    Yes. I tried reprogramming the FPGA again and this time it worked. I'm not sure why it failed the first few times.

  • FYI Another change in V13
    In Async Tx/Rx smart pin modes the NCO formula/ configuration has changed. See Docs.

    Example
    	wxpin	##((sys_clk / baudrate) * $1_0000) & $FFFFFC00 | 7,#tx_pin
    
  • cgraceycgracey Posts: 14,134
    ozpropdev wrote: »
    FYI Another change in V13
    In Async Tx/Rx smart pin modes the NCO formula/ configuration has changed. See Docs.

    Example
    	wxpin	##((sys_clk / baudrate) * $1_0000) & $FFFFFC00 | 7,#tx_pin
    
    ozpropdev wrote: »
    FYI Another change in V13
    In Async Tx/Rx smart pin modes the NCO formula/ configuration has changed. See Docs.

    Example
    	wxpin	##((sys_clk / baudrate) * $1_0000) & $FFFFFC00 | 7,#tx_pin
    

    This was done to allow baud rates with 6 bits of resolution below a clock period.
  • FYI Another change in V13 is async receive now requires a SHR to align the received data.
  • RaymanRayman Posts: 14,386
    V13 also lost setbyts.... Need to think of a efficient way to replace that...
  • Rayman wrote: »
    V13 also lost setbyts.... Need to think of a efficient way to replace that...

    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:
    SETBYTE     reg, src, #0    'only required if writing to a different register
    SETBYTE     reg, reg, #1
    SETWORD     reg, reg, #1
    
  • or use this
        movbyts reg,#0
    
  • SeairthSeairth Posts: 2,474
    edited 2016-11-08 22:14
    ozpropdev wrote: »
    or use this
        movbyts reg,#0
    

    That's what SETBYTS did?

    Edit: oh. yes. it is. (see https://github.com/Seairth/P2UnitTests/blob/master/test_movbyts.spin)
  • MOVBYTS is also useful for endian swapping buyes in a long.
    	movbyts	reg,#%%0123    'endian swap bytes
    
  • RaymanRayman Posts: 14,386
    Well, that was easy. Maybe setbyts was redundant? Seems that movbyts does what I needed anyway..
  • cgraceycgracey Posts: 14,134
    Is there any other instruction you'd like to see kicked off the island, so that SETBYTS can return?
  • cgracey wrote: »
    Is there any other instruction you'd like to see kicked off the island, so that SETBYTS can return?
    No need to bring back SETBYTS now, MOVBYTS can do the job.

  • RaymanRayman Posts: 14,386
    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?
  • evanhevanh Posts: 15,698
    edited 2016-11-11 22:16
    Rayman wrote: »
    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.
  • RaymanRayman Posts: 14,386
    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.
  • cgraceycgracey Posts: 14,134
    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.
  • evanhevanh Posts: 15,698
    edited 2016-11-12 12:37
    /me thinks that'll be the parallel bit pattern streaming rather than DAC streaming.
  • evanhevanh Posts: 15,698
    Not that I know for sure.
  • RaymanRayman Posts: 14,386
    Ok, I see the streamer can go to any set of pins.

    It's just the "setdacs" that only goes to fixed pins depending on cog #
  • RaymanRayman Posts: 14,386
    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...
  • RaymanRayman Posts: 14,386
    cgracey wrote: »
    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.
  • RaymanRayman Posts: 14,386
    Question about orgh...

    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...
  • Rayman wrote: »
    Question about orgh...

    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?


  • evanhevanh Posts: 15,698
    edited 2016-11-13 05:23
    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 ...
  • evanh wrote: »
    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) :lol:

    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.





  • evanhevanh Posts: 15,698
    Oops, lol. You're right, I pronounce them the same ... and I'm not coding.
  • RaymanRayman Posts: 14,386
    ozpropdev wrote: »
    BTW. What code of mine were you referring to?

    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               
    .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...

  • RaymanRayman Posts: 14,386
    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...
  • @rayman

    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 "\".

  • RaymanRayman Posts: 14,386
    thanks for reminding me about "\", that should fix that problem.

    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...
Sign In or Register to comment.