Yeah, I ran into this same issue when writing the tokenizer in
VirtualT's "Load from Host" feature. I never quite figured out the
encoding either (though to be honest, I probably could have had I been
persistent with it.).
Ken
On 7/31/24 3:22 PM, B 9 wrote:
So, after I finished the tokenizer for the Model 100 version of BASIC,
I figured NEC’s N82 BASIC would be a snap. It turns out that it is a
little trickier because the internal representation of literal numbers
is not the same as what is in the source listing. In particular,
double precision reals are immediately tokenized into a binary
floating point format that I haven’t completely deciphered yet. The
documentation says that it stores 17 significant digits internally,
although it shows only 16.
I don’t have a physical PC-8201A, so I am not sure if this is correct,
but the Virtual T emulator shows peculiar behaviour where a number in
the source code changes repeatedly when the line gets reparsed by
BASIC, e.g., after running |EDIT|.
For example,
|10 A=8.5070591730234611D+37 |
Type that into a device running N82 BASIC and type |LIST| and you’ll
see that the number has changed in the least significant digit.
|LIST 10 A=8.507059173023462D+37 |
That wouldn’t be too surprising this first time since it can only show
16 digits, but what is odd is that it keeps happening. You can use the
|EDIT| command and hit EscEsc or simply hit the up arrow twice to get
to line 10 and hit RETURN to make BASIC reread it as if you had just
typed it in. Run |LIST| and the last digit has changed yet again:
|LIST 10 A=8.507059173023463D+37 |
Keep doing that and the 16th significant digit will keep changing for
quite awhile, even overflowing the error to the 15th digit. The
problem is that BASIC is converting from decimal to binary when
saving, but when displaying the listing it uses a binary to decimal
conversion that is not an exact enough inverse.
While this probably doesn’t matter it seems extremely weird to modify
the constants a person has typed into their program. Even given the
inherent messiness of chaotic systems, I’ve never seen a computer
before where one of the factors in getting a different result might be
how many times the source code was saved!
Now, I have some questions: Is this well known? Is it documented
anywhere? Was this implementation something Microsoft did or was the
floating point math one of the additions NEC made for N82 BASIC? Is it
possible for there to be a loop such that the number would never stop
changing?
And, perhaps most relevant, should the N82 tokenizer I’m writing emit
just the next value or should it keep iterating between decimal and
binary until it finds a stable result?
Thanks everyone,
—b9
