I feel that it would be helpfull to create an entire IDE with compiler, assembler, and linker to run native on the verious common Propeller
Strangely enough the Props creator, Chip Gracey, has exactly the same desire. Sadly I can't find a link to his statements about that. Hence the pressing need for a bigger, faster Prop II to run it on.
I think discussion of that would be best on another thread. This one is specifically about bst.
Hence why I am requesting a port of BSTC to the prop.
Heater:
There is 32K of HUB mem, plus 2K * 8 in the cogs. Now there are full blown IDEs (including a Pascal compiler) that run on the VIC20 witch has 2K (or is it 3K) of usable RAM.
Runs fine on PropCade (after patching for SD card select logic), and pretty much any other propeller board.
It was one of my main motivations for writing single-cog high resolution text drivers.
I am looking forward to seeing a port of it to the C3, supporting SRAM and FLASH, because then I can easily back port it to PropCade, Morpheus, and my other upcoming boards.
interesting idea. Overlay support wpuld require a universal API for mass storage devices, hmm. I like it alot. What are the chances of BSTC (just the compiler) becoming open source, or some one documenting the spin byte code as well as the Props binary opcodes already are?
It isn't a legal file, but from some of your other posts I see that you encourage all reports.
The problem line is at the label check4a. A couple of newlines are missing, causing three lines to be merged into one.
The invocation and error message are:
[john@eccles asmtest]$ bstc testasmfail1.spin
Found a USB Serial Device
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
Loading Object testasmfail1
An unhandled exception occurred at $08053350 :
EAccessViolation : Access violation
$08053350
$0804BE65
$0804C4C4
$0804D045
$0806A1AE
This is under Fedora Core 11, using the latest bstc from fnarfbargle.
In case you're wondering, I'm testing a Prop simulator by parsing truth tables from the Propeller Manual v1.1, with a program that generates tests based on the information in the tables. The program that generated this file was missing a couple of "\n" in its output.
Correcting the program fixed the crash, so this needn't be high on your todo list.
davidsaunders,
Sphinx works very nicely on the Propeller. It would be a major rewrite to get BSTC to run on the Propeller if it is at all possible. The resources available on a PC are far and away greater than those on a Propeller. In fact, Sphinx works only because all the I/O drivers and their buffers have been moved into cogs including the file-level SD card I/O in order to maximize the hub storage available for compiler internal tables. Sphinx is also provided under the MIT License which is pretty broad.
I do not know if it is your code or the Qt libraries you use. I have had no problem using bst.linux until today, suddenly this afternoon I typed:
cd ~/bst
./bst.linux
as I have many times with out problem. This time it responded:
Sorry for the screen capture, my terminal does not make it easy to copy text out (and I did not feel like redirecting stderr).
Is this failure to create a pipe a known problem, if so what is the solution? I would like to continue to use an IDE that already works correctly with the command line tools.
I don't think Brad is following this thread any more. He hasn't been here in quite a while. At some point he said he didn't know how to subscribe to a thread on the new forum. You may want to email him directly.
Unfortunately, bst feels a bit abandoned. There are some bugs in the Mac development version that haven't been addressed. He hasn't updated the development snapshots since December.
It's not really significant, but he uses Gtk, not Qt.
I hope Brad will continue to maintain his tools because they are the only reason why I'm still using the prop
It's the only one working prety well under linux.
I hope Brad will continue to maintain his tools because they are the only reason why I'm still using the prop
It's the only one working prety well under linux.
Have you seen the PZST IDE? It has been in development for a while and is working well. Andrey is getting ready for the first release.
It seems like Brad has other things going on in his life that have put bst on the back burner at least for a while. One of the nice things about PZST is that it is open-source so if Andrey has to move on, we still have access to the source for further development.
Except PZST does not have a compiler of it's own. It uses BSTC to do the actual compilation. Perhaps one day it will also use Homespun. Or even the open source Spin compiler Roy Eltam is creating from the. Prop Tool compiler.
Strangely enough the Props creator, Chip Gracey, has exactly the same desire. Sadly I can't find a link to his statements about that. Hence the pressing need for a bigger, faster Prop II to run it on.
There are other earlier ones, and some PM's, which I think still exist for me on the old forum. Can anyone tell me how to get at those these days? I realized I never exported... I really want some of those. Help! We had some great "what if" kinds of discussions just prior to Chip really digging into Prop II, with lots of opinion and perspective tossed in by those who have experienced various environments, and the impact of core changes over time.
**found I can still log on to the old forum. Don't ditch that for a while, please! I've got to get my stuff archived.***
Anyway, the earlier discussions surround various trouble with operating systems, how things change, and dependencies in general. For some current perspective, just look at the "let's use gcc" discussion. One of the primary matters to tackle is how to integrate the bits needed to to propellers well, and keep up with the always changing gcc.
A self-hosting system, capable of something like ordinary ANSI C, SPIN, and PASM with macros and some other basic goodies, would provide one stable, long term, unchanging reference for code build with it / on it. That is compelling for a lot of reasons. Gold objects, actually any objects, code bits, you name it, once built with it, would remain build-able, with no real worries about dependent things.
The most often cited negative to this is on chip resources, nicely removed now that we know Prop II will just boot some environment, and the second most often cited negative is how it's a throw back to early days.
Well, it is. No question. But then again, the merits of such a self-feeding environment are many, the primary one being extremely high use value over longer periods of time.
Probably a fun thread someday in the near future. Just thought I would point to one fragment of that discussion.
Edit: Interestingly, there is this:
By the way, the main reasons for the many rev's of the Propeller Tool have had to do with Windows issues, not the core tool functionality.
-->Chip
And note the compiler was written in assembly language, debugged, and then just gets wrapped up in "the mess" we deal with every day. Interesting perspective!
Final edit: Ha! I re-read chunks of that thread, and... there is a nice, new, working Apple ][ in my work area. Funny that. I really want one, and have it, and really want to put a prop on a card in it to make a dev station, work machine. Seems that discussion had some sharp teeth. The bug bit!
I found a bug with BST 0.19.3. The following code compiles just fine with no problems at all:
PUB broken | n
n:=%12345678901234567890123456789012345678901234567890123456789012345678901234567890
I haven't actually run the code to see what happens, but 1) the number - even in decimal - is way more than 32 bits, and 2) the number has non-binary digits.
From looking at the memory map, commenting out the n:=... line makes the program only one long shorter, so it definitely is a parsing problem and the number is not being stuffed in there somewhere.
I just installed Ubumtu 11.04 32bit, and bst IDE is behaving very differently in this version. One big problem that I found was the use of the scroll bars in the font select. I did not check all of the places in your program where the scroll bars would appear. At this point it is impossible to change to a different font.
Does people still have a working bst for current Ubuntu versions? I have just finished a DracBlade board (had to use Windows and proptool to find out that the usb-to-serial adapter was broken, and find a working one), and I have now tried bst under two Ubuntu versions
10.10 64-bit:
tingo@kg-u35jc:~$ uname -a
Linux kg-u35jc 2.6.35-30-generic #59-Ubuntu SMP Tue Aug 30 19:00:03 UTC 2011 x86_64 GNU/Linux
11.04 32-bit:
tingo@kg-home:~/work/1_dmesg$ uname -a
Linux kg-home 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
i686 i686 i386 GNU/Linux
On both machines, bst behaves the same: if I press F7 (or if I select "Configure Ports") it hangs, and has to be killed.
The usb-to-serial adapter is detected as ttyUSB0, and my user has access to it:
tingo@kg-home:~/work/1_dmesg$ ls -l /dev/ttyU*
crw-rw---- 1 root dialout 188, 0 2011-10-08 18:43 /dev/ttyUSB0
tingo@kg-home:~/work/1_dmesg$ id tingo
uid=1000(tingo) gid=1000(tingo) groups=1000(tingo),4(adm),20(dialout),24(cdrom),46(plugdev)
,112(lpadmin),120(admin),122(sambashare),124(vboxusers)
Any hints on how to fix this?
(No, running Windows or Windows tools isn't an option that I'm comfortable with)
I have tested more (all this done on the 32-bit Ubuntu 11.04 machine):
First I compiled a program using bstc (this part seems to work):
tingo@kg-home:~/work/prop/kyedos$ ../bstc.linux -e KyeDOS3.spin
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
Loading Object KyeDOS3
Loading Object SD3.01_FATEngine.spin
Loading Object DS1307_RTCEngine.spin
Loading Object ASCII0_STREngine.spin
Loading Object VGA_1024_VT100
Loading Object vga_80x40
Loading Object Pocketerm_Keyboard
Loading Object DracLCD
Loading Object timing
Loading Object pcFullDuplexSerial2FC
Program size is 25812 longs
Compiled 3981 Lines of Code in 0.226 Seconds
Then I try to load the resulting code:
tingo@kg-home:~/work/prop/kyedos$ ../bstl.linux -p1 ./KyeDOS3.eeprom
Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 09:34:58 on 2009/07/03
Found a USB Serial Device
and it just sits there, doing nothing.
I also tried this way:
tingo@kg-home:~/work/prop/kyedos$ ../bstc.linux -e -d /dev/ttyUSB0 -p1 KyeDOS3.spin
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
Loading Object KyeDOS3
Loading Object SD3.01_FATEngine.spin
Loading Object DS1307_RTCEngine.spin
Loading Object ASCII0_STREngine.spin
Loading Object VGA_1024_VT100
Loading Object vga_80x40
Loading Object Pocketerm_Keyboard
Loading Object DracLCD
Loading Object timing
Loading Object pcFullDuplexSerial2FC
Program size is 25812 longs
Compiled 3981 Lines of Code in 0.227 Seconds
Does people still have a working bst for current Ubuntu versions? I have just finished a DracBlade board (had to use Windows and proptool to find out that the usb-to-serial adapter was broken, and find a working one), and I have now tried bst under two Ubuntu versions
10.10 64-bit:[..]
I too ran into problems where I didn't have any before. Everything worked fine on my Debian 64-bit system. After an upgrade BST hangs. The kernel isn't changed, so I guess the culprit is either an upgraded libc or an upgraded graphics library.
That's the pitfall with binary-only software.. it's almost 100% certain the problem would be fixed with a simple recompile.
The solution I'm going to use is to install a simple chroot environment with a Debian Lenny or Squeeze 32-bit system. That's very easy to do and will let me keep a fixed, working setup inside my incrementally-upgrading Debian Sid 64-bit system.
@Tor: have you tested if bstc still works on your 64-bit machine? I can compile code with bstc fine (on my Ubuntu 64-bit machine), its just the serial transfer part that isn't working.
@Tor: have you tested if bstc still works on your 64-bit machine? I can compile code with bstc fine (on my Ubuntu 64-bit machine), its just the serial transfer part that isn't working.
Yes, both bstc and bstl work fine on my Debian 64-bit system. bst will hang in 'bst loading... please wait'.
UPDATE: I found out why bst hangs.. it's not related to the latest Debian upgrade, it's because bst tries to scan all filesystems! And currently there's a hanging NFS filesystem mounted on the top level which it's trying to read, so it hangs there. Why on earth it does that is beyond me, that filesystem has got nothing to do with my user account.
So bst works after all. I think I will go with the chroot setup anyway, to prevent bst from trying to access things which it shouldn't even know about.
I just installed Ubuntu 11.10 64-bit, and bst is working just fine. Does anybody know what the latest version of PropBASIC is, and what version is offered with bst? If it is the latest version of PopBASIC then I will give that a try also. It sort looks like BradC has given up on bst, that is really sad news, it is a very good IDE.
I just installed Ubuntu 11.10 64-bit, and bst is working just fine. Does anybody know what the latest version of PropBASIC is, and what version is offered with bst? If it is the latest version of PopBASIC then I will give that a try also. It sort looks like BradC has given up on bst, that is really sad news, it is a very good IDE.
So, if Bean is switching over to ViewPort, then I guess I will not pursue using PropBASIC on a Linux (Ubuntu) machine with a bst IDE.
Ray
Ray,
I don't think the intention is to have PropBasic rely on ViewPort. It's just that Bean has been doing some upgrades to support ViewPort. It should still work with bst.
A couple of things to consider. The first is that unlike bst you have to pay for viewport. Not a lot but it's not free. The second is that as of right now viewport doesn't work under linux. I kind of got it to go with win-xp running in virtual box but it was unusable. :-( I understand that a port is in the works and about ready for beta testing though. Personally I'm looking forward to being able to use it. Unfortunately I don't have a computer running native windows. :-(
Comments
Strangely enough the Props creator, Chip Gracey, has exactly the same desire. Sadly I can't find a link to his statements about that. Hence the pressing need for a bigger, faster Prop II to run it on.
Heater:
There is 32K of HUB mem, plus 2K * 8 in the cogs. Now there are full blown IDEs (including a Pascal compiler) that run on the VIC20 witch has 2K (or is it 3K) of usable RAM.
http://www.sphinxcompiler.com/
http://propeller.wikispaces.com/Sphinx
http://www.youtube.com/watch?v=pqBEhP_ISlc
Runs fine on PropCade (after patching for SD card select logic), and pretty much any other propeller board.
It was one of my main motivations for writing single-cog high resolution text drivers.
I am looking forward to seeing a port of it to the C3, supporting SRAM and FLASH, because then I can easily back port it to PropCade, Morpheus, and my other upcoming boards.
I strongly suspect that a port of btsc (and I mean jut the command line compiler, not including IDE) would be even larger than Sphinx.
Sphinx is broken apart into multiple passes due to the memory limit of the Prop.
Now if some made a Spin VM that used VMCOG or steve's caching driver, it could be done as a single pass compiler.
Another potential path is to add overlay support to a spin compiler - that's how all the old CP/M compilers fit in so little space.
I seem to have a spin file that crashes bstc.
It isn't a legal file, but from some of your other posts I see that you encourage all reports.
The problem line is at the label check4a. A couple of newlines are missing, causing three lines to be merged into one.
The invocation and error message are:
This is under Fedora Core 11, using the latest bstc from fnarfbargle.
In case you're wondering, I'm testing a Prop simulator by parsing truth tables from the Propeller Manual v1.1, with a program that generates tests based on the information in the tables. The program that generated this file was missing a couple of "\n" in its output.
Correcting the program fixed the crash, so this needn't be high on your todo list.
Sphinx works very nicely on the Propeller. It would be a major rewrite to get BSTC to run on the Propeller if it is at all possible. The resources available on a PC are far and away greater than those on a Propeller. In fact, Sphinx works only because all the I/O drivers and their buffers have been moved into cogs including the file-level SD card I/O in order to maximize the hub storage available for compiler internal tables. Sphinx is also provided under the MIT License which is pretty broad.
I have an error.
I do not know if it is your code or the Qt libraries you use. I have had no problem using bst.linux until today, suddenly this afternoon I typed: as I have many times with out problem. This time it responded:
Sorry for the screen capture, my terminal does not make it easy to copy text out (and I did not feel like redirecting stderr).
Is this failure to create a pipe a known problem, if so what is the solution? I would like to continue to use an IDE that already works correctly with the command line tools.
Unfortunately, bst feels a bit abandoned. There are some bugs in the Mac development version that haven't been addressed. He hasn't updated the development snapshots since December.
It's not really significant, but he uses Gtk, not Qt.
Bean
It's the only one working prety well under linux.
JM
Have you seen the PZST IDE? It has been in development for a while and is working well. Andrey is getting ready for the first release.
It seems like Brad has other things going on in his life that have put bst on the back burner at least for a while. One of the nice things about PZST is that it is open-source so if Andrey has to move on, we still have access to the source for further development.
PZST Thread
You are correct. I meant to mention that, but it slipped my mind. Ideally PZST will eventually be part of an entirely open-source toolchain.
Here's one of the threads:
http://forums.parallax.com/showthread.php?117789-Prop-II-on-chip-development-question&highlight=chip+development+potatohead+chip+propeller
There are other earlier ones, and some PM's, which I think still exist for me on the old forum. Can anyone tell me how to get at those these days? I realized I never exported... I really want some of those. Help! We had some great "what if" kinds of discussions just prior to Chip really digging into Prop II, with lots of opinion and perspective tossed in by those who have experienced various environments, and the impact of core changes over time.
**found I can still log on to the old forum. Don't ditch that for a while, please! I've got to get my stuff archived.***
Anyway, the earlier discussions surround various trouble with operating systems, how things change, and dependencies in general. For some current perspective, just look at the "let's use gcc" discussion. One of the primary matters to tackle is how to integrate the bits needed to to propellers well, and keep up with the always changing gcc.
A self-hosting system, capable of something like ordinary ANSI C, SPIN, and PASM with macros and some other basic goodies, would provide one stable, long term, unchanging reference for code build with it / on it. That is compelling for a lot of reasons. Gold objects, actually any objects, code bits, you name it, once built with it, would remain build-able, with no real worries about dependent things.
The most often cited negative to this is on chip resources, nicely removed now that we know Prop II will just boot some environment, and the second most often cited negative is how it's a throw back to early days.
Well, it is. No question. But then again, the merits of such a self-feeding environment are many, the primary one being extremely high use value over longer periods of time.
Probably a fun thread someday in the near future. Just thought I would point to one fragment of that discussion.
Edit: Interestingly, there is this:
-->Chip
And note the compiler was written in assembly language, debugged, and then just gets wrapped up in "the mess" we deal with every day. Interesting perspective!
Final edit: Ha! I re-read chunks of that thread, and... there is a nice, new, working Apple ][ in my work area. Funny that. I really want one, and have it, and really want to put a prop on a card in it to make a dev station, work machine. Seems that discussion had some sharp teeth. The bug bit!
From looking at the memory map, commenting out the n:=... line makes the program only one long shorter, so it definitely is a parsing problem and the number is not being stuffed in there somewhere.
Ray
10.10 64-bit: 11.04 32-bit: On both machines, bst behaves the same: if I press F7 (or if I select "Configure Ports") it hangs, and has to be killed.
The usb-to-serial adapter is detected as ttyUSB0, and my user has access to it: Any hints on how to fix this?
(No, running Windows or Windows tools isn't an option that I'm comfortable with)
First I compiled a program using bstc (this part seems to work): Then I try to load the resulting code: and it just sits there, doing nothing.
I also tried this way: and here it hangs again.
I too ran into problems where I didn't have any before. Everything worked fine on my Debian 64-bit system. After an upgrade BST hangs. The kernel isn't changed, so I guess the culprit is either an upgraded libc or an upgraded graphics library.
That's the pitfall with binary-only software.. it's almost 100% certain the problem would be fixed with a simple recompile.
The solution I'm going to use is to install a simple chroot environment with a Debian Lenny or Squeeze 32-bit system. That's very easy to do and will let me keep a fixed, working setup inside my incrementally-upgrading Debian Sid 64-bit system.
-Tor
UPDATE: I found out why bst hangs.. it's not related to the latest Debian upgrade, it's because bst tries to scan all filesystems! And currently there's a hanging NFS filesystem mounted on the top level which it's trying to read, so it hangs there. Why on earth it does that is beyond me, that filesystem has got nothing to do with my user account.
So bst works after all. I think I will go with the chroot setup anyway, to prevent bst from trying to access things which it shouldn't even know about.
-Tor
Ray
It is normally available here:
http://www.fnarfbargle.com/PropBasic/
but Bean has been making some updates to work with ViewPort. Ver 1.25 is available in Post#2:
http://forums.parallax.com/showthread.php?135098-PropBasic-Bug
Jim
Ray
Ray,
I don't think the intention is to have PropBasic rely on ViewPort. It's just that Bean has been doing some upgrades to support ViewPort. It should still work with bst.
Jim