Prop2 FPGA files!!! - Updated 28 February 2017 - Version 16a

17172737476

Comments

  • Maybe it should be called something like LMAX and LMIN for limit max/min, like in P1...
    Prop Info and Apps: http://www.rayslogic.com/
  • maybe something with MIN in its name should result with the smaller of two provided values, not the bigger one?

    this limit Min/Max is (next to <=,>=) the biggest pain of Spin.

    Enjoy!

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • SeairthSeairth Posts: 1,992
    edited March 7 Vote Up0Vote Down
    Rayman wrote: »
    Maybe it should be called something like LMAX and LMIN for limit max/min, like in P1...

    Unfortunately, on the P1 it's also called MAX/MIN.
  • You're right! I thought these were new to P2, but they are not...
    Prop Info and Apps: http://www.rayslogic.com/
  • These are a weird thing on Propeller. I have been bitten by the min and max not really being min and max a few times.
    I see the need for the limit versions, but the names are just wrong. Min and max universally (everywhere but Propeller) means give me the min or max of the two operands.

  • Since it's this way in P1, I guess it doesn't make sense to change it...

    Just have to remember that Limit Maximum == Take Minimum...
    Prop Info and Apps: http://www.rayslogic.com/
  • It's frustrating that MIN and MAX are quite literally named backwards of what they actually do.

    From the manual:

    MIN Value1, <#> Value2
    Result: Greater of unsigned Value1 and unsigned Value2 is stored in Value1.

    MAX Value1, <#> Value2
    Result: Lesser of unsigned Value1 and unsigned Value2 is stored in Value1.

    Chip,
    Why oh why did you do this?????

    I really think that for P2, we should fix this. The P2 PASM is already very different from P1, so it's not a big deal.

  • jmgjmg Posts: 9,271
    Roy Eltham wrote: »
    It's frustrating that MIN and MAX are quite literally named backwards of what they actually do.

    From the manual:

    MIN Value1, <#> Value2
    Result: Greater of unsigned Value1 and unsigned Value2 is stored in Value1.

    MAX Value1, <#> Value2
    Result: Lesser of unsigned Value1 and unsigned Value2 is stored in Value1.

    Chip,
    Why oh why did you do this?????

    I really think that for P2, we should fix this. The P2 PASM is already very different from P1, so it's not a big deal.

    Yes, that certainly is backwards and it does need fixing.

    If new names are assigned for P2, then P1 Spin can pick those up too, and the older (wrong) ones can be deprecated.
    ie still work in old source, but all new code uses the operands that actually do what they say.

  • Yes! Those descriptions would lead one astray.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • I'm wondering what work is left to be done on the FPGA before freezing the design and starting chip synthesis. I know Chip wants to get the P2 Spin bytecode interpreter running to see if any tweaking needs to be done there. It seems like this can be accomplished by porting the P1 Spin interpreter, and modifying it to run efficient on the P2.

    Another thing to be done if for everyone to re-run the stuff that they've done with previous versions of the FPGA. This will help to uncover potential areas that may not run as efficiently as before, or may not even work anymore. Others may feel like me, and are reluctant to do this because the FPGA may change again. So it would be nice to get assurances that this really is the final FPGA, except for some minor fixes that may be needed.

    It seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
  • Dave Hein wrote: »
    IIt seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
    Is there documentation on how the ROM loader works?

  • Dave HeinDave Hein Posts: 5,002
    edited March 8 Vote Up0Vote Down
    It appears that Chip implemented the loader in the FPGA back in September, and he documented it at that time.
    cgracey wrote: »
    I just finished documenting the serial loader and boot process. It's at the end of the Google doc.

    Have any of you guys had a conversation via a terminal with the serial loader, yet?
    I'm not aware of anybody writing a loader that works with the FPGA.
  • There's nothing much to write, being simple and serial based (either text or hex).

    Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
  • jmgjmg Posts: 9,271
    David Betz wrote: »
    Dave Hein wrote: »
    IIt seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
    Is there documentation on how the ROM loader works?
    I think the ROM loader ideally needs a separate thread, and a separate .DOC

    Tubular wrote: »
    There's nothing much to write, being simple and serial based (either text or hex).
    Jmg was loading it from a small micro ....

    There are still quite some details around supported Bauds and Auto baud schemes, and the Boot Tree decisions/delays, as well as the Pin mapping.
    The UART transport layer is straightforward.

    FWIR, Chip planned to nudge the RCFast to MIN of 20MHz, rather than typical, and the UART Autobaud improved to I think close to 2MBd.
    Small MCUs can manage 1~2MBd commonly, with some capable of 3~4MBd

    I did some code for one-pin loading from a sub-40c MCU, but I'm not sure of the final outcome of 1-2-3-4 pin boot.
  • Tubular wrote: »
    There's nothing much to write, being simple and serial based (either text or hex).

    Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
    Has anybody written a stand-alone program that will load the P2? The protocol looks simple, but the program would also need to reset the P2 and establish a serial link before the boot loader switches to the flash chip. Can programs be burned into the flash chip? Basically I'm looking for the same kind of functionality that the P1 loaders provide.


  • Dave Hein wrote: »
    Tubular wrote: »
    There's nothing much to write, being simple and serial based (either text or hex).

    Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
    Has anybody written a stand-alone program that will load the P2? The protocol looks simple, but the program would also need to reset the P2 and establish a serial link before the boot loader switches to the flash chip. Can programs be burned into the flash chip? Basically I'm looking for the same kind of functionality that the P1 loaders provide.

    I will do that once I have a description of the ASCII protocol. I've seen scattered examples of it in forum threads but not a description of it. I've sent Chip email asking for one.

  • The protocol is described in the Prop documentation under the heading "SERIAL LOADING PROTOCOL"
    Melbourne, Australia
  • jmgjmg Posts: 9,271
    David Betz wrote: »
    I will do that once I have a description of the ASCII protocol. I've seen scattered examples of it in forum threads but not a description of it. I've sent Chip email asking for one.

    In the Prop2 DOCs, under the heading BOOT PROCESS, there is some info.
    Autobaud is using ">"

    loader commands include Prop_Chk, Prop_Hex, Prop_Txt (64b)

    Half duplex is via a suffix '*', but there seems no fast-ping (single char, or ">"+CharPing) ?
    ( "?" is always 10ms in the docs )
    ie on systems with variable reset exit delays, the host has no simple means to 'poll until exits reset'
    I guess you can sent repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?

    If the Prop executes a software reset, it's not clear how the boot-serial server can know that ?

    For normal bench use, I think you can use a UART with 2 handshake lines to
    a) reset the P2
    b) with 2 resistors, control the "pull-up on SPI_CS" test, to select SPI or UART boots

    For flashing (UART -> Flash PGM), I think you first download a UART2SPI-pgm stub, then "~" launches that.


  • ozpropdev wrote: »
    The protocol is described in the Prop documentation under the heading "SERIAL LOADING PROTOCOL"
    Thanks! I thought I had looked through that document but I must have missed it.

  • I think the Verilog is DONE, barring any bug fixes needed.

    The ROM booter code may get some minor changes, but the protocol should stay the same. For example, I need to add the PRNG seeding from the ADC to the ROM booter.
  • Ahle2Ahle2 Posts: 906
    edited March 9 Vote Up0Vote Down
    Let's celebrate the king with a Cake! :)

    20152_m.jpg
    SIDcog - The sound of the Commodore 64 in a single cog: Thread, OBEX, SIDcogMedlay.mp3
    AYcog - An emulation of the AY3-8910 / YM2149F PSG: Thread, OBEX
    SNEcog - An emulation of the SN76489 PSG(and variants): Thread, OBEX
    Propeller chiptune player: Thread
  • Oh yeah! LMAO!
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmgjmg Posts: 9,271
    cgracey wrote: »
    I think the Verilog is DONE, barring any bug fixes needed.

    The ROM booter code may get some minor changes, but the protocol should stay the same. For example, I need to add the PRNG seeding from the ADC to the ROM booter.

    It may need some tweaks around Reset exit handling.
    Looking more at the existing ping, of "send repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?"
    - one issue I see here is the">" works fine, provided that is the first Char P2 sees.

    However, what if the P2 reset-exit is delayed so it thinks some other char, is Autobaud ?
    You could resolve that with an echo on autobaud ">",(ie sending host merely repeats ">") but now there is a simplex/duplex issue.
    If it does not have two Autobaud chars, maybe it needs
    ">"+Char for AutoBaud, Duplex,
    ">"+Char("*"?) for Autobaud, Half-duplex (one pin)
    Where the trigger chars are selected so reset-exit anywhere in either RX char, is safe.
    ("*" does not look great, with 0x2A value ?)
    and both forms echo reply of one char after second char.

    A second area is around host-loaders, and watchdog resets.
    Here, the host needs to know P2 did a self-reset.
    An IO pin with SW pulldown, could signal to the host by floating hi on reset & then host pulses P2 RST.
  • I'm sure this has been discussed before, but I'm not sure I like or understand the LOC syntax...

    Using ##@ appears to work for me everywhere except on LOC.

    These things appear to work the same:
    loc       ptra,#@RomFont1 
    loc       ptra,#RomFont1
    

    But, wouldn't it be better if this worked:
    loc       ptra,##@RomFont1
    
    Prop Info and Apps: http://www.rayslogic.com/
  • SeairthSeairth Posts: 1,992
    edited March 10 Vote Up0Vote Down
    Rayman wrote: »
    I'm sure this has been discussed before, but I'm not sure I like or understand the LOC syntax...

    Using ##@ appears to work for me everywhere except on LOC.

    These things appear to work the same:
    loc       ptra,#@RomFont1 
    loc       ptra,#RomFont1
    

    But, wouldn't it be better if this worked:
    loc       ptra,##@RomFont1
    

    The LOC instruction (and a few others) contains a 20-bit field. No need for ## (AUGx).

    Edit: For a little more information clarification, "#label" and "#@label" are identical for labels defined in an ORGH section. The only place you must use a "#@" is when you want the address in hub memory of a label defined in the ORG section. Of course, if you are calling something like WRLONG and want to sepecify a hub address over $1FF, you then must use "##label" or "##@label".

    But there is one exception. There are six instructions that contain a 20-bit address field. These do not require a preceding AUGx instruction, so you would still only use "#label" or "#@label" with these. Look at the end of Chip's spreadsheet to see which instructions are in this set.

    In truth, PNUT could probably be updated to make "##" benign for those instructions. I could see how someone might want to use "##@label" for all hub label references, just for consistency sake.
  • RaymanRayman Posts: 8,067
    edited March 11 Vote Up0Vote Down
    Guess I don't understand how to use the new "ALTGN" instruction...
    Tried replacing the commented code with it, but doesn't work:
    mGetTileColorSet
                  call      #mGetTileColorsetLong
                  'and       mK,#%111 'get nibble number 
                  'andn      mGetNibT,##%111<<19
                  'shl       mK,#19
                  'or        mGetNibT,mK            
                  'nop
                  'nop
                  altgn     mk              
    mGetNibT      getnib    mcolorset,mb,#0
                  RET
    

    Anybody see what I'm doing wrong?
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 8,067
    edited March 12 Vote Up0Vote Down
    Ok, I see what's going on.... Nevermind....

    Seems ALTGN is only useful for a nibble array in cog ram.
    Not so useful when nibble array is in HUB ram.

    Actually, can do it like this:
    call      #mGetTileColorsetLong
                  and       mK,#%111 'get nibble number 
                  'andn      mGetNibT,##%111<<19
                  'shl       mK,#19
                  'or        mGetNibT,mK            
                  'nop
                  'nop
                  or        mk,##mb<<3
                  altgn     mk                            
    mGetNibT      getnib    mcolorset,mb,#0
                  RET
    

    Guess this is better than self-modifying code.

    Prop Info and Apps: http://www.rayslogic.com/
  • I've already found ALTGN to be quite useful.
    I needed a fast way to get the bit count in a nibble so I did this
    		altgn	ax,#bit_count
    		getnib	bx,0-0,#0
    '
    '
    bit_count	long	$32212110	'7..0	
    		long	$43323221	'F..8
    

    BTW. In my "Prop2 interactive Debugger" it includes sample code that demonstrates ALTGN/ALTSN.

    Melbourne, Australia
  • Just thinking about this alt stuff...

    If there was one that worked on the BITx instructions, then couldn't it replace all the DIRx, OUTx, etc. instructions?

    This is just a theoretical question, not actually asking for it...

    Anyway, could you have an ALTBIT instruction that would replicate OUTH like this:
    'OUTH #43
    ALTBIT #43
    BITH OUTA,#0-0
    

    Could that work? The altbit taking the lower 6 bits of operand and putting them into BITH's source and adding the 7th bit to BITH's destination?

    Just wondering...
    Prop Info and Apps: http://www.rayslogic.com/
  • Just found out that PNUT has a limit of 32 DAT include files
    279 x 134 - 4K
    Prop Info and Apps: http://www.rayslogic.com/
Sign In or Register to comment.