Propeller II update - BLOG

1217218219220221223»

Comments

  • David BetzDavid Betz Posts: 13,554
    edited 2014-03-30 - 09:32:58
    Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?

    Thanks,
    David
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 - 10:12:04
    Here you go:

    http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927
    David Betz wrote: »
    Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?

    Thanks,
    David
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 - 10:30:59
    Argh!

    I can't find Chip's example of using {RD|WR}WIDE with INDA++ to read/write cog memory to/from the hub at one long per clock. Anyone have the link handy?

    I looked at Chip's posting history, searched here and google... and it is buried in a zillion posts :(
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • potatoheadpotatohead Posts: 9,824
    edited 2014-03-30 - 10:45:05
    I have been looking too :(
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • fengfeng Posts: 31
    edited 2014-03-30 - 10:58:50
    I know two things for sure.
    1. I don’t know everything.
    2. I do know how to find the answer.
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-30 - 10:59:51
    Hi.

    Is it this part You look for
    New sustained-RDWIDE/WRWIDE instructions
    ----------------------------------------
    
    RDWIDEA D/#    'read D/# wides using background RDWIDE PTRA++, read conduit is $1F1, 4..11 initial clocks
    RDWIDEB D/#    'read D/# wides using background RDWIDE PTRB++, read conduit is $1F1, 4..11 initial clocks
    
    WRWIDEA D/#    'write D/# wides using background WRWIDE PTRA++, write conduit is $1F1, 1..8 initial clocks
    WRWIDEB D/#    'write D/# wides using background WRWIDE PTRB++, write conduit is $1F1, 1..8 initial clocks
    
    
    ' Transfer from hub to cog
    
                SETPTRA    <hubaddr>
                SETINDA    #<cogaddr>
                REPS    #<wides*8>,#1
                RDWIDEA    #<wides>
                MOV    INDA++,$1F1
    
    
    ' Transfer from hub to aux
    
                SETPTRA    <hubaddr>
                SETPTRX    <auxaddr>
                REPS    #<wides*8>,#1
                RDWIDEA    #<wides>
                WRAUX    $1F1,PTRX++
    
    
    ' Transfer from cog to hub
    
                SETPTRA    <hubaddr>
                SETINDA    #<cogaddr>
                REPS    #<wides*8>,#1
                WRWIDEA    #<wides>
                MOV    $1F1,INDA++
    
    
    ' Transfer from aux to hub
    
                SETPTRA    <hubaddr>
                SETPTRX    #<auxaddr>
                REPS    #<wides*8>,#1
                WRWIDEA    #<wides>
                RDAUX    $1F1,PTRX++
    '(4-way multitasking and 'ICACHEN 'in effect, so no prefetch to disrupt timing)
    
            ALIGNW                    'pad 0's to start of next WIDE block, or icache line (8 instructions follow)
    
    ???        REPTASK    #3+$1F0+1            'execute SETINDA, REPS, RDWIDEA, MOV * $1F0, and dummy MOV
                LOCPTRA    @newcode        'point to new code
                SETINDA    #0            'reset INDA (contiguous pipeline feed for this task begins)
                REPS    #$1F0            'ready to repeat MOV
                RDWIDEA    #8            'start read burst
                MOV    INDA++,$1F1        'load WIDE longs via $1F1 window into $000..$1EF
                NOP                'two trailing instructions need to be in this same icache
                NOP                '..line to avoid fetching during 2nd-to-last move
    
    
                NOTP    #0            'these instructions execute according to the time slots
                NOTP    #0            '('wait' instructions will loop to themselves)
            
                TLOCK                'execute only this task, beginning at the next instruction
                NOTP    #0            'these instructions execute at full-speed
                NOTP    #0            '('wait' instructions will stall the pipeline)
                NOTP    #0
            
                TFREE                'resume multitasking after two more instructions
                NOTP    #0            'these two instructions still execute at full-speed
                NOTP    #0            '('wait' instructions will loop to themselves)
            
                NOTP    #0            'these instructions now execute according to the time slots
                NOTP    #0            '('wait' instructions will loop to themselves)
    
    
    Regards
    Sapieha
    _____________________________________________________
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it as simple as possible yet as versatile/usable as possible.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-30 - 11:16:41
    Sapieha,

    THANK YOU!!!

    That is exactly what I was looking for.
    Sapieha wrote: »
    Hi.

    Is it this part You look for
    New sustained-RDWIDE/WRWIDE instructions
    ----------------------------------------
    
    RDWIDEA D/#    'read D/# wides using background RDWIDE PTRA++, read conduit is $1F1, 4..11 initial clocks
    RDWIDEB D/#    'read D/# wides using background RDWIDE PTRB++, read conduit is $1F1, 4..11 initial clocks
    
    WRWIDEA D/#    'write D/# wides using background WRWIDE PTRA++, write conduit is $1F1, 1..8 initial clocks
    WRWIDEB D/#    'write D/# wides using background WRWIDE PTRB++, write conduit is $1F1, 1..8 initial clocks
    
    
    ' Transfer from hub to cog
    
                SETPTRA    <hubaddr>
                SETINDA    #<cogaddr>
                REPS    #<wides*8>,#1
                RDWIDEA    #<wides>
                MOV    INDA++,$1F1
    
    
    ' Transfer from hub to aux
    
                SETPTRA    <hubaddr>
                SETPTRX    <auxaddr>
                REPS    #<wides*8>,#1
                RDWIDEA    #<wides>
                WRAUX    $1F1,PTRX++
    
    
    ' Transfer from cog to hub
    
                SETPTRA    <hubaddr>
                SETINDA    #<cogaddr>
                REPS    #<wides*8>,#1
                WRWIDEA    #<wides>
                MOV    $1F1,INDA++
    
    
    ' Transfer from aux to hub
    
                SETPTRA    <hubaddr>
                SETPTRX    #<auxaddr>
                REPS    #<wides*8>,#1
                WRWIDEA    #<wides>
                RDAUX    $1F1,PTRX++
    '(4-way multitasking and 'ICACHEN 'in effect, so no prefetch to disrupt timing)
    
            ALIGNW                    'pad 0's to start of next WIDE block, or icache line (8 instructions follow)
    
    ???        REPTASK    #3+$1F0+1            'execute SETINDA, REPS, RDWIDEA, MOV * $1F0, and dummy MOV
                LOCPTRA    @newcode        'point to new code
                SETINDA    #0            'reset INDA (contiguous pipeline feed for this task begins)
                REPS    #$1F0            'ready to repeat MOV
                RDWIDEA    #8            'start read burst
                MOV    INDA++,$1F1        'load WIDE longs via $1F1 window into $000..$1EF
                NOP                'two trailing instructions need to be in this same icache
                NOP                '..line to avoid fetching during 2nd-to-last move
    
    
                NOTP    #0            'these instructions execute according to the time slots
                NOTP    #0            '('wait' instructions will loop to themselves)
            
                TLOCK                'execute only this task, beginning at the next instruction
                NOTP    #0            'these instructions execute at full-speed
                NOTP    #0            '('wait' instructions will stall the pipeline)
                NOTP    #0
            
                TFREE                'resume multitasking after two more instructions
                NOTP    #0            'these two instructions still execute at full-speed
                NOTP    #0            '('wait' instructions will loop to themselves)
            
                NOTP    #0            'these instructions now execute according to the time slots
                NOTP    #0            '('wait' instructions will loop to themselves)
    
    
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-03-30 - 12:21:36
    David Betz wrote: »
    Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?

    Thanks,
    David
    I'll start putting the .zip files out on GitHub. I don't think it will have any problem with .zip files.
    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-03-30 - 13:22:05
    David Betz wrote: »
    Where are the most recent FPGA images? Is there any chance of putting them in a standard place with a date on them so it isn't necessary to search through the various threads to find the current one? I have the one that was released a few weeks ago with hub execution but I think some bugs were fixed since then. Where can I find the newest images?

    Thanks,
    David
    Usually Chip starts a new thread for each major release. The latest revision is maintained in the first post. I then update the sticky (first post) with a link and short description to the new thread.

    However, because this release came without updated docs this process was not followed. I started a new thread and pointed to the release. Chip noted that it was not a full release and use it with caution. Hence I did not update the sticky.

    As soon as the release has updated docs, I am fairly sure Chip will put it in a new thread, and I will update the sticky.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-04-01 - 01:46:18
    I tried this without success so I guess it's not possible...
    I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
                  targ      lmm_x
                  locptra   #_str_vers 
    

    BTW Does anyone recall what TARGN and TARGP do?
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • ozpropdevozpropdev Posts: 2,592
    edited 2014-04-01 - 02:39:47
    Cluso99 wrote: »
    I tried this without success so I guess it's not possible...
    I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
                  targ      lmm_x
                  locptra   #_str_vers 
    

    BTW Does anyone recall what TARGN and TARGP do?

    Ray
    I'd say because PTRA/B are not mapped in COG ram that won't work.
    Also did you try TARG #lmm_x
    IIRC TARGP and TARGN post increment / decrement the TARG destination.
    Brian :)
    Melbourne, Australia
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-04-01 - 04:51:40
    ozpropdev wrote: »
    Ray
    I'd say because PTRA/B are not mapped in COG ram that won't work.
    Also did you try TARG #lmm_x
    IIRC TARGP and TARGN post increment / decrement the TARG destination.
    Brian :)
    No, I will try targ #lmm_x tomorrow hopefully.
    Ah yes, inc and dec.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Dave HeinDave Hein Posts: 5,958
    edited 2014-04-01 - 06:26:58
    Cluso99 wrote: »
    However, because this release came without updated docs this process was not followed. I started a new thread and pointed to the release. Chip noted that it was not a full release and use it with caution. Hence I did not update the sticky.
    Will the docs be updated for this release of the FPGA, or do we need to wait till the next release for updated docs?
  • cgraceycgracey Posts: 11,777
    edited 2014-04-01 - 07:02:07
    Dave Hein wrote: »
    Will the docs be updated for this release of the FPGA, or do we need to wait till the next release for updated docs?


    I should have the docs updated and posted either today or tomorrow.
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-04-01 - 18:50:24
    ozpropdev wrote: »
    Ray
    I'd say because PTRA/B are not mapped in COG ram that won't work.
    Also did you try TARG #lmm_x
    IIRC TARGP and TARGN post increment / decrement the TARG destination.
    Brian :)
    No, TARG does not work with LOCPTRx.
    Perhaps this is because LOCPTRx provides its own fixed target result. It seems that it does not reset TARG as a TARGOFF was required to turn it off for the subsequent instruction.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-01 - 19:40:46
    Equivalent code:
    locptra   #_str_vers
    getptra  lmm_x
    
    Cluso99 wrote: »
    I tried this without success so I guess it's not possible...
    I was trying to put the resultant string address into lmm_x instead of ptra without corrupting ptra.
                  targ      lmm_x
                  locptra   #_str_vers 
    

    BTW Does anyone recall what TARGN and TARGP do?
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-04-01 - 21:56:21
    Yes I have already used that Bill. But using this requires saving PTRx first and restoring after. I can define a long in cog too.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 - 06:17:30
    Got it.

    How about:

    mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this :)
    Cluso99 wrote: »
    Yes I have already used that Bill. But using this requires saving PTRx first and restoring after. I can define a long in cog too.
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Cluso99Cluso99 Posts: 15,477
    edited 2014-04-02 - 06:32:21
    Got it.

    How about:

    mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this :)
    That's a nice solution. Forgot about this one.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 - 06:46:44
    Glad to help!
    Cluso99 wrote: »
    That's a nice solution. Forgot about this one.
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • ozpropdevozpropdev Posts: 2,592
    edited 2014-04-02 - 06:57:00
    Got it.

    How about:

    mov lmm_x, ##_str_vers ' yep, will generate args + move, but more readable with Chip's syntax like this :)

    Adding a note to that.

    This will return a 16 bit address of _str_vers (which must be long aligned)
    In COG mode define a long if 18 bit address is needed.
    In HUBEXEC mode use LOCBASE lmm_x,@_str_vers 'gets 18 bit address
    Brian :)
    Melbourne, Australia
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-02 - 07:04:58
    LOCBASE is nicer if _str_vers is close enough as it is one instruction... but perhaps

    LOCBASE lmm_x, ##_str_vers ' uses AUGS

    would do :)

    I think PNut needs to treat addresses as follows:

    JMPx/CALLx/LOCPTRx - 16 bit address constant embedded, so implied low to 0 bits

    MOV reg, #addr or @addr

    loads 18 bit byte address

    FYI, for all I know that is exactly how it treats it now, have not had time in four days to fire up my DE2-115
    ozpropdev wrote: »
    Adding a note to that.

    This will return a 16 bit address of _str_vers (which must be long aligned)
    In COG mode define a long if 18 bit address is needed.
    In HUBEXEC mode use LOCBASE lmm_x,@_str_vers 'gets 18 bit address
    Brian :)
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
Sign In or Register to comment.