[Coco] BASIC: order of operations query, and PRINT MEM

[rick ulland]

I think you nailed it. We want

(PEEK(33)*256+PEEK(34))  -  (PEEK(25)*256+PEEK(26))

the second term is subtracted from the first. But maybe we get

PEEK(33)*256+PEEK(34)-PEEK(25)*256  +  PEEK(26)

part of the second term is added

Cool!

-ricku

On 7/7/2022 11:52 PM, Allen Huffman via Coco wrote:
> In BASIC, you can get the 16-bit value from two 8-bit values in memory like this:
>
> PRINT PEEK(25)*256+PEEK(26)
>
> That is the start of where a BASIC program goes.
>
> On a non-disk 32K Extended BASIC machine it prints 7681.
>
> BASIC can grow from there to the start of reserved string space:
>
> PRINT PEEK(33)*256+PEEK(34)
>
> On the same machine, that prints 32566.
>
> Max BASIC program would be 32566 - 7681 = 24885.
>
> But that’s about 26 bytes different from what PRINT MEM shows (24871) so there’s probably some overhead for variable tables and such.
>
> I noticed when I did the calculation in one line:
>
> PRINT PEEK(33)*256+PEEK(34)-PEEK(25)*256+PEEK(26)
>
> …I got 24887.
>
> At first I thought maybe some memory was being used to create the calculation. But when I did it again, enclosing each side with parenthesis:
>
> PRINT (PEEK(33)*256+PEEK(34))-(PEEK(25)*256+PEEK(26))
>
> ...I got 24885 — two bytes different.
>
> That made me think it was an order of operations thing.
>
> The 25/26 location/value should not change. Neither should the start of string space 34/35.
>
> PRINT PEEK(x)*256+PEEK(y)
>
> produces the same value as
>
> PRINT (PEEK(x)*256+PEEK(y))
>
> What is the obvious thing that is happening that I am not seeing?
>
> Thanks, much.
>
> --
> Allen Huffman - PO Box 7634 - Urbandale IA 50323 - 515-999-0227 (vmail/TXT only)
> http://www.subethasoftware.com  -https://www.facebook.com/subethasoftware
>
>
>