Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: aeTIos on March 05, 2011, 02:14:39 pm
-
Hello,
As some of you might have noticed, I am working on a shell in Axe. I am now playing a bit with memkit to get some experience, and I wrote a little program to list programs on your calc, it is attached.
My questions and updates will go here.
I have already one question:
How can you run DCS, MOS and Ion programs in an Axe program, or isn't this possible?
(That would be too bad)
Oh, and do you maybe know a possible name for this? I am not really good at thinking names :P
VVVVV the attachment MEMEMEME is the source (yea, the name is a bit weird) VVVVVVV
-
This came form the name thread, but no one's using it: Axecute?
-
Hm, yea, that would be a nice name...
-
You can't easily run DCS, MOS, and Ion programs in Axe. Basically what you need to do is put their respective libraries in the same locations as they are in the official shell (download the DoorsCS SDK to see the locations and code). Either that, or make the program a "shell within a shell" (mandate that it must be run in the highest shell possible). After adding the libraries, you need to know how to recognize the headers of the programs.
Here are a few names: CalcWare, AxeCS, AxeOS, aeTIosOS, AxeShell
I'm not good at thinking of names either.
-
If there are enough, I'll start a poll to get the name you like most.
Maybe I'm going to make my own header for it too ;D
-
aeTIOS? ;)
I like Axecute myself.
-
Me too, it sounds like "cute" , "execute" and "Axe". 3 nice things!
-
It also reminds me of the pokemon eggsecute.
Yeah, you can't easily make a shell in Axe due to those issues with MOS/DCS/Ion incompatibility...
-
Are you going to include the libraries eventually? Otherwise you wouldn't be able to run anything other than normal BASIC and nostub ASM prgms, unless you chain with existing shells...
Anyway, I like Axecute too ;D
-
Well, you could make an Axe-Only shell, that just does nostub, or perhaps a header-remover that gets rids of the parts that make it DCS, MOS or Ion. Not sure how hard that second bit is tho, depends on how they do it :P
-
This sounds neat. I really like the name "Axecute." ;D Good luck. :D
-
When I saw this thread I was first thinking of something else. I was thinking of a shell designed for Axe programs. Think of it like this. The Axe language contains many useful functions such as DispGraphr, multiply, divide, bitmaps, sound, and other stuff that I'm not familiar with yet. What if the Axe compiler instead of writing the asm function of DispGraphr it would just write call DispGraphr (DispGraphr would be the address in the shell). Then inside the shell would be the Axe sub-routines that the program would call. This would be just like how all other shells contain their own libraries that programs can access, but instead these would be Axe libraries. Thereby decreasing the size of every program.
I'm not that good with names. This isn't like the nspire where you can just put an N in front of everything. nAXE :P
-
z80man: then that would defeat the point of Axe, which is to make a standalone program without a need for a big app. ;)
Besides, that has been done with MirageOS and Ion, in which both have built-in routines that can be called by the running prgm. What IS a possible idea is to get Axe to replace the internal routine with a call to the routine in the shell, which could reduce size for certain shells (specifically, MOS and DCS, since MOS covers quite a bit of the bases, and DCS covers both MOS and Ion).
=============================================
This is a very interesting project - in fact, I'm working on a Axe CS too! ;)
I'm working on the low level drawing side of things right now - basically, prepping for the GUI stuff.
(Workflow for me is Drawing => Prgm Listing (and reading possibly) => GUI => Prgm Execution)
For you though, it looks like prgm listing is done for you! ;)
It won't have "Axe" inside the name, but "Axe" will be mentioned in the about and the README of the program. :)
(It's not really focusing on "Axe", it's focusing on smallness, hence the special name I won't mention. ;))
If you are planning for MOS/DCS/Ion support (in which I highly recommend), you get to join me on an interesting journey! ;)
It seems easy enough to simply read the header to determine type, jump past it, and execute from there. That's all, right?
Not quite, as I've learned from looking at a DCS wiki entry on the SDK.
Apparently, the program also can access the shell's routines too!
It would involve implementing the routine, and then messing around with code (or at runtime)
to place the routine in the right position for MOS/DCS/Ion, and then executing the program so that it can access it.
The routines in question are NOT something you'd want to omit: http://dcs.cemetech.net/index.php?title=SDK
Remember that not everything is an Axe program - that is, not all programs bundle in internal routines.
(For instance, DispGraph in Axe compiles to a call to included code inside the program, which is Ion's FastCopy.)
Therefore, it's a must to implement these guys! :)
-
Well, you could make an Axe-Only shell, that just does nostub, or perhaps a header-remover that gets rids of the parts that make it DCS, MOS or Ion. Not sure how hard that second bit is tho, depends on how they do it :P
Ion can be run from the homescreen, and if you change BB6DAAC9 in the DCS header to BB6DAA00, it can too.
BTW, AxeCute is the name for it. I decided.
I also try to create addons like a grapher, word processor and moar.
-
Well, you could make an Axe-Only shell, that just does nostub, or perhaps a header-remover that gets rids of the parts that make it DCS, MOS or Ion. Not sure how hard that second bit is tho, depends on how they do it :P
Ion can be run from the homescreen, and if you change BB6DAAC9 in the DCS header to BB6DAA00, it can too.
There's a reason one form of the Ion header as well as the MirageOS and DoorsCS headers aren't compatible with Asm(. They use custom routines that are built into their respective shells, so simply changing the header may cause the program to run a routine that doesn't exist -- running arbitrary data that could be anything, in other words.
-
(For instance, DispGraph in Axe compiles to a call to included code inside the program, which is Ion's FastCopy.)
I think Quigibo switched it to SafeCopy because then there is no need for some calcs to have ALCDFIX or Door's Retune. ;)
I wonder if you could just run the routines straight from Doors. I.E. check to see if Doors is on the calc, and if it is then point to the Doors App for all of the routines...
-
I'm afraid there's a decent chance that I'll one-up you soon :( I've been working on something like this for three months now. If you need routines or advice, let me know.
-
O lol.
I have one question:
I want to include a grapher and I remember that you made one in Axe one time, do you still have it?
If not, can you give some advice for creating one?
-
Yes, I have it (I think) and I can post it later. However, the equation is hard coded and pre-translated to Axe. Your biggest concern should be interpreting the user's requested equation.
-
:o But I think I can do that :D
I started working on a more-lv-gray drawing suite for it, it looks pretty good now.
-
Seems interesting, although one thing I want to warn you about is that it will be hard to compete against Doors CS7 (which saw 10 years of work) and MirageOS (which saw quite a few years too), and to do so, the shell really needs to run all DCS/Mirage/Ion programs fine, which means including the routines (I am not sure if all authors would approve, especially Doors CS7, which is still being maintained). If it's for learning purposes, then I think this is gonna be a nice project idea to practice. Otherwise, my suggestion would probably be to create some sort of shell that requires DCS, for example, but use a different GUI or something, so for example, those who like to browse files through a Mirage-like interface instead of the PRGM menu or DCS menus, but still need DCS functionalities would find this pretty useful.
-
Oh, yeah, that's a great idea!
Axe Shell Extensions for DoorsCS7 would have a ton of potential. ;D
-
That reminds me... Doors CS 6 supported third-party add-ins or something like that. I remember it was possible to load a program on your calc that changed the DCS GUI completely, for example. However, it had to be in RAM and when a RAM Clear occured, you had to set it up again. If that still exists in DCS, maybe you could do that? I'm not sure if it would be easy in Axe, though...
-
That's called an SE (Shell Expansion), and it *cannot* be written in Axe.
-
Ok thanks for clarifying :D.
-
Or can they?
-
I guess if they're written in Axe, they would require some modifications or inline assembly.
-
You can always make an Axe program to copy its own code into the real program. I do that all the time for hooks :D