I just saw a tweet from Robin @ 8-Bit Show And Tell concerning a bug in Commodore BASIC that existed in the PET, C64 and VIC-20.
VAL() takes a string and converts it in to a floating point numerical variable. The value of “1E39” is a number in scientific notation, and this appears to cause a problem.
In Microsoft BASIC, the notation “1E39” represents the number 1 multiplied by 10 raised to the power of 39. This is also known as scientific notation, where the “E” indicates the exponent to which the base (10 in this case) is raised. So, “1E39” is equal to 1 * 10^39, which is an extremely large number:
1E39 = 1 * 10^39 = 1000000000000000000000000000000000000000
This number has 39 zeros after the 1, making it a very large value.
– ChatGPT
I was curious to see what the CoCo’s Color BASIC did, so I tried it…
It appears that port of BASIC to the 6809 also ported over this bug. Anyone want to take a look at the source and see what the issue is?
…to be continued, maybe…
The issue is that VAL puts a NUL at the end of the string then calls the regular number parser, which can then bail out unceremoniously. While VAL itself does restore the original byte after the string, that code path does not execute when an error occurs parsing the number. The NUL is required so the parser knows where to stop interpreting bytes.
As an added bit of trivia, if you were wondering why MEM reads 1 byte higher on the Coco3 than it does on the Coco1/2, it’s because the Coco3 runs in RAM mode and doesn’t need to have a protected byte above string space to make VAL work (it just overwrites the ‘E’ at the start of Extended Basic). On the Coco1/2, there is 1 unused byte of RAM immediately above string space which has to be there in case VAL is called on a string stored at the top of string space.
I assume this is the same behavior on the 6502 version.
Pssst…guess what time it is… https://logiker.com/Vintage-Computing-Christmas-Challenge-2023
Thanks!
Pingback: The VAL overflow bug and scientific notation | Sub-Etha Software