Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
I. Introduction: What?
Shell Expansions, or SEs, are modules for Doors CS. They are similar to the concept of Ion Modules, except that they are far more versatile. Shell Expansions can have one or more of three sections: Boot, Mouse, and Unload. A shell expansion with a Boot section is called while Doors CS is booting, before it counts programs and displays the desktop. Possible uses: load interrupts, set up hardware, sort programs, etc etc. Mouse sections are the most versatile: not only does Doors CS call them continuously while the mouse is active, they can actually interject actions into Doors CS itself. They can force mouse movement, clicking, and coordinate jumping via well-placed memory editing (not necessarily advocated). Finally, unload sections are, obviously, called while Doors CS is quitting, after it has closed down the GUI system but before it reverts to the TI-OS. Since a program can contain one or more of these sections, it can be anywhere from 768 byte to 2,304 bytes; each section can only be up to 768 bytes, since it must fit in SavesScreen.

II. Programming Detail: How?
Shell Expansions are currently loaded via an extremely inefficient system. When Doors CS first loads, it searches the VAT for programs that may be shell extensions, counting the number of shell extensions on the calculator but not making a note of which have boot, mouse, and unload sections. When the calculator reaches any of the three stages, it first checks to see if the SE count total is zero. If it is, it skips SE execution completely. If the variable is nonzero, it goes through an iterative loop, calling VATFind, Doors CS's most CPU-intensive routine, once for each of the Shell Extensions reportedly present. The VATFind routine searches through the VAT, counting the Shell Extensions it finds until the select one is found. It then checks if its vector table contains an entry for the calculator's current state (boot, mouse, or unload). If a relevant section is found in the selected Shell Extension, it copies it to RAM and then jumps to it.

Clearly, this is quite inefficient, because the entire VATFind system must be invoked each time an SE is executed, even if the specified SE does not have a relevant section for the current mode. However, this system does have its strenths. Because it does not store a table of SE locations anywhere, there is no inherent limit to the number of SEs on any system at a time, other than the 255-SE limit of using a byte to count. Secondly, it saves safe memory for programs for the same reason. However, by limiting the number of Shell Extensions on any system to, for example, eight, two major advantages could be attained:
1. The vector table could be consulted each time an SE event occured instead of needing to search through the VAT with VATFind once again
2. Additional memory, perhaps 2 bytes per SE, could be allocated to store important data in between executions.
With these changes, SEs would move closer to partial multithreading and away from the current rather cumbersome system.

III. Why?
As a programmer, why would you want to write your program as an SE rather than a full program? Well, not only would you have the programming challenge of fitting your entire program into 768, 1,536, or 2,304 bytes, you would have the advantage of interacting directly with the Doors CS kernel. Startup programs could directly set flags and options within Doors CS, or through some fancy programming, even prevent it from booting entirely (password protection, anyone?). Because Doors CS is now an app, SEs have access to each and every routine Doors CS has to offer to ASM programs, although it is not recommended that they mess with the GUI system, in case Doors CS itself is taking advantage of undocumented GUI API features. The mouse SEs are the crowning jewel of the SE system, for thety allow the programmer full control over cursor movement, cursor clicking, and even the direct cursor coordinates. Such power gives SEs the opportunity to completely change the way the interface works for the user. A low-end example could be remapping the keys on the keyboard, while a higher-end one might be a PS/2 or USB hardware driver.

IV. When?
Spurred by recent improvements in PS/2 routines written by the community, I just completed fixing support for SEs within Doors CS 5.7 Internal Beta 6, which unfortunately uses the old system. Please click on the Discuss link and give me some feedback on the new system I'm considering.
so how about that tab-key simulation I mentioned? and nice work, how do you manipulate the mouse coordinates?
By modifying the area of memory DCS uses to remember mouse coordinates. Smile That's why it's not a great idea to do it that way, and why I'll be adding some more dModes to the Mouse section.
excellent, and about the tab-key functionality?
Easy to make as an SE once I introduce the new dModes.
KermMartian wrote:
Easy to make as an SE once I introduce the new dModes.


awesome, keep chugging away
For anyone wondering, dModes are what shell expansions running at the mouse can do. When the SE quits, the following d values mean something:

d=
0: do nothing
1: leftclick
2: rightclick
3-98: set X coord to d-3
99-162: set Y cord to d-99
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement