I've never used PropBASIC, but if the .spin file it outputs is all one big file, then all occurences of @@@x can be replaced with @x + $10, since the top object is guaranteed to start at $10, immediately after the 16-byte header.
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
The difference is that HomeSpun is open source and BSTC is not. BSTC is a binary blob that won't run on a Raspberry Pi for example.
Yes it gets no attention in either place although I did update the instructions for use on Debian and the Raspberry Pi last year ! (It's got two stars mind)
I don't recall now if HomeSpun supports all the features of BSTC.
Hi Brett, the IDE looks good on Linux Mint, I just used the deb package for this. Now I know that btsc has a -l command line option to generate a listing which I always do but I can't see any options for forcing btsc to do that. If you don't have the feature it should be pretty easy to add a simple option for that, thanks.
btw, love the themes option and the help manuals are instant!
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Program Usage :- bstc (Options) Filename[.spin]
-a - Create Propeller object archive zipfile
-b - Write .binary file
-c - Write .dat file for C-Compiler (Drops a <filename.dat> file)
-d <device> - Device to load to (Default : )
-D <define> - Define a pre-processor symbol (may be used multiple times)
-e - Write .eeprom file
-f - Double download baud rate
-h - Display this help information
-l - Generate listfile
-L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times)
-o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
-O <options> - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!)
a - Enable all optmisations (Be careful! No, really)
b - Bigger constants (should be slightly faster at the expense of code size)
c - Fold Constants
g - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will generate
r - Remove unused Spin Methods
u - Fold Unary "-" Operations on Constants if it will make the code smaller
x - Non-Parallax compatible extensions
-p[012] - Program Chip on device (-d)
0 - Load Ram and run
1 - Load EEProm and shutdown
2 - Load EEProm and run
-s - Intersperse source in listfile (use with -l)
-w[012] - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0)
-v - Get program version information
Brett,
I found an issue.
After you program the propeller it appears that the COM port is left open because I cannot open it with the Parallax Serial Terminal unless I close PropellerIDE.
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
Dave, your suspicions appear to be correct re homespun's options vs BSTC's feature set.
E:\PropBasic>homespun032
Homespun Spin Compiler 0.32 - Batang Build
Usage: homespun filename [options]
Options:
-? -- Quick help (this message).
-b -- Write .binary file instead of the default .eeprom file.
-c -- Write .dat file too.
-d -- Dump memory listing.
-D -- Define symbol; e.g. -D DEBUG
-e -- Write .eeprom file (default).
-i<n> -- Set information level: -i0 -- no messages. -i1, -i2 -- some. -i3 -- all (default).
-L -- Specify library path; e.g. -L c:\mylib\ -L c:\obex\
-M -- Override 32k limit (use at own risk); e.g. -M 65536
-o -- Specify output filename; e.g. -o blah
-w -- Enable warnings.
No input file specified
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
The difference is that HomeSpun is open source and BSTC is not. BSTC is a binary blob that won't run on a Raspberry Pi for example.
I didn't know that the source for Homespun was available. The Google Code archive says it was established 3 years ago. Somehow I missed that event at the time it happened. However, it seems like any enhancements should be done using OpenSpin rather than Homespun. There's no reason others couldn't add features to it. OpenSpin is "open" right?
That's good that it's under the MIT license. Has anybody other than Roy made changes to the code? Maybe people that are proposing changes to OpenSpin could also code up the changes, and then verify them. Then Roy or somebody from Parallax could merge the changes if they are approved by Parallax.
It's been my dream since I took over PropellerIDE to see it become home to all the wacky things out there for the Propeller.
Is there a chance it will support C/C++ at some point?
Yes, absolutely, though it is still theoretical at this point. There is much that would need to be worked out as to how it would fit into the PropellerIDE environment, but it's very much feasible. At some point, I intend to break off the compiler support into plugins that can be maintained independently, so others will be able to add their own features as well. Then we really will come full-circle.
I use .lib extension just to keep my files straight. If there is no disagreement from others, I don't see why it couldn't be added to the list of recognized files.
*.lib looks like its used by quite a few applications. *.plib seems available though, so I can add that as a recognized extension.
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
There were some subtle differences in the way bst vs homespun handled ifdef. Both have listing output, but they are different. I am unsure if homespun handles dead code removal. At least the source is available for homespun. I use both these and PropTool.
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
The difference is that HomeSpun is open source and BSTC is not. BSTC is a binary blob that won't run on a Raspberry Pi for example.
Yes it gets no attention in either place although I did update the instructions for use on Debian and the Raspberry Pi last year ! (It's got two stars mind)
I don't recall now if HomeSpun supports all the features of BSTC.
I have no idea why HomeSpun hasn't gotten more attention, but I imagine it's for the same reason PropBASIC hasn't gotten more attention; lack of an IDE! (bstc has always has bst). I have no idea what it's capable of or how stable it is. Also, do you know how large a Mono run-time distribution would be?
Hi Brett, the IDE looks good on Linux Mint, I just used the deb package for this. Now I know that btsc has a -l command line option to generate a listing which I always do but I can't see any options for forcing btsc to do that. If you don't have the feature it should be pretty easy to add a simple option for that, thanks.
I'll be adding the ability to customize the compiler arguments in a later release. Also, while we're on the subject, Peter! Would you like a new home for Tachyon??
Brett,
I found an issue.
After you program the propeller it appears that the COM port is left open because I cannot open it with the Parallax Serial Terminal unless I close PropellerIDE.
Bean
That is correct.
PropellerManager doesn't yet implement an API for releasing ownership of a port as the behavior has been difficult to characterize.
Older versions maintained an active session count and released the devices when the session count hit zero, but this defeated PropellerManager's key feature: open device sharing. I think that releasing a device should then be a more explicit action, but where that would fit into the PropellerIDE UI, I'm not sure. So that's where I'm at now with that.
However, I have to ask: is there a problem with PropellerIDE's built-in terminal that you need to use PST?
I'll be adding the ability to customize the compiler arguments in a later release. Also, while we're on the subject, Peter! Would you like a new home for Tachyon??
What are you thinking Brett? Actually running a Tachyon interpreter session within a PropellerIDE session? Talk about complicating things. Since Tachyon has different binaries that are available, I think all that PropellerIDE would need is someway of loading and running the binary.
I quite like the idea of Tachyon being supported by PropellerIDE. Peter will jump in and correct me if I'm wrong about any of the notes below.
-- You have to download the Tachyon binary to a Propeller to start things anyway.
* I think the source is available; if not, PropellerIDE would have to allow direct downloading of binary images
-- Forth files are plain text, with a .fth extension
* the extension is used for identifying tool used by the file
-- Forth files would not be compiled, but they would have to be transmitted serially through the terminal
What a cool deal: you edit your Forth file, save it, then click on the download button and it's sent to a Propeller running Tachyon -- all in one environment. I'm sure many will continue to use their favorit text editor and terminal apps, but I'd love to have an integrated solution
I tend to use minicom for my terminal as all the ANSI/VT100 stuff works but a terminal integrated with PropellerIDE would be great if it supported ASCII file transfer with line delays or even special handshake characters. In addition to selecting a file to download it would be good to be able to run a macro or else perhaps having some dedicated buttons that I could assign a function (download) and a file to it. That way I could just click the button after Tachyon is compiled and loaded and ready to run.
I mention a special handshake character simply because soft handshake is useless with deep FIFOs but I'd also would want some basic ANSI capabilities although I know that is beyond the scope of writing the PropellerIDE. I can only ask
Then the other thing would be if the IDE could save the Prop's binary which really just means it sends a command for a hex dump, usually Intel 8 format, runs a hex2bin and saves that after fixing the checksum byte.
Now if you did something along those lines then that would be really cool for all the Tachyon users, to have an integrated development environment
I tend to use minicom for my terminal as all the ANSI/VT100 stuff works...
Yes, minicom, works if you are on a Linux install, unless somebody wants to port it too Windows. I remember a few years back when I tried Tachyon, I used TeraTerm on a Windows install, if I recall that did not go as well as I thought it should.
Now, if Brett goes ahead and makes all the mods to the in-built terminal, and the latest source for Tachyon is available, it might be a worthwhile venture. But, from what Peter just mentioned, in the previous post, looks like some extra work, unless he ports minicom to the PropellerIDE.
I tend to use minicom for my terminal as all the ANSI/VT100 stuff works...
Yes, minicom, works if you are on a Linux install, unless somebody wants to port it too Windows. I remember a few years back when I tried Tachyon, I used TeraTerm on a Windows install, if I recall that did not go as well as I thought it should.
Now, if Brett goes ahead and makes all the mods to the in-built terminal, and the latest source for Tachyon is available, it might be a worthwhile venture. But, from what Peter just mentioned, in the previous post, looks like some extra work, unless he ports minicom to the PropellerIDE.
Ray
I seem to recall you had troubles but I didn't think it was due to TeraTerm from what you described and anyway I use TeraTerm as well without any problems. But I mention minicom just so that Brett knows how I am using Tachyon, that although I could work with a basic terminal, there are a few programs I have that make use of the ANSI controls such as SPLAT plus we need that ASCII download ability,
There seems to be a problem with BWIDE ( ) taking control of the serial port so I can't really use it properly at the moment as I use minicom for my main terminal at present.
So, I went ahead and did a test run using Tachyon JUNO on the PropellerIDE. Surprisingly, for a test run, it went very good.
I used a QuickStart board as the test board and the in-built terminal for a creative session. I also used the JUNO.spin file, later I will test using a binary file. I just did a couple of quick items from the Intro docs and that seemed to go as expected.
I guess at this point, all you need to do is get the ...JUNO.spin file, open it up with PropellerIDE, hit RUN, open the terminal, do a CR and you are all set to go. Now all I have to do is figure out how to activate the touch pads so it can activate an LED.
It seems to depend on propgcc. Is it usable as a standalone tool?
Where does it say that ?
I see this
Usage is pretty simple:
fastspin -2 fibo.spin
produces fibo.p2asm, which can then be loaded by PNut.
Note that fastspin.exe can produce code for either P1 or P2; to get P2 you need to specify the -2 flag
There is not yet any Prop 2 GCC, but fast spin has a P2 (&P1) code generator.
Brett,
If you want some help in doing the terminal section, I (and others) could help put in the few ANSI sequences required. Just post the terminal section code and we could take it from there.
The terminal needs to have a few things...
* needs to function with a large scroll buffer - so we can go back and select a section/all and copy for pasting - else save to a file
* when used as a screen, needs cursor positioning - this mode needs the size to be configurable (x & y sizes)
* send an ascii file, with delays or handshake
* receive an ascii file would be nice
We don't want a separate window for user input (ie don't like PST for this reason). Nice to color user input differently.
There are other features that would be nice later (eg special font so control characters can be represented in a single character - excellent for debugging)
Brett,
If you want some help in doing the terminal section, I (and others) could help put in the few ANSI sequences required. Just post the terminal section code and we could take it from there.
The terminal needs to have a few things...
* needs to function with a large scroll buffer - so we can go back and select a section/all and copy for pasting - else save to a file
* when used as a screen, needs cursor positioning - this mode needs the size to be configurable (x & y sizes)
* send an ascii file, with delays or handshake
* receive an ascii file would be nice
We don't want a separate window for user input (ie don't like PST for this reason). Nice to color user input differently.
There are other features that would be nice later (eg special font so control characters can be represented in a single character - excellent for debugging)
Brett,
If you want some help in doing the terminal section, I (and others) could help put in the few ANSI sequences required. Just post the terminal section code and we could take it from there.
The terminal needs to have a few things...
* needs to function with a large scroll buffer - so we can go back and select a section/all and copy for pasting - else save to a file
* when used as a screen, needs cursor positioning - this mode needs the size to be configurable (x & y sizes)
* send an ascii file, with delays or handshake
* receive an ascii file would be nice
We don't want a separate window for user input (ie don't like PST for this reason). Nice to color user input differently.
There are other features that would be nice later (eg special font so control characters can be represented in a single character - excellent for debugging)
So, I went ahead and did a test run using Tachyon JUNO on the PropellerIDE. Surprisingly, for a test run, it went very good.
I used a QuickStart board as the test board and the in-built terminal for a creative session. I also used the JUNO.spin file, later I will test using a binary file. I just did a couple of quick items from the Intro docs and that seemed to go as expected.
I guess at this point, all you need to do is get the ...JUNO.spin file, open it up with PropellerIDE, hit RUN, open the terminal, do a CR and you are all set to go. Now all I have to do is figure out how to activate the touch pads so it can activate an LED.
Ray
Drop on by the darkside on the Tachyon thread if you need help loading Extend.fth or configuring ZTerm, TeraTerm, Minicom, Hypercomm, heck I've used them all it seems. Without Extend.fth Tachyon is very limited.
Excuse the thread bust, now back to this neat IDE.
Just wanted to verify that PropellerIDE does not deal with binaries, so, yesterdays session with ...JUNO.spin went very well, except for trying to load and run a binary file of course.
I sort of miss having a preference menu for the in-built terminal, probably something like the terminal setup that was on SimpleIDE. Also, a separate window for user input should be eliminated, that is what turned me off with PST.
It seems to depend on propgcc. Is it usable as a standalone tool?
spin2cpp is a general tool; it takes in Spin code and outputs C, C++, or PASM which can than be further compiled by propgcc, Catalina, Visual C++, or other tools.
fastspin is an alternate front end to spin2cpp which takes in Spin code and outputs a Propeller binary executable. It's intended to have the same interface as openspin, so it should be very easy to support it in any tool that supports openspin. The main difference is that fastspin compiles the Spin to an LMM executable, so it's much faster (and much larger) than the Spin bytecodes produced by openspin. fastspin does not rely on any external tools at all, it is completely self contained.
I tend to use minicom for my terminal as all the ANSI/VT100 stuff works but a terminal integrated with PropellerIDE would be great if it supported ASCII file transfer with line delays or even special handshake characters. In addition to selecting a file to download it would be good to be able to run a macro or else perhaps having some dedicated buttons that I could assign a function (download) and a file to it. That way I could just click the button after Tachyon is compiled and loaded and ready to run.
I mention a special handshake character simply because soft handshake is useless with deep FIFOs but I'd also would want some basic ANSI capabilities although I know that is beyond the scope of writing the PropellerIDE. I can only ask
Then the other thing would be if the IDE could save the Prop's binary which really just means it sends a command for a hex dump, usually Intel 8 format, runs a hex2bin and saves that after fixing the checksum byte.
Now if you did something along those lines then that would be really cool for all the Tachyon users, to have an integrated development environment
Would someone be so kind as to explain what line delays and handshake characters are? Aside from supporting some VT100 escape sequences, I'm not sure what everyone is asking for exactly. The terminal has some PST-compatible special characters already, like basic cursor positioning, but having full-on ANSI support would be NICE!
To be clear, with the current terminal, you can input text both directly into the terminal and via the user input line. You can use whichever you prefer, and there is no reason to remove either.
Also, what is meant by dealing with binaries? You can download binary images through memory map in PropellerIDE (assuming that function works! haha).
I'd like to see any Forth-specific functionality encapsulated in a special applet that will manage the download for you, so that you won't have to scroll around, copy/paste, and all those other non-automated things. I think an automatic converter, a nice file save dialog for receiving images, and all that would go a long way towards making Forth more accessible.
It seems to depend on propgcc. Is it usable as a standalone tool?
spin2cpp is a general tool; it takes in Spin code and outputs C, C++, or PASM which can than be further compiled by propgcc, Catalina, Visual C++, or other tools.
fastspin is an alternate front end to spin2cpp which takes in Spin code and outputs a Propeller binary executable. It's intended to have the same interface as openspin, so it should be very easy to support it in any tool that supports openspin. The main difference is that fastspin compiles the Spin to an LMM executable, so it's much faster (and much larger) than the Spin bytecodes produced by openspin. fastspin does not rely on any external tools at all, it is completely self contained.
Regards,
Eric
Sweet! I'm going to have to check this out and see about integrating this!
It addresses various things based on the feedback I've gotten from you, so thank you very much!
Release Notes:
- Add PropBASIC manual to help menu
- Add support for multiple builders per language definition
- Add *.plib extension for included PropBASIC files
- Rewrite save dialog to better support multiple filetypes
- Prevent build action from disabling when file contents have changed.
- Rewrite program logic to clearly delineate on/off states of various file actions
- Clear project view when all files are closed
Please let me know if it doesn't fix things it claims to have fixed. Thanks!
Line delays are used in Tachyon when loading new stuff.
The parser takes a little bit of time, so if you want to load a multiline program you add an end of line delay in the terminal.
It means the teminal sends a line, waits a little bit, sends the next line, waits a little bit, and so on.
Massimo
Comments
HomeSpun has a repo here: https://code.google.com/archive/p/homespun-spin-compiler/
I cloned that to github at the time here: https://github.com/ZiCog/HomeSpun
Yes it gets no attention in either place although I did update the instructions for use on Debian and the Raspberry Pi last year ! (It's got two stars mind)
I don't recall now if HomeSpun supports all the features of BSTC.
btw, love the themes option and the help manuals are instant!
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved Compiled for i386 Linux at 08:17:46 on 2009/07/20 Program Usage :- bstc (Options) Filename[.spin] -a - Create Propeller object archive zipfile -b - Write .binary file -c - Write .dat file for C-Compiler (Drops a <filename.dat> file) -d <device> - Device to load to (Default : ) -D <define> - Define a pre-processor symbol (may be used multiple times) -e - Write .eeprom file -f - Double download baud rate -h - Display this help information -l - Generate listfile -L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times) -o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin) -O <options> - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!) a - Enable all optmisations (Be careful! No, really) b - Bigger constants (should be slightly faster at the expense of code size) c - Fold Constants g - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will generate r - Remove unused Spin Methods u - Fold Unary "-" Operations on Constants if it will make the code smaller x - Non-Parallax compatible extensions -p[012] - Program Chip on device (-d) 0 - Load Ram and run 1 - Load EEProm and shutdown 2 - Load EEProm and run -s - Intersperse source in listfile (use with -l) -w[012] - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0) -v - Get program version informationI found an issue.
After you program the propeller it appears that the COM port is left open because I cannot open it with the Parallax Serial Terminal unless I close PropellerIDE.
Bean
It would help if there was a license file at the top of the github repo to make that clear as is standard practice.
If they have well developed and interesting changes they can make a "pull request" to the Parallax repo.
That may or may or may not be accepted by whoever is maintaining the the thing.
Yes, absolutely, though it is still theoretical at this point. There is much that would need to be worked out as to how it would fit into the PropellerIDE environment, but it's very much feasible. At some point, I intend to break off the compiler support into plugins that can be maintained independently, so others will be able to add their own features as well. Then we really will come full-circle.
*.lib looks like its used by quite a few applications. *.plib seems available though, so I can add that as a recognized extension.
Yes!
Noted and noted!
Bit of a chicken/egg scenario, I guess.
Shouldn't be a big deal to make existing PASM drivers work with PropBASIC.
It seems to depend on propgcc. Is it usable as a standalone tool?
I have no idea why HomeSpun hasn't gotten more attention, but I imagine it's for the same reason PropBASIC hasn't gotten more attention; lack of an IDE! (bstc has always has bst). I have no idea what it's capable of or how stable it is. Also, do you know how large a Mono run-time distribution would be?
I'll be adding the ability to customize the compiler arguments in a later release. Also, while we're on the subject, Peter! Would you like a new home for Tachyon??
That is correct.
PropellerManager doesn't yet implement an API for releasing ownership of a port as the behavior has been difficult to characterize.
Older versions maintained an active session count and released the devices when the session count hit zero, but this defeated PropellerManager's key feature: open device sharing. I think that releasing a device should then be a more explicit action, but where that would fit into the PropellerIDE UI, I'm not sure. So that's where I'm at now with that.
However, I have to ask: is there a problem with PropellerIDE's built-in terminal that you need to use PST?
Ray
-- You have to download the Tachyon binary to a Propeller to start things anyway.
What a cool deal: you edit your Forth file, save it, then click on the download button and it's sent to a Propeller running Tachyon -- all in one environment. I'm sure many will continue to use their favorit text editor and terminal apps, but I'd love to have an integrated solution
I mention a special handshake character simply because soft handshake is useless with deep FIFOs but I'd also would want some basic ANSI capabilities although I know that is beyond the scope of writing the PropellerIDE. I can only ask
Then the other thing would be if the IDE could save the Prop's binary which really just means it sends a command for a hex dump, usually Intel 8 format, runs a hex2bin and saves that after fixing the checksum byte.
Now if you did something along those lines then that would be really cool for all the Tachyon users, to have an integrated development environment
Now, if Brett goes ahead and makes all the mods to the in-built terminal, and the latest source for Tachyon is available, it might be a worthwhile venture. But, from what Peter just mentioned, in the previous post, looks like some extra work, unless he ports minicom to the PropellerIDE.
Ray
I seem to recall you had troubles but I didn't think it was due to TeraTerm from what you described and anyway I use TeraTerm as well without any problems. But I mention minicom just so that Brett knows how I am using Tachyon, that although I could work with a basic terminal, there are a few programs I have that make use of the ANSI controls such as SPLAT plus we need that ASCII download ability,
There seems to be a problem with BWIDE (
I used a QuickStart board as the test board and the in-built terminal for a creative session. I also used the JUNO.spin file, later I will test using a binary file. I just did a couple of quick items from the Intro docs and that seemed to go as expected.
I guess at this point, all you need to do is get the ...JUNO.spin file, open it up with PropellerIDE, hit RUN, open the terminal, do a CR and you are all set to go. Now all I have to do is figure out how to activate the touch pads so it can activate an LED.
Ray
I see this
Usage is pretty simple:
fastspin -2 fibo.spin
produces fibo.p2asm, which can then be loaded by PNut.
Note that fastspin.exe can produce code for either P1 or P2; to get P2 you need to specify the -2 flag
There is not yet any Prop 2 GCC, but fast spin has a P2 (&P1) code generator.
If you want some help in doing the terminal section, I (and others) could help put in the few ANSI sequences required. Just post the terminal section code and we could take it from there.
The terminal needs to have a few things...
* needs to function with a large scroll buffer - so we can go back and select a section/all and copy for pasting - else save to a file
* when used as a screen, needs cursor positioning - this mode needs the size to be configurable (x & y sizes)
* send an ascii file, with delays or handshake
* receive an ascii file would be nice
We don't want a separate window for user input (ie don't like PST for this reason). Nice to color user input differently.
There are other features that would be nice later (eg special font so control characters can be represented in a single character - excellent for debugging)
The code is already available here: https://github.com/parallaxinc/PropellerManager
Even better, thanks David
Drop on by the darkside on the Tachyon thread if you need help loading Extend.fth or configuring ZTerm, TeraTerm, Minicom, Hypercomm, heck I've used them all it seems. Without Extend.fth Tachyon is very limited.
Excuse the thread bust, now back to this neat IDE.
I sort of miss having a preference menu for the in-built terminal, probably something like the terminal setup that was on SimpleIDE. Also, a separate window for user input should be eliminated, that is what turned me off with PST.
Ray
spin2cpp is a general tool; it takes in Spin code and outputs C, C++, or PASM which can than be further compiled by propgcc, Catalina, Visual C++, or other tools.
fastspin is an alternate front end to spin2cpp which takes in Spin code and outputs a Propeller binary executable. It's intended to have the same interface as openspin, so it should be very easy to support it in any tool that supports openspin. The main difference is that fastspin compiles the Spin to an LMM executable, so it's much faster (and much larger) than the Spin bytecodes produced by openspin. fastspin does not rely on any external tools at all, it is completely self contained.
Regards,
Eric
Would someone be so kind as to explain what line delays and handshake characters are? Aside from supporting some VT100 escape sequences, I'm not sure what everyone is asking for exactly. The terminal has some PST-compatible special characters already, like basic cursor positioning, but having full-on ANSI support would be NICE!
To be clear, with the current terminal, you can input text both directly into the terminal and via the user input line. You can use whichever you prefer, and there is no reason to remove either.
Oh, alas, the terminal inside PropellerManager is very basic. There is another implementation inside propterm, which lives in the IDE itself: https://github.com/parallaxinc/PropellerIDE/tree/master/src/propterm
Also, what is meant by dealing with binaries? You can download binary images through memory map in PropellerIDE (assuming that function works! haha).
I'd like to see any Forth-specific functionality encapsulated in a special applet that will manage the download for you, so that you won't have to scroll around, copy/paste, and all those other non-automated things. I think an automatic converter, a nice file save dialog for receiving images, and all that would go a long way towards making Forth more accessible.
Sweet! I'm going to have to check this out and see about integrating this!
https://github.com/parallaxinc/PropellerIDE/releases/tag/0.38.5
It addresses various things based on the feedback I've gotten from you, so thank you very much!
Release Notes:
- Add PropBASIC manual to help menu
- Add support for multiple builders per language definition
- Add *.plib extension for included PropBASIC files
- Rewrite save dialog to better support multiple filetypes
- Prevent build action from disabling when file contents have changed.
- Rewrite program logic to clearly delineate on/off states of various file actions
- Clear project view when all files are closed
Please let me know if it doesn't fix things it claims to have fixed. Thanks!
The parser takes a little bit of time, so if you want to load a multiline program you add an end of line delay in the terminal.
It means the teminal sends a line, waits a little bit, sends the next line, waits a little bit, and so on.
Massimo