It took me quite a while to figure out how to load libraries into tasks, but I managed to find a way that works. You actually have to create two libraries: one library with ONLY the SUB and FUNC definitions which go at the top of the Task BEFORE your own SUB and FUNC definitions and another library with ONLY the SUB and FUNC code which go at the bottom of the Task AFTER your own SUB and FUNC difinitions.
I have attached an example of how to do this.
Sometimes programs become just too long to easily work on, so I also found a way to write Tasks as separate code and then also just include them in the main program (including loading Libraries into the Task). I have attached an example if this as well.
Following on from Maxwin's question on how to include Libraries in Tasks, I though the I should perhaps share some of the Libraries which I have written.
The first example is for an I2C Library which allows you to read or write either one or two Bytes (i.e. either a BYTE or a WORD) as well as using Data Addresses consisting of one Byte or two Bytes by assigning the appropriate value to the Address_Len Variable. It also caters for devices like the PCF8574 which do not have a Data Address, in which case you would assign zero to the Address_Len Variable. The I2C Pin Labels (I2C_SDA and I2C_SCL) are hardcoded in the I2C Library, but using variables, it is possible to dynamically change the Pin Numbers which are assigned to the hardcoded Pin Labels. Have a look at the TX_RX example of how to dynamically assign different Pin Numbers to the hardcoded Pin Labels.
Note that you ONLY have to define the Control Byte for the I2C WRITE operation - the Library code will do the necessary for I2C READs.
Secondly, because the TX_RX Library does not allow us to use variable Pins and Baud Rates, I have modified the TX_RX Library to so that we can use variables in the Main Program or Tasks for the TX and RX baud rates making it is possible to dynamically change the Baud Rates. Note that Labels TX_Pin, RX_Pin, TX_Baud and RX_Baud are hardcoded in the TX_RX Library. I have attached an example of how to use variable Baud Rates as well as changing the Pin Numbers assigned to the TX_Pin and RX_Pin Labels. This means that you can use the same TX_RX Library to write to many different Serial devices connected to different Pins and with different Baud Rates.
Please let me know if you get stuck with anything.
Regards
Andre
PS. The files with the _SUBS and _CODE names are for inclusion in Tasks. See my reply to Maxwin on how to include Libraries in Tasks.
Something which I forget to mention about the modified TX_RX library: I have written a new subroutine called TX_DECX which is based on the standard TX_DEC, except the new subroutine allows you to specify the number of digits that you want to display, especially useful for something like LCDs where you want a fixed number of digits displayed. TX_DECX will pad with leading zeroes if necessary, but take note, it will truncate leading digits if the number is larger than the number of digits to display. I have attached a sample program.
Finally, I have attached a library of Subroutines and Functions which I originally started writing mainly to get some of the .BIT and .BYTE alias functionality which we have in PBasic for the Basic Stamps, but it has expanded over the past 2 years and now contains all sorts of stuff.
Most of the subroutines and functions are fairly simple and their usage should be easily understood from the comments.
I have attached sample programs for most of the utilities. Note that these are my original test programs and are not always verbosely commented, but if you run them, you will get an idea of how it works.
Once again, the libraries with the _SUBS and _CODE in their names are for inclusion in TASKS.
Yes, great, that solves the matter by splitting into head and code files. Although 1 extra code line "load", its not a big effort- and is especially nice that the same technique can be used in the main cog and the tasks. That keeps things much simpler.
For reference, here is the update of my previous example, now working fine calling the same library code from both the main cog and task cog.
Thanks again Andre (and for TX_DEC also-- that was missing from my tx-lib)
TestLibs.pbas
DEVICE P8X32A, XTAL1, PLL16XXIN 5_000_000
LOAD "lib_delays.h.pbas"
LED1 PIN 1 LOW
TASK_BLINKLED TASK AUTO
PROGRAM Start
Start:
DO
TOGGLE LED1
DELAY_MS 1000
LOOP
END
LOAD "lib_delays.pbas"
' Task code
TASK TASK_BLINKLED
LED2 PIN 2 LOW
LOAD "lib_delays.h.pbas"
DO
TOGGLE LED2
DELAY_MS 1000
LOOP
LOAD "lib_delays.pbas"
ENDTASK
lib_delays.h.pbas
' Delays Library for PropBASIC by Jon McPhalen
DELAY_MS SUB 1 ' shell for PAUSE
DELAY_US SUB 1 ' shell for PAUSEUS
lib_delays.pbas
' Use: DELAY_MS duration' -- shell for PAUSE
'{$IFUSED DELAY_MS}
SUB DELAY_MS
PAUSE __param1
ENDSUB
'{$ENDIF}
' ----------------------------------------------------------------------
' Use: DELAY_US duration
' -- shell for PAUSEUS
'{$IFUSED DELAY_US}
SUB DELAY_US
PAUSEUS __param1
ENDSUB
'{$ENDIF}
And finally, finally, here is another library which I have been working on for a while and decided to finish at long last. It is for Parallel LCDs connected DIRECTLY to the Propeller (Can not use TX_RX Lib for Parallel LCDs :-( )
The library contains SUBS for:
* Sending an LCD Control Code
* Writing a Byte
* Writing a String (DATA or a Literal e.g. "My name is Andre"). It also allows for using the "@" character as a DATA terminator instead of zero because sometimes DATA strings have zeroes in them. The "@" is hardcoded in the Library, but you can change it to something else if you like.
* Writing a specified number of Digits without Leading Zeroes or Spaces for a Number (Constant, Variable or Literal)
* Writing a specified number of Digits with Leading Zeroes for a Number (Constant, Variable or Literal)
* Writing a specified number of Digits with Leading Spaces for a Number (Constant, Variable or Literal)
I have attached a sample program.
If you are going to use an IO Expander instead of connecting the LCD Pins directly e.g. 74HC595, MCP23008, MCP23S08, PCF8574, etc. you will have to modify the "LCD_CMD" and "LCD_BYTE" subroutines of the Library (and your program, obviously) to cater for the different output methods. If anybody gets stuck with this, let me know. I have sample programs for all these IO Expanders.
I also use the SparkFun Serial LCD Backpack often to save Pins (With the added advantage that you can use the modified TX_RX Lib), so if anybody requires help with this backpack, I will probably be able to assist. They are a little finicky to get to work properly. I have not had much success with Baud Rates higher than the default 9600. I have managed to get them to talk to the propeller at 115200 baud, but the comms is very eratic, so I tend to stick to the default 9600 Baud. In any case, changing the Baud Rate is a MISSION!
Something which I have to mention specifically regarding UTILS_LIB.pbas for the Look_Down and Look_Up Functions is that the DATA needs to be enclosed by "[" at the start and "]" at the end, e.g. Char0 DATA "[ABCDE]".
If I define variables in a subroutine as per the sample code below, am I correct in assuming that when the subroutine has finished executing, the variables defined in the subroutine are deleted or released? In other words, these variables exist only for the duration of the subroutine?
SUB LCD_STR
LCD_STR_Index VAR LONG
LCD_STR_Delimit VAR LONG
' Do Stuff
ENDSUB
If I define variables in a subroutine as per the sample code below, am I correct in assuming that when the subroutine has finished executing, the variables defined in the subroutine are deleted or released? In other words, these variables exist only for the duration of the subroutine?
SUB LCD_STR
LCD_STR_Index VAR LONG
LCD_STR_Delimit VAR LONG
' Do Stuff
ENDSUB
Regards
Andre
Hi Andre,
I think you will find they are common to the source file they exist in (common to the cog).
If you try to define the same var name in another sub, you will get an error that the var already exists.
For that reason, I usually prefix the sub-var name with the sub name, just to ensure they don't get re-used / conflict later
such as:
SUB getFishCount
getFishCount_idx VAR LONG
getFishCount_tmp VAR LONG
(oops, I can see you already used the prefix in your example!)
Anyhow, the vars are not specifically released or destroyed. The values remain as last set. They could be read or changed by any other code in the same cog.
I ran a small test program and found that variables defined in a sub are not cleared but that they are local to the sub - If you reference a variable which was defined IN a sub OUTSIDE of the sub, the compiler generates an error.
' LCD_STR_Index = 0 ' <== This generates a compiler error: ERROR 10 UNKNOWN COMMAND "LCD_STR_Index"
DO
LCD_STR
LOOP
SUB LCD_STR
LCD_STR_Index VAR LONG
TX_DEC LCD_STR_Index
TX_BYTE 13
INC LCD_STR_Index ' The variable is incremented with every pass
PAUSE 1000
ENDSUB
Hi
I've been monitoring this board for quite a long time and have only just discovered PropBasic!!!!
I've read people mention Basic but assumed it was to to with the stamp!!!! :thumb:
What a great facility - and if I understand the compiled code can be viewed and tweeked as well!!!
Ah well I have some catching up to do...
I expect everyone but me knows, BUT, will a version be available for the prop2???
Dave,
Not unless the Prop2 IDE supports external compilers.
I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.
Dave,
Not unless the Prop2 IDE supports external compilers.
I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.
Bean
I really hope that PropBASIC can be supported in the future version of the Parallax IDE.
The work that Bean has put into PropBASIC is faultless, and being at a loss without it, I would support any paid or community-effort initiative to keep it alive.
Bean - your great efforts have not been fruitless... rather an amazing work which (for me) is the only reason I continue to Propeller since the SX days. I really hope many more closet PropBASIC fans are out there, and can voice support to help PropBASIC remain and develop alongside future Parallax Propeller Languages.
It seems to me that PropBASIC is a more logical choice for new-user education, as it (BASIC) is a widely understood concept; and the fact that PropBASIC compiles to PASM provides the steps to the next level for all users- especially the young with brains made of sponge. Please find a way to keep the dream alive. Long Live PropBASIC!
I cant claim to be lost without Beans Basic (better name) because I have only just found it, but now that I have I will dust off my chameleon and give it a try.
Why dust it off - because the learning curve was too steep to achieve useful results.
From the manuals I am reading it seems to be a resource that Parallax would be foolish not to support.
If its half as good as it seems at first reading, then it makes a soft entry possible into the unique world called Propellar, showing quickly how powerful the processor(s) is(are), and how flexible a system it is having ONLY those I/O services installed that are required, and how fast and predictable those services are.
The ability (it appears) to view the pasm that Beans Basic produces has got to be a great educational tool.
How many processor companies have people like Bean ready to provide programming tools like this for FREE!!
I gave up on Basic Stamps a long time ago because of the exorbitant prices and started looking for something else. The propeller is unbeatable value for money, but were it nor for PropBasic, I would not have have moved to the propeller. At this stage of my life I have no interest whatsoever in learning Spin (or C, for that matter). In any case, here in South Africa I can buy eight 40-pin PDIP Propeller chips including EEPROM, Crystals and IC sockets for the price of one BS2PX! Talk about a no-brainer. Instead of Basic Stamps, I now use the Basic Micro Nano 8 and Nano 18 for the smaller projects for which a Propeller is a bit of an "overkill".
Bean deserves the utmost recognition for PropBasic. Sure, there are a few things that I personally miss in PropBasic, such as the ability to use mathematical expressions (please, please please, Bean?) and using multiple values with SERxxx, SHIFTxxx and I2Cxxx, and perhaps even floating-point math, but otherwise, as far as I am concerned, PropBasic is a fully-fledged, powerful, and above all, user-friendly programming language. I do not know the politics at Parallax, but their disregard in general for Basic as a programming language for the Propeller is, to say the least, both unfathomable and disconcerting.
An integrated IDE for PropBasic would be nice, but the lack of such is not an issue for me. I have set up Notepad++ to my liking with syntax colouring as well as shortcut keys for compiling and loading and since I ( beladly :-( ) discovered the /P and /E PropBasic command line switches, I hardly use ViewPort for syntax checking anymore (ever since I had to re-install my PC, I just cannot get BST IDE to work).
May both Bean and PropBasic yet have long lives ahead of them, and Bean, if you should ever decide to start charging money for PropBasic, I would gladly pay! Without PropBasic, I would be lost!
Dave,
Not unless the Prop2 IDE supports external compilers.
I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.
Bean
I'm also an admirer of all the work that Bean (and friends) has put into the PropBasic project. It is my opinion that somewhere, someday SimpleIDE (the new, soon to be, defacto IDE) will have PropBasic on the "Properties" tab. I know many people are working hard on PropGCC and Spin so its just a matter of time before the right people "get around to it". Lets face it, probably the second Spin program ever written was "BS2-functions.spin". This was because the transition from Pbasic to Spin was a bit overwhelming and there wasn't all the great documents that there is now. I remember that all of us Pbasicers were excited to be using this strange "parallel processor" chip. There has always been a need for some form of Basic and there will always be a need.
I personally do not posess the skills to make something like this happen. I wish I did.
Reading the last several comments here further confirms to my mind that interest in BASIC is far from dead. Maybe PropBASIC will get some love from Parallax soon, after some of the other fires have been put out.
It took me quite a while to figure out how to load libraries into tasks, but I managed to find a way that works. You actually have to create two libraries: one library with ONLY the SUB and FUNC definitions which go at the top of the Task BEFORE your own SUB and FUNC definitions and another library with ONLY the SUB and FUNC code which go at the bottom of the Task AFTER your own SUB and FUNC difinitions.
I have attached an example of how to do this.
Sometimes programs become just too long to easily work on, so I also found a way to write Tasks as separate code and then also just include them in the main program (including loading Libraries into the Task). I have attached an example if this as well.
The Attachment is a zip file.
I hope this helps.
Regards
Andre
Andre, just wanted to thank you for sharing this technique!
Is 1.30 still the latest version of PropBasic? I had a look at the PropBasic for Viewport thread, but that still shows 1.27.
Regards
Andre
Yes, 1.30 is the latest.
Here are the changes since 1.27
Version 00.01.28
Added: Support floating point constants with # prefix
Fixed: FREQ command caused abort if DEVICE is misspelled
Fixed: Allow constant with COGSTOP (was NOT fixed in 1.11)
Fixed: tempStr = STR temp (needs ",len" but causes abort) [Oct 10,2012]
Version 00.01.29
Fixed: PAUSE XXXX does not cause an error
Version 00.01.30
Added: Directive VIEWPORT defined if using viewport
NEED TO FIX: DO...LOOP x => y ' should be >= but no error
@Bean: Once again, many thanks for all your efforts with the excellent PropBASIC. I really hope you will continue to support it and develop it for Prop2.
@ParallaxKen: PLEASE make sure that PropBASIC gets full support from Parallax. Without PropBASIC I would likely have given-up on the Propeller long ago - it's the simplest way for me to learn PASM, and I find PropBASIC much simpler to learn than C.
Yes thats right. there are exactly 3 great languages: Spin, PASM and PropBasic!
I would love to see PropBasic support in the PropellerTool for both Propeller I and Propeller II
Comments
It took me quite a while to figure out how to load libraries into tasks, but I managed to find a way that works. You actually have to create two libraries: one library with ONLY the SUB and FUNC definitions which go at the top of the Task BEFORE your own SUB and FUNC definitions and another library with ONLY the SUB and FUNC code which go at the bottom of the Task AFTER your own SUB and FUNC difinitions.
I have attached an example of how to do this.
Sometimes programs become just too long to easily work on, so I also found a way to write Tasks as separate code and then also just include them in the main program (including loading Libraries into the Task). I have attached an example if this as well.
The Attachment is a zip file.
I hope this helps.
Regards
Andre
Here is the attachment.
Following on from Maxwin's question on how to include Libraries in Tasks, I though the I should perhaps share some of the Libraries which I have written.
The first example is for an I2C Library which allows you to read or write either one or two Bytes (i.e. either a BYTE or a WORD) as well as using Data Addresses consisting of one Byte or two Bytes by assigning the appropriate value to the Address_Len Variable. It also caters for devices like the PCF8574 which do not have a Data Address, in which case you would assign zero to the Address_Len Variable. The I2C Pin Labels (I2C_SDA and I2C_SCL) are hardcoded in the I2C Library, but using variables, it is possible to dynamically change the Pin Numbers which are assigned to the hardcoded Pin Labels. Have a look at the TX_RX example of how to dynamically assign different Pin Numbers to the hardcoded Pin Labels.
Note that you ONLY have to define the Control Byte for the I2C WRITE operation - the Library code will do the necessary for I2C READs.
Secondly, because the TX_RX Library does not allow us to use variable Pins and Baud Rates, I have modified the TX_RX Library to so that we can use variables in the Main Program or Tasks for the TX and RX baud rates making it is possible to dynamically change the Baud Rates. Note that Labels TX_Pin, RX_Pin, TX_Baud and RX_Baud are hardcoded in the TX_RX Library. I have attached an example of how to use variable Baud Rates as well as changing the Pin Numbers assigned to the TX_Pin and RX_Pin Labels. This means that you can use the same TX_RX Library to write to many different Serial devices connected to different Pins and with different Baud Rates.
Please let me know if you get stuck with anything.
Regards
Andre
PS. The files with the _SUBS and _CODE names are for inclusion in Tasks. See my reply to Maxwin on how to include Libraries in Tasks.
Most of the subroutines and functions are fairly simple and their usage should be easily understood from the comments.
I have attached sample programs for most of the utilities. Note that these are my original test programs and are not always verbosely commented, but if you run them, you will get an idea of how it works.
Once again, the libraries with the _SUBS and _CODE in their names are for inclusion in TASKS.
Perhaps someone finds this useful.
Regards
Andre
That's a lot of great material... Thank you.
Will feedback later on the task libs once I can run some tests.
Max.
For reference, here is the update of my previous example, now working fine calling the same library code from both the main cog and task cog.
Thanks again Andre (and for TX_DEC also-- that was missing from my tx-lib)
TestLibs.pbas
DEVICE P8X32A, XTAL1, PLL16XXIN 5_000_000 LOAD "lib_delays.h.pbas" LED1 PIN 1 LOW TASK_BLINKLED TASK AUTO PROGRAM Start Start: DO TOGGLE LED1 DELAY_MS 1000 LOOP END LOAD "lib_delays.pbas" ' Task code TASK TASK_BLINKLED LED2 PIN 2 LOW LOAD "lib_delays.h.pbas" DO TOGGLE LED2 DELAY_MS 1000 LOOP LOAD "lib_delays.pbas" ENDTASKlib_delays.h.pbas
lib_delays.pbas
' Use: DELAY_MS duration' -- shell for PAUSE '{$IFUSED DELAY_MS} SUB DELAY_MS PAUSE __param1 ENDSUB '{$ENDIF} ' ---------------------------------------------------------------------- ' Use: DELAY_US duration ' -- shell for PAUSEUS '{$IFUSED DELAY_US} SUB DELAY_US PAUSEUS __param1 ENDSUB '{$ENDIF}The library contains SUBS for:
* Sending an LCD Control Code
* Writing a Byte
* Writing a String (DATA or a Literal e.g. "My name is Andre"). It also allows for using the "@" character as a DATA terminator instead of zero because sometimes DATA strings have zeroes in them. The "@" is hardcoded in the Library, but you can change it to something else if you like.
* Writing a specified number of Digits without Leading Zeroes or Spaces for a Number (Constant, Variable or Literal)
* Writing a specified number of Digits with Leading Zeroes for a Number (Constant, Variable or Literal)
* Writing a specified number of Digits with Leading Spaces for a Number (Constant, Variable or Literal)
I have attached a sample program.
If you are going to use an IO Expander instead of connecting the LCD Pins directly e.g. 74HC595, MCP23008, MCP23S08, PCF8574, etc. you will have to modify the "LCD_CMD" and "LCD_BYTE" subroutines of the Library (and your program, obviously) to cater for the different output methods. If anybody gets stuck with this, let me know. I have sample programs for all these IO Expanders.
I also use the SparkFun Serial LCD Backpack often to save Pins (With the added advantage that you can use the modified TX_RX Lib), so if anybody requires help with this backpack, I will probably be able to assist. They are a little finicky to get to work properly. I have not had much success with Baud Rates higher than the default 9600. I have managed to get them to talk to the propeller at 115200 baud, but the comms is very eratic, so I tend to stick to the default 9600 Baud. In any case, changing the Baud Rate is a MISSION!
I hope this is useful.
Regards
Andre
I have attached an Example program.
Regards
Andre
If I define variables in a subroutine as per the sample code below, am I correct in assuming that when the subroutine has finished executing, the variables defined in the subroutine are deleted or released? In other words, these variables exist only for the duration of the subroutine?
SUB LCD_STR LCD_STR_Index VAR LONG LCD_STR_Delimit VAR LONG ' Do Stuff ENDSUBRegards
Andre
Hi Andre,
I think you will find they are common to the source file they exist in (common to the cog).
If you try to define the same var name in another sub, you will get an error that the var already exists.
For that reason, I usually prefix the sub-var name with the sub name, just to ensure they don't get re-used / conflict later
such as:
(oops, I can see you already used the prefix in your example!)
Anyhow, the vars are not specifically released or destroyed. The values remain as last set. They could be read or changed by any other code in the same cog.
Thanks for the reply :-)
I ran a small test program and found that variables defined in a sub are not cleared but that they are local to the sub - If you reference a variable which was defined IN a sub OUTSIDE of the sub, the compiler generates an error.
Problem solved :-)
Regards
Andre
All VARs "in a cog" are common. So VARs in other TASKs can have the same name (but not HUB variables, they are common to ALL cogs).
PropBasic is a single pass compiler. So it doesn't know LCD_STR_Index exists before it is declared. Hence the error...
Bean
I've been monitoring this board for quite a long time and have only just discovered PropBasic!!!!
I've read people mention Basic but assumed it was to to with the stamp!!!! :thumb:
What a great facility - and if I understand the compiled code can be viewed and tweeked as well!!!
Ah well I have some catching up to do...
I expect everyone but me knows, BUT, will a version be available for the prop2???
Dave
Not unless the Prop2 IDE supports external compilers.
I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.
Bean
I really hope that PropBASIC can be supported in the future version of the Parallax IDE.
The work that Bean has put into PropBASIC is faultless, and being at a loss without it, I would support any paid or community-effort initiative to keep it alive.
Bean - your great efforts have not been fruitless... rather an amazing work which (for me) is the only reason I continue to Propeller since the SX days. I really hope many more closet PropBASIC fans are out there, and can voice support to help PropBASIC remain and develop alongside future Parallax Propeller Languages.
It seems to me that PropBASIC is a more logical choice for new-user education, as it (BASIC) is a widely understood concept; and the fact that PropBASIC compiles to PASM provides the steps to the next level for all users- especially the young with brains made of sponge. Please find a way to keep the dream alive. Long Live PropBASIC!
Hajr
Why dust it off - because the learning curve was too steep to achieve useful results.
From the manuals I am reading it seems to be a resource that Parallax would be foolish not to support.
If its half as good as it seems at first reading, then it makes a soft entry possible into the unique world called Propellar, showing quickly how powerful the processor(s) is(are), and how flexible a system it is having ONLY those I/O services installed that are required, and how fast and predictable those services are.
The ability (it appears) to view the pasm that Beans Basic produces has got to be a great educational tool.
How many processor companies have people like Bean ready to provide programming tools like this for FREE!!
Dave
Bean deserves the utmost recognition for PropBasic. Sure, there are a few things that I personally miss in PropBasic, such as the ability to use mathematical expressions (please, please please, Bean?) and using multiple values with SERxxx, SHIFTxxx and I2Cxxx, and perhaps even floating-point math, but otherwise, as far as I am concerned, PropBasic is a fully-fledged, powerful, and above all, user-friendly programming language. I do not know the politics at Parallax, but their disregard in general for Basic as a programming language for the Propeller is, to say the least, both unfathomable and disconcerting.
An integrated IDE for PropBasic would be nice, but the lack of such is not an issue for me. I have set up Notepad++ to my liking with syntax colouring as well as shortcut keys for compiling and loading and since I ( beladly :-( ) discovered the /P and /E PropBasic command line switches, I hardly use ViewPort for syntax checking anymore (ever since I had to re-install my PC, I just cannot get BST IDE to work).
May both Bean and PropBasic yet have long lives ahead of them, and Bean, if you should ever decide to start charging money for PropBasic, I would gladly pay! Without PropBasic, I would be lost!
Andre
-Mike
I'm also an admirer of all the work that Bean (and friends) has put into the PropBasic project. It is my opinion that somewhere, someday SimpleIDE (the new, soon to be, defacto IDE) will have PropBasic on the "Properties" tab. I know many people are working hard on PropGCC and Spin so its just a matter of time before the right people "get around to it". Lets face it, probably the second Spin program ever written was "BS2-functions.spin". This was because the transition from Pbasic to Spin was a bit overwhelming and there wasn't all the great documents that there is now. I remember that all of us Pbasicers were excited to be using this strange "parallel processor" chip. There has always been a need for some form of Basic and there will always be a need.
I personally do not posess the skills to make something like this happen. I wish I did.
Paul
Thanks Bean! :cool:
I see there is a BST version, what is different about this version as opposed to a non BST version?
Azlan.
Edit: I have not read all the documentation, does it support #IF #ELSE #END etc?
-Mike
Hi Bean,
Is 1.30 still the latest version of PropBasic? I had a look at the PropBasic for Viewport thread, but that still shows 1.27.
Regards
Andre
It is a pleasure - glad you found this useful.
Regards
Andre
Yes, 1.30 is the latest.
Here are the changes since 1.27
@ParallaxKen: PLEASE make sure that PropBASIC gets full support from Parallax. Without PropBASIC I would likely have given-up on the Propeller long ago - it's the simplest way for me to learn PASM, and I find PropBASIC much simpler to learn than C.
C'mon - what say you?
3Cheers,
Bob
I would love to see PropBasic support in the PropellerTool for both Propeller I and Propeller II
73