The last version of 6502 EhBASIC on Lee's website is 2.09, dated 2005. Is the project still under development? Any plans? Has the website moved?

I think that it's simply "mature technology."

No, nothing's moved. That is the current version.


That's pretty much the case. I only started EhBASIC because I wanted some high level language that I could easily port to any target hardware and be able to use it interactively, so I wouldn't be left wondering if it was my new hardware or my new assembly language code that was broken.

EhBASIC as it is has gone quite a way beyond that goal. Features I'd always wanted from a BASIC such as the ability to easily use hex and binary in the code and for input and output were added. Commands were added that made coding for hardware easier as were commands that made writing code itself easier.

Version 2.xx came with the lessons learned in coding a Motorola 68K version from scratch and, while it looks outwardly very similar to 1.xx versions, internally it changed quite a bit and became a fair bit quicker. 2.09 is the last completed version and while it can probably be improved it works better than I ever expected when I started sometime in the last millenium.

I do plan a similar but expanded version for the 65816 but not having an assembler/simulator like Michal Kowalski's simulator for the 6502 and having all of my 65816 hardware in storage, along with a lot of other things, until I finally sell this place and move has precluded any real progress on that to date.

If there's any undocumented feature that needs addressing I'm always up for that, EhBASIC isn't abandoned, it's just .. resting.

Lee.

How would I go about adding keywords? I've implemented some stuff for a graphical LCD and would like to go from CALL PLOT,x,y to PLOT x,y.

Longer variable names would be nice but probably difficult to change.

How to add a new command to EhBASIC.

As this is a primary command, it can start a statement, first insert a new entry into the list of primary command tokens. It doesn't particularly matter where in the list.

E.g.

.. becomes ..


Next put a corresponding new entry in the command vector table that starts at LAB_CTBL. This must be in the same relative location as the token value.

E.g.

.. becomes ..


Now add an entry in the keyword tables.

E.g.

.. becomes ..


In this case there are already keywords that start with "P" so it's just a case of adding this one entry but if you were adding a keyword that starts with a so far unused letter then you also need to add entries in the first character table at TAB_1STC and in the character pointers table at TAB_CHRT and make a new character table for your entry.

Next you need to add an entry in the LIST decode table, this again must be in the same relative location as the token value.

E.g.

.. becomes ..


The last thing to add is the code for the new command which should be the same as the code you used for the CALL version but without the first scan for the comma. So instead of say using LAB_SCGB, scan for "," and get byte, you could use LAB_GTBY, get byte parameter, to get the X value.

.. and that should do it.


Not that difficult but wastefull of space and speed, unless you want variable length names and then it does get more awkward. The first two significant characters give you over 3000 different variables of each type and you can append any number of other characters of your choice as long as you avoid keywords.

Lee.

Thanks for your help. I will try this today.

The earliest Forth systems represented word names using the first three characters plus a length byte. This allowed a single 32-bit compare instruction to isolate the overwhelming majority of words when performing a dictionary lookup.

Maybe the same technique would apply for BASIC variable names as well. For example, you could have two variables PLOT (pointer to the graphics plot routine) and PLOTLINE (pointer to some line drawing code). Both variables would start with the PLO prefix, but they'd be further disambiguated by the length byte (4 in the former case, 8 in the latter).

A collision occurs only when you share both a common prefix and length. Hence, A=PLOXXXXX and A=PLOTLINE both assign the same value to A.

Yes, this is a very crude form of hashing the variable name.

Just an idea though.

Actually, precisely because EhBASIC lacks any kind of abstraction mechanisms whatsoever, and all variables are global, the names you assign to a variable become increasingly important as their quantity increases. Two-character variable names suffice for simple routines only.

Thankfully, if you're crafty with arrays, you can make yourself a stack, and implement your own support for abstraction. It's wordy to do, but it works -- I had to do it for many a VisualBasic application before VB learned proper abstraction constructs.

The technique applies to multiple data types too:


Example,



The code is ugly and wordy, like I said. However, it also allows for proper recursion, if your stack is deep enough. Here's how you might call the quadratic routine, for example:



Remember to update IP as you produce or consume values off the stack!

I also wanted to add:

The technique can be applied to multiple data types as well.


Obviously, you'll want to use LEN() to compute the length of a string. I'm merely illustrating that using stacks like this in BASIC prove powerful enough to compute arbitrary lambda expressions.

Remember, the original version of Smalltalk was written in BASIC!