I noted a natural progression, and feel that there's an effort to
develop PBASIC for the Propeller either under consideration or
going on right now. First, the Propeller was developed to fit
the Basic Stamp configuration and it took on the nickname of
Propeller Stamp. Next, the Parallax web page offered a remarkable
new C-Language Compiler for the Propeller. And I watch the
Parallax forum and postings and see more and more support for
the Propeller, and amazing projects that are beckoning for a
PBASIC language that will open the door for us dyed-in-the-wool
Basic Stamp and PBASIC advocates. Thanks sincerely.
I don't see any reason a PBASIC Compiler couldn't be written for the Propeller either generating Spin bytecode or for its own VM, and no reason a Basic Stamp emulator couldn't be coded up in Spin or PASM so a Propeller looks to the outside world like it is a Basic Stamp, allowing download from the Stamp Editor.
I got proof of concept working for a BS1 but I know nothing of the tokenised code for the BS2 nor used the later BS2 PBASIC language.
I can see the benefit of PBASIC for the Propeller as a stepping stone. At present the best option is Spin using the BS2 Function Library in the Object Exchange. I haven't heard anyone on here mention doing anything though to deliver PBASIC for the Propeller in any form.
I had started working on a Basic Compiler, wanted to see how far I could get with a single phase compiling from EEPROM to EEPROM. What I wrote would parse expressions and some simple statements, would build a dictionary (in EEPROM) for labels and variables, and would generate some code for a LMM interpreter. At this point, it needs to be split into a scanner / parser, then a code generator. I posted what I have so far, don't have the link handy. I hope to get back to it sometime this Fall.
Paul Baker said...
Where did you hear that we were coming out with PBASIC for the Propeller?
That's not what I'd call a denial, Paul!
Seriously, though, a Propeller PBASIC would provide a convenient on-ramp for a lot of BASIC Stamp users and might be a good marketing ploy. It would change the equation from, "If I buy a Prop, I'll have to learn Spin," to, "I bought a Prop because I could program it in BASIC, and now I'm learning Spin." But, like everything else, it's a question of priorities and resource allocation.
Precisely, it falls in the same catagory as linux and OS X IDEs, would be really nice to have but the determination was made not to devote resources towards it. Likewise we encourage customers to try to tackle these types of things. It would be really cool if someone could·get it to hook up to the PC and be programed via the Basic Stamp IDE.
Paul Baker (Parallax) said...
Likewise we encourage customers to try to tackle these types of things. It would be really cool if someone could get it to hook up to the PC and be programed via the Basic Stamp IDE.
What's the situation on the BS2 token code ? I'm guessing Parallax don't officially offer support or documentation for it, and I recall the Tokenizer license precluded its being used for reverse engineering effort, but is there any information, however 'unofficial', available ?
There's Brian Forbes' book, Inside the BASIC Stamp II, which provides detailed info on the byte codes. (It doesn't cover the BS2p, etc., extensions, though.) You can get it here. I have a copy (recommended by Tracy Allen), and it's quite thorough.
Mike, that's a considerable accomplishment so far
and I encourage you to try a full scale or limited
version of PBASIC for the Propeller. I'd like to be the
first on your waiting list. Even a subset of basic can be
extremely powerful as Tom Pittman showed with Tiny
Basic on the 1802.
I would like to help, but I do not know where to start, or even if I could be of help. What all would a project like this entail?
And could anyone point me in the right direction?
-Seth
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The pessimist is never disappointed.
humanoido said...
Mike, that's a considerable accomplishment so far
and I encourage you to try a full scale or limited
version of PBASIC for the Propeller. I'd like to be the
first on your waiting list. Even a subset of basic can be
extremely powerful as Tom Pittman showed with Tiny
Basic on the 1802.
In the late 70s/early 80s, there was the ELF 1802 club in So. CA (San Fernando valley) which met monthly (??) if I recall. Yes, Tom Pittman and his Tiny Basic was there then also. Fond memories of that (slow, no call/return archetecture; 16 registers).
Thanks for the memories.
Seth said...
I would like to help, but I do not know where to start, or even if I could be of help. What all would a project like this entail?
And could anyone point me in the right direction?
There are three major parts ( assuming you want a Propeller in a box which someone would eb convinced was a Basic Stamp ) ...
1) Getting the image code from the Stamp IDE to the chip and then getting that stored into Eeprom.
2) Understanding what the token code means both 'syntactically' and 'semantically', for want of better terms. That is, knowing what format it's in and what it does. It's also handy to have an idea as to how to achieve it.
3) Being able to execute the image a token at a time. Being able to map what the Basic Stamp does onto what the Propeller chip can do.
There's quite a lot of work there. The first place to start is probably with Brian Forbes' book Phil linked to.
The top-level question is what do people want ...
1) A PBASIC programming language and compiler ?
2) A Propeller masquerading as an actual Basic Stamp module ?
3) Something else ?
Another — and possibly easier — approach would be to write a pre-processor that converts PBASIC code to Spin code. Much of the low-level stuff has already been done via Martin Hebel's "BS2 Functions" object in the Exchange. Loading then becomes a matter of invoking Propellent to compile the generated Spin code and upload the object code to the Prop.
It would be interesting, as a preliminary feasibility test, to hand-translate some PBASIC code into Spin and compare their execution times — Stamp vs. Propeller.
Good idea. Taking incremental steps and documenting the test results would be immensley useful to those analysing the test results and taking the research to the second phase.
We really need a game plan if more than one person is to be involved in this project.
this is especially if this is going to be an exercise in getting others to contribute according to their unique abilities.
You know the drill - Project Management.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
I would like to participate if it gets started. Is there any way I can help?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
Phil Pilgrim (PhiPi) said...
Another — and possibly easier — approach would be to write a pre-processor that converts PBASIC code to Spin code.
I looked at that for BS1 - The big problem there is it's not block structured and there's no GOTO in Spin. The only way I could see of doing it was a large CASE statement indexed on 'pc'.
It would be possible to poke the bytecode to create a fast jump direct to the statement to execute rather than execute the CASE statement itself.
Seth said...
So would we need to make a new IDE, or just have PBASIC instructions in the Propeller IDE?
That depends on the approach. A Propeller emulating a Basic Stamp can use the Stamp Editor ( that's how the Propeller JVM works with the JVM IDE ). The user wouldn't see it as anything but a Basic Stamp Module.
For a compiler, that could be command line or IDE but would likely be separate from the Propeller IDE.
To add PBASIC to the PropTool would need buy-in from Parallax but that would be quite neat if PBASIC syntax could be support, so either Spin, BASIC or a mix of the two ...
It would need _CLKMODE, PUB Main and so on to be valid Spin, no GOTO and GOSUB would need to be to a Spin method, but other than that the transition for Basic Stamp programmers should be quite painless. No reason anyone writing their own Propeller compiler couldn't support that.
Hmm, yeah, GOTOs could simply be banned, I supose. The problem — in any language — with allowing them is when they vector in and out of control blocks like FOR..NEXT loops. PBASIC seems to allow that, but it has to be messy to implement. OTOH, as long as the GOTOs maintain a nested structure, they could be converted to REPEATs and IFs. It just makes parsing a lot harder if they're allowed. Otherwise, converting PBASIC to Spin shouldn't require very deep parsing, if you rely on the Spin compiler for most of the error detection. Of course, it does make debugging a pain if you get error messages regarding the target code.
One possible issue: PBASIC math is natively 16-bit unsigned; Spin math, 32-bit signed. How "work-alike" must Prop PBASIC programs be? Should BASIC programs that rely on 16-bit truncation be allowed to break? Or must each and every math step be followed by ANDing TOS with $FFFF?
For the 'Propeller Masquerading as a Stamp' part, I've gotten that working. It is finicky at best, but if you give it a couple dozen tries, it will work! As long as you can hook up an rs232 connection to your prop, it should work. I used info from here to write the code, and also a lot of debugging and luck
NOTE: YOU CANNOT USE THE PROPPLUG BECAUSE IT WILL RESET THE PROPELLER!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
There is a "goto" in spin, well at least in the byte code there is .
Actually, a goto does not fit with how spin works. It would encourage too much bad programming practice. Maybe pbasic could be compiled into spin bytecode? However, that would need a new ide...
Could the abort trap be used maybe? Every time that there is a goto it would simply abort, go back to a main function with a big case statement that simply calls a bunch of different functions. This would require a different function for every label though which could become a problem (isn't there a limit on the number of methods?). I'm not sure of the syntax of pbasic but maybe it could work something like this
pbasic code
label1
b=1
c=2
a=b+c
goto label1
and in spin
CON
#0 label1 'just an enumeration of all the labels
VAR
byte functionLabel 'a variable to hold which label we are going to go to
word a
word b
word c
PUB main
functionLabel:=label1 'setup for where to start
repeat 'repeat so it just happens forever
case functionLabel
label1: \label1Method
PUB label1Method
b:=1
c:=2
a:=b+c
functionLabel:=label1
abort functionLabel
stevenmess2004 said...
There is a "goto" in spin, well at least in the byte code there is .
Actually, a goto does not fit with how spin works. It would encourage too much bad programming practice. Maybe pbasic could be compiled into spin bytecode? However, that would need a new ide...
What about an extended spin compiler that compiled 'BAS' blocks?
I've been looking at it (and I'm by no means BASIC fluent) but I think there are probably enough of the fundamental bits there to allow something like this to happen.
BradC said...
What about an extended spin compiler that compiled 'BAS' blocks?
I've been looking at it (and I'm by no means BASIC fluent) but I think there are probably enough of the fundamental bits there to allow something like this to happen.
I guess it would be possible but what is the advantage? Ultimately, if you want anything to be done you will either have to do it yourself or prove to Parallax that it is going to provide enough sales for them to get their money back on the effort they put into developing it.
Its Funny that on 8/27/08 I was searching hard for a PBasic Complier for the Propeller, I saw a C-complier for the Prop. and got excited. All the while "Ya'll" were talking about building one. I'm a newbie to Spin and ASM and to be honest ASM sucks. I thought MSDOS was bad; I might as well be writting in BIN. or HEX$. The SPIN isn't too bad. I like the MACROs (woops) OBJ files, But it still seems forein to Me.
I would be your 1st costumer if Ya'll made a Complier that used PBasic and retained the speed "~" and features of the Prop.
Just like I was one of the 1st to get a Prop.Dev.Board (I couldn't wait!!!!)
I have just out grown the BS2 (I really like the BS2, if I could only make it run faster). Not to be off topic,but I'm working on a multi BS2 w/ a front side bus close to a COG as I debug this,If I find some thing of use for the Prop PBasic Compiler I'll PostIt
_WMc$_out_---
If I hadn't got side-tracked to the LCC Compiler project I'd have been working on a BS1 emulator. No reason that couldn't be a BS2 emulator. I have some good ideas on how to get the speed up using a sort of JIT compilation and optimising on download. This is the project which I talked about needing a PCB designed for a few weeks ago - a 'Basic Stamp' style module using a Propeller but proper PCB rather than DIP carrier.
No promises, and no timescales or concrete plans, but it's on the cards and a definite possibility. Once LCC is done and dusted I'll be reviewing what next.
Humanoido
Posts: 5,770
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
develop PBASIC for the Propeller either under consideration or
going on right now. First, the Propeller was developed to fit
the Basic Stamp configuration and it took on the nickname of
Propeller Stamp. Next, the Parallax web page offered a remarkable
new C-Language Compiler for the Propeller. And I watch the
Parallax forum and postings and see more and more support for
the Propeller, and amazing projects that are beckoning for a
PBASIC language that will open the door for us dyed-in-the-wool
Basic Stamp and PBASIC advocates. Thanks sincerely.
humanoido
I got proof of concept working for a BS1 but I know nothing of the tokenised code for the BS2 nor used the later BS2 PBASIC language.
I can see the benefit of PBASIC for the Propeller as a stepping stone. At present the best option is Spin using the BS2 Function Library in the Object Exchange. I haven't heard anyone on here mention doing anything though to deliver PBASIC for the Propeller in any form.
Seriously, though, a Propeller PBASIC would provide a convenient on-ramp for a lot of BASIC Stamp users and might be a good marketing ploy. It would change the equation from, "If I buy a Prop, I'll have to learn Spin," to, "I bought a Prop because I could program it in BASIC, and now I'm learning Spin." But, like everything else, it's a question of priorities and resource allocation.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
What's the situation on the BS2 token code ? I'm guessing Parallax don't officially offer support or documentation for it, and I recall the Tokenizer license precluded its being used for reverse engineering effort, but is there any information, however 'unofficial', available ?
There's Brian Forbes' book, Inside the BASIC Stamp II, which provides detailed info on the byte codes. (It doesn't cover the BS2p, etc., extensions, though.) You can get it here. I have a copy (recommended by Tracy Allen), and it's quite thorough.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
and I encourage you to try a full scale or limited
version of PBASIC for the Propeller. I'd like to be the
first on your waiting list. Even a subset of basic can be
extremely powerful as Tom Pittman showed with Tiny
Basic on the 1802.
humanoido
And could anyone point me in the right direction?
-Seth
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The pessimist is never disappointed.
In the late 70s/early 80s, there was the ELF 1802 club in So. CA (San Fernando valley) which met monthly (??) if I recall. Yes, Tom Pittman and his Tiny Basic was there then also. Fond memories of that (slow, no call/return archetecture; 16 registers).
Thanks for the memories.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
There are three major parts ( assuming you want a Propeller in a box which someone would eb convinced was a Basic Stamp ) ...
1) Getting the image code from the Stamp IDE to the chip and then getting that stored into Eeprom.
2) Understanding what the token code means both 'syntactically' and 'semantically', for want of better terms. That is, knowing what format it's in and what it does. It's also handy to have an idea as to how to achieve it.
3) Being able to execute the image a token at a time. Being able to map what the Basic Stamp does onto what the Propeller chip can do.
There's quite a lot of work there. The first place to start is probably with Brian Forbes' book Phil linked to.
The top-level question is what do people want ...
1) A PBASIC programming language and compiler ?
2) A Propeller masquerading as an actual Basic Stamp module ?
3) Something else ?
Then, with experience gained, I would start with 2) A Propeller masquerading as an actual Basic Stamp module.
That is quite a great deal, in my estimation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
It would be interesting, as a preliminary feasibility test, to hand-translate some PBASIC code into Spin and compare their execution times — Stamp vs. Propeller.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 8/27/2008 4:37:57 PM GMT
Good idea. Taking incremental steps and documenting the test results would be immensley useful to those analysing the test results and taking the research to the second phase.
We really need a game plan if more than one person is to be involved in this project.
this is especially if this is going to be an exercise in getting others to contribute according to their unique abilities.
You know the drill - Project Management.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
-Seth
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The pessimist is never disappointed.
I looked at that for BS1 - The big problem there is it's not block structured and there's no GOTO in Spin. The only way I could see of doing it was a large CASE statement indexed on 'pc'.
It would be possible to poke the bytecode to create a fast jump direct to the statement to execute rather than execute the CASE statement itself.
That depends on the approach. A Propeller emulating a Basic Stamp can use the Stamp Editor ( that's how the Propeller JVM works with the JVM IDE ). The user wouldn't see it as anything but a Basic Stamp Module.
For a compiler, that could be command line or IDE but would likely be separate from the Propeller IDE.
To add PBASIC to the PropTool would need buy-in from Parallax but that would be quite neat if PBASIC syntax could be support, so either Spin, BASIC or a mix of the two ...
CON _CLKMODE = XTAL1+PLL16x _XINFREQ = 5_000_000 PUB Main repeat 10 toggle 1 pause 1000 serout 1, 4800, [noparse][[/noparse] "Amazing" ]It would need _CLKMODE, PUB Main and so on to be valid Spin, no GOTO and GOSUB would need to be to a Spin method, but other than that the transition for Basic Stamp programmers should be quite painless. No reason anyone writing their own Propeller compiler couldn't support that.
One possible issue: PBASIC math is natively 16-bit unsigned; Spin math, 32-bit signed. How "work-alike" must Prop PBASIC programs be? Should BASIC programs that rely on 16-bit truncation be allowed to break? Or must each and every math step be followed by ANDing TOS with $FFFF?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 8/27/2008 10:30:12 PM GMT
NOTE: YOU CANNOT USE THE PROPPLUG BECAUSE IT WILL RESET THE PROPELLER!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
There _could_ be a goto in spin.. if it were <ahem> "extended" slightly..
Hippy, could you ping me OOB when you get a minute? I can't seem to find any other way of contacting you..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Actually, a goto does not fit with how spin works. It would encourage too much bad programming practice. Maybe pbasic could be compiled into spin bytecode? However, that would need a new ide...
Could the abort trap be used maybe? Every time that there is a goto it would simply abort, go back to a main function with a big case statement that simply calls a bunch of different functions. This would require a different function for every label though which could become a problem (isn't there a limit on the number of methods?). I'm not sure of the syntax of pbasic but maybe it could work something like this
pbasic code label1 b=1 c=2 a=b+c goto label1 and in spin CON #0 label1 'just an enumeration of all the labels VAR byte functionLabel 'a variable to hold which label we are going to go to word a word b word c PUB main functionLabel:=label1 'setup for where to start repeat 'repeat so it just happens forever case functionLabel label1: \label1Method PUB label1Method b:=1 c:=2 a:=b+c functionLabel:=label1 abort functionLabelWhat about an extended spin compiler that compiled 'BAS' blocks?
I've been looking at it (and I'm by no means BASIC fluent) but I think there are probably enough of the fundamental bits there to allow something like this to happen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
He would have the greatest enthusiasm and excitement
about this.
humanoido
I guess it would be possible but what is the advantage? Ultimately, if you want anything to be done you will either have to do it yourself or prove to Parallax that it is going to provide enough sales for them to get their money back on the effort they put into developing it.
I would be your 1st costumer if Ya'll made a Complier that used PBasic and retained the speed "~" and features of the Prop.
Just like I was one of the 1st to get a Prop.Dev.Board (I couldn't wait!!!!)
I have just out grown the BS2 (I really like the BS2, if I could only make it run faster). Not to be off topic,but I'm working on a multi BS2 w/ a front side bus close to a COG as I debug this,If I find some thing of use for the Prop PBasic Compiler I'll PostIt
_WMc$_out_---
No promises, and no timescales or concrete plans, but it's on the cards and a definite possibility. Once LCC is done and dusted I'll be reviewing what next.