I ask because so many P1 tools just died, for example, Propeller Tool because of QT.
Propeller Tool didn't die because of QT... If Propeller Tool died it was because it was not open source and single-platform based (WIN). QT just happens to be a cross-platform development environment and was available at the time a new Propeller IDE was being developed. Note: all the code for SimpleIDE and PropellerIDE are open source. Anyone can access the sources for these apps (many have!) and update them.
Apparently the Prop Tool uses some proprietary editor that Parallax can't release. My guess is that they would have released the Prop Tool sources except for that.
Are we talking Propeller Tool or Propeller-IDE?
It was Propeller-IDE that used QT wasn't it?
I'm talking about the proprietary Windows-only Prop Tool that Parallax has provided since the P1 was first introduced. PropellerIDE is indeed based on Qt and is entirely open source.
Are we talking Propeller Tool or Propeller-IDE?
It was Propeller-IDE that used QT wasn't it?
I'm talking about the proprietary Windows-only Prop Tool that Parallax has provided since the P1 was first introduced. PropellerIDE is indeed based on Qt and is entirely open source.
Ok
@Genetix
I wasn't aware that Propeller Tool had "passed away"?
Bst is no more abandoned than PropTool or homespun.
It's a shame that OpenSpin isn't used more often. I guess you use what you know until there is a need.
Apologies Roy, I haven't even tried OpenSpin - just never seem to get around to it. I prefer to use PropTool as the editor, even when using pnut (P2). If I had to change, I'd probably prefer to use NotePad++ for editing.
No need to apologize. Not many people are using OpenSpin. Some people continue to use BST because they can't live without the @ @ @ (the forum won't let me do 3 @'s in a row) extension.
I'm guessing most people still use PropTool Spin/PASM, I still use it for mostl my Spin/PASM coding. Recently I have switched to mainly using SimpleIDE with C/C++ and BlocklyProp for my Prop based projects.
At one time I had talked with Jeff Martin about integrating OpenSpin into PropTool, but it never became a priority over his other work (which I understand completely).
I think Ken is right about not building and supporting yet another IDE/editor. There are MANY good choices available that would just need some configuring or small extension to make work for whatever command line compiler tools we make. Visual Studio Code is probably what I will use long term, I'll end up writing my own extension for it if needed. I'm already using it for Python coding for our game engine scripts at work. It's already got good C/C++ support, and getting it to build via propgcc should be easy. Making a Spin/PASM extension for it should be too hard either.
Notepad++ is also a great choice for windows users. I use that for a lot of random text/binary file viewing/editing (it's hex editor plugin is nice).
I use NotePad++ at work. When I started (January this year) they used NoteTab but I introduced NotePad++ because of the support for Python Scripts and Compare add-ins.
Every week we email out a Newsletter to 10,000 customers and I wrote scripts to automate a large part of the manual process.
I have used NotePad++ for quite a few years. Originally I thought it was cross-platform but unfortunately it's only Windoze
Saphieha and ??? setup parameters to support P1 spin/PASM Code but I lost the parameters
I love the integrated PropTool, it needs PST or a better terminal emulation. However, this time around, I think it would be simpler to have separate editor, compiler/downloader, terminal. The compiler can call a downloader. It's an easier development path. I think SimpleIDE and PropellerIDE proved this.
Bst is no more abandoned than PropTool or homespun
I think the difference is that Parallax still has the source code for PropTool and they would almost certainly update it if it stopped working on some new version of Windows. They may even update it for P2 once Chip gets his x86 Spin2 compiler working. I don't think Brad even has the BST sources anymore. That's maybe part of the reason that he abandoned it.
Bst is no more abandoned than PropTool or homespun
I think the difference is that Parallax still has the source code for PropTool and they would almost certainly update it if it stopped working on some new version of Windows. They may even update it for P2 once Chip gets his x86 Spin2 compiler working. I don't think Brad even has the BST sources anymore. That's maybe part of the reason that he abandoned it.
Sure if PropTool stopped working. But is archaic and lacks even primitive advances made with bst and homespun.
Brad abandoned the Prop for other reasons. He's not likely to release the code but still had it when last we spoke.
Homespun source has been released. It was also used in Catalina C.
But bst and homespun just work as they always did and that is many years later, just like PropTool.
But bst and homespun just work as they always did and that is many years later, just like PropTool.
I guess that is more a testament to Microsoft and their efforts to make sure that old programs still work on new versions of Windows than anything else.
I guess I don't care what lipstick you put on this pig but how do we get a P2 binary.
I use SimpleIDE because it gets the job done and I know where everything is.
So do we need a new environment that can direct it to use P1 or P2?
It would be nice to just change a parameter and recompile.
Mike
For P2, we have pnut which has an editor like PropTool without colours. We also have P2PASM - it's a compiler (and downloader?). It's advantage is that it can produce a listing.
P1 & P2 PASM is too different to be able to compile the same source. Spin2 is still an unknown, but I suspect most P1 spin code will compile to P2. Of course some things will not port, like the counters and video. Bit-banging will still work providing it's not timing conscious.
For P2, we have pnut which has an editor like PropTool without colours. We also have P2PASM - it's a compiler (and downloader?). It's advantage is that it can produce a listing.
I don't know why people seem to continue to ignore FastSpin. It not only assembles P2 PASM, it also compiles Spin2 and it's the only tool that can do that right now. On top of that it now supports a pretty complete version of BASIC as well as a subset of C and each language can call code written in the others. It even has a simple IDE.
I have one question. If parallax or forum members decide to choose gcc, is there any plan to develop with the goal of having the code submitted upstream? I mean, is there any plan to made it easy for gcc developpers to merge that version into the official GCC source code? I think it should be desirable to do it in this way (with the purpose of being a official port of GCC), if not please explain why.
For P2, we have pnut which has an editor like PropTool without colours. We also have P2PASM - it's a compiler (and downloader?). It's advantage is that it can produce a listing.
I don't know why people seem to continue to ignore FastSpin. It not only assembles P2 PASM, it also compiles Spin2 and it's the only tool that can do that right now. On top of that it now supports a pretty complete version of BASIC as well as a subset of C and each language can call code written in the others. It even has a simple IDE.
Thanks for the reminder.
Note to self - try FastSpin.
There is a learning curve I'm not quite ready for just yet. Then I will be keen to see what it can do with Spin from P1 to get my OS running on P2.
Currently, I've been hesitant to try anything but pnut live because of P2 changes. At least pnut should support the latest changes. I use P2PASM to checkout a listing but I've never tested its binary output.
It would be nice to just change a parameter and recompile.
Mike
Ya know,,,, fastspin says its a drop in replacement for openspin, (at least the version from when it was made?) The latest openspin is v1.00.81, is fast spin built on it?
So the fastspin info says you can just rename fastspin to openspin and write over the copy of openspin in simpleIDE's path or where ever your copy of open spin is.... https://github.com/totalspectrum/spin2cpp/releases --> fastspin.zip
Then use extra flags in the compiler options to indicate P2?
Right?
fastspin
fastspin is a simple interface to the SPIN -> PASM converter.
It acts very much like openspin, including mimicking its console output, so that it can easily be used in IDEs in place of openspin.
The basic usage is
fastspin file.spin
which will produce file.binary, an executable which may be downloaded to the Propeller.
There are various options, use fastspin -h to see them all.
Probably the most significant is -2 to compile a Propeller 2 executable:
fastspin -2 file.spin
produces a file.binary which can be run on a Prop2 FPGA.
As an alternative, fastspin can also mimic the bstc command line compiler,
if it is named something that starts with the letters "bstc" (e.g. "bstc.fastspin").
I guess i could try it. Gotta compile it first...
/opt/parallax/bin$ ./openspin
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.11-beta-cf71b44 Compiled on: Dec 2 2018
usage: ./openspin [options] filename.spin | filename.bas
[ -h ] display this help
[ -L or -I <path> ] add a directory to the include path
[ -o <name> ] set output filename to <name>
[ -b ] output binary file format
[ -e ] output eeprom file format
[ -c ] output only DAT sections
[ -l ] output DAT as a listing file
[ -f ] output list of file names
[ -q ] quiet mode (suppress banner and non-error text)
[ -p ] disable the preprocessor
[ -D <define> ] add a define
[ -u ] ignore for openspin compatibility (unused method elimination always enabled)
[ -2 ] compile for Prop2
[ -O# ] set optimization level:
-O0 = no optimization
-O1 = basic optimization
-O2 = all optimization
[ -w ] compile for COG with Spin wrappers
[ -C ] enable case sensitive mode
[ --code=cog ] compile for COG mode instead of LMM
[ --fcache=N ] set FCACHE size to N (0 to disable)
[ --fixedreal ] use 16.16 fixed point in place of floats
SpinEdit may one day be a viable substitute for the Prop Tool.
Gives you the same coloring, which I've grown accustomed to...
I'm using it right now to develop with P2 assembly.
For this it's better than PNut or PropTool in many aspects.
Still a work in progress though...
Although a Windows program, I'm told it can run on a Mac using Wine. I just bought a Mac mini to test this out (ok, that is for a different MFC program at work, but results should be similar)…
BTW: Eric is working on added C support to FastSpin, so I might add C syntax coloring to SpinEdit too...
I'd really love to have C++ on GCC though so I can use the Microsoft Visual Studio to develop code with...
Ramon,
please don't post the same thing to multiple threads.
Roy sorry. I was with the cellphone, and did't noticed. I have moved it here were I think it belongs.
That requires a lot of work, and on an ongoing basis. I don't think anyone here can commit to that.
Isn't that a double-edge sword issue?
Why using a big elephant compiler like gcc that requires such a big learning curve just to step in for anyone but the 3 or 5 genious here that understand it?
Isn't that one of the reasons that the gcc fork has become 'old and unmaintained'?
If the goal is not to merge into maintream version, why parallax would prefer to choose/promote a fork of the previous 'old and unmaintained' fork? instead of any other lightweigth, homegrown, and/or easyer to understand (and to evolve, and maintain too) option?
(and not to mention too the awkward pseudo-assembler syntax: GAS)
Isn't that one of the reasons that the gcc fork has become 'old and unmaintained'?
If the propgcc project is "old and unmaintained", it is because Parallax doesn't have the internal resources necessary to move to newer versions and hence there is no point in updating it.
So current c/c++ compiler status is stag nated? and it seems it will continue to be so because there are no internal resources, and forum members still don' t known how to proceed. Or they are waiting some instructions or meeting with parallax to discuss options and alternatives. is it that a correct brief status?
So current c/c++ compiler status is stag nated? and it seems it will continue to be so because there are no internal resources, and forum members still don' t known how to proceed. Or they are waiting some instructions or meeting with parallax to discuss options and alternatives. is it that a correct brief status?
To be fair, it hasn't really "stagnated". It works fine for what Parallax needs. As far as I know, there are no bugs that need addressing. It is stable.
I can't get simpleIDE to take my option of -h does it only accept certain things?
it accepts NOTHING for SPIN.
I CAN get the c compilers to take it, when I type "hello" in one of the c compiler options box, it shows in the output with error.
But not for the spin compiler.
I can write a novel in the options box and it will ignore it, and not show it.
If that can be made to work(is this a problem with simpleIDEv1-1-2?, or did my compile fail?....)
Then the -2 "option" for Prop2 switch will work if you replace openspin with--> (fastspin renamed to openspin)
Eric does have a program called spin2gui that provides a basic IDE. It should also be possible to extend SimpleIDE to work with the P2 tools as well as P1. I haven't really looked much, but aren't there off-the-shelf IDEs available that can be adapted to run the P1 and P2 tools?
Eric does have a program called spin2gui that provides a basic IDE. It should also be possible to extend SimpleIDE to work with the P2 tools as well as P1. I haven't really looked much, but aren't there off-the-shelf IDEs available that can be adapted to run the P1 and P2 tools?
There are many "off-the-shelf IDEs" but it's going to depend on what tools you're talking about and how much work you want to do to shoehorn them in. For instance, PropWare does a great job of making PropGCC, spin2cpp, and OpenSpin work in any IDE that CMake supports (that includes CLion, Eclipse, full-blown Visual Studio, Code::Blocks, etc). But if Parallax doesn't want to use PropWare, it's going to take some real effort to make any cross-compiling toolchain work well with existing IDEs. Depending on how you define "work well" that effort might be an hour to test out a configuration and write a short instructional page on or it might take months to develop an IDE plugin to provide full debugging, loading, context-sensitive auto-completion, static code analysis, etc.
I stick by what I've said in the past.... I'd love to get Parallax's opinion on PropWare and hear them say "we like PropWare, but in order for us to push it as a recommended solution, it would have to...."
I think whatever changes they'd want to make PropWare usable for their customers would be far less work than re-writing equivalent functionality with something else. Even getting usable Windows support shouldn't be hard if I cared enough to put more than an hour or two of work into it, or had someone familiar with development on Windows to bounce ideas off of.
I just skimmed the last 30 or so new posts in this thread.
The BIGGEST PROBLEM I see is the FRAGMENTATION that has occurred around spin/pasm and related tools.
Why the heck do we need Proptool, Openspin, Fastspin, SimpleIDE, PropellerIDE, etc?
There is no way the P2 is going to get off the ground, tool wise, if everyone is working on their own fork of some tool.
Effort needs to focus on a single compiler suite and single editor choice, the more people evangelize and fragment, the slower things will be and the finish line becomes that much further away.
Comments
It was Propeller-IDE that used QT wasn't it?
@Genetix
I wasn't aware that Propeller Tool had "passed away"?
It's a shame that OpenSpin isn't used more often. I guess you use what you know until there is a need.
Apologies Roy, I haven't even tried OpenSpin - just never seem to get around to it. I prefer to use PropTool as the editor, even when using pnut (P2). If I had to change, I'd probably prefer to use NotePad++ for editing.
I'm guessing most people still use PropTool Spin/PASM, I still use it for mostl my Spin/PASM coding. Recently I have switched to mainly using SimpleIDE with C/C++ and BlocklyProp for my Prop based projects.
At one time I had talked with Jeff Martin about integrating OpenSpin into PropTool, but it never became a priority over his other work (which I understand completely).
I think Ken is right about not building and supporting yet another IDE/editor. There are MANY good choices available that would just need some configuring or small extension to make work for whatever command line compiler tools we make. Visual Studio Code is probably what I will use long term, I'll end up writing my own extension for it if needed. I'm already using it for Python coding for our game engine scripts at work. It's already got good C/C++ support, and getting it to build via propgcc should be easy. Making a Spin/PASM extension for it should be too hard either.
Notepad++ is also a great choice for windows users. I use that for a lot of random text/binary file viewing/editing (it's hex editor plugin is nice).
Every week we email out a Newsletter to 10,000 customers and I wrote scripts to automate a large part of the manual process.
I have used NotePad++ for quite a few years. Originally I thought it was cross-platform but unfortunately it's only Windoze
Saphieha and ??? setup parameters to support P1 spin/PASM Code but I lost the parameters
I love the integrated PropTool, it needs PST or a better terminal emulation. However, this time around, I think it would be simpler to have separate editor, compiler/downloader, terminal. The compiler can call a downloader. It's an easier development path. I think SimpleIDE and PropellerIDE proved this.
I use SimpleIDE because it gets the job done and I know where everything is.
So do we need a new environment that can direct it to use P1 or P2?
It would be nice to just change a parameter and recompile.
Mike
Brad abandoned the Prop for other reasons. He's not likely to release the code but still had it when last we spoke.
Homespun source has been released. It was also used in Catalina C.
But bst and homespun just work as they always did and that is many years later, just like PropTool.
P1 & P2 PASM is too different to be able to compile the same source. Spin2 is still an unknown, but I suspect most P1 spin code will compile to P2. Of course some things will not port, like the counters and video. Bit-banging will still work providing it's not timing conscious.
please don't post the same thing to multiple threads.
Thanks for the reminder.
Note to self - try FastSpin.
There is a learning curve I'm not quite ready for just yet. Then I will be keen to see what it can do with Spin from P1 to get my OS running on P2.
Currently, I've been hesitant to try anything but pnut live because of P2 changes. At least pnut should support the latest changes. I use P2PASM to checkout a listing but I've never tested its binary output.
lol... you mean ... simple.. interface...
not that it has anything to do with SimpleIDE
Ya know,,,, fastspin says its a drop in replacement for openspin, (at least the version from when it was made?) The latest openspin is v1.00.81, is fast spin built on it?
So the fastspin info says you can just rename fastspin to openspin and write over the copy of openspin in simpleIDE's path or where ever your copy of open spin is....
https://github.com/totalspectrum/spin2cpp/releases --> fastspin.zip
Then use extra flags in the compiler options to indicate P2?
Right?
fastspin fastspin is a simple interface to the SPIN -> PASM converter. It acts very much like openspin, including mimicking its console output, so that it can easily be used in IDEs in place of openspin. The basic usage is fastspin file.spin which will produce file.binary, an executable which may be downloaded to the Propeller. There are various options, use fastspin -h to see them all. Probably the most significant is -2 to compile a Propeller 2 executable: fastspin -2 file.spin produces a file.binary which can be run on a Prop2 FPGA. As an alternative, fastspin can also mimic the bstc command line compiler, if it is named something that starts with the letters "bstc" (e.g. "bstc.fastspin").I guess i could try it. Gotta compile it first...
/opt/parallax/bin$ ./openspin Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc. Version 3.9.11-beta-cf71b44 Compiled on: Dec 2 2018 usage: ./openspin [options] filename.spin | filename.bas [ -h ] display this help [ -L or -I <path> ] add a directory to the include path [ -o <name> ] set output filename to <name> [ -b ] output binary file format [ -e ] output eeprom file format [ -c ] output only DAT sections [ -l ] output DAT as a listing file [ -f ] output list of file names [ -q ] quiet mode (suppress banner and non-error text) [ -p ] disable the preprocessor [ -D <define> ] add a define [ -u ] ignore for openspin compatibility (unused method elimination always enabled) [ -2 ] compile for Prop2 [ -O# ] set optimization level: -O0 = no optimization -O1 = basic optimization -O2 = all optimization [ -w ] compile for COG with Spin wrappers [ -C ] enable case sensitive mode [ --code=cog ] compile for COG mode instead of LMM [ --fcache=N ] set FCACHE size to N (0 to disable) [ --fixedreal ] use 16.16 fixed point in place of floatsGives you the same coloring, which I've grown accustomed to...
I'm using it right now to develop with P2 assembly.
For this it's better than PNut or PropTool in many aspects.
Still a work in progress though...
Although a Windows program, I'm told it can run on a Mac using Wine. I just bought a Mac mini to test this out (ok, that is for a different MFC program at work, but results should be similar)…
BTW: Eric is working on added C support to FastSpin, so I might add C syntax coloring to SpinEdit too...
I'd really love to have C++ on GCC though so I can use the Microsoft Visual Studio to develop code with...
Roy sorry. I was with the cellphone, and did't noticed. I have moved it here were I think it belongs.
Isn't that a double-edge sword issue?
Why using a big elephant compiler like gcc that requires such a big learning curve just to step in for anyone but the 3 or 5 genious here that understand it?
Isn't that one of the reasons that the gcc fork has become 'old and unmaintained'?
If the goal is not to merge into maintream version, why parallax would prefer to choose/promote a fork of the previous 'old and unmaintained' fork? instead of any other lightweigth, homegrown, and/or easyer to understand (and to evolve, and maintain too) option?
(and not to mention too the awkward pseudo-assembler syntax: GAS)
it accepts NOTHING for SPIN.
I CAN get the c compilers to take it, when I type "hello" in one of the c compiler options box, it shows in the output with error.
But not for the spin compiler.
I can write a novel in the options box and it will ignore it, and not show it.
If that can be made to work(is this a problem with simpleIDEv1-1-2?, or did my compile fail?....)
Then the -2 "option" for Prop2 switch will work if you replace openspin with--> (fastspin renamed to openspin)
There are many "off-the-shelf IDEs" but it's going to depend on what tools you're talking about and how much work you want to do to shoehorn them in. For instance, PropWare does a great job of making PropGCC, spin2cpp, and OpenSpin work in any IDE that CMake supports (that includes CLion, Eclipse, full-blown Visual Studio, Code::Blocks, etc). But if Parallax doesn't want to use PropWare, it's going to take some real effort to make any cross-compiling toolchain work well with existing IDEs. Depending on how you define "work well" that effort might be an hour to test out a configuration and write a short instructional page on or it might take months to develop an IDE plugin to provide full debugging, loading, context-sensitive auto-completion, static code analysis, etc.
I stick by what I've said in the past.... I'd love to get Parallax's opinion on PropWare and hear them say "we like PropWare, but in order for us to push it as a recommended solution, it would have to...."
I think whatever changes they'd want to make PropWare usable for their customers would be far less work than re-writing equivalent functionality with something else. Even getting usable Windows support shouldn't be hard if I cared enough to put more than an hour or two of work into it, or had someone familiar with development on Windows to bounce ideas off of.
The BIGGEST PROBLEM I see is the FRAGMENTATION that has occurred around spin/pasm and related tools.
Why the heck do we need Proptool, Openspin, Fastspin, SimpleIDE, PropellerIDE, etc?
There is no way the P2 is going to get off the ground, tool wise, if everyone is working on their own fork of some tool.
Effort needs to focus on a single compiler suite and single editor choice, the more people evangelize and fragment, the slower things will be and the finish line becomes that much further away.