Re: Weird BASIC problem

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Thu, 4 Jun 2026 20:50:22 +0200
Message-ID: <aiHI7hJl0WwTp6Kp_at_hermes.local.trikaliotis.net>
Hallo Marko, Ruud,

* On Thu, Jun 04, 2026 at 04:03:35PM +0300 Marko Mäkelä wrote:
> I assume that the code that performs this adjustments is simply looking for
> NUL bytes and then rewriting the next-line pointers.

That's exactly what happens here: It goes through the memory until it
finds an end-of-line with a NUL byte. Then it corrects the linker
address before to point to the next byte after the NUL.

Then, it checks the next pointer. If it is NUL (both byte are NUL), it
stops. Unfortunately, as you only have 1 NUL byte here, it proceeds for
your boot2.prg.

> Did you try saving the memory from the VICE machine language monitor after
> the LOAD statement and then compare it to the original file?

That's exactly what is done:

-00000000: 01 08 0c 08 01 00 9e 20 32 30 36 32 3a 00 00 ea  ....... 2062:...
-00000010: ea a0 00 98 99 00 04 99 00 05 99 00 06 c8 d0 f3  ................
+00000000: 01 08 0d 08 01 00 9e 20 32 30 36 32 3a 00 15 08  ....... 2062:...
+00000010: ea a0 00 98 99 00 1b 08 00 05 99 00 21 08 d0 f3  ............!...
 00000020: 60 00 00 00 00 00


You see the difference at $0E/$0F ($00/$EA on the original, $15/$08 in memory),
and then $1b/$08 at $16/$17, and so on. $0815 and $081b are clearly
links to the next address.

Even the first link is correct ($080D at offset 2, it was $080C in the
original), as one would expect.

Note, however, that the NUL byte at $18 is *not* treated as an
end-of-line. Obviously, the BASIC interpreter does not handle "empty"
lines correctly. Of course, this is not a big issue, because you cannot
generate such an empty line with the interpreter, anyway. I was not
aware of this specific detail before.

Regards,
Spiro

-- 
Spiro Trikaliotis
https://spiro.trikaliotis.net/
Received on 2026-06-04 20:00:02

Archive generated by hypermail 2.4.0.