Bug in Integer BASIC (strings longer than 250 chars crash)
cmosher01
sample session:
>LIST
10 DIM A$(255)
20 FOR I=1 TO 251
25 A$(I)="A"
30 NEXT I
31 PRINT "CRASH:"
35 A$=A$
40 END
>RUN
CRASH:
E67B- A=E9 X=1E Y=00 P=F0 S=F8
*
I can't find any reference to this bug... anyone else ever run across
it? It seems to exist both in the original Apple ][ ROMs, and in the
INTEGER BASIC that's on the DOS 3.3 system master disk (which I know
has some other bug fixes). It seems that anytime you fill up a string
variable with more than 250 characters, and try to access it, it just
crashes.
Chris Mosher
D Finnigan
>
> I can't find any reference to this bug... anyone else ever run across
> it? It seems to exist both in the original Apple ][ ROMs, and in the
> INTEGER BASIC that's on the DOS 3.3 system master disk (which I know
> has some other bug fixes). It seems that anytime you fill up a string
> variable with more than 250 characters, and try to access it, it just
> crashes.
It likely not a bug, but rather a limitation of the language interpreter.
Charlie
"cmosher01" <cmos...@gmail.com> wrote in message
news:079d7945-5dc1-4823...@g6g2000vbr.googlegroups.com...
I believe you are not filling up the strings. You are running out
of memory and maybe stepping on some of your own code or data (I'm
not sure how Integer BASIC stores strings).
Anyway, you are creating 250 strings each with one character "A".
To see what I mean enter this line into your code:
26 PRINT I,A$(I)
When you run it you will see something like:
1 A
2 A
3 A
...
and so on to
...
250 A
but because of the extra memory used by line 26 you don't even get
the "CRASH:" printed before the crash into the monitor.
If you remove lines 26, 31 and 35 you gain a little memory and the
program doesn't crash at all, presumably creating 251 strings.
Charlie
John B. Matthews
<079d7945-5dc1-4823...@g6g2000vbr.googlegroups.com>,
cmosher01 <cmos...@gmail.com> wrote:
No, but I can see it remaining obscure. The Red Book says string arrays
can have length 1-255, but printing past index 250 crashes. I can see
the "X" after all the "A"s in low memory at $8FF.
>LIST
10 DIM A$(255)
20 FOR I=1 TO 250
30 A$(I)="A"
40 NEXT I
50 PRINT A$
60 A$(251)="X"
99 END
>RUN
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA
>PRINT A$
E67C- A=F9 X=1E Y=00 P=F0 S=F7
*`
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Charlie
"Charlie" <charl...@verEYEzon.net> wrote in message
news:h9hgia$rui$1...@news.eternal-september.org...
Well that will teach me to answer before I fully check things out.
I'm wrong about there being 250 strings. There is only one. It
still seems like something is eating up memory since you can get 251
characters in the string by removing lines 31 and 35 from the
original program.
Charlie
Charlie
"John B. Matthews" <nos...@nospam.invalid> wrote in message
news:nospam-B299AB....@news.aioe.org...
Even this crashes:
10 DIM A$(255)
20 FOR I = 1 TO 252
30 A$(I) = "A"
40 NEXT I
50 END
252 characters and no printing.
Charlie
John B. Matthews
"Charlie" <charl...@verEYEzon.net> wrote:
[...]
> Even this crashes:
>
> 10 DIM A$(255)
> 20 FOR I = 1 TO 252
> 30 A$(I) = "A"
> 40 NEXT I
> 50 END
>
> 252 characters and no printing.
I see this, too; but every once in a while I GET "*** STRING ERR", when
doing an immediate mode assignment.
cmosher01
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
Nick Westgate
> I looked at some disassembly of Integer BASIC around the area of the
> crash:
There isn't note of a bug there in Paul SM's disassembly:
http://www.easy68k.com/paulrsm/6502/INTLST.TXT
A couple of other bugs are mentioned here:
http://apple2history.org/history/ah03.html
Cheers,
Nick.
cmosher01
E675- 4C AE EF JMP $EFAE
EFAE- E6 D0 INC $D0
EFB0- 4C FD F3 JMP $F3FD
F3FD- D0 02 BNE $F401
F3FF- E6 D1 INC $D1
F401- 4C 6F E6 JMP $E66F
It just increments $D0.$D1 instead of Y. I haven't tested it much for
adverse effects, but it seems OK.
(You could patch this on the INTBASIC program on the DOS 3.3 system
master and run it on a ][+.)
--
Chris Mosher