Shop Learn
FlexProp: a complete programming system for P2 (and P1) - Page 13 — Parallax Forums

FlexProp: a complete programming system for P2 (and P1)

1101113151619

Comments

  • yetiyeti Posts: 772

    An overlay system like OpenSpin showed somewhen (2014) would be nice.
    But maybe having that is already ™good enough™ in the P1 world.

    (I attached it because I wasn't in the mood for disarming my watchdogs for being able to search the forum via Bad-Big-G.)

  • RaymanRayman Posts: 11,976

    @Wuerfel_21 said:

    • during the load the original program has to remain resident (it's busy doing the load) so both programs must fit into HUB memory together.


    Lame :)
    P1 SD drivers can boot full 32k executables, P2 surely should be able to manage it, too.

    I wonder if you could chain two execs to load a bigger one... First, load and execute a tiny program that only loads the big program...

  • ersmithersmith Posts: 4,890

    @Wuerfel_21 said:

    • during the load the original program has to remain resident (it's busy doing the load) so both programs must fit into HUB memory together.


    Lame :)
    P1 SD drivers can boot full 32k executables, P2 surely should be able to manage it, too.

    P1 SD drivers also take up one or two cogs, whereas the flexprop driver does not, and the P1 loaders can't load a file from the PC.
    I don't really want to use a cog all the time just on the off chance someone might want to CHAIN a program which is bigger than the free memory.
    But I'm always open to suggestions, so if someone has a good idea of how to improve this I hope she'll submit a pull request :).

  • ersmithersmith Posts: 4,890

    @Rayman said:

    @Wuerfel_21 said:

    • during the load the original program has to remain resident (it's busy doing the load) so both programs must fit into HUB memory together.


    Lame :)
    P1 SD drivers can boot full 32k executables, P2 surely should be able to manage it, too.

    I wonder if you could chain two execs to load a bigger one... First, load and execute a tiny program that only loads the big program...

    Sure, you could do that.

  • ersmithersmith Posts: 4,890

    @yeti: Looks like that overlay code depends on (a) the layout of the Spin-1 bytecode, and (b) the fact that Spin-1 bytecode is relocatable. So adapting it for fastspin would basically be a re-write :(.

  • @ersmith said:

    @Wuerfel_21 said:

    • during the load the original program has to remain resident (it's busy doing the load) so both programs must fit into HUB memory together.


    Lame :)
    P1 SD drivers can boot full 32k executables, P2 surely should be able to manage it, too.

    P1 SD drivers also take up one or two cogs, whereas the flexprop driver does not, and the P1 loaders can't load a file from the PC.
    I don't really want to use a cog all the time just on the off chance someone might want to CHAIN a program which is bigger than the free memory.
    But I'm always open to suggestions, so if someone has a good idea of how to improve this I hope she'll submit a pull request :).

    Well yeah, if you use the normal FS code it's not easy to do that. I think it could be improved if the FS/CHAIN code could be compiled into its own relocatable object, which first relocates itself to end of RAM and then loads the program. Then only the size of that would matter. But that'd require support for position independent compilation first.

  • ersmithersmith Posts: 4,890

    @Wuerfel_21 said:

    @ersmith said:

    @Wuerfel_21 said:

    • during the load the original program has to remain resident (it's busy doing the load) so both programs must fit into HUB memory together.


    Lame :)
    P1 SD drivers can boot full 32k executables, P2 surely should be able to manage it, too.

    P1 SD drivers also take up one or two cogs, whereas the flexprop driver does not, and the P1 loaders can't load a file from the PC.
    I don't really want to use a cog all the time just on the off chance someone might want to CHAIN a program which is bigger than the free memory.
    But I'm always open to suggestions, so if someone has a good idea of how to improve this I hope she'll submit a pull request :).

    Well yeah, if you use the normal FS code it's not easy to do that. I think it could be improved if the FS/CHAIN code could be compiled into its own relocatable object, which first relocates itself to end of RAM and then loads the program. Then only the size of that would matter. But that'd require support for position independent compilation first.

    And would also need a different version for each file system :(. I initially thought that maybe we could just provide a small "stream to RAM" function in each file system that could run in COG or LUT ram, but for FAT that would still need to parse the FAT table, and for other file systems there would be similar issues. There's probably something clever we could do to minimize the amount of code required, but I really don't know if it's that big a deal. I guess we'll see how much the CHAIN feature gets used.

  • @ersmith said:
    And would also need a different version for each file system :(. I initially thought that maybe we could just provide a small "stream to RAM" function in each file system that could run in COG or LUT ram, but for FAT that would still need to parse the FAT table

    You could just do it ahead of time and store the necessary cluster offsets into an array. Or just check if the file is fragmented and return an error if it is. (The latter is what I usually do...).
    If you drag a fresh file onto an SD card, it is usually never fragmented. IME it only becomes fragmented if you then copy other files onto it afterwards and then paste a bigger version of the first file.

  • Cluso99Cluso99 Posts: 17,720

    In P1 the SD loader code resided totally in hub once it was called.
    I.ve done the same with my SD driver - it can locate a file 8+3 in the root directory (FAT32) and load the file into hub $0 and execute it. Don't recall if I've actually booted it yet, but it certainly can load it.
    So yes, it's definitely doable!

  • Eric,

    I just compiled and tested your fcache fix and it worked. The program no longer crashes.

    Mike

  • ersmithersmith Posts: 4,890

    @iseries said:
    Eric,

    I just compiled and tested your fcache fix and it worked. The program no longer crashes.

    Mike

    That's good to hear. Thanks for checking this, Mike!

  • Anyone know where I need to put the C header files (math.h and friends) such that flexspin can find them? I tried in the same directory as the exe and the directory above, to no avail.

  • ersmithersmith Posts: 4,890

    Typically flexspin goes in $ROOT/bin, and the include files in $ROOT/include, where ROOT is whatever you want (e.g. /usr/local/p2tools). There's also a FLEXSPIN_INCLUDE_PATH environment variable which you can set to explicitly override this.

  • Does the directory have to be /bin or can it be anything?

  • ersmithersmith Posts: 4,890

    It can be anything, flexprop looks in ../include relative to its own executable name.

  • For some reason, it just started working. I have literally no idea why.

  • Also, gotta say thanks for that Spin1-on-P2 feature. Super useful. Already have SpinHexagon running on P2 in 1024x768. Now I just need the keyboard code to work (and I need to implement audio/highscores, I guess)

  • Wuerfel_21Wuerfel_21 Posts: 1,686
    edited 2021-02-23 01:59

    Also: Is there a way to use floats in Spin? (Aside from the referencing a C file in an OBJ block)

  • RaymanRayman Posts: 11,976

    For flexspin.exe, one needs to tell the include directory, like this:
    C:\FlexSpin\flexspin.exe -2 -O1 -L C:\FlexSpin\include EditP2.c

  • ersmithersmith Posts: 4,890

    @Wuerfel_21 said:
    Also: Is there a way to use floats in Spin?

    Just the usual way, by including a float object. Spin doesn't have data types, so something like "1.0" just gets converted to the IEEE binary representation 0x3f800000 and after that treated like any other 32 bit value, so "1.0 + 1" will give 0x3f800001.

    Actually I guess you could skip the float object and directly call into the built in floating point routines for BASIC and C:

    _float_add(x, y)
    _float_sub(x, y)
    _float_mul(x, y)
    _float_div(x, y)
    _float_negate(x)
    _float_abs(x)
    _float_sqrt(x)
    _float_fromint(x) ' converts integer to float
    _float_trunc(x)     ' converts float to integer
    _float_cmp(x, y, u) ' compare x to y, return negative if x < y, 0 if x=y, positive if x>y, u if x or y is NaN
    
  • Hi

    I would like to do the following

    dim shared as ubyte vfont(800)={$00, $00, $00, $00, $00, $00, $00, $00,_ 'space
    $30, $78, $78, $30, $30, $00, $30, $00,_ ' !
    $6C, $6C, $28, $00, $00, $00, $00, $00,_ ' " "
    $6C, $6C, $FE, $6C, $FE, $6C, $6C, $00,_ ' #
    $18, $7E, $C0, $7C, $06, $FC, $18, $00,}' $

    but only this works-

    dim shared as ubyte vfont(800)={$00, $00, $00, $00, $00, $00, $00, $00,_
    $30, $78, $78, $30, $30, $00, $30, $00,_
    $6C, $6C, $28, $00, $00, $00, $00, $00,_
    $6C, $6C, $FE, $6C, $FE, $6C, $6C, $00,_
    $18, $7E, $C0, $7C, $06, $FC, $18, $00}

    Is there a way of including comments with these tables (arrays)

    Dave

  • ersmithersmith Posts: 4,890

    @tritonium : You'll have to use inline comments like /' space '/, and put them before the _, like:

    $00, $00, /' space '/ _
    $40, $00, /' some other character '/ _
    

    The document calls these "multi-line" comments, but they don't actually have to span any lines, so I need to fix that. They're just like C /* comment */.

  • Eric

    Thanks again.
    what I tried was...

    $00, $00, _/' space '/
    $40, $00, _/' some other character '/

    and that didn't work

    Dave

  • JRoarkJRoark Posts: 728
    edited 2021-02-23 21:03
    Deleted (he fixed it. Good!)
  • @ersmith ,

    While your playing with SD card functions you need to fix long file name support.
    In ff.c:

    #if FF_USE_LFN
        strncpy(ent->d_name, finfo.altname, _NAME_MAX-1);
        ent->d_name[_NAME_MAX-1] = 0;
    #else
        strcpy(ent->d_name, finfo.fname);
    #endif
    

    should be changed to this:

    #if FF_USE_LFN
        strncpy(ent->d_name, finfo.fname, _NAME_MAX-1);
        ent->d_name[_NAME_MAX-1] = 0;
    #else
        strcpy(ent->d_name, finfo.fname);
    #endif
    

    Long file name support already copies the long file name into the correct name.

    Mike

  • ersmithersmith Posts: 4,890

    Thanks, Mike!

  • ersmithersmith Posts: 4,890

    FlexProp version 5.2.0 is available now from the usual places. The changes are pretty much all in the compiler, and include:

    - Added GET as keyword to BASIC
    - Added GET and PUT binary I/O to BASIC
    - Added _vfs_open_sdcardx() to allow explicit setting of pins for SD card
    - Added new option -Wmax-errors=N to allow more errors to be printed in a run
    - Added new option -Wabs-paths to print absolute paths in error messages
    - Changed Spin2 member variables to be layed out in the order declared
    - Fixed QCOS, QSIN
    - Fixed a crash with negative ending values in repeat
    - Fixed a problem with SEND(func(...)) in Spin2
    - Fixed a problem with initializing two dimensional C arrays with strings
    - Modified P2 serial receive to use @evanh's suggestion of 28 bit async receive (so it is effectively 3 characters at a time)
    
  • Cluso99Cluso99 Posts: 17,720

    Thanks Eric :)

  • ersmithersmith Posts: 4,890
    edited 2021-03-10 16:54

    I've posted a .dmg file for Mac users to my Patreon page ( https://www.patreon.com/totalspectrum ). This is my first time signing a Mac application, and the process took much longer to figure out than I'd expected :( but hopefully this will make things easier for Mac users.

  • ersmithersmith Posts: 4,890

    For those of you building flexprop from source, the most recent source code no longer depends on openspin (I've changed flexspin to output a Spin stub for P1 that's compatible with the PropLoader build process). This seems to have been a common stumbling block for new users, so I hope it'll make things easier.

Sign In or Register to comment.