[TI ASM] Allocating memory.
Moderator: MaxCoderz Staff
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
[TI ASM] Allocating memory.
I was wondering the way people use to allocate RAM for use in their programs. For example, if you need an extra screen buffer, or otherwise (for example; Vinegar needs two 5KB-ish buffers).
I tend to create temporary programs and, after adding 2 to the returned data pointers, this seems to work quite well. If I need more speed, I'll calculate offsets into these programs and use a SMC-like approach to adjust the pointers in my program.
Of course, I pick silly names that shouldn't exist (Vinegar uses "ch8.tmpf" and "ch8.save" - lowercase) and delete the programs at the end.
Advantages of this are that the space is marked as being used, so other functions don't end up accidentally using this space. It does seem a bit messy, though...
Are there any better/cleaner methods?
I tend to create temporary programs and, after adding 2 to the returned data pointers, this seems to work quite well. If I need more speed, I'll calculate offsets into these programs and use a SMC-like approach to adjust the pointers in my program.
Of course, I pick silly names that shouldn't exist (Vinegar uses "ch8.tmpf" and "ch8.save" - lowercase) and delete the programs at the end.
Advantages of this are that the space is marked as being used, so other functions don't end up accidentally using this space. It does seem a bit messy, though...
Are there any better/cleaner methods?
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
I personally haven't used this method but there is rom call called Insertmem(opposite of delmem). It will insert memory into the ram so it won't effect other variables other than what it's inserting into. You could insert directly into end of your program. And since it shouldn't update you size bytes, you probably won't need to uninitialize.
However, i don't know if this exist for the 83(that's what you have right?). And i have never used it.
However, i don't know if this exist for the 83(that's what you have right?). And i have never used it.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Ah, I never thought of that (I know _insertmem, but try to keep away from the editing ROM calls as some I've used in the past have been incorrectly documented). That's pretty damned clever, and you wouldn't even have to recalculate the pointers.Jim e wrote:I personally haven't used this method but there is rom call called Insertmem(opposite of delmem). It will insert memory into the ram so it won't effect other variables other than what it's inserting into. You could insert directly into end of your program. And since it shouldn't update you size bytes, you probably won't need to uninitialize.
However, i don't know if this exist for the 83(that's what you have right?). And i have never used it.
I have a regular 83+
I've used _enoughmem (see the Unification FAQ or Google cache since it seems to be down, section II.5)
mod edit: fixed urls to stop page from widening
mod edit: fixed urls to stop page from widening
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
_enoughmem only checks free RAM after cleaning up all the temp variables, though... you still need to know where to put data?pacHa wrote:I've used _enoughmem (see the Unification FAQ or Google cache since it seems to be down, section II.5)
EDIT: I should read better That approach looks to be the easiest, but I wonder what would happen if you used a ROM call that dealt with the memory..?
I'd say any method that creates variables is the best, since it won't mess up if the calc is shut off, or somehow directly exits to the homescreen. Then again, it won't matter if you're using a shell that doesn't keep memory correct (Ion).
You know your hexadecimal output routine is broken when it displays the character 'G'.
thanks CompWiz
ben > Indeed it's easy to use, since I'm not a memory guru I can't answer about the effect of a ROM call dealing with memory though...
Dwedit > what happens to the free ram (reached by _enoughmem and then (FREE_MEM_START)) if the calc is shut down ? Is it flagged 'reserved' or something by the TI-OS ? If the program using free ram through this technique creates a new variable, is it possible that this new var is actually stored within that ram area ?
edit : it seems that paxl.org is up again
ben > Indeed it's easy to use, since I'm not a memory guru I can't answer about the effect of a ROM call dealing with memory though...
Dwedit > what happens to the free ram (reached by _enoughmem and then (FREE_MEM_START)) if the calc is shut down ? Is it flagged 'reserved' or something by the TI-OS ? If the program using free ram through this technique creates a new variable, is it possible that this new var is actually stored within that ram area ?
edit : it seems that paxl.org is up again
-
- MCF Legend
- Posts: 1601
- Joined: Mon 20 Dec, 2004 8:45 am
- Location: Budapest, Absurdistan
- Contact:
Yes, but the pointers will be changed too, so they are always safe to you as long as you don't mess with the variables manually (going around TIOS). I don't think any TIOS calls use the free RAM, they have all their data in the system RAM; that's why it is so big...pacHa wrote:If the program using free ram through this technique creates a new variable, is it possible that this new var is actually stored within that ram area ?
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Well, there are temp varibles and fps, but I doubt ben ryves is useing anything like that. I'm not certain it's wise to use un-allocated freemem now, it may change in the future. You now how kind TI likes to be with the community. tempvar is the sure thing, insertmem should work, though less often used(spencer uses this actually).
I had put a set of memory management routines in the API, a few months ago. I never tested them though, and I'm unsure as to how they work, but perhaps they can give you some ideas
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
(FREE_MEM_START is actually the floating point stack beginning, equivalent to the standard equate FPS, FREE_MEM_END is the operator stack OPS)pacHa wrote:thanks CompWiz
ben > Indeed it's easy to use, since I'm not a memory guru I can't answer about the effect of a ROM call dealing with memory though...
Dwedit > what happens to the free ram (reached by _enoughmem and then (FREE_MEM_START)) if the calc is shut down ? Is it flagged 'reserved' or something by the TI-OS ? If the program using free ram through this technique creates a new variable, is it possible that this new var is actually stored within that ram area ?
edit : it seems that paxl.org is up again
If you don't create any variables or anything else, the free mem region should be usable with no side effects, since it's not part of anything. The TIOS doesn't check if the values have changed and give less ram or anything like that.
If you create any variable, or use the floating point stack, or call a ti-basic program, then the pointers will change position, so your "free memory" area will move forward in memory. Your new var will be stored in what was previously "free memory", so if you touch the formerly free memory, you're messing with the new variable.
You know your hexadecimal output routine is broken when it displays the character 'G'.
-
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact: