I am working on programming my own monitor to work over a serial connection(hard going)

But when I am done I want to start working on a BASIC interpreter and i am having a really hard time getting my head around it. To read the commands i guess i would read bytes from the serial monitor and took for ASCII Patterns to match key words, but how do I create and store variables? I have looked around for some resources and have found a couple ready made version, but I want to learn by doing. any one know a site or article that goes over how to do such a thing? or can point me in the right direction?

Have you looked at Lee's EhBASIC? I'm sure it's a much better BASIC than what you're looking at, and much better documented.

What do you know about such things?

eg do you know C?
Is this going to be your second 6502 assembly laguage
project?

ie where are you starting from?

Personally I think it would be a lot simpler and more productive to
get your head wrapped around Forth, if you're a complete beginner
(sounds like you are) (me too).
Maybe write a Forth then write your Basic in Forth.

There's lots of good stuff about Forth and you'd cover a lot of the
same or similar ground.

I've not found so much about Basic

Coincidentally, I was just reading about Marc Feeley's tiny C
http://www.iro.umontreal.ca/~felipe/IFT ... ts/tinyc.c

Not really what you want, but might give you some ideas or even
a place to start (eg syntax diagrams)

The early small basics for micros would allow 26 single-character variable names: so you'd just store the values in a table indexed by the variable name.

That's enough to support simple programs, and if you write your basic interpreter in a structured way (using well named subroutines) you will perhaps be able to upgrade it later to us a more sophisticated approach which allows for longer variable names: when you encounter a name, you have to look up the name in a list of known names, to find the address which you use for the value.

Cheers
Ed

Thanks for the help,

As to where I am, I have experience in c# and c++ as well as BASIC(when I was young) however assy and low level programing is new to me. I am still working on my first 6502 assy project(the monitor) and am still near the beginning and have a long way to go.

I have never heard of FOUTH(do you have any good links to implement it?), so I will look into that, I also like the idea of the 26 single letter var's, That would be easy to do. In the end maybe it would just be best to use ehBASIC but i want to learn. i see that is what the tini-c does that was linked above aswell, so I think i will make a basic...BASIC with the 26 vars for now and move on from there.

I am an ardent supporter of Forth (no "u") for many reasons. Unfortunately a lot of Forth has been home-grown. It has not had much commercial support because the user can get under the hood and modify the compiler on the fly and without re-compiling everything, and make it hard for a vendor to say, "You need our new version because it can do <bla bla bla>" and you'll just say, "Good idea!" and go implement it yourself, very quickly, and not buy their product. Daryl has been selling his SBCs, and for his next version, I would like to port my Forth to it if I can put the time into it so newbies can have a turnkey system that works right out of the box and is super well documented, and of course they can modify it to their hearts' content too.

As to what Forth is, there's a topic in the Forth section of this forum here that might be of some help. I see now that unfortunately a couple of my links there in the fifth post, to tinyboot.com pages, are dead. The rest still work.

I'm prejudiced. I like RPN. If I were writing a BASIC,
I'd [have the BASIC] translate as much as possible to RPN

Also I think you need to familiarize yourself with syntax diagrams
if you're not already (including BNF and the bubble and box pictures),
if for no other reason than almost anything that's worth a damn is going
to use them.

FORTH is RPN
I expect Garth Wilson can give you better info on Forth
than I can, but I think this is a pretty good read:
http://www.bradrodriguez.com/papers/moving1.htm

Read about parsing. Unfortunately I don't know of a lot of online stuff
(which doesn't mean it isn't there) here's something:
http://www.cs.rochester.edu/~nelson/courses/csc_173/grammars/parsing.html

Stuff on Wikipedia varies from pretty good to purely awful to just
plain bullshit, never the less I'd suggest you go there and poke around.
At least you could get an idea of what to look for, ie terminology and
related subjects.

http://en.wikipedia.org/wiki/EBNF
http://en.wikipedia.org/wiki/Syntax_diagram
http://en.wikipedia.org/wiki/Reverse_Polish_notation
http://en.wikipedia.org/wiki/Parsing

Here's something I just came across. Dunno if it's any good but it might
be usefull. I prefer bubble and box* syntax diagrams to BNF in some
ways (where feasible) but I haven't tryed it.

http://dotnet.jku.at/applications/Visualizer/


*I think they're usually just called "syntax diagrams" but I tend to include
BNF in that term. Wikipedia calls them "railroad diagrams"

It sounds to me that you are trying to bite off way too much, considering that you said you're a novice at assembly language. This is analogous to someone who has never scratch-designed and built a 65xx computer but wants to be able to connect 16 dumb terminals, a brace of LVD-SCSI disks and dual Ethernet ports.

If you think a monitor is hard going, you ain't seen nothing until you scratch-write a BASIC interpreter. Monitors don't have to create variables on the fly, do floating point arithmetic, compute transcendental functions and evaluate complex expressions

I strongly recommend you take a look at Forth, as suggested above. It'll not only give you a base on which to start (plus access to several Forth experts around here), but will introduce you to the coding principles that make an interpreted language work.

Later on, get a copy of the EhBasic source code (it's somewhere around here) and thoroughly study it. As you will quickly discover, there's a lot to building a language interpreter. When working with the 65C02 or 65C816, you won't have the hand-holding that is part of high level languages like C++ and C# (which is one of those Microsoft abominations). So, you really need to sharpen your assembly language skills before tackling a BASIC interpreter. Creating an ANSI C compiler would be less difficult.

None of us are trying to discourage you in any way. We just don't to listen to your screams of frustration when you can't get things to work.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

You may want to study Tiny BASIC first, rather than EhBASIC.

http://ittybittycomputers.com/IttyBitty ... /index.htm

EhBASIC has a lot features, some of which might be rather complicated for a starting point, e.g. floating point math (integer math is suitable most of the time) and garbage collection.

The single letter variables that Ed suggested is a good starting point, but you might want to think more about parsing details, as that will be one of the big chunks in BASIC.

For Forth, FIG-Forth (in the source code repository) is one place to start. You might familiarize yourself with the language itself first, since it's a much different world than C++, C#, and BASIC. (Especially if there aren't any exotic-as-compared-to-C languages you're familar with, e.g. Lisp, LabVIEW, APL.) The Forth article on Wikipedia is a pretty good introduction.

Interpreters usually read whole lines into a buffer and then work on them there.


Variables are stored as an unordered list immediately after the program.

When the interpreter encounters a variable name in a program it calls a routine that searches the list for that name. If no match is found and a value is to be assigned to the variable then a new entry is created at the end of the list.


Feel free to email me with questions about interpreters.

Lee.

Well, I finished a very basic monitor, if anyone can it would be nice for some feedback or a THIS WONT WORK AT ALL! so I can start over I did not have much more to go on then the data sheets, so I am not sure if I am even on the right track. It Works in the Kowalski simulator when i modify the the 6551 specific code, so that is the part I am not sure about

http://pastebin.com/Y7pbi9ya

Having just given it a cursory look

line 40 says:

" LDA SET_6551ADDRESS ;Read and clear status register ;Set Y to 00"

Is that ";Set Y to 00" a goof? is something missing?

There's a few typo's in your comments too

Yea some of the comments got messed up when I pasted some, commands got changed and the comments did not. I tried to clean it up a bit here is a updated past. Besides that anything else scream out as bad?

http://pastebin.com/4fwMGnbj

I would find a page of memory to store the data and you might want to order it in 256 byte increments. I remember that Strings could hold about 256 bytes. I also remember data statements in Basic where you could poke (put) the data into memory into a table format.

I think that a more modern system could be devised where the variable system acts more like a disk drive in RAM.

I kept running out of variable space on the Commodore 64.

Just curious, why don't you name the addresses after the registers?

ie "command_register" instead of "SET_6551ADDRESS + 2"

line 14 you appear to be calling the command register the control register
in the comment