Variables were also 2-bytes, but ASCII. The user could enter a longer name, but only the first two characters were significant.
sign-bits type (payload)
0 0 ... floating point number (1 byte exponent, 4 bytes mantissa)
1 1 ... integer (2 bytes)
0 1 ... string (1 byte length, 2-bytes pointer to location)
1 0 ... FN function (2 bytes pointer to BASIC, 2 bytes pointer to parameter variable)
In a program (the BASIC text), though, variables names are stored in full and in plain ASCII, at whatever length of characters.
OhMeadhbh•5h ago
I can't remember if this worked on the C64, but it worked on the 4016 and 4032's in our high school's computer lab.
jim_lawless•3h ago
10 REM NOTHING TO SEE HERE
20 PRINT "HELLO!"
POKE 2049,1
Run it. You'll see HELLO! LIST it and you'll continuously see line 10. If you try to LIST 20 the machine pretty much locks up.
Screen image is here:
https://jimlawless.net/images/remtrick.gif
(note that in the above image, you'll see two RUN lines ... it appears that I captured the screen as it was in mid-scroll... )
LocalH•1h ago
masswerk•1h ago
[Edit]
Coincidentally, a shifted "L" is PETSCII code 0xCC. Which is just one after the highest available token in Commodore BASIC 2.0 / V.2. (The last one being 0xCB, `GO`.) Therefor, a lookup into the keyword list will yield the terminating zero-byte, which probably causes the problem. (E.g., by defeating what was intended to be an unconditional branch instruction.)
(In BASIC 4.0 for the 40xx/80xx PETs, this is actually a valid token, namely `CONCAT`, which is expanded by LIST without further issues. Meaning, this kind of LIST protection can be broken by simply loading the program on one of the later PETs.)