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

[Allen Huffman]

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