Re running on a dracblade (or C3, Hydra etc), is the external memory defined as an IDE setting or as a line of code in the program?
Install the IDE and find out There is documentation for the IDE mentioned in the first post, but for simplicity it does not go into detail for external memory settings. The only external module support today is for C3 and SSF (SpinSocket Flash). I expect to add a few more external memory types soon.
The compiler takes the "board type" as an argument, looks for the definition in the include\xbasic.cfg fie, and sends clock info + cache driver + byte code interpreter to the Propeller for RAM load. It's a little different for EEPROM loads. There is no board specific information built into the compiler code.
@JonnyMac, did the .exe in that zip file fix your clock setting problem?
Yep, that seems to have fixed it. I'm getting finicky results connecting to various Propeller boards, but will keep trying. Will be interesting see see some full-blown programs written in xBasic.
I have just done that and it is a very smooth install process. Nice download speed too - about 1 megabyte in 5 seconds so the download took under 3 minutes.
First impression is very good. And I want more!
One minor thing, comments are //. Is it possible to add rem and ' as well?
Next, I can already see how you should be able to add more string commands based on this
def printStr(dev, str() as byte)
dim n = 0
dim ch = str(n)
do while ch
uartTX(ch)
n = n + 1
ch = str(n)
loop
end def
If you are passing str() then it ought to be possible to pass two strings - the string you want to change and the return string. One could argue whether it is destination<source or source<destination, but something like left(destination_string,source_string,5)
OR
You could return a string like you return a number
mystring = left(source_string,5)
and in the subroutine, put a 'return' like in C with a pointer to the string?
Can I ask - what assembly language is this and where can I learn more?
def coginit(id, code, par)
asm
lref 0 // get id
lit 0xf // bitwise and low order 4 bits
band
lref 1 // get code
native 0x80bc0a06 // add tos, base
lit 0xfffc // bitwise and to 14 bits
band
lit 2 // shift left 2
shl
bor // bitwise or with id and par
lref 2 // get par
native 0x80bc0a06 // add tos, base
lit 0xfffc // bitwise and to 14 bits
band
lit 16 // shift left 16
shl
bor // bitwise or with id
native 0x0cfc0a02 // coginit tos wr
returnx
end asm
end def
How about info how USER can build its own XXX_CACHE:DAT file ?
I guess I should write a document to describe that. You can get an idea of what is involved by looking at spin/cache_interface.spin in the xbasic source tree. Also, take a look at some of the existing cache drivers. The ssf_cache.spin driver would probably be the best one to look at as the C3 cache driver is complicated by the fact that it handles SD card access as well.
I have just done that and it is a very smooth install process. Nice download speed too - about 1 megabyte in 5 seconds so the download took under 3 minutes.
First impression is very good. And I want more!
One minor thing, comments are //. Is it possible to add rem and ' as well?
You can already use REM for full line comments.
Next, I can already see how you should be able to add more string commands based on this
def printStr(dev, str() as byte)
dim n = 0
dim ch = str(n)
do while ch
uartTX(ch)
n = n + 1
ch = str(n)
loop
end def
If you are passing str() then it ought to be possible to pass two strings - the string you want to change and the return string. One could argue whether it is destination<source or source<destination, but something like left(destination_string,source_string,5)
OR
You could return a string like you return a number
mystring = left(source_string,5)
and in the subroutine, put a 'return' like in C with a pointer to the string?
The "str() as byte" syntax just means that "str" is an array of bytes. This is the type of all string constants as well so you can certainly write all of the string functions you want using that approach. Currently you can't return an array as the value of a function so you'll have to pass the output array as the first parameter as you suggested in an earlier message.
Can I ask - what assembly language is this and where can I learn more?
def coginit(id, code, par)
asm
lref 0 // get id
lit 0xf // bitwise and low order 4 bits
band
lref 1 // get code
native 0x80bc0a06 // add tos, base
lit 0xfffc // bitwise and to 14 bits
band
lit 2 // shift left 2
shl
bor // bitwise or with id and par
lref 2 // get par
native 0x80bc0a06 // add tos, base
lit 0xfffc // bitwise and to 14 bits
band
lit 16 // shift left 16
shl
bor // bitwise or with id
native 0x0cfc0a02 // coginit tos wr
returnx
end asm
end def
Like Spin, xbasic compiles to bytecodes for a virtual stack machine. These are the instructions for that virtual machine. I haven't documented them (Spin didn't either) since I only intended to use them to write library functions that would be included with xbasic. You can see a one line description of each opcode if you look at the source file src/common/db_image.h if you're interested.
In case anyone wants to look at the internals of xbasic, it is an open source project posted on Google Code. Both the compiler and the IDE sources are posted there.
How does that work for external memory? And can you fill the array with data like in C - eg in catalina I have a global array, which ends up in external ram, with a font bitmap
dim myfont(1280) as byte in "external" {1,2,3,4... etc}
This is mostly correct but external memory is divided into "ram" and "flash". Some boards will have one but not the other. On the C3 both are available. So your statement could be written like this:
dim myfont(1280) as byte in "flash" = {1,2,3,4... etc}
It's not using ZPU bytecodes. It is using a bytecode instruction set that I've used in lots of different languages I've written in the past.
I thought I'd add a little explanation to this since my original response was a bit short. The xbasic code base came from the xgsbasic compiler that I wrote for Andre' to run on his XGS PIC and XGS AVR boards. It was later ported to his Chameleon boards and then to the C3. So it predates my knowledge of the ZPU architecture as well as my work on ZOG. I have from time to time considered converting the xbasic code generator to produce ZPU instructions but haven't had time to make the change yet. Also, until recently the ZPU and the ZOG implementation of it were big-endian which doesn't match the Propeller very well. I could consider switching to ZPU opcodes again but I'll first have to figure out how to merge the ZOG little-endian changes with my zogload program and build environment. When I last looked at it there were many changes that were unrelated to the endian changes and the job was bigger than I wanted to undertake.
Heater: any chance you might consider checking the ZOG code out of Google Code and making the endian changes to that version?
What I would really like to see is more debugging options:
Breakpoints, single stepping, walking, variable watches etc.
I'll have to make some time to really check it out thoughly.
Bean
Yes, you're right. A debugger would be a very nice addition. I'm not really sure how to handle breakpoints in code that resides in flash though. I guess the VM could maintain a breakpoint table and compare every PC value to that table before executing an instruction but that would slow things down considerably. Do you have any better ideas on how to handle debugging of code that resides in flash?
VERY nice work, and a very valuable contribution to the Propeller community.
I am going to have to dig out my C3 to play with this.
I scanned the thread, and the only major lack I can see is string handling. I agree with others, having to dimension strings is much better than the headache of dynamic strings.
I am sure you will come up with a nice way to handle them. It would be really nice to have normal basic style LEN(), "+", MID$(), LEFT$(), RIGHT$(), INSTR(), VAL(), STR$(), HEX$(), "=", capability.
Over the last several months David Betz and I have been working on xBasic.
Why another BASIC?
xBasic is designed to run programs from HUB, C3 Flash, or SpinSocket Flash .
xBasic syntax is similar to the older Visual Basic languages but is simpler.
xBasic can start PASM programs in COGs like other languages.
The xBasic IDE and the xBasic tools are multi-platform and open source.
Several demo programs are available including a TV demo.
A Windows installer is available today for Windows XP, Vista, and Windows 7 (x86).
Linux and Mac OSX distributions are coming.
Yep, that seems to have fixed it. I'm getting finicky results connecting to various Propeller boards, but will keep trying. Will be interesting see see some full-blown programs written in xBasic.
@JonnyMac. Glad that works for you. I'll roll that and a few .bas updates into a new package and post it on microcsource.com. Hopefully you can provide more information on the "finicky results" so I can reproduce/fix issues.
The GameBaby unit has been a major test platform for xBasic. It is quite complicated with an LCD, NES-like buttons, 5 different I2C devices, SDCard, and 4MB Flash for program code. All drivers were written in PASM and I still have a COG and tons of code space left over. Things have worked out nicely for GameBaby so far. The fully developed application progress has been on hold pending other work.
@Bean I look forward to your testing results.
@Bill, thanks. Hopefully your boards can be added to the list. I'll be documenting that better later.
How about info how USER can build its own XXX_CACHE:DAT file ?
I'll document further details about doing this while I port another memory type. The procedure is complicated today as it requires Linux or Cygwin to build some tools. The tools can be built for DOS/Windows, but that has to be added. I'd like to add features to the xBasic IDE to have a "self-supporting" environment, but it will take time. I have many other things to do too.
Among the tools required for a self-supporting IDE will be including a Spin compiler like BSTC and an editor. I haven't figured out exactly how to do all that yet. Spin and other tools are required for building PASM cache drivers as well as other device driver components like TV.bas in the TV Demo. So despite my reluctance, the xBasic IDE will also become a Spin IDE to a point.
I'll document further details about doing this while I port another memory type. The procedure is complicated today as it requires Linux or Cygwin to build some tools. The tools can be built for DOS/Windows, but that has to be added. I'd like to add features to the xBasic IDE to have a "self-supporting" environment, but it will take time. I have many other things to do too.
Among the tools required for a self-supporting IDE will be including a Spin compiler like BSTC and an editor. I haven't figured out exactly how to do all that yet. Spin and other tools are required for building PASM cache drivers as well as other device driver components like TV.bas in the TV Demo. So despite my reluctance, the xBasic IDE will also become a Spin IDE to a point.
I'll document further details about doing this while I port another memory type. The procedure is complicated today as it requires Linux or Cygwin to build some tools. The tools can be built for DOS/Windows, but that has to be added. I'd like to add features to the xBasic IDE to have a "self-supporting" environment, but it will take time. I have many other things to do too.
I guess it would be easy enough to build the tools into the loader so you'd only have to have xbcom.exe and nothing else. In other words, the loader could be made to handle .binary or .eeprom files directly eliminating the need for the tool to convert them to .dat files.
So despite my reluctance, the xBasic IDE will also become a Spin IDE to a point.
Maybe it's time to resurrect the BigSpin project. It seems the only advantage xbasic has at the moment is its ability to run code from external memory. If we had BigSpin, we wouldn't need xbasic.
I guess we would need a review of what was proposed for BigSpin.
I gave xbasic a try on my Win 7 64bit box, and there were some problems. It installed OK, but when I made some changes to the .cfg file via the IDE, the IDE could not find the file to make the changes. I also tried to compile one of the example progs, and the IDE came up with a compile error, could not find the file. So, with the 64bit setup, the IDE is having problems finding the files. I guess it is not a straight forward install, if I find some time, I will see if I can find the problem.
I gave xbasic a try on my Win 7 64bit box, and there were some problems. It installed OK, but when I made some changes to the .cfg file via the IDE, the IDE could not find the file to make the changes. ...
Hi Ray.
What version of Windows do you have?
Please download the .zip from here and replace the xbasic-qt.exe in the xbasic bin folder.
That has a fix to one xbasic.cfg save problem I had (after many installs) that you may also be having.
Can you find the xbasic include\xbasic.cfg file with Windows Explorer?
Can you click on the wrench button and browse for the compiler and includes path?
Is the include path set correctly?
I've attached a fresh xbasic.cfg file just in case you need it.
I guess we would need a review of what was proposed for BigSpin.
BigSpin is an idea for running a Spin program from external memory. The problem is we have to do special tricks to make it "Big" because of Spin's 16 bit address range. It is possible to do and I have a version that is very close, but there are challenges.
Also BigSpin performance (code size limited to 32KB) is 3x slower than xBasic on C3 for simple tests. xBasic runs FIBO(20) from C3 Flash in 803ms and SSF in 649ms.
I downloaded the new xbasic-qt file, and tried a new installation. The installation brings up an error:
"The program can't start because QtCore4.dll is missing from your computer.Try reinstalling the program to fix this problem."
Was I supposed to leave the other installation in place, and start the new file on top of that?
Hi Guys, nice work!
For the most part it works good on my 32 bit Vista laptop. Easy install, no problems locating files etc. However using the tool bar icons it doesn't seem to program the prop unless I hit F11. Also I hit the help on the terminal and get a circle with a slash for my pointer that stays.
@KMyers, Ray (and others) ... thanks for trying this. Thanks for your patience too.
Forum participants are the only people available to me for testing out programs before a major release.
I'll send everyone who helps a free DIP32 4MB Flash SpinSocket-Flash module (limited time offer).
Dint know why but the tool bar icon for loading the eeprom does work, my bad! I was thinking the run icon would just load ram for testing. So it turns out no issue!
On the terminal window I clicked the help and mt mouse pointer stays the circle with the slash in it. I will look in the menu bar help. I guess I was being lazy today, will check it out!
One question now. Could I take a basic stamp program into this IDE and it run straight off? I will be trying this out later today!
Bottom line if I can install and have success anyone can! I am no great programmer and probably never will...
BTW: I did upgrade the file xbasic-qt right after the first install, no problems
Comments
Install the IDE and find out
The compiler takes the "board type" as an argument, looks for the definition in the include\xbasic.cfg fie, and sends clock info + cache driver + byte code interpreter to the Propeller for RAM load. It's a little different for EEPROM loads. There is no board specific information built into the compiler code.
Yep, that seems to have fixed it. I'm getting finicky results connecting to various Propeller boards, but will keep trying. Will be interesting see see some full-blown programs written in xBasic.
I have just done that and it is a very smooth install process. Nice download speed too - about 1 megabyte in 5 seconds so the download took under 3 minutes.
First impression is very good. And I want more!
One minor thing, comments are //. Is it possible to add rem and ' as well?
Next, I can already see how you should be able to add more string commands based on this
def printStr(dev, str() as byte) dim n = 0 dim ch = str(n) do while ch uartTX(ch) n = n + 1 ch = str(n) loop end defIf you are passing str() then it ought to be possible to pass two strings - the string you want to change and the return string. One could argue whether it is destination<source or source<destination, but something like left(destination_string,source_string,5)
OR
You could return a string like you return a number
mystring = left(source_string,5)
and in the subroutine, put a 'return' like in C with a pointer to the string?
Can I ask - what assembly language is this and where can I learn more?
def coginit(id, code, par) asm lref 0 // get id lit 0xf // bitwise and low order 4 bits band lref 1 // get code native 0x80bc0a06 // add tos, base lit 0xfffc // bitwise and to 14 bits band lit 2 // shift left 2 shl bor // bitwise or with id and par lref 2 // get par native 0x80bc0a06 // add tos, base lit 0xfffc // bitwise and to 14 bits band lit 16 // shift left 16 shl bor // bitwise or with id native 0x0cfc0a02 // coginit tos wr returnx end asm end defHow about info how USER can build its own XXX_CACHE:DAT file ?
I think xbasic is already on his list. It's been around a while. It started out life as a sample program for ZOG.
I guess I should write a document to describe that. You can get an idea of what is involved by looking at spin/cache_interface.spin in the xbasic source tree. Also, take a look at some of the existing cache drivers. The ssf_cache.spin driver would probably be the best one to look at as the C3 cache driver is complicated by the fact that it handles SD card access as well.
The "str() as byte" syntax just means that "str" is an array of bytes. This is the type of all string constants as well so you can certainly write all of the string functions you want using that approach. Currently you can't return an array as the value of a function so you'll have to pass the output array as the first parameter as you suggested in an earlier message.
Like Spin, xbasic compiles to bytecodes for a virtual stack machine. These are the instructions for that virtual machine. I haven't documented them (Spin didn't either) since I only intended to use them to write library functions that would be included with xbasic. You can see a one line description of each opcode if you look at the source file src/common/db_image.h if you're interested.
http://code.google.com/p/xbasic/
dim myfont(1280) as byte in "flash" = {1,2,3,4... etc}It's not using ZPU bytecodes. It is using a bytecode instruction set that I've used in lots of different languages I've written in the past.
I thought I'd add a little explanation to this since my original response was a bit short. The xbasic code base came from the xgsbasic compiler that I wrote for Andre' to run on his XGS PIC and XGS AVR boards. It was later ported to his Chameleon boards and then to the C3. So it predates my knowledge of the ZPU architecture as well as my work on ZOG. I have from time to time considered converting the xbasic code generator to produce ZPU instructions but haven't had time to make the change yet. Also, until recently the ZPU and the ZOG implementation of it were big-endian which doesn't match the Propeller very well. I could consider switching to ZPU opcodes again but I'll first have to figure out how to merge the ZOG little-endian changes with my zogload program and build environment. When I last looked at it there were many changes that were unrelated to the endian changes and the job was bigger than I wanted to undertake.
Heater: any chance you might consider checking the ZOG code out of Google Code and making the endian changes to that version?
What I would really like to see is more debugging options:
Breakpoints, single stepping, walking, variable watches etc.
I'll have to make some time to really check it out thoughly.
Bean
Yes, you're right. A debugger would be a very nice addition. I'm not really sure how to handle breakpoints in code that resides in flash though. I guess the VM could maintain a breakpoint table and compare every PC value to that table before executing an instruction but that would slow things down considerably. Do you have any better ideas on how to handle debugging of code that resides in flash?
Thanks,
David
Congratulations.
VERY nice work, and a very valuable contribution to the Propeller community.
I am going to have to dig out my C3 to play with this.
I scanned the thread, and the only major lack I can see is string handling. I agree with others, having to dimension strings is much better than the headache of dynamic strings.
I am sure you will come up with a nice way to handle them. It would be really nice to have normal basic style LEN(), "+", MID$(), LEFT$(), RIGHT$(), INSTR(), VAL(), STR$(), HEX$(), "=", capability.
Totally off topic here but yes I'll try and find time for that.
Well, it's not completely off topic. If you update ZOG I could change my code generator to generate ZPU bytecodes.
The GameBaby unit has been a major test platform for xBasic. It is quite complicated with an LCD, NES-like buttons, 5 different I2C devices, SDCard, and 4MB Flash for program code. All drivers were written in PASM and I still have a COG and tons of code space left over. Things have worked out nicely for GameBaby so far. The fully developed application progress has been on hold pending other work.
@Bean I look forward to your testing results.
@Bill, thanks. Hopefully your boards can be added to the list. I'll be documenting that better later.
Among the tools required for a self-supporting IDE will be including a Spin compiler like BSTC and an editor. I haven't figured out exactly how to do all that yet. Spin and other tools are required for building PASM cache drivers as well as other device driver components like TV.bas in the TV Demo. So despite my reluctance, the xBasic IDE will also become a Spin IDE to a point.
Thanks for answer. Nice to know IT will be possible.
Maybe it's time to resurrect the BigSpin project. It seems the only advantage xbasic has at the moment is its ability to run code from external memory. If we had BigSpin, we wouldn't need xbasic.
I gave xbasic a try on my Win 7 64bit box, and there were some problems. It installed OK, but when I made some changes to the .cfg file via the IDE, the IDE could not find the file to make the changes. I also tried to compile one of the example progs, and the IDE came up with a compile error, could not find the file. So, with the 64bit setup, the IDE is having problems finding the files. I guess it is not a straight forward install, if I find some time, I will see if I can find the problem.
Ray
Hi Ray.
What version of Windows do you have?
Please download the .zip from here and replace the xbasic-qt.exe in the xbasic bin folder.
That has a fix to one xbasic.cfg save problem I had (after many installs) that you may also be having.
Can you find the xbasic include\xbasic.cfg file with Windows Explorer?
Can you click on the wrench button and browse for the compiler and includes path?
Is the include path set correctly?
I've attached a fresh xbasic.cfg file just in case you need it.
BigSpin is an idea for running a Spin program from external memory. The problem is we have to do special tricks to make it "Big" because of Spin's 16 bit address range. It is possible to do and I have a version that is very close, but there are challenges.
Also BigSpin performance (code size limited to 32KB) is 3x slower than xBasic on C3 for simple tests. xBasic runs FIBO(20) from C3 Flash in 803ms and SSF in 649ms.
"The program can't start because QtCore4.dll is missing from your computer.Try reinstalling the program to fix this problem."
Was I supposed to leave the other installation in place, and start the new file on top of that?
Ray
For the most part it works good on my 32 bit Vista laptop. Easy install, no problems locating files etc. However using the tool bar icons it doesn't seem to program the prop unless I hit F11. Also I hit the help on the terminal and get a circle with a slash for my pointer that stays.
Overall good job!!
Forum participants are the only people available to me for testing out programs before a major release.
I'll send everyone who helps a free DIP32 4MB Flash SpinSocket-Flash module (limited time offer).
So clicking the white on green "down" arrow doesn't burn the eeprom?
This is circle and slash is on your mouse pointer? Did you use Menubar -> Help -> About for this?
Yes. Sorry i forgot to mention that. I'll be making a release update today.
Everytime I do RUN, I have to unplug and re-plug the QuickStart board. If I don't I get the errror "Lost HW contact. 0 f9"
Bean
That's because it isn't broken like the Propeller Tool! :-)
Dint know why but the tool bar icon for loading the eeprom does work, my bad! I was thinking the run icon would just load ram for testing. So it turns out no issue!
On the terminal window I clicked the help and mt mouse pointer stays the circle with the slash in it. I will look in the menu bar help. I guess I was being lazy today, will check it out!
One question now. Could I take a basic stamp program into this IDE and it run straight off? I will be trying this out later today!
Bottom line if I can install and have success anyone can! I am no great programmer and probably never will...
BTW: I did upgrade the file xbasic-qt right after the first install, no problems