Page 1 of 1

PEEK & POKE math (?? +256 ??)

Posted: Mon Jan 15, 2018 4:20 pm
by vwbz80a
This must be really Obvious!!!!! But it is NOT computing between the ears. (or on paper). :oops:

Problem: why do you add 256 to the low byte decimal before multiplying by the high order decimal? :roll: :roll:
using a hex calculator there is no need for any additon.

and it is not that i can't get the right values to poke in, or peek at...........[here is where we loose everyone]....because i can.

It is that i just wish to use the simple calculator, manually. and follow the process. make sense ?

Okay. Why do you add 256 (ZX81 Basic add 256)? :geek: :geek:

Re: PEEK & POKE math (?? +256 ??)

Posted: Mon Jan 15, 2018 6:12 pm
by Andy Rea
We are not adding 256 to the low byte... when we do something like

Code: Select all

PRINT PEEK 16388 + 256 * PEEK 16389
To display the current value of ramtop you have to remeber the order of processing.

the computer will do both PEEKS then it will multiple the second PEEK [highbyte] value by 256 and finally add on the first PEEK [lowbyte] value.

hth Andy

Re: PEEK & POKE math (?? +256 ??)

Posted: Mon Jan 15, 2018 7:18 pm
by vwbz80a
Andy Rea wrote:
Mon Jan 15, 2018 6:12 pm
We are not adding 256 to the low byte... when we do something like

Code: Select all

PRINT PEEK 16388 + 256 * PEEK 16389
To display the current value of ramtop you have to remeber the order of processing.

the computer will do both PEEKS then it will multiple the second PEEK [highbyte] value by 256 and finally add on the first PEEK [lowbyte] value.

hth Andy
thanks, Andy.