Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: ZippyDee on March 24, 2011, 02:41:40 am
-
AXE/ASM noob here! :D
What's the ideal way to store large amounts of data (i.e. map data, sprites, large strings) for your programs? I'd expect that you'd just keep the data in your program, but is there a better way to do it?
Also, could I get some guidance on when to use temp ram areas/external variables rather than portions of program memory for data storage?
Any other data optimization tips would be greatly appreciated!
Thanks!
-Zippy Dee
-
Personally, in my Axeanoid program, there is 4 types of bricks (which are stored as 8x8 sprites at the beginning of the program) and the level is stored in an appvar. Said level is a tilemap, each type of brick is assigned a 4-bit number between 0x0 and 0xF. So in Axe, you would retrieve each brick using nib{} (instead of the normal {}) and do the correct conversion (displaying the correct sprite using the number from the tilemap). Useful if you have less than 16 sprites, it divides the size of your level by 2.
-
Yeah, that's a fairly straightforward compression technique, but if you have more than 15 of the same tile in a row, you have to break it up into multiple bytes, but that's still better than it would be without compression. Even so, how do you store the data as an appvar without it adding to the size of your program? Or does axe write to appvars when compiling?
-
Also, could I get some guidance on when to use temp ram areas/external variables rather than portions of program memory for data storage?
There are certain chunks of memory in system RAM ($8000-$9D94) that programs can use for temporary storage:
- appBackUpScreen - 768 bytes, perfectly safe (L3 in Axe; it's used for the back-buffer, so don't use it if you use grayscale in your game)
- saveSScreen - 768 bytes, safe unless APD (auto-power-down) starts (L1 in Axe; last 54 bytes are used for A-Z and θ variables in Axe)
- tempSwapArea - 323 bytes, safe unless you archive/unarchive a variable (L4 in Axe)
- textShadow - 128 bytes, used to store the contents of the homescreen, so safe as long as you either:
- not use the homescreen bcalls at all; or
- run RES appTextSave,(IY+appFlags) before using any homescreen bcall
- statVars - 531 bytes, not to be used if running from MirageOS or using statistics functions (L2 in Axe; do not use in Axe if custom interrupts are enabled, either)
- plotSScreen - 768 bytes, safe if you don't draw any graphics, since this is used as the graph buffer (L6 in Axe)
There are more, but they get smaller (<100 bytes).
Generally, it's smaller to use scrap RAM for temporary variables, while constant data should be stored in the program itself.
-
AXE/ASM noob here! :D
What's the ideal way to store large amounts of data (i.e. map data, sprites, large strings) for your programs? I'd expect that you'd just keep the data in your program, but is there a better way to do it?
Also, could I get some guidance on when to use temp ram areas/external variables rather than portions of program memory for data storage?
Any other data optimization tips would be greatly appreciated!
Thanks!
-Zippy Dee
You can use Appvars if you want them saved even when the program is closed.
-
Don't use them if the data is required for the program to run, though (always have a backup to rely on in-prgm). Appvars are generally useful for saving high scores or external levels.
-
Don't use them if the data is required for the program to run, though (always have a backup to rely on in-prgm). Appvars are generally useful for saving high scores or external levels.
Yes that's right, but they do allow moderately high amount of data.
-
If you only have a limited amount of data (0-768 bytes), you could probably use safe ram. Also, if you want it to be modified, you should use safe ram when possible. Also, any space you reserve in your program adds to the overall size, and should be avoided. Large amounts of data can also be compressed, but will most likely have to be decompressed as well. If you have large amounts of data to manipulate, you can consider swapping in a spare RAM page for tens of thousands of bytes, like I do in Motherload. However, this restricts you from using many OS routines, and interrupts must be disabled. Another alternative that is much less common is creating a temporary appvar or program to store information in during the program's lifetime. However, you aren't always guaranteed to have enough space.
As for compression, there are several ways. Run length encoding is one popular and simple way. There are many others. Both memory usage and compression algorithms should be appropriately used to suit whatever your specific needs are.
-
Don't use them if the data is required for the program to run, though (always have a backup to rely on in-prgm). Appvars are generally useful for saving high scores or external levels.
Yes that's right, but they do allow moderately high amount of data.
Actually, that's what I use in TaNF as a 3rd and 4th screen buffer zone, and it's actually quite helpful (and caused it to speed up by at least 30 FPS) -- but make sure you delete them, I'm sure people don't like to delete appvars called 'A' and 'B' after each runtime.
-
How does one use an appvar? I've never done anything with apps or appvars, so I'm kinda new to all this :P
-
In assembly, an appear is just a place to dump data. Look at the WikiTI documentation for the bcalls ChkFindSym and CreateAppVar.
-
Ah okay, thanks. What's the size limit for an appvar?
-
However much RAM is available. It can also be stored in Archive (Flash) memory, and take up however much is available.
-
But when it's in Archive, wouldn't it only be accessible by an app and not by a regular asm program?
-
No - accessible by both (though more difficult), and writable by neither (unless you move it to RAM or you're clever).
-
How do you access archive data from a program?
And would you care to define "clever" a bit more? :P
-
I believe that the ChkFindSym bcall returns the flash page the data is stored on, which you could swap into memory and read from.
And by "clever," I mean unlocking flash through an exploit (which can be dangerous if you screw up), and even then, you can only reset bits, and in order to get around that, supreme trickery is involved, including use of the swap sector (which moves) and all sorts of other complicated problems. It is much easier to copy it to RAM.
-
Ah yes it seems that is the case. B contains the page. Well thanks, this has been quite helpful! :D
-
Sure thing, glad I could help.
-
About the original question, the best way to store large amounts of data is not to store it at all. Simple algorithms that generate the data on the fly are generally the most efficient way to go for large amounts of data. If that's not possible or practical, then it really depends on precisely what your data looks like. Compression will sometimes work, but the shortest way to encode an arbitrary message of n bits without a change of storage format is in n bits. In other words, no compression algorithm can compress all data. All algorithms have some set of inputs that actually grow when the algorithm is applied to them. Keep in mind that access efficiency is also important. Sometimes it makes sense to have a few hundred data alignment bytes in your array if it means you can access the data in that array twice as fast.
So, there's really no answer to your question if it's interpreted that way. Everyone else has given some great answers otherwise, though.