So about Doors CE and Cesium...

I like both shells. Cesium is super quick at running through the 118 apps (ahem...programs) I have. Of course, DCE will have folders for better organisation, that kinda stuff.

In the video Kerm posted, Doors CE would replace the prgm "A", which is what Cesium also uses. I'm wondering if anytime soon, we could have an option for which prgm is Doors CE and Cesium, with the option on first run, to pick either A or AA.

Kerm, Mateo, any thoughts on this occuring once DCE comes out?
(I get that I could just as easily make an AA program in TI Connect with the ASM command for Cesium or DCE, but it'd be nice for an easier (and automated) way for this to occur.)
o355 wrote:
So about Doors CE and Cesium...

I like both shells. Cesium is super quick at running through the 118 apps (ahem...programs) I have. Of course, DCE will have folders for better organisation, that kinda stuff.
...

Well, I think Cesium is super buggy and glitches out occasionally, but I do see how you could like its speed.

I don't really get what you mean with an automated way of selecting which program gets run first. I feel like the prgmAA would work fine(but then I don't know how well DCE9 and Cesium will work side by side)
Caleb_Hill wrote:

Well, I think Cesium is super buggy and glitches out occasionally, but I do see how you could like its speed.

Makes me wonder if you are using the latest version or the one in the archives Wink I mean, it's not like there's a place where you can post feature requests or bug reports Razz
https://github.com/MateoConLechuga/Cesium

Anywho, it's all a matter of preference.
After downloading the newest version, I think the problem lies with my calculator, or a program that I have. I will try again, though.
I think it would indeed be a good thing for DCE9 to pay attention to existing shells released months earlier, and whose usage can only expand by the time DCE9 actually hits the general public.
The exact technical means to achieve some form of shell interoperability (or at least, non-harm) on the TI-eZ80 series are beyond my area of expertise, but having conventions for well-behaved shells is a good thing for both programmers and users.

FWIW, replacing other shells' components does not fit the TI-68k/AMS definition of "well-behaved". On that platform, there's been a convention for detecting "kernels" by signature and version, through unused areas of the vector table in RAM, since a while before I joined the community in the spring of 2001. Newer kernels used it to make themselves detectable, to detect other kernels and refuse to run until the user uninstalled other kernels, and could expand on it: PreOS provides more information and entry points than the older, dirty DoorsOS did.
Another area where PreOS expanded on DoorsOS's feature set is library loading + launching. I've successfully proposed that design and functionality as a model for third-party TI-eZ80 developments in the same area, because making specs and design is time-consuming, and when one well-designed implementation has been working on another platform for over 10 years, "NIH" is plain harmful.


Technically, could the non-core functionality of Cesium, DoorsCE and whatever else future shells aiming at interoperability with those be layered on top of an open-source core providing the bootstrap + interoperability framework, the library loading + launching code (which is also available standalone, as it should be), some absolute musts for any decent shell (Home run ?), and whatever other very core functionality common to all decent shells I forget ?
Lionel Debroux wrote:
Technically, could the non-core functionality of Cesium, DoorsCE and whatever else future shells aiming at interoperability with those be layered on top of an open-source core providing the bootstrap + interoperability framework, the library loading + launching code (which is also available standalone, as it should be), some absolute musts for any decent shell (Home run ?), and whatever other very core functionality common to all decent shells I forget ?

This is already the plan. Launching and loading of programs that use libraries do not require a shell feature, and can be run via the homescreen simply as a nostub program. DoorsCE and Cesium will have some issues over compatibility, and here is a solution I propose:

When running, both shells could detect the presence of the other, and simply have the user specify which launcher should exist in prgmA when launched for the first time. As of right now, Cesium does not play nice, and simply overwrites prgmA on each launch, which will definitely cause issues. Also, an option could potentially be added to the options screen to specify if prgmA should be always be overwritten with the shell's launching code, in order to have users change their mind after installation.
sounds nice, but that means anytime a new shell is released that uses a similar loader, then the current shells will have to be recompiled to look for those too. would it be better for shells to manage an appvar that lists their name and what code should be in prgmA, kinda like boot.ini from the windows bootloader?
Luxen wrote:
sounds nice, but that means anytime a new shell is released that uses a similar loader, then the current shells will have to be recompiled to look for those too. would it be better for shells to manage an appvar that lists their name and what code should be in prgmA, kinda like boot.ini from the windows bootloader?


I'm with Lionel and Luxen on this, and proposed something similar for the CSE when we discussed standards for that platform.
If elfprince13 and Luxen agree on something, then I think it's probably something that I should consider pursuing. Elfprince13, you definitely discussed a more flexible ASM program header, but I'm afraid I'm forgetting what you proposed to making multiple shells work nicely together. Luxen: in your proposal, would every shell author use the same prgmA that reads that AppVar and selects which shell to launch? Part of the problem is that prgmA is just a TI-BASIC program that contains "Asm(prgmDOORSCE" in my case, and TI-BASIC programs can't inherently read AppVars without some libraries already being available. Mateo, can you think of a reasonable mechanism that we could use? One of the potential issues with this proposal is that the functionality of Cesium, Doors CE, and presumably similar shells is also largely mutually-exclusive, in that with the exception of the GUI and Hybrid BASIC libraries in Doors CE, both shells run ASM and BASIC programs from RAM and Archive.
KermMartian wrote:
If elfprince13 and Luxen agree on something, then I think it's probably something that I should consider pursuing. Elfprince13, you definitely discussed a more flexible ASM program header, but I'm afraid I'm forgetting what you proposed to making multiple shells work nicely together.

https://www.cemetech.net/forum/viewtopic.php?p=208087#208087 and https://www.cemetech.net/forum/viewtopic.php?p=208404#208404 both suggest using a generic shell-manager app that for the purposes of OpenLib( that forwards to an end-user's shell of choice. The context is slightly different, but the principle is the same.

[edit]

This feels somehow relevant:
elfprince13 wrote:
KermMartian wrote:
If elfprince13 and Luxen agree on something, then I think it's probably something that I should consider pursuing. Elfprince13, you definitely discussed a more flexible ASM program header, but I'm afraid I'm forgetting what you proposed to making multiple shells work nicely together.

https://www.cemetech.net/forum/viewtopic.php?p=208087#208087 and https://www.cemetech.net/forum/viewtopic.php?p=208404#208404 both suggest using a generic shell-manager app that for the purposes of OpenLib( that forwards to an end-user's shell of choice. The context is slightly different, but the principle is the same.

[edit]

This feels somehow relevant:


The gif is so relevant that the relevance with that relevant gif will...uh...make Doors CE come out faster!
  
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 UTC - 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