Re: Pointer at the start of a BASIC line: what good is it?

On Wed, Oct 27, 2021 at 3:25 PM <ruud_at_baltissen.org> wrote:
> ... I was sure that the
> first two bytes of a BASIC line were the length of it. That worked fine
> for a long time until I loaded a real C64 program and tried to edit it.
> Seeing the values and checking on Internet I learned it were pointers to
> the next line. Or better (IMHO worse), it points to the zero end byte at
> the end of the line. Why is this all?

It's a forward pointer chain and the pointer is set so that when you
call CHRGET, which increments the pointer first, you'll fetch the
first byte of the next line.

(from the MS 6502 BASIC source)

$ more chrget.s
.segment "CHRGET"
RAMSTART1:
GENERIC_CHRGET:
        inc     TXTPTR
        bne     GENERIC_CHRGOT
        inc     TXTPTR+1
GENERIC_CHRGOT:
GENERIC_TXTPTR = GENERIC_CHRGOT + 1
        lda     $EA60
.ifdef KBD
        jsr     LF430
.endif
        cmp     #$3A
        bcs     L4058
GENERIC_CHRGOT2:
        cmp     #$20
        beq     GENERIC_CHRGET
        sec
        sbc     #$30
        sec
        sbc     #$D0
L4058:
        rts

> And why pointing to the zero end byte, why not to the start of the next
> line? Now I have to read this pointer and add one to it before I can use
> it.

It's optimized for fetching the next char, not for directly reading
the current byte from a pointer.  That's what CHRGOT is for
(re-getting the current char without incrementing)

> So my question: what good is it? Or can I only blame mr. Bill Gates for
> this behaviour?

Feel free to blame Bill Gates.  He has a lot to answer for.

-ethan