6502.org

Some improvements:

* '?' works for PRINT
* Numeric constants using 'E' work
* Lowercase works in strings, DATA, REM
* The ATN function is accurate to 9 digits not 6

Ah - much better!

I've fixed the last of the things that seemed to be broken or missing:

* INPUT work with a prompt now, e.g., INPUT "Name: ";NAME$
* RESTORE with line number works
* GOTO after THEN is optional
* No longer prints "AT" a random number if first line of input has an error
* Added platform-specific functions, e.g., PDL(n) for Apple II

But it's 385 bytes over 8K now, so I need to do some optimization.

Let me know if you find anything that just doesn't work.

Please forgive me for not digging into this myself, but what style of floats are you using? MS, IEEE, Woz, BCD, custom? I want to design something to fill the void between the tiny BASICs and the 8K BASICs, and I think a custom 24-bit float should do the trick, along with HP-style strings and a few trig functions. It should fit into 4K ROMable bytes in its base form. Time is not on my side at the moment, however.

It's a 40-bit float with an 8-bit excess-128 exponent and 32-bit significand. There's an implied 1 before the binary point so only 31 significand bits are encoded and the most-significant bit is the sign bit.

It's similar to IEEE-754 but with an extra 8 significand bits and excess-128 exponent instead of excess-127. I might change to excess-127 just to make it easier to work out the correct encoding for specific floating point values using modern languages.

My FP module supports the four primary operations plus power, comparison, SIN, COS, TAN, ATN, LOG, and EXP. It's about 2.4K right now. If you just wanted the four main operations and comparison, it would be much smaller, especially if you reduced the size of the float to 24 bits. All the other functions involve polynomial approximations so you need the polynomial function and lots of lists of coefficients. You could implement just LOG and EXP and let people implement the trig functions in their own program if they really want them. LOG and EXP would be hard to implement in user code because they need to do separate calculations on the exponent and significand.

Shows up late.

I have modified TinyBasic a few times (mostly for the 68k and other projects), and it may save some bytes if the BASIC is not tokenized.
The long variable name support has got to be using up some bytes. For TinyBasic I added local variables on the stack which removes some of the need for long variable names.
Often long variable names are wanted to avoid name collisions since everything is global.

To find variables in the variable name table, I use the exact same functions that the parser uses to identify keywords. The format of the variable name table and the statement and function name tables are all the same.