Update for FemtoBasic

Mike Green

Attached is the latest FemtoBasic interpreter. The main addition is that loading Spin programs from an SD card file now works. This is described near the end of the file "FemtoBasic Notes". There's also a DUMP statement that displays a portion of main memory in formatted in hex and ASCII.

The archive includes pre-compiled binaries for TV and VGA displays and for the Demo board, Hydra, and Proto board. The Protoboard version has the TV outputs wired to pins 12-15 as on the Demo board, but has the SD card attached to pins 8-11 instead of the Demo board's pins 0-3.

The VGA version is compiled only for the Demo board and Proto board because the expansion port on the Hydra uses the same pins as the VGA display and you can't use both an SD card and a VGA display the way it's wired up.

The VGA version seems to have an initialization bug in the VGA driver. The FemtoBasic version display is followed by some characters of "garbage". The VGA FemtoBasic seems to work fine otherwise and I'll post a corrected version once I've fixed the bug.

fred2

Beautiful, beautiful!

The dump function is wonderful! I was playing around with the earlier version trying to create
a dump as an exercise, but the built-in one is so great I will give up on that project!

I am still having trouble assigning an ASCII character to a variable. I tried c="A" which it
accepts but when I do "print c" it gives me an arithmetic 65 instead of an A. I don't have
the Tiny Basic specs in front of me, but did they have the "$" feature for a string character?
c$="A" gives a Syntax Error.

I can't get the VGA version to display on VGA mode -- is that one completely VGA without the
interferring SD card function? I would love to see that one while I am waiting for my SD
breakout hardware to be shipped.

All in all, this is the most exciting HYDRA program so far! Congratulations!!

fred2

Mike Green

Fred2,
As I mentioned, the VGA version is not pre-compiled for the Hydra because you can't use the VGA display and the SD card I/O at the same time. It uses the VGA Hires Text driver in 640 x 480 resolution at a 69Hz refresh rate. Your monitor may have problems with that. I have a Samsung SyncMaster and it seems to be ok with that. I haven't tried the higher resolution versions of the driver (like 800 x 600 at 75Hz). If you look at the beginning of the vga_Drive.spin object, you'll see 3 sets of comments, one for each resolution. One of the sets is "uncommented". You can change that to a comment and "uncomment" one of the others and recompile.
Mike

hinv

Wow Mike,

I just got my propeller setup going downstairs where my network is then loaded FemtoBasic. I am really impressed. Now I can't wait until my microSD breakout board shows up.
It really reminds me of the Commodore64 days. I was wondering though, If I wrote a program that also used the VGA, how could I take over the screen, run my application, and then return it back to basic when I am done?

Thanks,
Doug

Mike Green

Doug,
The SPIN command will run a completely independent application off the SD card (or from EEPROM other than the 1st 32K "page" on pins 28/29). If your application exits using the Spin reboot statement, FemtoBasic (or whatever is in the boot EEPROM) will be restarted. You won't be able to "return" to your FemtoBasic application. It's like a GOTO. It's possible to modify FemtoBasic to load a startup program from EEPROM or an SD card, but this version doesn't have that.
Mike

Mike Green

Attached is another update to FemtoBasic.

1) The VGA initialization bug is corrected

2) Statements after a LOAD now work correctly (like "LOAD : GOTO 100" or "LOAD : RUN"). This means
that large, multi-overlay programs are possible using an SD card.

3) The format of FemtoBasic programs saved to SD card files has changed. They're now standard text files.
This means that FemtoBasic programs can be created, edited, and printed on a PC (or Mac).

Mike Cook

Great work Mike! This is loads of fun!

Only issue that I had so far is my little BTC 84 key mini keyboard outputs a 'garbage' key when it is initialized. Happens on other *.spin programs, so I added a 'key.clearkeys" right after the 'if not key.present' check, took care of the display of the 'garbage" key when "FemtoBasic" loads.

Now for a wish list!·

Any chance of getting 'FullDuplexSerial.spin' in there so we can access RS-232 ports in the basic programs?

Also checking for a file named like 'autoexec.bat' on "FemtoBasic" boot, and if exists then run that file, would be a great feature. Might want to have a check for <ESC> from the keyboard if you need to bypass this feature and a file with this file name exists on the SD card.

Right now running this on a Propeller ProtoBoard with the SD card on pins 0..3, need to build up another ProtoBoard and move the SD card to 8..11.


fred2: Try this for printing the value of a variable:

10 A = 10
20 PRINT "The value is: "; A

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Post Edited (Mike Cook) : 2/25/2007 1:41:14 PM GMT

Mike Green

Mike,
The only difference between the Demoboard and Protoboard versions is the location of the SD card pins. Your Protoboard is wired like my Demoboard, so just use the Demoboard binary or compile it for the Demoboard. I'll add the key.clearkeys to future versions.

1) Good idea. I'll keep it in mind.

2) I'll add this to future versions. Rather than having a check for ESC on startup, you can just remove your SD card, reset the Propeller, then reinsert the SD card once FemtoBasic has finished its initialization without the SD card. The SD card routines are reinitialized every time you do a command that needs them (FILES, DELETE, SPIN, COPY, LOAD, SAVE, OPEN).

Mike Cook

Mike,

That's what I did on my Propeller ProtoBoard; just loaded and then later modified the FemtoBasic.spin to use the code for the Demo Board.

Famous last words..... One more thing:

A little confused on the usage of the INPUT statement. From the "FemtoBasic Notes.rtf":

"INPUT {"prompt";} <var>{,<var>} An optional prompt and a list of variables. The comma separated values may be arbitrary expressions all on one line."

I tried in the following program:

10 INPUT "Press a Key: "; A
20 PRINT "You Pressed: "; A
30 GOTO 10

If I press <1> and then <ENTER>

I get:

IN LINE 10 Syntax Error

However if I type a string like <A><B><C><ENTER> then I don't get the above error.

In the above program I expected that the value of the key or the number·'1' would be assigned to the variable 'A'. It's been a while since I programmed in 'line numbered BASIC', so what am I missing?



I've compiled one of my *.spin programs to a binary and transferred that to the SD card. Then renamed it to 'TEST.BIN', and used:

SPIN "TEST.BIN"<ENTER>

Very COOL!, I see a FemtoBasic menu program in my near future!


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Mike Green

Thanks for the info. I'll check the INPUT statement.

By the way, you don't need an extension of BIN although that helps organize things.

Mike Cook

Also while I'm 'pinging of the walls with excitement'!

It would be neat to access a DS1307, or other I2C devices, from the default SCL SDA lines on the Propeller ProtoBoard, from FemtoBasic.

Although being able to load and execute a *.spin binary, from FemtoBasic, just makes my day!

Thought I would include extensions with my file names just to keep me organized:

*.BIN = Compiled SPIN Binaries

*.BAS = FemtoBasic programs

Probably will try to keep the traditional DOS file naming extensions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Mike Green

Yes, it would be neat to have that too. In fact, I put together a version of FemtoBasic with built-in PING and servo support for use with a BOE-BOT using the experimental Propeller Stamp module. It used a FullDuplexSerial serial channel instead of the keyboard/display since it used an xBee wireless link.

Maybe I ought to put together a "FemtoBasic construction kit" with the process of adding simple commands documented with some examples. This way people can add what they want.

Mike Cook

Actually I would be very interested in the FemtoBasic FullDuplexSerial serial version instead of using the keyboard/display. This reminds me of the old MicroMint BASIC BCC-11, Z8 micro card. I can think of many uses of this for embedded control. Just connect your laptop running a communications program (ProComm or whatever) and that's your I/O device when needed.

The "FemtoBasic construction kit" is a good idea, that way there won't be such a 'feature creep' in the standard release, that others may not need.

Keep us posted, I'll keep banging on the base features.

Great Job!


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Post Edited (Mike Cook) : 2/28/2007 3:49:50 AM GMT

rokicki

Yeah, that would be great! Especially if we can figure out how to make each command its own chunk instead of having them
separated into a keyword list, a big switch statement, etc. etc. That way people could pick and choose what they want.

I'm also playing with a BOE-BOT based on the protoboard, and it would be cool to use a pair of XBEEs to interact with it.
The USB cable I'm using now tends to get tangled around things.

Mike Green

OK, this is the most recent version of the BOE-BOT Basic for the Propeller Stamp. It's not quite as up-to-date as the FemtoBasic posted earlier in this thread. For example, it doesn't write text files when programs are saved to an SD card. Note that it uses a 10MHz crystal and 8x PLL. Just change that as you need to for a protoboard or demo board. The IR detect stuff isn't tested. The PING and servo stuff seemed to work fine. You can use any kind of serial connection, but it was tested with an xBee preconfigured to provide a serial connection on startup. Have fun.

Mike Cook

Thanks Mike!

Let me look though this, right now on a F8 compile I'm getting a "Expected a constant name" error on line 382:

t := getAddress(false) | fsrw#bootAddr

in the pri factor method. Need to read through all the comments. Lots of stuff to keep me busy!

Thanks Again

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Mike Green

Add this constant definition and use "bootAddr" instead of "fsrw#bootAddr". Sorry, I must have reverted to a copy of fsrw.spin without it.

  bootAddr    = 28 << 18               ' Address of boot EEPROM

Mike Green

Here's the next update to FemtoBasic. It has the auto execute feature and some minor bugs fixed including the INPUT problem. It clears the keyboard buffer during initialization right after making sure a keyboard is present.

The auto execute feature simply checks for an SD card during initialization. If there, it checks for a file called "autoexec.bas". If present, it attempts to LOAD it, then does a RUN. If any of these fail, the interpreter simply ends up at the "OK" prompt. To stop this auto execute, simply pop out the SD card until FemtoBasic is finished initializing. Once the "OK" prompt appears, you can insert the SD card. It will only load the "autoexec.bas" file just before the first "OK" prompt.

Mike Cook

Mike,

I just wanted to say 'THANKS!' for posting your FemtoBasic & the 'BOE-BOT' BASIC.

I've been hacking at FemtoBasic 2.002 and managed to get it to work via FullDuplexSerial.spin, with the guidance from BOE-BOT basic. I've still got some work to do on the DUMP command so it can use ANSI codes to display properly, but most, if not all, of the features of your original FemtoBasic 2.002 are working using a terminal program as my console I/O.

Right now I'm using a different set of pins (16 & 17) for the terminal I/O, but will change this later to use the programming pins (30 & 31) so I can 'reuse' those pins. Uses a terminal program as the console and the terminal program needs to be configured to add <LF> to incoming <CR>.

Now to dig up the XMODEM *.spin protocol I saw here a while back, so I can transfer files to the SD card, via the console. Shooting for a totally wireless solution to update program code.

Attached is my 'hacked up' version. Still need to do a bunch of testing to see what I might have broken!

<EDIT>

Added:

"REBOOT" - Reboots the Propeller platform either from a program or the 'OK' prompt

[noparse][[/noparse] 'Lifted' the free_cogs method from Parsko originally posted here:
http://forums.parallax.com/showthread.php?p=631490 ]

"COGS?" - Displays the number of free cogs·to the 'OK' prompt (probably will delete this one)
"COGS" - returns the number of free cogs, can be assigned to a variable.

Example:

10·A = cogs
20 print "Number of free Cogs: "; A

<EDIT>

Thanks Again!


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Post Edited (Mike Cook) : 2/28/2007 2:47:20 AM GMT

hinv

Kudos to Mikes and rokicki,

I just got my microSD card plugged in to my demo board, and now I am able to save my files. It's like I upgraded my Atari 400 with a hard drive, skipping the tape and floppy drives alltogether
Now I am going to try and get this running via serial on a protoboard so I can get away from that membrane...oops, I mean parallax, keyboard. This is really cool stuff! Keep up the good work
Any chance you guys are going to support ethernet? It shure would be cool to telnet in, ftp files over, etc. I don't know if this will fit in 32K though.

I have a suggestion.. what about making an autoexec.spin also?
Not that there wouldn't be a much quicker way to boot into a spin program off of the SD Card, but it would make things simpler.

Thanks,
Doug

Mike Green

You can make an "autoexec.bas" file that just has '100 spin "autoexec.spi"' in it. The interpreter will load and run it and you'll get your spin program executed.

Ethernet is just too complex to support. There are some ethernet interfaces meant for microcontroller use that work somewhat like a modem with command sequences. The best way to support something like this would be to add strings and serial I/O with FullDuplexSerial. I'll keep this in mind.

Harrison.

Telnet would probably be possible, although it will eat up a somewhat large portion of memory. I have a really bad implementation of a http server that fits in about 2400 longs (program + vars). This includes a 1500 byte buffer used to receive and build packets. My best guess is a telnet driver that functions like a keyboard / display would take around 1500 longs (the http server requires alot more than a basic raw telnet implementation).

I assume that if one wrote a intermediate driver that imitated the keyboard and display driver functions / methods then it should drop in relatively well. I am actually going to try this after I figure out whats wrong with my tcp state handling. I think it would be really neat if people could play with their Propeller projects from the internet just like if they were using the serial driver / keyboard + display drivers.

Note that I am using the Microchip enc28j60 ethernet mac/phy chip. It costs around 4 bucks and has a nice spi interface.

Post Edited (Harrison.) : 2/28/2007 5:52:09 AM GMT

tallyken

Hi Mike,
Worked right outa the box, including the SD card support. Haven't had so much fun since the pigs ate my brother.
Now to turn the clock back 30 years: It's HUNT THE WUMPUS time!
Beautiful job, Thanks!
Ken

hinv

Hi Mike,

Thanks for the autoexec.spin I didn't think of that.

I am having trouble reading files though. here is what I do:

open "bible13.txt",r
read a

I get a "Can't read file" message.

Then i "print a" and I get a 0 back.

So I would guess that I am expecting to dump a string into an integer and that is the problem, but I don't know how to handle strings. Any tips?

Harrison,
Thanks for your work on the ethernet code. I saw this one of thse withthe socket and transformer on SparcFun.com.
http://www.sparkfun.com/commerce/product_info.php?products_id=765#
Would you recommend this one? It says it has an 8k buffer also.

Wouldn't it be cool to write code in xemacs, or your favorite editor, ftp it to the prop, and run it. I know I would be more productive in that environment, especially since I have to now work on this winblose laptop in order to program. VNC doesn't even work right for downloading. I find that I have to open up the laptop, close down the vnc connection, and then download.
It shure would be even cooler if I had the option of using an IDE directly on the prop using telnet. One of these days I will get this little prop worked up to be like a real unix machine except it only capable of running 7 client processes, any of which can be spin, assembly, or basic code based. And it would still boot faster than my monitor warm up time! I shure do miss those days! Ever tried to boot a 64 processor SGI Origin? takes about half an hour from power up. Right now I get my OK prompt in about 3 seconds!

I sure appreciate all of the work you guys do..

Thanks,
Doug

Mike Green

Doug,
The FILE pseudo-variable is what you want. READ is only for reading numeric values and WRITE is like PRINT for files. Your OPEN is fine. FILE can appear in expressions and its value is the next byte in the file. You can use it on the left side of an assignment to write the next byte in a file opened for writing (or appending).
Mike

hinv

Hi Mike,

Is there any documentation other than just the Notes.rtf? I had the hardest time figuring out the IF syntax.
Here is my program:

10 OPEN "bible13.txt"
20 c=FILE
30 IF c<>10 THEN DISPLAY c
40 GOTO 20

It's just like unix "cat'" except it takes out the newlines.
Which brings up another question. Is there anyway to pass arguments to the program?

It is cool what you can do once you connect a microcontroller to big data! Thanks rokicki!

Thanks,
Doug

Mike Green

Sorry, there's no additional documentation yet.

There's no built-in way to pass arguments. Probably the only way would be to write the information to a file, then execute the next program. If you're doing FemtoBasic overlays (using LOAD), you can leave values in the variables and use LOAD : GOTO 100 to start your program at 100 and the LOAD and GOTO doesn't clear the variables.

RobotWorkshop

Hey, I just wanted to say that I finally had a chance to try this out and I must say that it is excellent! I have this running on a homebrew Demo board. I just need to get the Micro-SD card working (on P0-P3) and then I can work with that a bit. Your efforts are appreciated.

Robert

Oldbitcollector (Jeff)

After much debate between the advantages and disadvantages of the Demo Board vrs the Proto Board, I've ordered a Protoboard and related Kit. Can someone share the differences between the Demo and the Proto in regard to Femtobasic? I was under the impression that the Proto could/would match up with the Demo in regard to VGA/PS2 ports, but it appears that this isn't the case.

Are there specific instructions for setup of the Proto and say the SD interface that differ from the Demo board?

Thanks
Oldbit

Mike Green

The built-in connectors for the VGA, keyboard, and mouse are wired the same way on the Protoboard as on the Demo Board. When I wired up my Protoboard, I set up a video output using the same I/O pins as on the Demo Board (12-15). When I wired up an SD card socket, I attached it to I/O pins 8-11 because it worked for me. On the Demo Board, these were connected to I/O pins 0-3. It's kind of arbitrary. If you look at the source code, you'll see that the SD card pins are the only differences between the Demo Board and the Protoboard. If, for some reason, you want to hook them up to some other pins, just change the constant definitions. I posted a picture of my Protoboard setup in the Completed Projects forum here (http://forums.parallax.com/showthread.php?p=635533).

Oldbitcollector (Jeff)

Finally got around to attaching my Sparkfun SD/MMC breakout to my proto/breadboard setup and loading Femtobasic. AWESOME! I've got to hack in some additional commands.

The VGA spin supports appears to support cursors. Any chance of enabling one in Femto?

Keep up the great work guys. Wow..

Oldbitcollector