Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Ki1o on October 07, 2012, 08:10:17 pm
-
Ok bear with me for this one... Is it possible to make a command library and place it an appvar?
-
Maybe it's just me, but i feel like you need a bit more detail before I could actually answer, it seems a bit ambiguous... But to answer your question, probably, yes.
-
Let me explain by example:
Say builderboy decides to makes an interactive app or something for zedd. Would it be possible to take the commands used in the original library and put them in an appvar so when the user opens the code editor (inside of the app) he/she can write out the commands and the program would still compile?
-
There is no "code editor inside of the app." People writing Axe programs use the usual TI-BASIC editor (the one you get when you press PRGM and go to EDIT or NEW).
I don't know what you mean by "write out the commands," but here's a quick rundown of the types of variables Axe uses:
- Source - program
All Axe projects have a source program (the program with the code in it). These are what Axe looks for when it lists out the projects when compiling.
You can edit source programs in the TI-BASIC editor.
- Library - program
Source programs can include code from libraries with the prgm token. It basically works like #include in C or import in other languages, if you know what either of those mean.
You can edit libraries in the TI-BASIC editor. Libraries work like source programs except that they can't be compiled on their own—they need to be included into the source program.
- Axiom - appvar
Axioms are like extensions to the Axe language written in assembly. They're like libraries but in assembly instead of Axe language.
You can't edit them with the TI-BASIC editor because they're assembly code (they're made for Axe, not with Axe).
- Backup - appvar
Backups are just archived appvar copies of Axe source programs. You can create, restore, and delete them from the Axe Parser app.
- Executable - program
The executable is what the user actually runs. It's the program produced by compiling a source program, and it's what people publish for others to download.
You can't edit executables, and there's no way to get the original source or library programs used from them.
See Documentation.pdf (http://axe.eeems.ca/Documentation.pdf) in the Axe download for more info.
Zedd is a library—you can just get the 8XP files from the download (http://www.ticalc.org/archives/files/fileinfo/441/44185.html) and open the programs in the TI-BASIC editor.
Does that answer your question?
-
Well... ummm I was thinking about the way xde had a "code editor" so people could use the app instead of the standard code editor.
EDIT : 40th post I lvled up!
-
XDE didn't "have" a code editor—it was (supposed to be) a code editor and nothing else.
You can make editors just like anything else in Axe.
-
I'm sorry. One last question though. Back to the actual library part... could you put the commands in an appvar?
-
the commands ARE put in an appvar, but only for program backups, like he said. the programs that axe compiles are, and have to be, completely in the BASIC program format, with the exception of code inserted from axiom libraries.
-
What would you do with an appvar?
-
Forgive me for putting you through all this trouble. I was was experimenting with an idea I had in my head and I just wanted to know if it was possible. Sorry.
-
The Run Programs Axiom (http://www.omnimaga.org/index.php?action=downloads;sa=view;down=786) lets you call an external program (or a program typecast into an appvar) from an application. Axe variables aren't affected by the call. However, the transition in and out of the external code is pretty slow, an almost unavoidable* limitation of the OS.
*Yes, assembly programmers can come up with dozens of ways to get around that. None of them will integrate cleanly with Axe.
-
*Yes, assembly programmers can come up with dozens of ways to get around that. None of them will integrate cleanly with Axe.
That honestly stopped me from writing like 5 different examples he could use. But I agree with DrDnar, you'll have to call external programs.
But the real reason I'm posting is to clarify his question. I'm fairly certain he wants to use an appVar like a .dll. Basically, he wants so be able to use runtime libraries to that he can simply call them at will from his program.
So, to answer that question, no, you can't easily do that, and here's why:
- Where the appvars are stored, they are not executable
- The appvar would have to be pulled out of flash and stuck in ram (this is similar to what simply running it does)
- To be able to call the right routine in the appvar would absolutely require asm (and a lot of code counting)
While a runtime library axiom could in theory be created, you're best just to use libraries that go into the compiler (or just copy/paste the code). Also, you'll notice that in the past, all runtime libraries on the 84+ have been apps (xLib, Mirage, Doors, Celtic3) because apps can execute in place.
-
Forgive me for putting you through all this trouble. I was was experimenting with an idea I had in my head and I just wanted to know if it was possible. Sorry.
I don't see that it was trouble at all. It was a good question, and drew quite a few good responses. :)
-
thanks you all for your responses. and the penguin77, yes that was what I was thinking about but I couldn't think of a decent explanation atm. what if instead the dll was inside of the app instead of it being an external var, would that be possible? or would I need asm for that as well?
-
thanks you all for your responses. and the penguin77, yes that was what I was thinking about but I couldn't think of a decent explanation atm. what if instead the dll was inside of the app instead of it being an external var, would that be possible? or would I need asm for that as well?
You could totally put it inside an app, but it's not going to be as clean as you like. You app would look like this: (asm)
;this is a comment
;jp is jump
startOfApp: ;addresses
jp routineA ;4080h
jp routineB ;4083h
jp routineC ;4086h
jp routineD ;4089h
jp routineE ;408Ch
routineA:
;blah
routineB:
;blah
routineC:
;blah
When your axe program runs in ram, it runs in the $8000-$BFFF region (not exactly, but close enough). You can then swap the library app into the $4000-$7FFF region with a bit of asm. Then, to call your subroutines, you would simply call the addresses of their jumps. I'm not exactly sure what the mechanism is in Axe, but I know you can call absolute addresses.
The real trouble would be making that app. Maybe someone better than me with Axe knows how to put a jump table in like that, but I don't. So totally possible in theory, a bit of trouble in practice.
-
Mmh, it's a pretty interesting thing to try. I think that you can define and call jump tables like that :
.your jump table
.the main problem is to make PC $4000, but I'm not sure to understand how apps work
Goto Func1
Goto Func2
Lbl Func1
.code here
Lbl Func2
.same
.etc
.then call your routines
(E4080)(args)You can still compile your Axe jump table into an app, but the real problem is how to access the resulting app and make the code work. Maybe an axiom using _FindApp (like I did for AxeSh where I use the Axe API using Axe and Axioms, search it in the z80 projects thread).
-
Thanks that idea is interesting. Two things though. 1. what do you mean by "PC $4000" and 2. What does E4080 mean?
-
That honestly stopped me from writing like 5 different examples he could use.
I was totally thinking of you when I wrote that.
But also myself to a degree. Because I later had the idea that you could use Run Programs to load a program into RAM from an app, and have the app and program exchange pointers to sharable data and code using tables in scrap RAM. Of course, you'd have to jump back into the app from the RAM program, instead of returning normally; and, you'd have to use a bit of assembly (five or so bytes) to keep track of the app page. That introduces some ugliness, either requiring you to keep careful track of the stack, and making instant quit impossible without leaking memory; or, requiring some assembly code to fix up the stack and delete the RAM used, so that instant quit works right. Personally, I think the latter is the better solution, since keeping track of the order to use the code isn't too hard, I think. Does anybody want such an Axiom?
You know, it's actually do-able. You could do it the reverse way, too, using an Axiom to search for the app, and jumping into it instead of calling it from the OS. Because, you know, otherwise there's ugliness arising from the context change and all. . . .
EDIT: Right, so, to answer partially the previous post's question, PC is how the CPU keeps track of where it is in a program. Basically, each part of an Axe program is assigned an address in memory, which is just a simple number. The CPU just keeps incrementing that address, so it executes instructions in order (unless you ask it not to with a loop, conditional, or transfer). Programs are loaded into RAM at the address $9D95, whereas apps are loaded into the pageable space at $4000.
Matrefeytontias's idea of making a jump table is probably sound, but I'm not clear on what he means about changing PC. Axe apps start with PC=$4080, because the first 128 bytes are the header.
-
Well, let's answer that : I've already done that. Right now, I have a Nostub Axe program using 4 functions I defined in an Axe App. And it works greatly :) I'll open a topic for that in a few minutes, just the time to make screenshots.
So, let's explain.
I have two source codes : one for the API and one for the program using it. With a rapid test (I displayed the value of a label I put as first line of the code of the API), I saw that the first instruction is at $408B.:.AppTest
:.This is at $408B
:Goto Func1
:.This one at $408E
:Goto Func2
...
Now that I have my API, I made an Axiom on the fly including three commands :- getCurPage
- setCurPage(
- getAppPage(
I used them to access to my API using app pages.
So, now that you know all, I post my code.:.APIUSER
:getCurPage->P
:
:setCurPage(getAppPage("AppTest"))
:
:(E4094)(0,16,[FF818181818181FF])
:(E4097)()
:(E408E)(42)
:(E4091)(0,8,"Over 9000!")
:setCurPage(P
:getKey^r
:.AppTest
:Goto Start
:Goto Func1
:Goto Func2
:Goto Func3
:Goto Func4
:
:Lbl Start
:ClrHome
:Text(0,,"This app is an Axe lib
:Text(0,8,"You don't have to launch it.
:Text(0,16,"Press any key to quit
:getKey^r
:Return
:
:Lbl Func1
:Disp >Dec
:Return
:
:Lbl Func2
:Text(r1,r2,r3
:Return
:
:Lbl Func3
:Pt-On(r1,r2,r3
:Return
:
:Lbl Func4
:DispGraph
Like you see, it's nothing complicated :)
I'll post screenies in a new topic, so wait a moment ;)
-
Your way is definitely cleaner. I can imagine there being one reason for wanting to keep your extra code in a program---it lets users start the app, instead of the program. You're not far from writing a shell now.