Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: LincolnB on September 22, 2011, 05:07:29 pm
-
Hi there everyone. I'm working on a project right now, Base 671, in Axe, that will eventually run as an App, because it's gotten too big. I was using CrabCake so it would run at all, and the executable was nearing 1100 bytes, which is about how big all the billions of source files put together are, so I was running out of memory, so now it's going to be an app.
What do I need to change from a nostub ASM program when recompiling as an App? I know enough not to try and use SMC, but I'm not sure what all that entails. Could someone please provide me with a list of what I need to change/prevent from happening in an App's source code?
-
When making applications in Axe, the only thing you can't do that you can do in programs is write data back to the application. Probably the two most common uses of writeback are to store data like options/high scores and to create an extra buffer with Zeros(768). Instead of storing such data inside of your application, you should create appvars in which to store the data.
-
Also, if you access nibble data from your app, you'll need to use the alternate nibble read/write functions.
-
Just a quick question (and a minor thread hijack) - how would I get the MemKit Axiom to work for apps? I suspect that it's still parsing the VAT, but when I try to get the program name (Print(Str1)), it doesn't copy the program name at all, as it should in regular programs.
-
alberthrocks: That is because you're trying to write data back to Str1, which is a part of the application. As I explained in my previous post, that isn't possible. You should instead write the data to RAM somewhere, in scratch RAM or in an appvar.
-
alberthrocks: That is because you're trying to write data back to Str1, which is a part of the application. As I explained in my previous post, that isn't possible. You should instead write the data to RAM somewhere, in scratch RAM or in an appvar.
I've tried via #Realloc(L1) or #Realloc(L2), but they always fail. The #Realloc command seems to not be effective in apps, eh? :P (That's the "write to someplace in RAM" attempt.)
As for the appvar method, how would I accomplish that?
-
How did we get on the topic of #Realloc()? That has to do with changing where in memory the A-θ variables reference, not strings or MemKit. I meant you should use a different pointer argument for Print() that will result in the string being copied to RAM, since Str1 is a part of your application and cannot be written to. For example: Print(L₁).
Regarding appvars, unless you want data to persist between runs (like settings or high scores), I would try to use scratch RAM to hold your data whenever possible. As far as I know, you don't need this string to persist between runs and it's pretty small, at most 9 bytes, so it's probably easiest to use scratch RAM to hold it.
-
Also, if you access nibble data from your app, you'll need to use the alternate nibble read/write functions.
What functions?
-
Also, if you access nibble data from your app, you'll need to use the alternate nibble read/write functions.
What functions?
nib{nibble_address}r and value->nib{nibble_address}r
-
Oh, with the superscript r. Got it.
-
Also, if you access nibble data from your app, you'll need to use the alternate nibble read/write functions.
What functions?
nib{nibble_address}r and value->nib{nibble_address}r
Um, you can't write a nibble to an App, can you? Isn't it in ROM?
-
No, but if you have an appvar or some free ram, you can write nibbles to there. Correct, calc84/runer112/anyone else?
-
How did we get on the topic of #Realloc()? That has to do with changing where in memory the A-θ variables reference, not strings or MemKit. I meant you should use a different pointer argument for Print() that will result in the string being copied to RAM, since Str1 is a part of your application and cannot be written to. For example: Print(L₁).
Regarding appvars, unless you want data to persist between runs (like settings or high scores), I would try to use scratch RAM to hold your data whenever possible. As far as I know, you don't need this string to persist between runs and it's pretty small, at most 9 bytes, so it's probably easiest to use scratch RAM to hold it.
Oh... I was under the assumption that #Realloc() would cause the variables to be located in L₁ for modification. :P
So wait, if I do use Print(L₁), will I still be able to use regular variables?
(Or maybe I just don't get where the variables are/how do variables work/etc. :P)
-
No, but if you have an appvar or some free ram, you can write nibbles to there. Correct, calc84/runer112/anyone else?
Yes, but you'd use the normal nibble commands for that.
-
No, but if you have an appvar or some free ram, you can write nibbles to there. Correct, calc84/runer112/anyone else?
Yes, but you'd use the normal nibble commands for that.
Oh, ok. Got it.
-
On a semi related topic: I heard somewhere that axe makes "Trial" apps that can only run a certian number if times. Is that still true?
-
How did we get on the topic of #Realloc()? That has to do with changing where in memory the A-θ variables reference, not strings or MemKit. I meant you should use a different pointer argument for Print() that will result in the string being copied to RAM, since Str1 is a part of your application and cannot be written to. For example: Print(L₁).
Regarding appvars, unless you want data to persist between runs (like settings or high scores), I would try to use scratch RAM to hold your data whenever possible. As far as I know, you don't need this string to persist between runs and it's pretty small, at most 9 bytes, so it's probably easiest to use scratch RAM to hold it.
Oh... I was under the assumption that #Realloc() would cause the variables to be located in L₁ for modification. :P
So wait, if I do use Print(L₁), will I still be able to use regular variables?
(Or maybe I just don't get where the variables are/how do variables work/etc. :P)
The variables are stored at the END of L1, not the beginning. Using the first 714 bytes of L1 is perfectly fine and encouraged. Its only the last 54 bytes that are freed during #Realloc() to expand the L1 buffer to the full 768 bytes so it can be used as a screen buffer. Hope that clears up your confusion.
Also, no, there is no such command as ->nib{}r since you cannot write to ROM pages. The nib{}r command is ONLY for reading data from the app itself (your strings, sprites, data, etc). If you are reading nibbles from appvars, free ram, or other ram variables, you STILL use the regular nib{} command even in an app.
As of 1.0.4, all apps generated by Axe Parser are non-trial :)
-
Also, no, there is no such command as ->nib{}r since you cannot write to ROM pages.
Oh whoops, my bad :P
-
1100 bytes is a lot? My games are simple and they are all more than 1100 bytes.
-
1100 bytes is a lot when it's just data.