« previous next »
Pages: 1 [2]   Go Down

Author Topic: Pointers memory location  (Read 8728 times)

0 Members and 1 Guest are viewing this topic.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Pointers memory location
« Reply #15 on: May 26, 2010, 11:20:58 pm »
I belive you are beaing misled.  When it says that Static pointers cannot be changed, what that means is that the chunk of data that you just named cannot be moved.  You can change the data to whatever you want just like you were using a normal memory location.  For example if you defined a sprite like this

Code: [Select]
[123456789012231]->Pic0
You can change the data inside Pic0 like this

Code: [Select]
# -> {Pic0 + 0} changes the first byte of Pic0 to #
Now if i understand you correctly, you might want to do something like this?

Code: [Select]
[10101021347809]->Pic0

"do stuff"

[FFFFFFFFFFFFFF]->Pic0
Unfortunately due to the way Axe handles data right now this isn't possible :( although there might be a way to do it in the future.
Logged

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Pointers memory location
« Reply #16 on: May 26, 2010, 11:33:10 pm »
Yeah, here are the specifics of what happens when writing to one of these locations:

No-stub: The data is changed, but will be reset after the program exits.
Ion/MOS/DCS: The data is changed and saved after exit (unless you have, for example, archive write-back turned off in MOS)
App: The data cannot be changed, because it is in ROM.
Logged
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Pointers memory location
« Reply #17 on: May 26, 2010, 11:42:45 pm »
Quote from: calc84maniac on May 26, 2010, 11:33:10 pm
Ion/MOS/DCS: The data is changed and saved after exit (unless you have, for example, archive write-back turned off in MOS)

Ah thats worthy to note.  Ill have to make sure Portal doesn't self modify itself to destruction if you exit at the wrong time.  If the program crashes and crashes your calc the changes wont be saved right?
Logged

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Pointers memory location
« Reply #18 on: May 26, 2010, 11:45:31 pm »
That's correct. If it is in RAM, it will be lost in the RAM clear. If it is archived, MOS won't have the chance to remodify it.
« Last Edit: May 26, 2010, 11:46:50 pm by calc84maniac »
Logged
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Pointers memory location
« Reply #19 on: May 27, 2010, 12:34:02 am »
Quote from: Builderboy on May 26, 2010, 11:20:58 pm
I belive you are beaing misled.  When it says that Static pointers cannot be changed, what that means is that the chunk of data that you just named cannot be moved.  You can change the data to whatever you want just like you were using a normal memory location.  For example if you defined a sprite like this

Code: [Select]
[123456789012231]->Pic0
You can change the data inside Pic0 like this

Code: [Select]
# -> {Pic0 + 0} changes the first byte of Pic0 to #
Now if i understand you correctly, you might want to do something like this?

Code: [Select]
[10101021347809]->Pic0

"do stuff"

[FFFFFFFFFFFFFF]->Pic0
Unfortunately due to the way Axe handles data right now this isn't possible :( although there might be a way to do it in the future.
aaaah ok, well it was more for Kindermoumoute, who wanted to know how to copy a sprite from a pointer to another to no avail.

Thanks, though, because in the future I know I'll need to modify map data a lot, for example, when picking an item on a map or breaking a block. It's nice to know about the SMC behavior too. I'll need to be careful about that.

Axe will prbly need to document this eventually if this is 100% exact.
Logged

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Pointers memory location
« Reply #20 on: May 27, 2010, 02:11:02 am »
Quote from: DJ Omnimaga on May 27, 2010, 12:34:02 am
aaaah ok, well it was more for Kindermoumoute, who wanted to know how to copy a sprite from a pointer to another to no avail.
That's the copy command Conj().  You can use it to copy a sprite,  into for instance the L1 address, by doing conj(Pic1,L1,8)
Logged
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Pointers memory location
« Reply #21 on: May 27, 2010, 02:24:12 am »
won't this cause the sprite to end up like this, though:

1111111110000001100000011000000110000001100000011000000111111111

Instead of
11111111
10000001
10000001
10000001
10000001
10000001
10000001
11111111

like this?
Logged

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Pointers memory location
« Reply #22 on: May 27, 2010, 02:31:38 am »
Um... if you're copying it to the screen, then just use Pt-On() and it will align it correctly.  Otherwise, the 2 sprites you posted are exactly identical in RAM.  All of the ram is a single 1 dimensional string if you look at it from a low level, there is no difference with reading and writing to it vertically or horizontally, only the circumstances change how you visualize it.  Data is data.
Logged
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Pointers memory location
« Reply #23 on: May 27, 2010, 02:38:53 am »
ooh ok right my bad x.x

Somehow I visualized a 8x8 sprite with each byte separated every 12 byte, like on a tilemap in xLIB. I need to get xLIB out of my head x.x


(for xLIB, a black filled 8x8 sprite on a plain white tilemap would look like this in data form:)

Code: [Select]
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
FF0000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
« Last Edit: May 27, 2010, 02:40:27 am by DJ Omnimaga »
Logged
Pages: 1 [2]   Go Up
« previous next »