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
