Hacker News new | ask | show | jobs
by LocalH 345 days ago
That's why I said "at least on the C64". This particular bug probably also happens on the VIC-20, but I don't know if PET BASIC 2.0 is the same or not. I'd also imagine the "protection" would break if loaded on BASIC 7 or 10 (although 10 was never finished, but it was based on BASIC 7 AFAIK, so there's that).
2 comments

It also happens on the PET, before BASIC 4.0.

I had a cursory look at it: there's no check for REM, of any kind, but there's, of course, a check for quoted strings. For any tokens, an offset count is calculated by subtracting 0x7F from the token and then a loop starts searching for set sign-bits in the keyword list, decrementing the counter each time, it finds one. If the counter is zero, we must be right at the keyword, we're looking for. – But in those cases, where we are not…

For values larger than 0xCC (shift-L), the routine actually wraps around. E.g, shift-M is listed as FOR (0x81), shift-N as NEXT (0x82), and so on. This is, because the keyword list is exactly 256 bytes long (including GO and the terminating zero-byte, like on the C64) and is inspected by an indexed load instruction. So the index register just wraps around.

(BASIC 4.0, on the other hand, has to deal with a longer keyword list anyway, so it uses a more complex method to read the list, involving a pointer. Thus it happily spills over into the list of error messages, which follows immediately after this and happens to be encoded in the same way. Therefor, it will expand any excess-tokens into error messages. I guess, this will be the same with BASIC 7, and so on, if they are anything like this.)

Small update: I did a write-up on LIST and its mishaps (covering the PET to the C64 – so, no BASIC 7, etc.)

https://www.masswerk.at/nowgobang/2025/the-remarkable-misadv...