Hey guys, I'm back!
I know I've been (basically) gone for over a year due to college stuff, but now that things have calmed down a bit, I figured I'd come back with a project that's been in the works for a few months now:

Introducing CEsh, a command line shell for the TI-84 Plus CE.
Features include:

▪ Running programs
▪ Filesystem structure
▪ Custom system naming (via CERMASTR)
▪ Support, albeit limited, for ANSI escape sequences
▪ Full API including custom command registration, command line arguments, and more

At the moment, this shell is not in a release-ready state, but I hope to have it there in a matter of weeks (months if classes keep getting in the way).

Nice project, which certainly represents a good learning exercise

Great work, I particularly like that special font (which is Dr. Mono, I believe?), and how polished it's already looking. I'd like to hear a little bit more about how you implemented the filesystem and the details of that API, if you're willing to share. Also, are you planning on making a GUI equivalent to the shell, like Alvajoy123 is doing with Xenon? I presume not, as this is advertised as a terminal.

Keep up the great work, I look forward to more updates. More competition in the shell business is always good.

Thanks!

The font is actually Terminus, and the API (still very WIP) would just be an abstraction of some of the internal code that would allow other programs to communicate with each other and with the shell.
As far as the filesystem goes, it's still a WIP but the basic layout will look something like this:

Code:

Where each "type" folder can have custom subfolders which are stored in an index appvar.

I am not planning on adding a GUI, but since that's the case, I may end up adding integration with another shell (I'd love to see it work with Vysion )

Oh, also, more screenies:

ANSI Codes:


Program execution:

Looking very nice, once again. Out of curiosity, are you able to move the text caret around within the currently edited text? That's something that's very nice for quality of life purposes, especially in a program where text input is the only input method. Here's a screenshot of how that looks in VYSION 2, for reference (where the arrows are used to move the caret around):


That filesystem layout seems reasonable, although I do wonder what the purpose of having all the TI variables listed would be--perhaps you could view/edit them?


Absolutely would be interested in this. What you do you have in mind as to how that kind of integration would improve usability (especially as that would require two appvars, one for CEsh and one for VYSION 2, both representing filesystems, as well as possibly more for data).

Anyway, great progress on this once again, making a shell is no easy task and you seem to have a mostly functional one already. Looking forward to more updates!

Funny you should mention integration with Vysion -- I was thinking the exact same thing myself! More to the point, I was thinking of an actual terminal in Vysion (with movable/ resizable windows) and, of course, she'll scripting (like .bat on Win10). The point being, it's all inside Vysion. Not launched by Vysion -- inside Vysion.

What do you think of that?

This probably wouldn't be viable for reasons that were recently gone over in the VYSION 2 thread--in order to make the kind of terminal that you're describing, I'd have to write it for the program itself to work with the windowing system and filesystem in the shell.

Not as of right now, but that is a feature I am in the process of adding (as well as command recall via the up/down arrows).


My goal is to do one of two things:

1) Create a tool similar to nano or vim, or
2) Leave it up to someone else to write a utility, which could be registered to launch/edit (./) that kind of file via the API

Well, for it to be inside Vysion it'd have to be part of Vysion, and I'm not sure how feasible that would actually be (epsilon explained it well). As far as shell scripting goes, that is one of my "I'll do this eventually" plans (which basically means there's about a 50% chance of it actually getting done ).


I wasn't thinking anything too advanced, maybe just command registration and command line arguments for Vysion, and maybe some kind of filesystem integration (perhaps a /vysion folder accessible from CEsh and vice-versa?).

Update time:

Not much has changed as far as usability is concerned, but I've refactored a very large portion of the backend code.
Changes include:

▪ Fully functional argument parsing (see screenshot)
▪ Screen textbuffer (allows implementation of a getC()-style API function)
▪ Made RAM footprint 26x smaller (literally, 76800 bytes → 2964 bytes)
▪ Made program launching a lot faster

More updates are on the way soon!

When you launch a program, does it return to the shell with the same history?

Awesome work! I assume you used the solution we discussed in Discord a while back to create the screen text buffer and decrease the RAM footprint (saving all of the text including color and formatting options, and presumably run commands as well rather than a screenshot of the entire screen).

EDIT: Seems like yes--2964 divided by the 988 characters on the screen comes out to 3, which is the number that we discussed earlier (1 byte for the character itself, 5 bits for the 32 background colors, 5 bits for the 32 foreground colors, and 6 bits for text attributes, such as bold, underline, strikethrough, or some combination of them).

Also, it's occurred to me that if you're keeping that buffer on the stack using the os_RunPrgm function, you probably shouldn't, as that only leaves ~1k of stack space left for the run program to use. You're using an appvar or keeping it in safe RAM somewhere, correct?


I'm almost certain that it does based on the previous screenshots and discussion about this (not all on the forums), but calclover would know for sure.

Yes it does, as epsilon mentioned. It creates a "save state" in an appvar before launching the program, and then restores it afterwards. This also leaves other programs free to modify that state, and the shell will pick up wherever the last program to edit that appvar left off. That's actually how I intend to implement a large part of the API.


Yep, that is correct


I am indeed storing it in an appvar, and yeah, storing it on the stack would be a terrible idea. I don't really intend to store anything extra on the stack at all, except what is necessary to run programs, since I can still very easily pass data between programs using appvars and it's a lot less buggy.

More Updates:

It's been a while, but I'm still working on this in my free time. The latest updates include:

▪ Complete rewrite of the input routine - Now faster and much less buggy
▪ Command recall - Recall up to 250 of your previously-entered commands using the up and down arrows. Implemented the history command as well
▪ Usable cursor - The cursor can now be moved with the arrow keys in order to quickly insert or delete text from an already-typed string. You can quickly jump to the beginning or end of the string using [X,T,θ,n] and [stat]
▪ Many bugs have been patched to make the user interface more user-friendly and polished
▪ All code is now posted and updated on GitHub, although I will continue to post periodic updates in this thread as well

Last but not least, screenshots:

Why is everything in one file and every single variable is global

Because I'm lazy

In all seriousness though, I know my use of globals is ridiculous and I definitely could split up the source code more. I wrote the original code ages ago, and I've been, albeit slowly, attempting to improve on it. I likely will be fixing a lot more of the bad-practice type issues with the code before I move on to adding more features (it's actually been on my radar for a while), and suggestions are always welcome

Sweet keep up the good work it is looking really nice

Thanks

Looks great - I like the cursor movement particularly.

Are you planning on having power off/on so you can leave your calc in the shell permanently if desired?