Re: Bug in Integer BASIC (strings longer than 250 chars crash)

[cmosher01 <cmosher01@gmail.com>]

Thanks for looking into this, folks. I'm looking into it a bit further
myself. I found a few things. First, the same program runs fine on the
POM1 emulator... that emulator comes with the basic.rom file, which is
an older version of Integer BASIC. Interesting. So the bug was
introduced when Apple (Woz, I guess??) ported BASIC to the Apple ][.
Second, back on the Apple ][ now: after the crash, the variable table
in memory looks OK (no corruption or anything).
I looked at some disassembly of Integer BASIC around the area of the
crash:
E66F: LDA ($D0),Y     ; D0.D1 points to $800, the beginning of A$ var
entry in var table
E671: BPL $E682       ; branch if we hit the end of the string (we
didn't)
E673: INC $78,X  ;?
E675: INY            ; next byte within A$ var in var table
E676: BNE $E66F   ; oops*
E678:     $09    ; garbage byte $09 here, treated as ORA
E679: LDA #$00

*At the BNE, it looks like it's intended to always branch, assuming Y
will never hit 0, but in the case of this long string it does. It
wraps because there are 5 bytes of overhead for A$ var in memory,
followed by 251 bytes = 256. So LDA ($D0),Y can never reach the end of
the string in this case, because Y cannot increment past 255. After
the BNE $E66F is a garbage $09 byte, followed by what is supposed to
be LDA #$00, but in this case, BNE falls through, $09 is treated as
ORA, which gives ORA #$A9 ("absorbing" the LDA instruction), and
following that is the #$00 (from LDA #$00) which it now treats as a
break instruction.

To fix the bug, it looks like it would have to increment $D0.$D1
instead of Y, in that loop, but I don't know if that would have any
other side effects.
---
Chris Mosher