I like the new look!

Go get Gemini or Claude and have the AI build the extension that you need. I did this to build a source level debugger and having the debugger dramatically improved my ability to diagnose and fix problems. It took me a few solid days to get the debugger built out even with the AI assist. But you're ...

Okay, you all wanted INT to do floor, so now it does floor.

Since now ROUND(X) is exactly INT(X+0.5), I removed ROUND to save 10 or so bytes.

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.

Checked CINT on TRS80 and it does truncate (same like FIX) instead of round to nearest for some reason. And also noticed that INT on VC83 truncates instead of flooring.

Interesting. I didn't know that INT is actually a floor function but it looks like Applesoft and Atari at least both work that ...

Five byte floats are handy for being able to store four byte integers…

You know, that what I had hoped. I thought, with a 32-bit significand, I can represent every 32-bit integer value.

Except not quite, for two reasons:

1. With a separate sign bit it's not possible represent -2,147,483,648 ...

I'm happy to report that I've reduced the Apple II version down to 8,186 bytes! This version is the v0.3.2 tag on GitHub. There are a few bug fixes too, e.g., comparisons of negative numbers work correctly now.

My `ROUND` is not exactly the same as `INT(X+0.5)`; it's actually `INT(X+0.5*SGN(X ...

Do you need ROUND() ? It's typically done by the programmer with INT(x+0.5) rather than the interpreter.

That sounds like an easy win, thanks for pointing that out!

I've also been thinking I could just get rid of `install_exception_handler`. It's there because I wanted a way to handle exceptions ...

Saving code bytes? Why bother. No-one (see below) has minimal 6502 systems now. Some are even making memory management units to add more memory because 64K is just not enough...

On one hand, you're right, but on the other, if we're just going to say, why bother, everyone has 128K or more now ...

I'd like my BASIC interpreter (see previous post ) to fit into 8K but after working on it for a few days, I've only managed to reduce it by about 100 bytes. I need to eliminate another 280.

I'm considering offering a bounty for patches that save space. It would mostly be for fun, with the bounty ...

The short answer is: I don't know. It would make sense that if the assignment to load_reg were delayed, then everything else, including processing of the following instruction that used it, would also be delayed.

But I would not change the code based only a suspicion that something might be wrong ...

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 ...

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 ...

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

Someone else brought that to my attention. It's a consequence of my using lowercase letter values to tokenize function names. I'll fix it.

The GitHub master branch understands "E" now, so your program works without any changes. I'm not proud of the implementation, but it works. Converting between ...