Basically, it's like a C switch statement. The syntax is:
Then, it will branch to the label specified in the list above. For example,
could be used to replace

I'm not quite sure what you mean by object code, but basically it will let you take a PBASIC program and "run" it on a regular computer, thus letting you see what it does without the need for a $1200 OI/RC pair, so I guess it would fall under the "parse PBASIC" category.

I make frequent use of looking at bits in a byte or word, but i have never needed to look at the nibble. now for thi biggest feature -- communicate with the serial port and control the bot!

Recently, I've worked on an expression evaluator in C++. It would solve mathematical expressions in the correct order of operations. For example, I could input a string like "2*(5+4)^(1/2)" and it would output "6". If you would like to collaborate, I would be glad to help. If I can get the source code to my program (I worked on it in school and we, the senior class, are pretty much done, so I haven't showed up in a while). then I can provide you with my engine for parsing strings.

my old team did, as well as multiple program slots.

debug would be nice, although probably not necessary.

one that i just thought of from seeing a picture of joe...

DATA and READ. those are the commands that use the eeprom in a bsx stamp. i'm sure joe knows this well by now :D. anyways, if any teams do use this for something valid, i think you may want to include functionality for those commands. an easy way would be to make an array for all the eeprom spots requested, and then just have the READ function call a certain array index, and you have your data. sounds simple in my head, probably isn't in real life :p.

Multiple program slots of course implies the RUN command

I'll probably do it as a linked list, just because it is more dynamic in size, but it shouldn't be too bad. This is the setup I have for the variables, and it's working very well (I've posted this part on my website, if you're interested).

From what I've been hearing, every PBASIC command has been used for FIRST (with the exception of some of the pin-based I/O), so this project just became a whole lot bigger than I expected. But that's what summers are for! (I just finished school about 10 min ago, and can't wait to get started on something other than English papers). Look for a mostly finished product by the end of June (hopefully).

one possible problem about running the eeprom as a linked list...

eeprom is semi random access. you can jump from anywhere to anywhere in it, so unless you like having lot's of loops, i'd think your better off with an array. of course, as long as it doesn't take that long to run through a loop, a linked list is fine. just try to keep the list down in size if possible.

Ahh... the age old question: optimize for memory, disk space, or performance? I might write a class that auto-resizes the array when there gets to be too many elements, or I might just make an array big enough to map the entire eeprom to even though it wastes a lot of memory.

well, something else which would be slightly harder, yet still use an array, and not waste any space is as follows...

to enter anything into the eeprom, you use the DATA command. so, before you run the entire code, run though once, checking for DATA commands. after every DATA command, count the number of commas (indicating how many spaces are needed in the eeprom), or something like that to determine the amount of eeprom needed (or in your case, the length of the array). not that complicated, and just a little harder. also, this way, if you don't use the DATA command, you waste no memory on the eeprom array. win/win situation for all. now, just to program that... :D

in case you guys didn't notice, but a stamps rom is 2k... My computer has roughly 192000 times that much in ram... i think optimizations should be done not for speed (1ghz vs 40khz) disk space (20gb vs 2kb) or ram (384mb vs 32b) but for workablility (currently does not run PBASIC vs currently does run PBASIC) good luck though.

A 2k element array wouldn't be that bad (I've done multi-million-element), but its the principle of wasting RAM unnecesarily. I gave up on conserving disk space long ago, but I'd like to try (for the sake of good software engineering) to find a balance for RAM and speed. As for the speed, a 2sx is 50Mhz, which makes me a little concerned about speed on older computers (especially laptops) due the increased overheard with translating the strings, providing a UI, and Windows hogging a big chunck of it.

I thought about just making the array big enough for the DATA commands, but then I'd still have to resize the array after a WRITE command, as this can be used to write data to a new location on the fly. Using a self-resizing array would still require some kind of indexing because there is nothing saying that DATA has to start at location 1 in eeprom. Either I'd have to use an array the size of the whole eeprom(at which point I may as well make my array 2k elements) to do mappings to my little array, or store the location with the data, at which point I'd have to loop through anyway. And that gets me thinking of my friend the binary search tree...

Anyway, as of right now, it loops through and finds all VAR/CON statements (since PBASIC doesn't care where you put them), so adding the DATA directive to the list should be easy.

heh, this gets so much more complicated than it has to be... :D

Still....
 

I still think it would be easier and perhaps better to just instantiate the whole array. You are making an emulator, so you should be true to the original flaws. That is why you must not use floats, you must maintain that original inability to do order of opps and so forth. Besides, simply writing char eeprom[2k] is alot simpler to debug later...