23K256 SRAM: Why not expand Femto to use this?

Oldbitcollector (Jeff)

I've been playing with the 23K256 SRAM lately..
It's really something that should probably become a "standard" as the SD card has in many designs.

I was thinking... (dangerous) Why couldn't FemtoBASIC use the 32K of SRAM as the workspace for programs? Or has this already been done by Mike Green somewhere? Then the command-base of Femto could be increased to include new video, audio modes, or new commands.

A true 32K basic could be a nice tool to have on the Propeller..

Anyone have some tips on starting points for this?

OBC

trodoss

There is a FemtoBASIC version in the OBEX entry "Winbond Flash and Microchip SRAM Driver" that uses the SPI SRAM that you might be able to make work for what you want. I think this version was being written with the C3 in mind. It luses VGA for dislpay however, so that would also have to be adapted.

http://obex.parallax.com/objects/744/

Mike Green

@OBC,
It certainly would be possible to use a 23K256 SRAM to store the Basic program in FemtoBasic. It would take quite a bit of work to do it properly and, in that case, FemtoBasic is terribly in need of extensions like string handling and arbitrary variable names and arrays. That's really a total rewrite ... not a bad idea, but more than I want to take on at present.

The version that trodoss mentioned has the flash and sram driver included. It can read and write data to SRAM (up to 64K) and use flash for programs and data as sequential files.

Oldbitcollector (Jeff)

@Mike

It's a project that I wouldn't mind undertaking, but I have never gotten the hang of how your tokens work. I know how to add commands using the existing examples, but am clueless to how your parsing engine worked. Would you mind explaining it a little?

OBC

Duane C. Johnson

I second that;

I've added many commands for my uses, stepper motor drivers, DS1307 clock, and the like.
I'm currently trying to get an INPUT command to allow a simple C/R with no expr that retains the old contents of the variable.

I am a rank novice and do not have a clue as to how Femto works internally. This would be useful.

Duane J

Mike Green

Here's a brief sketch of how FemtoBasic converts an input line into a tokenized line. Line references are from the current version of FemtoBasic in the ObEx:

When FemtoBasic lines are entered, either from the keyboard or an SD card file, the input line is converted to tokens in a buffer. The line number, if present, is scanned and saved, then the rest of the line is passed to the routine "tokenize" (lines 273-307) for processing. This routine uses a table of multi-character tokens (lines 70-139).

"toks" is a table of addresses (offsets actually) of the actual strings of text. Although these are all text strings, they could contain digits and non-alphanumeric characters as well. The strings are all zero-terminated. Because this table is searched in order, longer strings that start with the same characters as a shorter string should come first. In other words, "ENDIF" would need to come before "END". This issue doesn't arise with the current table of keywords / tokens.

"tokenize" does the following:

1) Multiple spaces are replaced with a single space (except in strings).

2) Strings that start with a quote (") are copied as-is stopping at the closing quote and include the quotes.

3) For the remainder of the processing, lower case letters are treated like upper case.

4) At each point in the input buffer, "tokenize" searches the token table for a match to the exact string in the table. If this is found, the number of the table entry plus 128 is placed in the token buffer. A check is made to ensure that the zero terminator in the token table matches a non-alphabetic character. The token "REM" is treated as a special case. If this is found, the rest of line is ignored.

5) The token buffer is terminated with a zero byte.

The tokenized lines are stored in part of the area between the Spin stack and the end of memory in order by line number. A line begins with a byte-aligned word containing the line number followed by the tokenized line and its zero terminator. An empty dummy line with line number 65535 ends the program. Look at "insertline" (lines 318-338) and "findline" (lines 312-316) for some of the handling of these lines. "putlinet" (lines 221-235) is used to display a tokenized line given its address. A similar routine is used when writing a program to an SD card file.

Oldbitcollector (Jeff)

@Mike

Thanks.. I know I'm going to have some questions here once I digest this a bit..

I get the sense that re-creating BASIC for the Propeller might actually be easier if we moved forward and got rid of the line numbers all together and used labels.

IIUC, parsing (compiling) is actually done at runtime of the BASIC program itself and "tokenizing" the commands just provides a method by which the parsing engine can jump to the correct set for instructions for each command.

OBC

Mike Green

You have to remember that FemtoBasic was based on Tomas Rokicki's homage to Radio Shack's Color Basic. I started with his implementation and added lots of new statements and things like FOR / NEXT loops.

Yes, parsing is done as the program is executed. The tokenizing is just to make the parsing easier and it compresses the stored programs. Single byte tokens are much easier to handle than plain text.

You might look at the Pascal lexical analyzer I wrote for the Propeller C3 (there's an old thread somewhere here ... ). It uses the SRAMs for a dictionary and my flash file system for intermediate files (mostly because of the space taken up by the SD card file system). It handles floating point constants and strings and could be adopted for use with Basic. It needs another phase to build a constant dictionary (to find identical string and floating point constants), then a 3rd phase to do the actual parsing into some kind of compact interpretive code.

We're talking about major work here ... a great project, but a lot of work.

Here's the link.