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

Anything Sinclair ZX Basic related; history, development, tips - differences between BASIC on the ZX80 and ZX81
vwbz80a
Posts: 31
Joined: Wed Nov 29, 2017 2:35 pm

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

This must be really Obvious!!!!! But it is NOT computing between the ears. (or on paper).

Problem: why do you add 256 to the low byte decimal before multiplying by the high order decimal?
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 ?

Andy Rea
Posts: 1313
Joined: Fri May 09, 2008 2:48 pm
Location: notts UK

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

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
6 x ZX81, 1 x TS1500 , 1 x +3e, 1 x timex 2040 printer, 1 x timex 2020 cassette deck, siclair printer and some spectrum

vwbz80a
Posts: 31
Joined: Wed Nov 29, 2017 2:35 pm

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

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.