For some reason I've been unable to download the Lattice tools so I haven't been able to try mine. I get an error saying I don't have access. I thought these tools were supposed to be free. I have an email in to their web support people to sort this out.
Go to the Lattice website and FAQ. That will walk you thru the steps to get your code authorised. It is free, just an unpleasant bit of garbage - it wants your mac address.
For some reason I've been unable to download the Lattice tools so I haven't been able to try mine. I get an error saying I don't have access. I thought these tools were supposed to be free. I have an email in to their web support people to sort this out.
Go to the Lattice website and FAQ. That will walk you thru the steps to get your code authorised. It is free, just an unpleasant bit of garbage - it wants your mac address.
The site isn't working for me. When I click on the link to get a license it says I don't have access to that page. In any case, I've installed the IceStorm toolchain and am able to build an RGB blinking example that should work on the Upduino board. Unfortuately, it doesn't. That may be because I built or loaded it wrong or it may be because I soldered the LED onto the board wrong. I think I'm going to have to find another development board unless the maker of the Upduino gets back to me about how to buy a board with the LED already soldered on.
I spent most of today at a friend's place who I met at our county's Farm Bureau. He and his team are using a drone to disseminate pollen over flowering tree crops, in order to ensure better pollenation than what the bees will do, alone. They are using some open-source software to pilot the drone. The whole thing barely works, due to all kinds of ever-changing updates and tenuous compatibility issues. 97% of their time today was spent just trying to get to the point where they could do a test flight. This is normal, they say.
The way things are going today, hardly anything is reliable, due to the way things are put together. Nobody, almost, has sufficient control of the mess to make any of it work. And everything is gigabytes in size.
My Android phone isn't able to forward emails and messages, lately. The Firefox browser on my PC suddenly can't display videos, though you can hear the audio. On and on.
And companies are getting very invasive about who and where you are. These guys were telling me that although DJI drones are the best tech, the software spies on you.
I'm thinking there has got to be pent-up demand for stuff that simply works and stays private.
There sure is !! (well...me anyway :-)
On the Internet/Social front, tomorrow I will proposing to my local Makerspace that they setup a NextCloud server for private sharing and community building. One cool aspect of NextCloud is that it can be "federated" with other NextCloud servers to grow the network. I think if other Makerspaces implement NextCloud, we could have a powerful alternative to social media (at least for Makerspace members in this case).
I have also been looking at things like the Red language (red-lang.org). With only a 1MB download and it contains the whole toolchain, full standard library, REPL and is cross-platform too !! (They are in the middle of a crypto-coin offering to help fund their existing foundation). Red is a modernization and compilable re-envisioning of the REBOL language (rebol.com) (~90% compatible).
You can find out much more here: http://www.red-lang.org/p/about.html
I think software needs a massive reset as the bloat and security issues have become overwhelming. Red could be one of the answers to that call.
Even the CPUs are fully backdoored and broken. Thankfully, P2 doesn't use speculative execution NOR does it have a "Management Engine".
I really look forward to the P2's release. It may not be a replacement for our laptops and servers but at least with it, we will actually know what is running on it and that it isn't compromised from the circuits up!
Looking back, I'm amazed what the Mac and Amiga were able to do with 1MB of RAM and 1.4 MIPS (8MHz 68000). It makes me wonder what could be done with the P2 and Tachyon!
I just listened to the first half of the video on the red-lang.org link. Very neat! I totally agree with his objectives.
Do you have any idea if it would be practical to write a multi-platform IDE in red today?
What he said about needing to have control of your tool is right on. I think a lot of these "makers" aren't really even programming. I'd call it more "configuring". If you can't control and understand what is actually happening, you're guessing, somewhat, and not gaining the understanding and confidence needed to actually do anything new. I believe that when people get a taste of certainty, their abilities can multiply quickly. Almost nobody knows what that's all about, anymore. Huge potential lies in bringing things back down to earth.
For some reason I've been unable to download the Lattice tools so I haven't been able to try mine. I get an error saying I don't have access. I thought these tools were supposed to be free. I have an email in to their web support people to sort this out.
Go to the Lattice website and FAQ. That will walk you thru the steps to get your code authorised. It is free, just an unpleasant bit of garbage - it wants your mac address.
The site isn't working for me. When I click on the link to get a license it says I don't have access to that page. In any case, I've installed the IceStorm toolchain and am able to build an RGB blinking example that should work on the Upduino board. Unfortuately, it doesn't. That may be because I built or loaded it wrong or it may be because I soldered the LED onto the board wrong. I think I'm going to have to find another development board unless the maker of the Upduino gets back to me about how to buy a board with the LED already soldered on.
One final update on my Upduino because it is off-topic for this thread. I posted a question on the IceStorm forum and it was suggested that I remove the -S from the iceprog command since that tells iceprog to program the SRAM and the Upduino board wiring instructions tell it to boot from the onboard flash instead. That results in the RGB blink demo mostly working. The blue and green LEDs seem to work but the red one doesn't. I imagine that's because I didn't do a good job of soldering. I'm ordering another Upduino board and asking that the LED be soldered on before shipping. We'll see if that works. In the meantime I'll try heating the red pin again to see if it's just a cold solder joint that is causing the problem. If not I may have fried the red LED by applying too much heat.
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin. I guess I'll either have to forget the red LED or wait for Gnarly Grey to send me a Upduino board with the LED already soldered on.
If you can't control and understand what is actually happening, you're guessing, somewhat, and not gaining the understanding and confidence needed to actually do anything new. I believe that when people get a taste of certainty, their abilities can multiply quickly. Almost nobody knows what that's all about, anymore. Huge potential lies in bringing things back down to earth.
Yeah, I wasn't confident with what can or cannot be done with a computer until I stepped through a disassembly on screen - It crystallised the execution for me. Until then, CPUs were a magic black box that only ran fast when a mysterious binary blob got called from a BASIC program.
My real understanding then built both up and down from that point. Going up to languages and programming concepts and down to hardware and design efficiencies.
Yeah, I wasn't confident with what can or cannot be done with a computer until I stepped through a disassembly on screen
I remember the day myself.
A few of us were poking around, having finished up required work.
"So that's what it is doing."
Soon after, it was computers only do a few things, and they do them fast:
Add numbers, Boolean operators, copy numbers.
It's like never really being grounded in your OS without a full load and configure.
The hardware follows quickly too. Why does copying a number here do that on this computer, and not that one? How are these things determined? Changing things? Adding new things?
Thej,
Do you have any idea if it would be practical to write a multi-platform IDE in red today?
@cgracey
Today, it's not quite ready for that.
However, it appears that the RED coin offering is going very well and if it truly does, then they will have the funds to double (or more) their dev team and accelerate their release of Red 1.0.
Currently, Red is at version 0.6.3 with 0.6.4 (guessing) to be released some time in Feb.
There are still a number of missing features from the system. GUI features are not yet consistent across all platforms but should be improved with the next release. The Windows version is the most feature complete there and Linux is the furthest behind (they need a GTK developer to bring it up to par).
Now would be an excellent time to learn Red in anticipation of their accelerated development schedule.
As far as making a IDE, I think it could be made once version 0.7.0 is out. The language itself is already very reliable and functional. That version will have full IO. Currently, IO consists of only Files and Http. Things like Serial will wait for 0.7.0.
From comments I have read by the developers, Ports and Garbage Collection "may" be released as soon as 0.6.4 as work on them has gone "really well" but we will only know once it is released.
One last note; Red is based on REBOL which was created by Carl Sassenrath, the creator of the Amiga OS.
REBOL and thus Red, embody Carl's philosophy on language and system design.
Here's a great example. Carl outlined and implemented, with REBOL, the "Internet OS". Substantially faster, smaller and more functional than Web apps today back in the mid 90's. http://www.rebol.com/index-ios.html
What? IceStorm does actually work with the Ultra Plus?
That is the best news I have heard all year! Looks like I now need an Upduino or two.
Now, the question is can we fit a P1V in there? Or even part of one? ZiCog would love that, what with all the RAM available.
As this is all off topic perhaps a reply in General Discussion would be appropriate.
As this is P1V centric, perhaps a P1 forum thread, on P1v in Lattice Ultra Plus on Upduino, using Icestorm ?
Be great to see what MHz a 2-clock P1V can reach on the Lattice part.
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin.
Can you remove the reset header to allow better access ?
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin.
Can you remove the reset header to allow better access ?
Maybe. My desoldering skills are worse than my soldering skills though.
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin.
Can you remove the reset header to allow better access ?
Maybe. My desoldering skills are worse than my soldering skills though.
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin.
Can you remove the reset header to allow better access ?
Maybe. My desoldering skills are worse than my soldering skills though.
But they will improve with practice.
You're right! I removed the ground pin from the two-pin header. I don't need that anyway since only the reset pin needs to be connected to program the FPGA. I heated up the red pin and now it works as well as the blue and green LEDs. Thanks for the encouragement!
And companies are getting very invasive about who and where you are. These guys were telling me that although DJI drones are the best tech, the software spies on you.
I'm thinking there has got to be pent-up demand for stuff that simply works and stays private.
If they want to trade their frustration and time for success, just get a DJI. This battle was won a long time ago. The open source code requires a depth of understanding beyond most casual users.
And companies are getting very invasive about who and where you are. These guys were telling me that although DJI drones are the best tech, the software spies on you.
I'm thinking there has got to be pent-up demand for stuff that simply works and stays private.
If they want to trade their frustration and time for success, just get a DJI. This battle was won a long time ago. The open source code requires a depth of understanding beyond most casual users.
They'd rather struggle with difficult-to-use stuff if it means maintaining their privacy. The new way is that there's no privacy.
I think the inherited ability of the future P2 is that one does not need a OS to use it. Chip did a great job on the P1 to simplify the environment and build a MC like nobody else would have done at that time.
Because - we all need to understand that both of the Gracey Brothers are simply insane or genial, depending on the point you look from.
Chip for doing things NOT according to usual reasons and understanding and common practice, Ken for supporting all of this and believing in his ability to STILL make a sustainable business out of this mess.
And they did!
That nonconformismus(?) is what a lot of people draw to the P1. It was different from the other stuff, and better, simpler, more intuitive as everything out there.
It was so with the Javelin, the Stamp, the P1 and will be with the P2. Every time groundbreaking changes to 'known' things.
The P2 is finally coming together, having TAQOZ in the ROM is the right decision, a REPL spin would do it also but FORTH is inherently extensible, something spin can not provide as easy.
Like @potatohead and others mentioned a couple of times, one part of the beauty of the P1 is the seamless integration from HLL and ASM to get things done in short time.
This will be even more true with HUBEXEC and inline-PASM in SPIN2.
SURE, Parallax said they can not finance GCC at the moment, but Guys be relaxed, the complete BLOCKLY system is bound to C and Ken will make sure it will run on a P2.
He has to.
But going to silicon is a major investment that needs to be done first.
The P2 might be good enough to get us out of that OS dilemma with weekly updates and bloated software.
SURE, Parallax said they can not finance GCC at the moment, but Guys be relaxed, the complete BLOCKLY system is bound to C and Ken will make sure it will run on a P2.
He has to.
So what is the plan for C on the P2? When will the development start? Will it start right after the chip is available, or will it start some time after the chip has been sold and some of the NRE has been recouped?
Does BLOCKLY really need C? Why can't it just use Spin2? People that program in BLOCKY really don't care which language BLOCKLY is converted into.
Along the lines of the subject of this thread, the biggest competitor to the P2 will be chips that can be programmed in C/C++. Without C/C++ support the P2 will not attract many new customers. TAQOZ and Spin2 it will not attract the mainstream of developers.
SURE, Parallax said they can not finance GCC at the moment, but Guys be relaxed, the complete BLOCKLY system is bound to C and Ken will make sure it will run on a P2.
He has to.
So what is the plan for C on the P2? When will the development start? Will it start right after the chip is available, or will it start some time after the chip has been sold and some of the NRE has been recouped?
Does BLOCKLY really need C? Why can't it just use Spin2? People that program in BLOCKY really don't care which language BLOCKLY is converted into.
Along the lines of the subject of this thread, the biggest competitor to the P2 will be chips that can be programmed in C/C++. Without C/C++ support the P2 will not attract many new customers. TAQOZ and Spin2 it will not attract the mainstream of developers.
Dave,
You have a P1 to P2 translator that lets one use PropGCC for P1 to write programs for P2. How does that work? Does it support the LMM memory model? Does it support hub exec on P2?
It supports hub exec on the P2. The utility s2pasm converts a P1 assembly file that was produced by PropGCC using the COG memory model. The command that produces the P1 assembly file is "propeller-elf-gcc -O2 -mcog -S file.c". It is then converted to P2 assembly by typing "s2pasm -p prefix.spin2 file". The file prefix.spin contains the P2 assembly code that defines the registers, and includes the __MULSI, __DIVSI and __UDIVSI routines for multiplication and division.
It supports hub exec on the P2. The utility s2pasm converts a P1 assembly file that was produced by PropGCC using the COG memory model. The command that produces the P1 assembly file is "propeller-elf-gcc -O2 -mcog -S file.c". It is then converted to P2 assembly by typing "s2pasm -p prefix.spin2 file". The file prefix.spin contains the P2 assembly code that defines the registers, and includes the __MULSI, __DIVSI and __UDIVSI routines for multiplication and division.
What do you use as a linker? Have you tried compiling the PropGCC C library?
I agree with Dave that Parallax should support C/C++ on the P2.
Personally I do avoid C/C++ when possible, but it IS the mainstream language used by millions of programmers.
The current BLOCKLY system uses PropGCC and the simple libraries, a attempt to also support SPIN was made by @ValeT, but never reached production level.
PASM2 + SPIN2 can be done by Parallax, but for GCC or Clang they have to hire external help. For some odd reason I always mix up Dave and David, please bear with me if I misattribute things.
In his spare time Dave build a lot of tools to convert Spin/Pasm to C for the P1. Hoping to convert some of us Spin Guys to use C too. And some of us took the bait, success!
He also can compile C for the P2 now, not GCC but working. All of this in his spare time, not getting paid for.
Jazzed build Simple IDE, Brent(?) did Propeller IDE, sadly (like with BST) development stopped. Even newer versions of PropGCC did not get included by Parallax, and now PropGCC itself is not easy to compile with current GCC versions.
Since SPIN2 is not in the ROM, but needs to be included into every SPIN2 program we will pretty soon have more then one SPIN2 interpreter.
Because we can.
I am not sure if I dislike C/C++ more or less then FORTH but I still advocate for TAQOZ and I still advocate for GCC or Clang.
What I do not understand is that @Clusso99 is building a MBR boot and file system boot and Peter is doing the same. In one of my former life's I was coordinating software developments. It does look wrong to me. Same goes for Peters assumption that once TAQOZ runs it has the whole P2 on its own.
It should be possible to run TAQOZ in its COG, while loading some C/SPIN2/Basic program into the lower memory. If not then it is no ROM OS but a ROM program.
It supports hub exec on the P2. The utility s2pasm converts a P1 assembly file that was produced by PropGCC using the COG memory model. The command that produces the P1 assembly file is "propeller-elf-gcc -O2 -mcog -S file.c". It is then converted to P2 assembly by typing "s2pasm -p prefix.spin2 file". The file prefix.spin contains the P2 assembly code that defines the registers, and includes the __MULSI, __DIVSI and __UDIVSI routines for multiplication and division.
What do you use as a linker? Have you tried compiling the PropGCC C library?
I use p2link, which is a utility I wrote to link the object files produced by p2asm. Instead of using the ELF file format I use a simple object file format that I developed. I thought about using the ELF format, but it was too complicated for my brain to comprehend.
I haven't tried compiling the PropGCC library. Currently, p2gcc has a small library containing frequently used library functions. It would make sense to just copy the whole PropGCC library, and modify the functions that contain P1-specific code.
It supports hub exec on the P2. The utility s2pasm converts a P1 assembly file that was produced by PropGCC using the COG memory model. The command that produces the P1 assembly file is "propeller-elf-gcc -O2 -mcog -S file.c". It is then converted to P2 assembly by typing "s2pasm -p prefix.spin2 file". The file prefix.spin contains the P2 assembly code that defines the registers, and includes the __MULSI, __DIVSI and __UDIVSI routines for multiplication and division.
What do you use as a linker? Have you tried compiling the PropGCC C library?
I use p2link, which is a utility I wrote to link the object files produced by p2asm. Instead of using the ELF file format I use a simple object file format that I developed. I thought about using the ELF format, but it was too complicated for my brain to comprehend.
I haven't tried compiling the PropGCC library. Currently, p2gcc has a small library containing frequently used library functions. It would make sense to just copy the whole PropGCC library, and modify the functions that contain P1-specific code.
I don't think there is too much P1-specific code in the PropGCC library. Shouldn't be too hard to just compile all of it with your new compiler toolchain.
Comments
The way things are going today, hardly anything is reliable, due to the way things are put together. Nobody, almost, has sufficient control of the mess to make any of it work. And everything is gigabytes in size.
My Android phone isn't able to forward emails and messages, lately. The Firefox browser on my PC suddenly can't display videos, though you can hear the audio. On and on.
And companies are getting very invasive about who and where you are. These guys were telling me that although DJI drones are the best tech, the software spies on you.
I'm thinking there has got to be pent-up demand for stuff that simply works and stays private.
On the Internet/Social front, tomorrow I will proposing to my local Makerspace that they setup a NextCloud server for private sharing and community building. One cool aspect of NextCloud is that it can be "federated" with other NextCloud servers to grow the network. I think if other Makerspaces implement NextCloud, we could have a powerful alternative to social media (at least for Makerspace members in this case).
I have also been looking at things like the Red language (red-lang.org). With only a 1MB download and it contains the whole toolchain, full standard library, REPL and is cross-platform too !! (They are in the middle of a crypto-coin offering to help fund their existing foundation). Red is a modernization and compilable re-envisioning of the REBOL language (rebol.com) (~90% compatible).
You can find out much more here:
http://www.red-lang.org/p/about.html
I think software needs a massive reset as the bloat and security issues have become overwhelming. Red could be one of the answers to that call.
Even the CPUs are fully backdoored and broken. Thankfully, P2 doesn't use speculative execution NOR does it have a "Management Engine".
I really look forward to the P2's release. It may not be a replacement for our laptops and servers but at least with it, we will actually know what is running on it and that it isn't compromised from the circuits up!
Looking back, I'm amazed what the Mac and Amiga were able to do with 1MB of RAM and 1.4 MIPS (8MHz 68000). It makes me wonder what could be done with the P2 and Tachyon!
J
I just listened to the first half of the video on the red-lang.org link. Very neat! I totally agree with his objectives.
Do you have any idea if it would be practical to write a multi-platform IDE in red today?
What he said about needing to have control of your tool is right on. I think a lot of these "makers" aren't really even programming. I'd call it more "configuring". If you can't control and understand what is actually happening, you're guessing, somewhat, and not gaining the understanding and confidence needed to actually do anything new. I believe that when people get a taste of certainty, their abilities can multiply quickly. Almost nobody knows what that's all about, anymore. Huge potential lies in bringing things back down to earth.
Edit: Looks like the red LED pin must be one of the ones next to the reset header. That means there is not enough space to get the soldering iron between them to heat the pin. I guess I'll either have to forget the red LED or wait for Gnarly Grey to send me a Upduino board with the LED already soldered on.
That is the best news I have heard all year! Looks like I now need an Upduino or two.
Now, the question is can we fit a P1V in there? Or even part of one? ZiCog would love that, what with all the RAM available.
As this is all off topic perhaps a reply in General Discussion would be appropriate.
My real understanding then built both up and down from that point. Going up to languages and programming concepts and down to hardware and design efficiencies.
I remember the day myself.
A few of us were poking around, having finished up required work.
"So that's what it is doing."
Soon after, it was computers only do a few things, and they do them fast:
Add numbers, Boolean operators, copy numbers.
It's like never really being grounded in your OS without a full load and configure.
The hardware follows quickly too. Why does copying a number here do that on this computer, and not that one? How are these things determined? Changing things? Adding new things?
Can I make one?
@cgracey
Today, it's not quite ready for that.
However, it appears that the RED coin offering is going very well and if it truly does, then they will have the funds to double (or more) their dev team and accelerate their release of Red 1.0.
Currently, Red is at version 0.6.3 with 0.6.4 (guessing) to be released some time in Feb.
There are still a number of missing features from the system. GUI features are not yet consistent across all platforms but should be improved with the next release. The Windows version is the most feature complete there and Linux is the furthest behind (they need a GTK developer to bring it up to par).
Now would be an excellent time to learn Red in anticipation of their accelerated development schedule.
As far as making a IDE, I think it could be made once version 0.7.0 is out. The language itself is already very reliable and functional. That version will have full IO. Currently, IO consists of only Files and Http. Things like Serial will wait for 0.7.0.
Here is the Trello for the project. Obviously, there are no dates listed.
https://trello.com/b/FlQ6pzdB/red-tasks-overview
From comments I have read by the developers, Ports and Garbage Collection "may" be released as soon as 0.6.4 as work on them has gone "really well" but we will only know once it is released.
One last note; Red is based on REBOL which was created by Carl Sassenrath, the creator of the Amiga OS.
REBOL and thus Red, embody Carl's philosophy on language and system design.
Here's a great example. Carl outlined and implemented, with REBOL, the "Internet OS". Substantially faster, smaller and more functional than Web apps today back in the mid 90's.
http://www.rebol.com/index-ios.html
J
As this is P1V centric, perhaps a P1 forum thread, on P1v in Lattice Ultra Plus on Upduino, using Icestorm ?
Be great to see what MHz a 2-clock P1V can reach on the Lattice part.
Can you remove the reset header to allow better access ?
But they will improve with practice.
Now stop while youre ahead
Even if this thing is slow it might be a really good bridge project for getting people across the line and into P1Vs.
If they want to trade their frustration and time for success, just get a DJI. This battle was won a long time ago. The open source code requires a depth of understanding beyond most casual users.
They'd rather struggle with difficult-to-use stuff if it means maintaining their privacy. The new way is that there's no privacy.
Because - we all need to understand that both of the Gracey Brothers are simply insane or genial, depending on the point you look from.
Chip for doing things NOT according to usual reasons and understanding and common practice, Ken for supporting all of this and believing in his ability to STILL make a sustainable business out of this mess.
And they did!
That nonconformismus(?) is what a lot of people draw to the P1. It was different from the other stuff, and better, simpler, more intuitive as everything out there.
It was so with the Javelin, the Stamp, the P1 and will be with the P2. Every time groundbreaking changes to 'known' things.
The P2 is finally coming together, having TAQOZ in the ROM is the right decision, a REPL spin would do it also but FORTH is inherently extensible, something spin can not provide as easy.
Like @potatohead and others mentioned a couple of times, one part of the beauty of the P1 is the seamless integration from HLL and ASM to get things done in short time.
This will be even more true with HUBEXEC and inline-PASM in SPIN2.
SURE, Parallax said they can not finance GCC at the moment, but Guys be relaxed, the complete BLOCKLY system is bound to C and Ken will make sure it will run on a P2.
He has to.
But going to silicon is a major investment that needs to be done first.
The P2 might be good enough to get us out of that OS dilemma with weekly updates and bloated software.
Mike
.
Does BLOCKLY really need C? Why can't it just use Spin2? People that program in BLOCKY really don't care which language BLOCKLY is converted into.
Along the lines of the subject of this thread, the biggest competitor to the P2 will be chips that can be programmed in C/C++. Without C/C++ support the P2 will not attract many new customers. TAQOZ and Spin2 it will not attract the mainstream of developers.
You have a P1 to P2 translator that lets one use PropGCC for P1 to write programs for P2. How does that work? Does it support the LMM memory model? Does it support hub exec on P2?
Personally I do avoid C/C++ when possible, but it IS the mainstream language used by millions of programmers.
The current BLOCKLY system uses PropGCC and the simple libraries, a attempt to also support SPIN was made by @ValeT, but never reached production level.
PASM2 + SPIN2 can be done by Parallax, but for GCC or Clang they have to hire external help. For some odd reason I always mix up Dave and David, please bear with me if I misattribute things.
In his spare time Dave build a lot of tools to convert Spin/Pasm to C for the P1. Hoping to convert some of us Spin Guys to use C too. And some of us took the bait, success!
He also can compile C for the P2 now, not GCC but working. All of this in his spare time, not getting paid for.
Jazzed build Simple IDE, Brent(?) did Propeller IDE, sadly (like with BST) development stopped. Even newer versions of PropGCC did not get included by Parallax, and now PropGCC itself is not easy to compile with current GCC versions.
Since SPIN2 is not in the ROM, but needs to be included into every SPIN2 program we will pretty soon have more then one SPIN2 interpreter.
Because we can.
I am not sure if I dislike C/C++ more or less then FORTH but I still advocate for TAQOZ and I still advocate for GCC or Clang.
What I do not understand is that @Clusso99 is building a MBR boot and file system boot and Peter is doing the same. In one of my former life's I was coordinating software developments. It does look wrong to me. Same goes for Peters assumption that once TAQOZ runs it has the whole P2 on its own.
It should be possible to run TAQOZ in its COG, while loading some C/SPIN2/Basic program into the lower memory. If not then it is no ROM OS but a ROM program.
my 2 cents
Mike
I haven't tried compiling the PropGCC library. Currently, p2gcc has a small library containing frequently used library functions. It would make sense to just copy the whole PropGCC library, and modify the functions that contain P1-specific code.