Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: squidgetx on October 20, 2010, 03:23:55 pm

Title: a couple questions
Post by: squidgetx on October 20, 2010, 03:23:55 pm
Ok...after spending an hour on my battle engine for my current project, I have a lot of questions that I hope I can get some help with. Thanks in advance ;D

1. Files: Does having a file open cause any significant issues? It seems to me that if you can't call subroutines with file open...and that they make the program rather glitchy in general. Is there a way to "close" files?

2. Lowercase letters: Let's say you want to create a database for the different items in a game. So let's say you wanted the first few bytes to be the name of the item, then how much it raises your HP by, and then how much it costs in the store. Example Data(TN,TE,TT,TH,TA,TM, 9000r, 9000r, TT,TI,T-,T8,T4,T+, 42r, 1337r)->GDB1 So then to display the name of your item if the item # is in variable I, you'd write
For(A,0,5)
Text(A*5,0,{I*12+A+GDB1}>Char
End


But now let's say that you want to use lowercase letters, which are two-byte tokens. I tried this:
Data(TNr,Ter,Ttr,Thr,Tar,Tmr, 9000r, 9000r, TTr,Tir,T-r,T8r,T4r,T+r, 42r, 1337r)->GDB1 ...
For(A,0,5)
Text(A*5,0,{I*18+(A*2)+GDB1}r>Char
End


..except it didn't work. Any ideas?

edit: looking at the documentation again and thinking about the >Tok command. That might be it

and 3. This whole data and code limit thing. So let me know if this is right, because I'm really confused:

Nostub: only up to 8192 bytes of executable code. Data isn't code, but since Axe mixes subroutines and code, it's possible that your >9000 byte program with 2kb of data won't work.
Shell: only up to 8811 bytes of executable code. Data isn't code, but since Axe mixes subroutines and code, it's possible that your >9000 byte program with 2kb of data won't work.
App: only up to 8811 bytes of executable code. As much data as you can fit into the app is OK
Title: Re: a couple questions
Post by: DJ Omnimaga on October 20, 2010, 03:41:03 pm
Nostub: 8192 bytes of executable code doesn't count any data in the program. basically you can have 8192 bytes of code but as much data as your RAM can hold (preferably stored in archived appvars, though, if the game is massive)
For shells it's roughly the same except 8811 for code I think. Your program can be slightly larger because shells lets you run programs even if you have like 200 bytes of free RAM, unlike the Asm() command.

For apps it's 16384 bytes of both executable code AND data, though (although you can have more data in external appvars too)
Title: Re: a couple questions
Post by: squidgetx on October 20, 2010, 03:42:57 pm
Oh, apps can have >8811 bytes of executable code? XD awesome
Title: Re: a couple questions
Post by: Quigibo on October 20, 2010, 04:58:24 pm
1. Files: They don't need to be closed.  They are always valid (if reading them succeeded) until garbage is collected/defragmenting.  This means that if you in order:

open an archived program to Y1
unarchive the program
modify the program
archive it again

Y1 is still pointing to the unmodified file since the new copy of the program is now copied to a different spot in rom.  For normal use though, if the file stays in archive its valid.

2. Axe doen't natively display token strings, it displays ascii.  The only time you might ever need tokens is reading and writing to programs.

3. Anything in ram is limited by the 8kb limit, but apps have a 16kb limit.
Title: Re: a couple questions
Post by: squidgetx on October 21, 2010, 07:09:41 am
Ok...thanks quigibo. A few more q's now lol:

4: In BASIC, putting Goto's inside If:Then blocks causes memory leaks. Does it do the same in Axe? (resolved)

5: How does Pt-Mask( work? (i figured it out :P)

6: Do apps take up any user RAM while being run?

7: Is there a way to retrieve the amount of free RAM and display/store it somewhere as a two-byte number? (resolved)

Thanks :)
Title: Re: a couple questions
Post by: DJ Omnimaga on October 21, 2010, 09:45:08 am
In response to 4, nope Axe doesn't do that. TI failed epically hard at coding their Goto instructions.
Title: Re: a couple questions
Post by: Deep Toaster on October 21, 2010, 10:38:28 am
In response to 7: It's Asm(EFE542).

So you can display it with
Code: (Axe) [Select]
:Disp Asm(EFE542)►Dec
or store it with
Code: (Axe) [Select]
:Asm(EFE542)→A

EDIT: It's a b_call that finds the amount of free RAM.
Title: Re: a couple questions
Post by: squidgetx on October 21, 2010, 03:21:01 pm
Thanks! I also figured out the lowercase thing during calc today (turns out there's a much more efficient way of coding that type of data structure: ie "Netham" : Data(9000r,9000r)

Title: Re: a couple questions
Post by: Mighty Moose on October 21, 2010, 04:44:19 pm
I think this might have been said in another topic, but for (7), you can simply do:
Code: [Select]
{E9828}^r - {E9824}^r->VARto get the amount of free ram.
Title: Re: a couple questions
Post by: Deep Toaster on October 21, 2010, 04:56:25 pm
Asm(EFE542) is smaller though. It also seems faster, but I'm not sure.
Title: Re: a couple questions
Post by: DJ Omnimaga on October 21, 2010, 09:22:44 pm
In response to 7: It's Asm(EFE542).

So you can display it with
Code: (Axe) [Select]
:Disp Asm(EFE542)►Dec
or store it with
Code: (Axe) [Select]
:Asm(EFE542)→A

EDIT: It's a b_call that finds the amount of free RAM.
Wow I didn't knew we could store Asm() stuff to a variable/pointer. If you are going with a pure-Axe way to do it, you would have to use Mighty Moose's way, though.
Title: Re: a couple questions
Post by: Runer112 on October 21, 2010, 09:26:10 pm
Asm(EFE542) is smaller though. It also seems faster, but I'm not sure.

It's a bcall. Bcalls are slow.
Title: Re: a couple questions
Post by: Quigibo on October 21, 2010, 11:42:03 pm
In response to 6, no apps don't take up space in RAM.  But the side effect to this is that you can't use self modifying code with your program data, you would have to copy it to free ram to make modifications.

Bcalls are ALWAYS slower, but they're much smaller, so it depends on what kind of trade-off you need with size vs speed.  For something like getting the free memory, I'm guessing you wouldn't be calling it 1000 times a second so the bcall is probably fine.  Conversely, division for example has a smaller bcall, but I don't use it because the performance is much more important for a function like that.
Title: Re: a couple questions
Post by: DJ Omnimaga on October 21, 2010, 11:47:05 pm
In response to 6, no apps don't take up space in RAM.  But the side effect to this is that you can use self modifying code with your program data
But no SMC inside the executable code, right? (nor the data included in the app)
Title: Re: a couple questions
Post by: Quigibo on October 21, 2010, 11:50:48 pm
Sorry, that was a typo -_-
Title: Re: a couple questions
Post by: DJ Omnimaga on October 21, 2010, 11:51:28 pm
Ah ok ;D