Now I’ve moved on all P2 is .spin2 and I edit with VSCode which highlights the operators and indentation nicely. I now find it preferable to editing in PropTool for both P1 and P2. VSCode is open source and cross platform and I have .spin and .spin2 highlighting. Works nicely in dark mode (black background). It’s now my go to editor that I use every day in my python programming for work.
On that note, (not wanting to take too much away from this thread...) for Mac users, SubEthaEdit works well as an editor... I use a .spin2 mode addition (Spin2.seemode) that does a 'fair' job of syntax highlighting. I can attach in a new forum posting with the mode file with instructions for interested macOS users.
dgately
When I invented the unsigned comparison operators it was in the context of Spin1, so unsigned greater than or equal to is written "+=<". When Chip took them over into Spin2 he changed it to "+<=". I didn't realize that, I'll add an alias for them in Spin2. Meanwhile you can write code that works in both compilers by using the fact that "a +<= b" is equivalent to "NOT (b +> a)".
Thanks Eric.
This was a great feature to invent by the way. It saves extra comparisons particularly with invalid argument checking where you are validating values that you don't want to be negative or higher than a maximum limit, given there are no explicit "unsigned" types in Spin2 that would otherwise be used for achieving this.
Spin (1 & 2) does not execute random code at the end of the code. It shuts down the cog (and tristates the pins).
The endless repeat at the end is for keeping the cog alive, and the pins in their current states. For Smartpins that may not be necessary. Edit: It is, because DIRx goes low and disables the smartpin.
Eric,
Here is a test program I've compiled with all the optimization levels and behaves differently with -O2 compared to -O1 and -O0. See the ***** comments in TestProgram.spin2. Rayman, in another thread, made some corrections in TestProgram and said that it worked for him. I still haven't had much luck there.
@"Mike Green" : it looks like sdspi_bashed.spin2 is using ptra, which is the fastspin stack pointer, in some of its internal code. If you do a global search and replace of "ptra" to "ptrb" then it seems to work. The code does try to save and restore ptra, I think, but I suspect the optimizer is getting confused by the unexpected uses of ptra and that's causing -O2 to fail.
To be honest I suspect that the inline assembly is probably redundant, the code looks straightforward enough that the compiler could probably produce pretty much the same thing from plain Spin.
@Rayman: if you use loadp2's built in terminal then there's no need to start another one to catch messages .
Eric,
Thanks. I'll make the change in sdspi_bashed. About the missing ")", it's easy to leave out, particularly if I've been doing some C coding too. I've run into a warning that I'm only referencing the first character in a string. I'm used to writing "x" for a single character passed to a method. I assume using single quotes like in C is what I'm supposed to do. There's some confusion in my head about using single quotes to introduce a comment though.
I am in need of a download program to send (normally a propeller binary) file to the P2 for my OS to store on the SD card. Ultimately it will go both ways. It must not reset the P2 as the OS code is already running. I wrote a program to do this maaaany years ago. I use a very simple set of control characters and a basic sum for crc, nothing fancy.
But I figure that I would be better taking the existing LOADP2 program an modifying it to do this. Then perhaps it could be an optional parameter later. This way it's multi-platform too.
So, I guess there is the source in Eric's github. Are there any gotchas, and are there instructions to compile, and what do I need???
I haven't looked yet, but just wanting to get a leg up for when I get time next.
I am in need of a download program to send (normally a propeller binary) file to the P2 for my OS to store on the SD card. Ultimately it will go both ways. It must not reset the P2 as the OS code is already running. I wrote a program to do this maaaany years ago. I use a very simple set of control characters and a basic sum for crc, nothing fancy.
But I figure that I would be better taking the existing LOADP2 program an modifying it to do this. Then perhaps it could be an optional parameter later. This way it's multi-platform too.
So, I guess there is the source in Eric's github. Are there any gotchas, and are there instructions to compile, and what do I need???
I haven't looked yet, but just wanting to get a leg up for when I get time next.
I am in need of a download program to send (normally a propeller binary) file to the P2 for my OS to store on the SD card. Ultimately it will go both ways. It must not reset the P2 as the OS code is already running.
But I figure that I would be better taking the existing LOADP2 program an modifying it to do this. Then perhaps it could be an optional parameter later. This way it's multi-platform too.
You don't need to modify loadp2. What you probably want to do is to take advantage of loadp2's built in file server. It uses the 9p network file system protocol (a very simple protocol developed for the plan9 operating system, the successor to Unix) to allow programs running on the P2 to access files on the PC.
So you'd have your P2 program open a file on the PC (with 9p), open a file on the SD (with fsrw or whatever SD object you use) and then copy data from one to the other, in either direction.
For this to work you'll have to launch your original OS with loadp2, and use loadp2's "-9 C:\PATH\TO\ROOT" option to specify a root directory for the 9p file server. The default in FlexGUI is to run with "-9.", which uses the current directory on the PC as the root for the remote file system; that means that the P2 can access any files or directories in the current directory (or under it).
The sample OS that I posted on your thread (myos.zip) uses 9p to read the files from the PC, since at the time I didn't have an SD card implementation handy. There are also samples in the FlexGUI samples\fileserver folder.
Note that the actual 9p object I used (fs9p.cc) is written in FlexC. If you need to use it from Chip's Spin interpreter you'll have to translate it to Spin. That shouldn't be difficult. On the other hand if your OS can load and run arbitrary PASM programs you could leave it as C and compile it with fastspin, which would save you some work.
Thanks. I'll make the change in sdspi_bashed. About the missing ")", it's easy to leave out, particularly if I've been doing some C coding too. I've run into a warning that I'm only referencing the first character in a string. I'm used to writing "x" for a single character passed to a method. I assume using single quotes like in C is what I'm supposed to do. There's some confusion in my head about using single quotes to introduce a comment though.
In Spin you always use double quotes for characters, and "xyz" is equivalent to the 3 character list "x", "y", "z". That's why to get a pointer to a string you have to use STRING("xyz"). The most recent fastspin also lets you write @"xyz" to mean the same thing as STRING("xyz"). @"Jeff Martin" , @cgracey , and I discussed this notation quite a while ago, and I hope Chip may add it to his interpreter at some point.
There's a very nice Spin2 feature (also implemented by fastspin) called SEND which is useful too: you can do something like:
which causes the method assigned to SEND to be called for each of the characters in the argument list. This only works for the special method pointer SEND. But that method pointer is inherited by sub-functions, so in:
SEND("val:", hex(x))
the "hex" function can itself use SEND to transmit characters. Chip has an example in his VGA code.
I am in need of a download program to send (normally a propeller binary) file to the P2 for my OS to store on the SD card. Ultimately it will go both ways. It must not reset the P2 as the OS code is already running.
But I figure that I would be better taking the existing LOADP2 program an modifying it to do this. Then perhaps it could be an optional parameter later. This way it's multi-platform too.
You don't need to modify loadp2. What you probably want to do is to take advantage of loadp2's built in file server. It uses the 9p network file system protocol (a very simple protocol developed for the plan9 operating system, the successor to Unix) to allow programs running on the P2 to access files on the PC.
So I can prevent loadp2 from sending a DTR (reset) to the P2 when using it?
If yes, then this sounds like a plan (pun intended).
BTW I heard of Plan9 in the 90s' but know nothing about it other than I had presumed there was unix link.
So you'd have your P2 program open a file on the PC (with 9p), open a file on the SD (with fsrw or whatever SD object you use) and then copy data from one to the other, in either direction.
For this to work you'll have to launch your original OS with loadp2, and use loadp2's "-9 C:\PATH\TO\ROOT" option to specify a root directory for the 9p file server. The default in FlexGUI is to run with "-9.", which uses the current directory on the PC as the root for the remote file system; that means that the P2 can access any files or directories in the current directory (or under it).
My OS has all the code to send/receive files and get/put them to a FAT32 file on SD. I'll just need to add the 9p protocol to my code.
I can a;ready copy, rename, delete and type FAT32 files in my OS already, and I can move files to/from the cpm system on the SD too. All working now
The sample OS that I posted on your thread (myos.zip) uses 9p to read the files from the PC, since at the time I didn't have an SD card implementation handy. There are also samples in the FlexGUI samples\fileserver folder.
Thanks. I'll dig it out and take a look.
Note that the actual 9p object I used (fs9p.cc) is written in FlexC. If you need to use it from Chip's Spin interpreter you'll have to translate it to Spin. That shouldn't be difficult. On the other hand if your OS can load and run arbitrary PASM programs you could leave it as C and compile it with fastspin, which would save you some work.
I am still waiting for Chip to answer some questions regarding how spin2 places its' code in hub. I need this to be able to load/run binaries from SD while retaining the interpreter and the OS in hub.
There is the cmdline option -E (i think) allowing to compile and load at a certain position in HUB.
I used it with my TAQOZ object I never finished, since Peter never stops changing.
Question is why you do not load your operation system into the ROM area and leave the lower HUB for your binaries to load into.
Haven't quite got there yet although the SD and serial/monitor are already in the ROM area replacing the existing SD and monitor. It's relocatable by recompiling anyway.
Would make sense and you even can write protect the area.
I sadly have no P2 time, but the HOST file System used in FastSpin could maybe made work with Pnut too?
Mike
Not sure what you mean here?
My OS compiles under pnut currently. I received an error with fastspin so I'll have to revisit that again shortly.
sorry for the misunderstanding, what I meant to say is that since you mastered the magic needed to compile your OS with Pnut AND fastspin it would be very nice if you could support the plan9 file system on the host provided by @ersmith.
I am very happy to hear that you already support your CP/M file system on the SD, this lets my hope growing that you may build a Z80 emulator for the P2. I tried and failed.
I think something wrong with using "REP" in inline assembly...
PNut doesn't appear to allow it and so I had to unroll my REP loops in the FSRW "Bashed" SPI driver.
When I did this, the speed increased about 2X, making it nearly as fast as the pure assembly version.
Could it be that REP in HUBEXEC mode is slow?
Here is the REP loop and it unrolled:
{
rep #.end_read, #8
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
.end_read
}
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
drvl c
rcl x,#1 ' shift in msb first (first dummy zero)
waitx #2
drvh c
nop
testp o wc
rcl x,#1
wrbyte x,ptrb++
Comments
dgately
This doesn't work right:
But, this does:
loc ptra,#@HyperBuffer rdfast ##1<<31,ptraOr, it could be the other driver is wrong, in which case the first one is right and the second one is wrong...
This was a great feature to invent by the way. It saves extra comparisons particularly with invalid argument checking where you are validating values that you don't want to be negative or higher than a maximum limit, given there are no explicit "unsigned" types in Spin2 that would otherwise be used for achieving this.
That is messing up the compiler... I don't really remember why I did that...
It works fine as:
I did WInDiff on it and see something suspicious here... the -2 million something looks wrong...
Is it the same as PNut now?
Think it must be.
I'm not really a fan of letting go of control of clock parameters, but I suppose I need to...
Yes, you can set up the clock automatically by creating various constants. Chip documented them I think.
clkset() is still available if you want to use it.
The endless repeat at the end is for keeping the cog alive, and the pins in their current states.
For Smartpins that may not be necessary. Edit: It is, because DIRx goes low and disables the smartpin.
Andy
Here is a test program I've compiled with all the optimization levels and behaves differently with -O2 compared to -O1 and -O0. See the ***** comments in TestProgram.spin2. Rayman, in another thread, made some corrections in TestProgram and said that it worked for him. I still haven't had much luck there.
(at least, I see the directory printed...)
But, I see a compiler warning on this line:
outputStr("mount failed ")Looks to be missing the "string("")"
-1 is apparently what you get when you print "true".
Also, you might want to add in a little delay at the beginning. I have to be fast to start the terminal to catch this...
To be honest I suspect that the inline assembly is probably redundant, the code looks straightforward enough that the compiler could probably produce pretty much the same thing from plain Spin.
@Rayman: if you use loadp2's built in terminal then there's no need to start another one to catch messages
Why do you think that? As far as I can see they both do the same thing for clkset().
Thanks. I'll make the change in sdspi_bashed. About the missing ")", it's easy to leave out, particularly if I've been doing some C coding too. I've run into a warning that I'm only referencing the first character in a string. I'm used to writing "x" for a single character passed to a method. I assume using single quotes like in C is what I'm supposed to do. There's some confusion in my head about using single quotes to introduce a comment though.
I thought I was restoring ptra, but maybe that fell out somehow...
But, it's now changed to ptrab
I am in need of a download program to send (normally a propeller binary) file to the P2 for my OS to store on the SD card. Ultimately it will go both ways. It must not reset the P2 as the OS code is already running. I wrote a program to do this maaaany years ago. I use a very simple set of control characters and a basic sum for crc, nothing fancy.
But I figure that I would be better taking the existing LOADP2 program an modifying it to do this. Then perhaps it could be an optional parameter later. This way it's multi-platform too.
So, I guess there is the source in Eric's github. Are there any gotchas, and are there instructions to compile, and what do I need???
I haven't looked yet, but just wanting to get a leg up for when I get time next.
You could also look at this Python P2 Loader ?
https://forums.parallax.com/discussion/168850/python-p2-loader/p1
and there is script support in LoadP2, which might be enough to do SD loading ?
http://forums.parallax.com/discussion/170858/new-loadp2-now-with-simple-scripting/p1
You don't need to modify loadp2. What you probably want to do is to take advantage of loadp2's built in file server. It uses the 9p network file system protocol (a very simple protocol developed for the plan9 operating system, the successor to Unix) to allow programs running on the P2 to access files on the PC.
So you'd have your P2 program open a file on the PC (with 9p), open a file on the SD (with fsrw or whatever SD object you use) and then copy data from one to the other, in either direction.
For this to work you'll have to launch your original OS with loadp2, and use loadp2's "-9 C:\PATH\TO\ROOT" option to specify a root directory for the 9p file server. The default in FlexGUI is to run with "-9.", which uses the current directory on the PC as the root for the remote file system; that means that the P2 can access any files or directories in the current directory (or under it).
The sample OS that I posted on your thread (myos.zip) uses 9p to read the files from the PC, since at the time I didn't have an SD card implementation handy. There are also samples in the FlexGUI samples\fileserver folder.
Note that the actual 9p object I used (fs9p.cc) is written in FlexC. If you need to use it from Chip's Spin interpreter you'll have to translate it to Spin. That shouldn't be difficult. On the other hand if your OS can load and run arbitrary PASM programs you could leave it as C and compile it with fastspin, which would save you some work.
I used it with my TAQOZ object I never finished, since Peter never stops changing.
Question is why you do not load your operation system into the ROM area and leave the lower HUB for your binaries to load into.
Would make sense and you even can write protect the area.
I sadly have no P2 time, but the HOST file System used in FastSpin could maybe made work with Pnut too?
Mike
In Spin you always use double quotes for characters, and "xyz" is equivalent to the 3 character list "x", "y", "z". That's why to get a pointer to a string you have to use STRING("xyz"). The most recent fastspin also lets you write @"xyz" to mean the same thing as STRING("xyz"). @"Jeff Martin" , @cgracey , and I discussed this notation quite a while ago, and I hope Chip may add it to his interpreter at some point.
There's a very nice Spin2 feature (also implemented by fastspin) called SEND which is useful too: you can do something like:
SEND := @ser.tx SEND("hello") ' note: equivalent to SEND("h", "e", "l", "l", "o")which causes the method assigned to SEND to be called for each of the characters in the argument list. This only works for the special method pointer SEND. But that method pointer is inherited by sub-functions, so in:SEND("val:", hex(x))the "hex" function can itself use SEND to transmit characters. Chip has an example in his VGA code.If yes, then this sounds like a plan (pun intended).
BTW I heard of Plan9 in the 90s' but know nothing about it other than I had presumed there was unix link. My OS has all the code to send/receive files and get/put them to a FAT32 file on SD. I'll just need to add the 9p protocol to my code.
I can a;ready copy, rename, delete and type FAT32 files in my OS already, and I can move files to/from the cpm system on the SD too. All working now
I found your myos.zip and took a quick look at main.spin and the fs9p.cc and fs9p.h files. Looks simple enough.
My OS compiles under pnut currently. I received an error with fastspin so I'll have to revisit that again shortly.
usage: loadp2 ... [ -n ] no reset; skip any hardware reset ...sorry for the misunderstanding, what I meant to say is that since you mastered the magic needed to compile your OS with Pnut AND fastspin it would be very nice if you could support the plan9 file system on the host provided by @ersmith.
I am very happy to hear that you already support your CP/M file system on the SD, this lets my hope growing that you may build a Z80 emulator for the P2. I tried and failed.
Enjoy!
Mike
PNut doesn't appear to allow it and so I had to unroll my REP loops in the FSRW "Bashed" SPI driver.
When I did this, the speed increased about 2X, making it nearly as fast as the pure assembly version.
Could it be that REP in HUBEXEC mode is slow?
Here is the REP loop and it unrolled:
{ rep #.end_read, #8 drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc .end_read } drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc drvl c rcl x,#1 ' shift in msb first (first dummy zero) waitx #2 drvh c nop testp o wc rcl x,#1 wrbyte x,ptrb++https://forums.parallax.com/discussion/169657/question-about-rep-instruction-repeating
Found something in the P2 docs too: