Allocated memory seems to change its values???

[Hysteria]

I must be doing something stupid here but I can't for the life of me see what it is.

After I write data to a memory location, I can read it once and it returns correctly but read it again and the content changes.

The following demonstrates

Code: Select all

*memoryid=AllocateMemory(10)
If Not *memoryid:Debug "Could not allocate memory":End: EndIf

For a=0 To 9
  PokeU(*memoryid+a,a)
  Debug PeekU(*memoryid+a)
Next

For c=0 To 9
  Debug PeekU(*memoryid+c)
Next

The first peek returns 0,1,2,3, etc but the second returns seemingly random numbers - different each time I run it.

What am I doing wrong?

Many thanks in advance

[netmaestro]

You are intending to write an unsigned byte but what you're actually doing with PokeU() is writing an unsigned word. Change all poke/peeks to PokeA()/PeekA() and your results will be as expected.

[Hysteria]

Hi Netmaestro

Sorry, I forgot to say that this little bit of code is drawn from something larger where I'm dealing with values of between 0 and 1.5bn so given that I need a 32bit word. In fact I am actually using PokeL/PeekL in my other code (same result).

So while your change based on the Ascii type work (I'm not sure why frankly) using Unsigned/Long types don't.

[netmaestro]

For Longs:

Code: Select all

*memoryid=AllocateMemory(10*SizeOf(Long))
If Not *memoryid:Debug "Could not allocate memory":End: EndIf

For a=0 To 9*SizeOf(Long) Step SizeOf(Long)
  PokeL(*memoryid+a,a/SizeOf(Long))
  Debug PeekL(*memoryid+a)
Next

For c=0 To 9*SizeOf(Long) Step SizeOf(Long)
  Debug PeekL(*memoryid+c)
Next

[RASHAD]

Code: Select all

; PokeU() writes an unicode character (2 bytes)


*memoryid=AllocateMemory(20)
If Not *memoryid:Debug "Could not allocate memory":End: EndIf

For a=0 To 20 Step 2
PokeU(*memoryid+a,a/2)
Debug PeekU(*memoryid+a)
Next

Debug  "--------"
Debug  "--------"


For c=0 To 20 Step 2
Debug PeekU(*memoryid+c)
Next

[Hysteria]

Hi Netmaestro

Well there's no doubting that works so many thanks!

However, I am surprised one has to go to those lengths given the many variants of Peek and Poke. I thought that was what they were for. And there's nothing in the help that suggests that this approach is necessary for standard memory access (I'm not a user of or familiar with structures so perhaps its covered in that section).

What's also confusing is why it works the first time and then changes with my simpler approach. Why would it work even once if the bytes weren't in the right order/aligned correctly or whatever? And it does, always work once, the first peek is always correct but a second peek seems to disturb the first one. The pointer doesn't change (at least that I can see) so either the memory is being overwritten or the Peek is malfunctioning...or I'm just lucky it worked the first time at all...but I'm not sure I believe it was just luck

[Hysteria]

Code: Select all

; PokeU() writes an unicode character (2 bytes)


*memoryid=AllocateMemory(20)
If Not *memoryid:Debug "Could not allocate memory":End: EndIf

For a=0 To 20 Step 2
PokeU(*memoryid+a,a/2)
Debug PeekU(*memoryid+a)
Next

Debug  "--------"
Debug  "--------"


For c=0 To 20 Step 2
Debug PeekU(*memoryid+c)
Next

Thanks also. So we're allocating bytes...yes...I suppose I should have realised that...Hence the need for correct word sizing...but why does it work once?

[djes]

Look at this http://www.purebasic.com/documentation/ ... ables.html

Code: Select all

Name         | Extension  | Memory consumption | Range
  -------------+------------+--------------------+----------------------------------------------
  Byte         |    .b      | 1 byte             | -128 to +127
  Ascii        |    .a      | 1 byte             | 0 to +255
  Character    |    .c      | 1 byte (ascii)     | 0 to +255
  Word         |    .w      | 2 bytes            | -32768 to +32767
  Unicode      |    .u      | 2 bytes            | 0 to +65535
  Character    |    .c      | 2 bytes (unicode)  | 0 to +65535
  Long         |    .l      | 4 bytes            | -2147483648 to +2147483647
  Integer      |    .i      | 4 bytes (32 bits)  | -2147483648 to +2147483647
  Integer      |    .i      | 8 bytes (64 bits)  | -9223372036854775808 to +9223372036854775807
  Float        |    .f      | 4 bytes            | unlimited (see below)
  Quad         |    .q      | 8 bytes            | -9223372036854775808 to +9223372036854775807
  Double       |    .d      | 8 bytes            | unlimited (see below)
  String       |    .s      | string length + 1  | unlimited
  Fixed String | .s{Length} | string length      | unlimited

[RASHAD]

Hi Hysteria
It works the first time because the allocated memory was still empty
So you debug what you just poked
But not the second time where the whole allocated memory is totally full

[Hysteria]

Yes I'm familiar with that table Djes (but thanks).

I now realise where I was going wrong. The last time I used Peek and Poke it was years ago and all you had were bytes so I was used to treating everything as a byte and combining them to form words myself, etc.

For some reason, with all of the variants of peek and poke in PB, I thought this was done for you, bit stupid of me really especially as I am incrementing a pointer that is in bytes and expecting Poke and Peek to magically change that to whatever format I am using for my data

I think the fact it appeared to work on every first set of peeks confused me sufficiently that I couldn't see the wood from the trees.

Thanks everyone - much appreciated!

[djes]

Our poor memory is not an EPROM