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 .
@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 .
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.
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.
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!
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.
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.
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_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
@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 */.
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)
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.
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.
Comments
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.)
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...
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
Sure, you could do that.
@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
.
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.
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.
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
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.
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?
It can be anything, flexprop looks in
../includerelative 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)
Also: Is there a way to use floats in Spin? (Aside from the referencing a C file in an OBJ block)
For flexspin.exe, one needs to tell the include directory, like this:
C:\FlexSpin\flexspin.exe -2 -O1 -L C:\FlexSpin\include EditP2.cJust 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:
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
@tritonium : You'll have to use inline comments like /' space '/, and put them before the _, like:
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
@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); #endifshould 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); #endifLong file name support already copies the long file name into the correct name.
Mike
Thanks, Mike!
FlexProp version 5.2.0 is available now from the usual places. The changes are pretty much all in the compiler, and include:
Thanks Eric
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.
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.