Can I see the assembly for that write-back hex code?  And does it work when the program is archived?  And if so does it re-archive the program when it copies back?

mhmm I hope not , cuz what if I have like 200 sprites in my data?

Hold your horses, Axe already puts the sprites there, and it doesn't take super long to copy.  Imagine Phoenix.  The time it takes Phoenix to exit is an outrageous example of an absurdly huge program writing back.  Descresion is not necissary.  Try it yourself - take your biggest Axe program and implement this.

Can I see the assembly for that write-back hex code?  And does it work when the program is archived?  And if so does it re-archive the program when it copies back?

The code is back a ways in terms of posts.  I'm going to modify it a little later on so that it works with archived programs.

yeah I asked him more info about that but he never awnsered my question. I guess it was poorly worded

Sorry, I have been offline.

That's pretty cool!  Great job SirCmpwn!  This opens a door in Axe programming.

Quote from: Quigibo on March 19, 2010, 07:47:33 pm

Can I see the assembly for that write-back hex code?  And does it work when the program is archived?  And if so does it re-archive the program when it copies back?

The code is back a ways in terms of posts.  I'm going to modify it a little later on so that it works with archived programs.

Hold up, you can't even run no-stub ASM programs when they are archived, so this shouldn't be necessary.

Quote from: calc84maniac on March 19, 2010, 10:05:16 pm

Quote from: SirCmpwn on March 19, 2010, 08:03:53 pm

Quote from: Quigibo on March 19, 2010, 07:47:33 pm

Can I see the assembly for that write-back hex code?  And does it work when the program is archived?  And if so does it re-archive the program when it copies back?

The code is back a ways in terms of posts.  I'm going to modify it a little later on so that it works with archived programs.

Hold up, you can't even run no-stub ASM programs when they are archived, so this shouldn't be necessary.

You can run Archived no-stub Asm programs with DoorsCS and CalcUtil.

I also would like to see this implemented into Axe itself.

I think when DoorsCS encountered a archived program it just copied it to ram and ran it, I came across this situation a few times when DCS didn't delete the copy.

I'm sorry SirCmpwn, but this:

You are thinking in a TI-Basic frame of mind.  Get out of it.

caused me to rate your post down.  You can write in Ti Basic and think about Axe like Ti Basic and still have amazing programs.  There is a Basic frame of mind, but  no reason that you need to "get out of it".

Remember, fighting does not solve any problems.

Quote from: DJ Omnimaga on March 19, 2010, 08:39:27 pm

Well, my main worry about huge writeback is that is there a memory limit in how much stuff can be written back? Let's say, for example, I create a RPG with 9 KB of map data.

You are thinking in a TI-Basic frame of mind.  Get out of it.  With pure assembly, there is direct access to the proccessor, and no interpreter in between.  A rough estimate to copy 9 KB is maybe about 6 seconds.  And, you can have a "saving..." screen, too.  I'll probably write some code later that will allow you to just store what you need into an AppVar or something.

I was more worried about if there would be enough RAM areas left to put that 9 KB in for writeback purposes. For example, the pointers from L1 to L6 seemed to have limited RAM. This is why I asked. I was worried that if we tried to copy way too much data, that it could accidentally overwrite RAM areas that shouldn't be. I'm not sure if I understand the pointer concept in Axe, but what would happen if you loaded over 9000 bytes of hex data in L5?

Unfortunately, though, I rated down the post too, because one day you could be replying to a new member and scare him away, which is something we do not want. It also has risks of starting fights or feuds with certain people, especially if they are in a bad mood one day.

Also for my defense, it is not someone's fault if he doesn't understand something as easily as someone else. Understanding assembly is not for everyone. I myself tried for years and I barely even understand anything. This is something to understand, too.

Thanks for the apology, though.

Let me see if i understand the concept behind the global data concept.  When the program is run, it is copied to RAM somewhere safe where the TiOS can run it.  After it is finished executing, it is NOT copied back, making the program effectively write protected . So all we need to do is write a little bit of code to find out where the program acualy located (the first hex code) and store it in a safe place (L4) until the end of the program where we use it.  Once we get to the end, we merely copy the program right back to where it started again, so that any changes we made are permanent.  We are not using any of the L1-L6 variables for anything more than a 4 byte address storage during the program execution, so there is no possibility that we could run out of memory due to large programs.

(did i get that correctly?)

Well actually, it is a 9-byte storage of the program name. But you've got the idea