Simulator vs Chip uses different addresses space for storing variables

Jack Burns

New Member
First of all I would like to say what a great forum this is and to thank the many members who devote their time to helping others. I have been a silent member for many years and learnt a great deal from the many interesting topics that are discussed here.

I'm not working on any projects at the moment, but hope someone can help me understand the Memory RAM panel on PICAXE Editor 6.1.0.0.

Manual 2 states that the function of the poke/peek commands has been amended on M2 parts as follows...

"The peek and poke commands are used to read and write to all 256 bytes of the user RAM. However the lower 28 bytes (addresses 0 to 27) also correspond to the variables b0 to b27. Therefore these lower bytes can be accessed in two ways, via the bxx variable name or via the peek/poke command. The higher variables can only be accessed via the peek/poke commands."

I fully understand the above quote, however I have a few older parts (08M and 18X) and notice these parts store their variables b0 to b13 in the address range 50 to 63 on a real chip. So why does the Simulator show these variables as being stored in memory addresses 0 to 13? Is this a bug or am I not understanding something?

Thanks in anticipation.
 

AllyCat

Senior Member
Hi,

Welcome to the forum. Firstly, your bold text from Manual 2 is rather Out-Of-Date (I hesitate to say "wrong"); The 08M2 has only 128 bytes of RAM and most of the other M2s now have 512 bytes! I believe only the (obsolete) 18M2 (without a "+" suffix) has/had 256 bytes.

Secondly there are (now) three ways to access the lower RAM addresses (and two for the remainder). All the M2 and X2 chips can also use the "Byte Pointer" (bptr) which is a variable that is always the correct "size" (number of bits) for addressing the RAM. For example, with an 08M2, if bptr is set to 127 then bptr = bptr + 1 becomes 0 because the (7 bit) value overflows, or wraps around, back to zero and with a 20M2, bptr = 511 (9 bits = $1FF) increments to zero.

Thus you can write PEEK bptr , b1 and will always read a valid area of the RAM (or do a valid Write with a POKE bptr , b1 ). But even more usefully you can add an "@" prefix (only to pointer variables) anywhere that you'd normally use a variable or constant, for example SERTXD(#@bptr) to show the value of any preselected RAM location. Also in more complex expressions such as IF @bptr > 10 ... or @bptr = @bptr + 10 * @bptr , etc.. Normally used for the "High" RAM locations (i.e. > 27), but also they can be used to process a sequence of "bx" variables, e.g. FOR bptr = 10 TO 27 : @bptr = 0 : NEXT will clear all the variables from b10 to b27.

Personally I've never used the pre-M2 PICaxes, so I had hoped that the bptr could "arbitrate" on the RAM addresses of your 08M and 18X chips, but sadly they don't support the bptr. :( Therefore, I can't give a definitive answer to your question, but I believe the issue is that the function of the PEEK and POKE commands completely changed with the introduction of the M2 chips. Previously they accessed the "Special Function Registers", but these are now accessed by the PEEKSFR and POKESFR commands. These (latter) commands use a "byte" address but the "base PIC" (hardware) may use a different address range and is not even calculated in the same way for M2 and X2 chips! Note that the SFRs access Hardware locations, so are not supported by the Software Simulator.

Therefore, my interpretation of your issue is that the RAM addresses and variables both start at zero (for all PICaxes), but the "SFRs" (which appears to have been an alternative way to access the RAM in the older chips) use a "special" method of calculating the addresses i.e. by adding 50 (decimal) in the case of the older PICaxes.

Cheers, Alan.
 

Jack Burns

New Member
Hi,

Welcome to the forum. Firstly, your bold text from Manual 2 is rather Out-Of-Date (I hesitate to say "wrong"); The 08M2 has only 128 bytes of RAM and most of the other M2s now have 512 bytes! I believe only the (obsolete) 18M2 (without a "+" suffix) has/had 256 bytes.

Secondly there are (now) three ways to access the lower RAM addresses (and two for the remainder). All the M2 and X2 chips can also use the "Byte Pointer" (bptr) which is a variable that is always the correct "size" (number of bits) for addressing the RAM. For example, with an 08M2, if bptr is set to 127 then bptr = bptr + 1 becomes 0 because the (7 bit) value overflows, or wraps around, back to zero and with a 20M2, bptr = 511 (9 bits = $1FF) increments to zero.

Thus you can write PEEK bptr , b1 and will always read a valid area of the RAM (or do a valid Write with a POKE bptr , b1 ). But even more usefully you can add an "@" prefix (only to pointer variables) anywhere that you'd normally use a variable or constant, for example SERTXD(#@bptr) to show the value of any preselected RAM location. Also in more complex expressions such as IF @bptr > 10 ... or @bptr = @bptr + 10 * @bptr , etc.. Normally used for the "High" RAM locations (i.e. > 27), but also they can be used to process a sequence of "bx" variables, e.g. FOR bptr = 10 TO 27 : @bptr = 0 : NEXT will clear all the variables from b10 to b27.

Personally I've never used the pre-M2 PICaxes, so I had hoped that the bptr could "arbitrate" on the RAM addresses of your 08M and 18X chips, but sadly they don't support the bptr. :( Therefore, I can't give a definitive answer to your question, but I believe the issue is that the function of the PEEK and POKE commands completely changed with the introduction of the M2 chips. Previously they accessed the "Special Function Registers", but these are now accessed by the PEEKSFR and POKESFR commands. These (latter) commands use a "byte" address but the "base PIC" (hardware) may use a different address range and is not even calculated in the same way for M2 and X2 chips! Note that the SFRs access Hardware locations, so are not supported by the Software Simulator.

Therefore, my interpretation of your issue is that the RAM addresses and variables both start at zero (for all PICaxes), but the "SFRs" (which appears to have been an alternative way to access the RAM in the older chips) use a "special" method of calculating the addresses i.e. by adding 50 (decimal) in the case of the older PICaxes.

Cheers, Alan.
Hi Alan,

Many thanks for your detailed reply.

The bptr and @bptr on the M2 chips certainly look straightforward and very useful from your examples, so I will experiment with those commands to check I fully understand how they work.

Going back to the older 08M and 18X chips, the bit that really confuses me is that you have to peek 50 to access b0 on a real chip, but on the simulator you would need to peek 0 to access the same variable.

Regards
Jack
 

AllyCat

Senior Member
Hi,

The @BPTRINC and @BPTRDEC variables are even more useful, but the concept can be confusing so it's better to learn to walk before you run. ;)

I think the problem with the memory addresses is because the function/definition of the PEEK/POKE commands needed to change. I don't know if the "Old" version is still documented anywhere, but the Original Base PIC Data Sheets are. The basic PIC architecture hasn't changed, it basically has a "window" into the outside world, organised as 128 bytes of RAM (i.e. addresses 0 to 127 or $0 to $7F). However, the first 32 addresses are actually a Hardware interface to functions such as the Port.Pins, Timers, ADC values, address pointers (like bptr), etc., commonly known as "Special Function Registers" (SFRs). Then the remaining (up to) 96 bytes are "real" RAM, described as "Registers" like the PICaxe's "bx" variables.

But, the first 32 addresses are not now sufficient to contain all the SFRs, so they are organised in "Banks" (blocks), rather like looking through a different window. Also, the RAM/variables may be "banked", or contain the same data, in the same way that the view through a house's windows might be the same (e.g. the "distant" view) or completely different (nearby objects). The early 08M base chips had only two banks so the total memory (SFRs and RAM) could be addressed by a single byte via the PEEK/POKE commands. But the RAM/Variables started at 32 and it appears that PICaxe Basic chose to start its "named" variables (as opposed to the "System" variables) at 50 - 63 (which conveniently ends just before 64, a useful binary boundary).

However, the base PICs used for the M2 family have/need more banks, generally 8, to give 256 possible SFR addresses, and potentially more RAM/variables. Therefore, the PEEK/POKE commands were split into two types, the second type being called PEEKSFR/POKESFR where the first 32 bytes of each bank are allocated to consecutive blocks in the address map. Thus, the first 32 bytes of the PEEK/POKE commands were no longer reserved for SFRs and since there might be 256 (or more) "genuine" RAM locations required, it was sensible to (now) start the RAM/variable addresses at zero.

Then the problem arises of how to handle "Legacy" issues: Do you re-write all the documentation and Program Complilers, etc. (probably confusing existing users) for a system which is (or may soon be) "Obsolete"? Many items, particularly in (consumer) electronics are now considered obsolete within just a few years, so it's fortunate that Rev. Ed. are still basically supporting devices like the 08M and 18X after more than 10 years! ;)

Cheers, Alan.
 

lbenson

Senior Member
Going back to the older 08M and 18X chips, the bit that really confuses me is that you have to peek 50 to access b0 on a real chip, but on the simulator you would need to peek 0 to access the same variable.
Are you saying that PEEK 0 doesn't give the same value as B0? I'm not sure how PEEK works on the older chips, but RAM on the 08 is available from 80 to 127. It's possible that a PEEK in the range of 0 to 79 would not be accessing what you expect. Perhaps there are values in the indeterminant range which the PICAXE interpreter uses.
 

AllyCat

Senior Member
Hi,
you have to peek 50 to access b0 on a real chip, but on the simulator you would need to peek 0 to access the same variable.
I've no way to test that, as I don't have any "real" 08M chips, but this might be a PE5/PE6 issue. With the PE5 Simulator it appears that you must Peek 50 but with PE6 it's Peek 0 to read Register b0. I suspect the same might apply, depending whether the Code is/was Compiled and Downloaded to the 08M by PE5 or PE6 ?

Cheers, Alan.
 

Jack Burns

New Member
I had to read AllyCat's reply (post 4) several times and then had a look at the Original Base PIC Data Sheets. Once things started to sink in, I then had another search around the Forum and found a couple of interesting posts...

PICAXE Memory Map and SFR Details Chart (Created by westaust55)

Useful Firmware RAM Addresses (Created by hippy)

Hippy said:
Firmware RAM usage can vary between PICAXE devices although for all PICAXE's ( except the X1 and X2 ), $32-$3F are used to hold the variable values of 'b0' through 'b13'.


Out of interest I installed PE5 and found it made no difference whether PE5 or PE6 was used to put test code in a chip, the results were the same for both. ie 'PEEK 50' on a real 08M chip returned variable b0, and 'PEEK 0' on a real 08M chip addressed a 'Special Function Register' at address 0.

However in the simulators it's a different story.
PE5 needs 'PEEK 50' to read 'b0'
PE6 needs 'PEEK 0' to read 'b0'

I then began to wonder how PE6 knew how much RAM to show in the 'RAM memory panel' for the Simulator when switching between 08M and 08M2 devices. Looking at these two devices..

08M shows available RAM as:
0-13 ($00-$0D), and 80-126 ($50-$7E)

08M2 shows available RAM as:
0-127 ($00-$7F)

So I wondered if these differences were hard coded in PE6 or configured in a file somewhere. After some digging around I found there are 'XML' files in the 'C:\Program Files (x86)\Revolution Education\PICAXE Editor\PICAXE' folder and there is one for each type of PICAXE.

Having studied the PICAXE-08M.XML and PICAXE-08M2.XML for differences, I came to the conclusion that there is an entry called '<Max_Ram>' but couldn't find anything which defines a mapping address for variable locations, so I guess this must be hard coded in PE6.

I'm not suggesting anyone fiddles with the XML files, I'm just pointing the information out for anyone who may be interested.

Regards
Jack
 
Top