Strings in Atari Basic

[kaneda23]

Say that I Dimmed A$ with a length of 20. If I do PR. ADR(A$), I get 2079.

 

So I set A$ = "ABCDE", and if I do a PEEK(2079), I would expect to see a 65, but instead I see 121. The next location, 2080, has a 0 in it. What's going on?

[DanBoris]

I tried it and it worked ok. Here is what I did:

 

10 DIM S$(4)

20 S$="ABCD"

30 I=ADR(S$)

40 PRINT PEEK(I)

50 PRINT PEEK(I+1)

60 PRINT PEEK(I+2)

70 PRINT PEEK(I+3)

 

When run this pritners:

 

65

66

67

68

 

Dan

[kenfused]

If you are doing this in direct mode and not in a program, strings will move in memory depending on the number of bytes the direct mode line you enter or if you add or remove lines from a program.

[kaneda23]

Ahh..okay. I was doing it in direct mode. Thanks for the replies.

[kaneda23]

There is another thing that I didn't understand. Take the following code snippet:

10 DIM B$(384)

20 B$ = "X"

30 B$(384) = CHR$(0)

40 B$(2) = B$

 

The end result is that each byte of B$ contains an "X".

 

So, line 20 sets the first byte of B$ to "X" (or the ATASCII code for X). But, what is the purpose of line 30?

 

After line 30, the first byte of B$ is set to "X", and the 384th byte is set to 0. Can someone explain how line 40 sets each byte of B$ to "X"?

 

Thanks.

[Nukey Shay]

It defines the very last byte in memory allocated to the string...setting the string length to the maximum...so that the copy process (B$(2)=B$) is consistantly grabbing the preceding value of the position that it is at currently...translating to the loop B$(2)=B$(1), B$(3)=B$(2) - which now contains the copy from 1, B$(4)=B$(3) - which now contains the value from 2, etc.

An interesting note is if this had been coded to run in reverse and copied strings from the top down, it wouldn't have worked. Serendipity, I guess

 

If this is not done, the resulting string would only be 2 bytes long (it would only be copying one byte in that case).