I have fixes several bugs, and now allow "IF...THEN commands" instead of just "IF...THEN line#"
Also you can use ' to put comments after commands.
Yet to do:
Allow variable names instead of single letters
Better expression evaluation with precidence.
Allow OR and AND in IF commands.
Text based instead of graphic based TV (will free alot of memory, and be faster).
Color TV text.
Support CAPS-LOCK on keyboard
to do...Better expression evaluation with precidence.
Mike Green posted something very interesting on post #6. Bodmas is pretty important. I think Mike Green's example is similar to this http://en.wikipedia.org/wiki/Shunting_yard_algorithm and there is a code example there in C so it should be possible to convert that to Basic. As long as your caffeine levels are not sub-therapeutic...
Dr_Acula,
Thanks for the link. I'll check it out. Is this the method Mike Green uses for FemtoBasic ?
After I get a bit further along, I'll make some much needed documentation.
Todo:
Arrays
Expression Evaluator (right now is strictly left to right)
Color video - Maybe TV & VGA at the same time ???
I'd love to support SD cards, but I don't think I'll have near enough memory to do that.
Oh, here is cool speed test program.
10 start=CNT
20 FOR a=1 TO 10000
30 NEXT a
40 PRINT CNT-start/80000;" milliseconds"
50 PRINT "for 10,000 FOR..NEXT loops."
PropBasic only allow one expression per line. And ONLY during assignment to a variable.
In this case Embedded Basic is a vast improvement as expressions can be used most anywhere a value is needed.
Oh and here is an explaination of the PIN command for the demo board.
10 OUTPUT 23..16
20 FOR a=0 TO 255
30 PIN 23..16,a
40 PAUSE 100
50 NEXT a
60 GOTO 20
PropBasic only allow one expression per line. And ONLY during assignment to a variable.
In this case Embedded Basic is a vast improvement as expressions can be used most anywhere a value is needed.
That's interesting. You decided to implement the most advanced parsing in the most constrained context, on the Propeller! I guess it should be pretty easy to move it back to PropBasic once you've got it worked out in Embedded Basic. I wrote a simple Basic in C that works with ZOG on the C3. It is also an embedded basic in that you can type in programs on the C3 and run them. It contains an expression parser that generates a parse tree in memory and then generates bytecodes from the parse tree. I've attached it in case you're interested in looking at how expression parsing is done. It's fairly straight forward recursive descent but it does do constant folding along the way.
Tumbler,
POKE does the same thing as WRBYTE it writes to RAM, not EEPROM.
Among other things it will be useful to change the character bitmaps once I get that far along.
I was just looking at my "old-stuff-I-just-can't-bear-to-get-rid-of" collection, and came across a BASICON board.It had an interpreted BASIC in the National Semi. 8073* chip, and something like 8K of ROM, 8K of RAM, and an 8255(?) I/O chip. Programming was via a plain old ASCII terminal. I remember using a Radio Shack Model 100 as the terminal.
I drop by here, and what do I see??
Bean -- Have you seen Jack Crenshaw's "Let's Build a Compiler" tutorial? It's free, it's on the 'Net, but it is incomplete in that he did not get to strings. (He also tells you how to make an interpreter.) The reason I'm asking is because the compiler he designed did not need an operator stack. Unfortunately, I do not remember the details...
I just updated the first post with the latest version 0.08. This version has a full expression evaluator.
I have added a system variable CHARS that points to the character bitmap table. The first character bitmap is space. POKEB CHARS,255 will change the top line of the space character to a solid line.
So get your demo board, a PS/2 keyboard and a TV and try it out.
Question welcomed...
P.S. I just realised that the code won't compile for terminal use because of the CHARS system variable. I'll get that fixed in the next release. You can just change the line "__param1 = GETADDR TV_Font" to "__param1 = 0" and then it will compile for serial terminal use.
Tumbler,
The final version will not be a bitmapped screen. It takes too much memory. I've had to reduce the maximum basic code size to 4K to get this to fit.
Right now it has PLOT and LINE, but those will go away because Potatohead is working on a color tile based driver. So there will be color and redefinable character bitmaps.
And the code right now is not optimized in any way. I just wanted to get it working first. That will no doubt free up some space too. I want to allow at least 8K for the basic program.
When the Parallax WiFi module comes out I'd like to port "embedded basic" to the S2 robot using telnet as the interface. (Can android tables do telnet ???). Also the Spinneret might be a good choice to. It would be cool to have a module that you could program from anywhere in the world via telnet.
You need to use BST to compile it. The PropTool doesn't support LMM code generation. At least I think that is what the problem is...
Yup, that's the issue here. __DO_12 is supposed to go to $1F7 which goes against the hard-wired $1F0 limit. There is one way of side-stepping that but it's hardly worth the trouble, i.e. if you reference labels relative to here ($) then even PropTool is happy. For this particular line it would read
Great Work Bean.
'
I can't believe how fast it is!
'
This is what the C3 needed. I'll have to get one.
'
Works great on the Spinneret Too!
'
All I can say is " Brilliant "
'
This is what us BASIC guys are after, and have been looking for.
'
I hope Parallax is paying attention here!!!!
'
'
EDIT yes parallax is paying attention to PropBasic. Feb.2011 Nut&Volts Parallax S2 advertisement, lists PropBasic as third party tool for the Propeller S2
'
Were getting closer.
I ran Embedded BASIC, which has the screen dated Feb 5,2011. However, on the small Parallax TV, the characters are very tiny and not easy to read. I looked for another version of Embedded BASIC that would have larger TV characters in this thread but did not find it. I also ran the binary. The binary enbeddedBasic_0_12.binary has even smaller tiny black characters on blue screen impossible to read. Is there a version with larger TV characters yet retains the latest version commands?
I'm sure Bean could code up the 20, 32, or 40 column display modes possible.
For what it's worth, using white on blue will render much better. Input "FCOLOR 15" right away, and see if that doesn't help some. I've not used the little Parallax TV. Is the LCD ~300 pixel resolution, or higher. If it's ~300 or so, we need the 32, or 40 column mode.
I'm sure Bean could code up the 20, 32, or 40 column display modes possible.
For what it's worth, using white on blue will render much better. Input "FCOLOR 15" right away, and see if that doesn't help some. I've not used the little Parallax TV. Is the LCD ~300 pixel resolution, or higher. If it's ~300 or so, we need the 32, or 40 column mode.
The cute little TV display is 240 x 320. There are 32 tiny numbers that fit across one horizontal line in EmbeddedBasic. Perhaps these would be more readable if their vertical height was greater. The FCOLOR 15 was entered as a command and as a run program statement and did nothing.
Bean, I'll probably be interested in an external memory version of this and/or PropBasic.
How hard would it be to support separate code and data if that is necessary? SDRAM would not need separate code/data but an EEPROM or other "read-only" code solutions would need them separated.
Humanoido,
Did you enter fcolor 15 alone? No line number is not needed, not sure how you did it.
-Ron
Ron, yes it was entered alone. No effect. The FCOLOR 15 was entered as a command and as a run program statement and did nothing. I'll take another look at it today.
Here's some views of the screen.
The photos make the characters look larger than they actually appear.
Definitely too small for any useful work.. and not sure why it has artifacts.
Hope this has a fix as Embedded Basic is otherwise working excellent.
The binary load has a screen that is totally unusable on the Parallax TV
Almost a microscope view, artifacts appear to make the screen difficult to interpret
Photo is larger scale than real life. Real life characters are difficult to see. Shows artifacts across
the screen.
Bean, I'll probably be interested in an external memory version of this and/or PropBasic.
How hard would it be to support separate code and data if that is necessary? SDRAM would not need separate code/data but an EEPROM or other "read-only" code solutions would need them separated.
I am trying to do something along these lines... but I am still in the learning phase so progress has been slow. I get as big of a rush from learning as I get from doing.
My goal is to use an SD card to run multiple PropBasic or Embedded Basic programs in sequence... or as needed based on user input. At this point I am totally destroying Kye's SD interface and its offspring KyeDOS... and trying to wrap a PropBasic/Embedded Basic program(s) around it. If I knew more it might be easier. But is a great learning experience, and a lot of fun. If anyone has tried this (with success) I would love to know the details.
Comments
Bean
I have fixes several bugs, and now allow "IF...THEN commands" instead of just "IF...THEN line#"
Also you can use ' to put comments after commands.
Yet to do:
Allow variable names instead of single letters
Better expression evaluation with precidence.
Allow OR and AND in IF commands.
Text based instead of graphic based TV (will free alot of memory, and be faster).
Color TV text.
Support CAPS-LOCK on keyboard
Comment welcome.
Bean
Connect a PS/2 keyboard and NTSC monitor to a demo board and try this demo program to see the speed of "Embedded Basic".
I'm not crazy about the atari font, but it's better than the one I had on hand.
Comments welcome...
P.S. The "1 CONT" line makes the program auto-run at startup if you SAVE it.
P.P.S. Press the ESC key to stop the program.
Bean
'
Just caught your post,Can't wait to try it.
Mike Green posted something very interesting on post #6. Bodmas is pretty important. I think Mike Green's example is similar to this http://en.wikipedia.org/wiki/Shunting_yard_algorithm and there is a code example there in C so it should be possible to convert that to Basic. As long as your caffeine levels are not sub-therapeutic...
Very Cool. :cool: And very fast. I need to find some more programing examples for this kind of Basic. Off to search the Web.
Thanks for all your efforts
-Ron
Thanks for the link. I'll check it out. Is this the method Mike Green uses for FemtoBasic ?
After I get a bit further along, I'll make some much needed documentation.
Todo:
Arrays
Expression Evaluator (right now is strictly left to right)
Color video - Maybe TV & VGA at the same time ???
I'd love to support SD cards, but I don't think I'll have near enough memory to do that.
Oh, here is cool speed test program.
Bean
In this case Embedded Basic is a vast improvement as expressions can be used most anywhere a value is needed.
Oh and here is an explaination of the PIN command for the demo board.
You can also do:
varname = PIN 23..16
Bean
David
But what does the poke commands do? writing values to the upper 32K eeprom?
POKE does the same thing as WRBYTE it writes to RAM, not EEPROM.
Among other things it will be useful to change the character bitmaps once I get that far along.
Bean
I was just looking at my "old-stuff-I-just-can't-bear-to-get-rid-of" collection, and came across a BASICON board.It had an interpreted BASIC in the National Semi. 8073* chip, and something like 8K of ROM, 8K of RAM, and an 8255(?) I/O chip. Programming was via a plain old ASCII terminal. I remember using a Radio Shack Model 100 as the terminal.
I drop by here, and what do I see??
Bean -- Have you seen Jack Crenshaw's "Let's Build a Compiler" tutorial? It's free, it's on the 'Net, but it is incomplete in that he did not get to strings. (He also tells you how to make an interpreter.) The reason I'm asking is because the compiler he designed did not need an operator stack. Unfortunately, I do not remember the details...
--Rich
* Nat Semi denies all knowledge of the 8073!
I have added a system variable CHARS that points to the character bitmap table. The first character bitmap is space. POKEB CHARS,255 will change the top line of the space character to a solid line.
So get your demo board, a PS/2 keyboard and a TV and try it out.
Question welcomed...
P.S. I just realised that the code won't compile for terminal use because of the CHARS system variable. I'll get that fixed in the next release. You can just change the line "__param1 = GETADDR TV_Font" to "__param1 = 0" and then it will compile for serial terminal use.
Bean
Very nice one. but i miss a screen bitmap. To get a char from the screen, or to show an info window or something.
Tumbler,
The final version will not be a bitmapped screen. It takes too much memory. I've had to reduce the maximum basic code size to 4K to get this to fit.
Right now it has PLOT and LINE, but those will go away because Potatohead is working on a color tile based driver. So there will be color and redefinable character bitmaps.
And the code right now is not optimized in any way. I just wanted to get it working first. That will no doubt free up some space too. I want to allow at least 8K for the basic program.
When the Parallax WiFi module comes out I'd like to port "embedded basic" to the S2 robot using telnet as the interface. (Can android tables do telnet ???). Also the Spinneret might be a good choice to. It would be cool to have a module that you could program from anywhere in the world via telnet.
Bean
sorry for the stupid question, but when I launch the program I get this error!
Andress is out of range
Marc71
John Abshier
You need to use BST to compile it. The PropTool doesn't support LMM code generation. At least I think that is what the problem is...
http://forums.parallax.com/showthread.php?118611-Download-PropBASIC-here...-00.01.04
Bean
http://forums.parallax.com/showthread.php?129444-Contest-Entry-Spinneret-Embedded-BASIC
Bean
'
I can't believe how fast it is!
'
This is what the C3 needed. I'll have to get one.
'
Works great on the Spinneret Too!
'
All I can say is " Brilliant "
'
This is what us BASIC guys are after, and have been looking for.
'
I hope Parallax is paying attention here!!!!
'
'
EDIT yes parallax is paying attention to PropBasic. Feb.2011 Nut&Volts Parallax S2 advertisement, lists PropBasic as third party tool for the Propeller S2
'
Were getting closer.
For what it's worth, using white on blue will render much better. Input "FCOLOR 15" right away, and see if that doesn't help some. I've not used the little Parallax TV. Is the LCD ~300 pixel resolution, or higher. If it's ~300 or so, we need the 32, or 40 column mode.
Did you enter fcolor 15 alone? No line number is not needed, not sure how you did it.
-Ron
How hard would it be to support separate code and data if that is necessary? SDRAM would not need separate code/data but an EEPROM or other "read-only" code solutions would need them separated.
The photos make the characters look larger than they actually appear.
Definitely too small for any useful work.. and not sure why it has artifacts.
Hope this has a fix as Embedded Basic is otherwise working excellent.
The binary load has a screen that is totally unusable on the Parallax TV
Almost a microscope view, artifacts appear to make the screen difficult to interpret
Photo is larger scale than real life. Real life characters are difficult to see. Shows artifacts across
the screen.
I am trying to do something along these lines... but I am still in the learning phase so progress has been slow. I get as big of a rush from learning as I get from doing.
My goal is to use an SD card to run multiple PropBasic or Embedded Basic programs in sequence... or as needed based on user input. At this point I am totally destroying Kye's SD interface and its offspring KyeDOS... and trying to wrap a PropBasic/Embedded Basic program(s) around it. If I knew more it might be easier. But is a great learning experience, and a lot of fun. If anyone has tried this (with success) I would love to know the details.