EgonOlsen71/basicv2

TAB function/keyword outside of output functions is being recognized. (C64 BASIC difference)

gillham opened this issue · 5 comments

The following generates a syntax error with mospeed but not on a real C64:
19080 sm = 50 : se = 0 : dim stable$(sm)

This appears to be due to mospeed seeing the 'TAB' in there, when C64 basic only considers TAB valid in things like PRINT.

I ran into this issue trying to compile the 'Mastercode' assembler. It references this variable as 'ST$' everywhere except the DIM part. So changing the dim line and I can compile further (size issue now), but it does seem to be a syntax difference from real C64 basic.

ready.
tab(1)

?syntax  error
ready.
?tab(1)

ready.
10 tab(1)
run

?syntax  error in 10
ready.

C64 basic v2 is perfectly happy with this construct. As long as it is used as st$ (or sta$), it is valid on my C64.

ready.
10 dim stable$(50)
run

ready.

Actually it can be referenced as 'stable$' in a print. I guess due to not having '(' it doesn't see tab as a function.
Goofy example below.

list

10 dim stable$(50)
15 dim le$(10)
20 stable$(1) = "test"
25 le$(1) = "other"
26 s = 5
30 print stable$(1)
40 print stab(5)le$(1)
ready.
run
test
 5   other

ready.

I wasn't aware of this quirk. In general, you can't use function names as part of variable names in the C64's interpreter, unless they are TAB and SPC... I'll look into this....

To summarize:

  1. Normal variables, no matter if float, integer or string can't include a function name...
  2. ...unless this function name is TAB or SPC, in which case it's fine...
  3. ...but not for arrays, because...
  4. ...arrays can't end with TAB or SPC, so DIM ATAB(...) is wrong while DIM ATAB%(...) or DIM SPCHX(...) are fine

I think, I've fixed most of these now. Your test case runs fine. There's still an issue with arrays named SPC% or TAB%, but I'll look into that one now...

Arrays like SPC% and TAB% should now work as well. IMHO, SPC and TAB are fundamentally broken in the interpreter. I don't see the reason, why they are treated differently from any other string function. Maybe for performance reasons, but it would be nice to be able to use them in combination with actual strings as well...
Anyway, I hope it works now and that I haven't broken anything by these changes.

This is working for me. Thanks Egon!
I had to do some testing with various options (compact/float) to get the compiled binary small enough. Working fairly well now so I'm doing more testing of the compiled version.