Ah ok but if it's a shell rather than a full OS, how will it be possible to access the entire 128 KB of RAM even from the TI-OS? Or will it just be restricted to games/programs running from inside the shell? In both cases you would have to make sure that no compatibility issues occur with programs that uses extra RAM, like TI-Boy SE.

When you run the app, all the TI-OS RAM data is backed up in the archive (stuff in pages 0, 1, and 2|3).
Then, page 1 in mapped in bank A, page 2 in B, and page 0 in C).
As far as i know, those pages are not used for permanent storage, except by the TI-OS.
By default, hybrid will not touch the other pages.
But, hybrid-compatible programs will still be free to use them if they need to (for temporary or permanent storage).
So bascially, like on the regular TI-OS environement, the program creator is responsible for compatibility conflicts (but also the user if he hasn't checked the program readme).
I initially had the idea to be able to use some other pages for program execution using a custom page swapping method, in order to be able to run 64K programs.
But i don't know if that will be possible (depending on how the project goes), but again, the user is free to decide to run such programs or not.

UPDATE
> re-coded a few routines : flasherase / flashwrite / flashcopy
> still working on sector defragmenting (once done, i can finally code the RAM backup part)

Yeah, looks like that reply got lost somewhere in the wordwide flow.
Anyway, thx a lot for your interest =]

What's left to do ? Well, let me see...
For the system to be operational, i need :
> finish the RAM backup section
> define which system RAM locations will be available to the user, move the data in the system RAM, and add the equates in hybrid.inc
> same thing for system rountines (a little reformating required for some of them, cause they are currently executed from the app)
> define the location and available size of the hardware stack
> code the kernel (should include the command line interface, program loading/return code, and hybrid exiting)
> code the RAM restore section (should be way easier than the backup, but it will include a VAT update which should be a bit hardcore)
I probably forget a few things...

Quite a lot to do, indeed...

Well, the CLI will be quite minimalist.
There won't be many features, just the essentials.
Mainly because i think the most important things should be done by the programs themselves (at least on a calculator).
Every command that you enter will cause the kernel to search the archive space for an appvar with that name, check if it contains hybrid-compatible executable data, verify the size, load the stuff @ $4000, and jump to it.
The commands history will scroll down, but there won't be any way to scroll it up (i want to avoid wasting some precious RAM, yeah, that's an excuse ).
But still, i intend to reserve 112 bytes for some kind of txtshadow, for when you exit a program.
You will be able to enter lower and uppercase letters, numbers, and that's all (following the appvars name formatting).
The input line length will probably be restricted to 1 line.
As you can see in one of the previous screenshots, the char @ (15,0) will be reserved for busy state, as well as current type mode.
The only available special key combinations will be [ENTER], [CLEAR] (clears the current line, or the whole window if the line is empty), and [2ND]+[MODE] (back to TI-OS).
After that, and due to how it works, special commands could simply be added by making tiny programs that you normally run (a bit like in .COM files in our good old DOS).
I had some projects about handling special programs, a bit like batchs, but i need to code a proper text editor first (not for tomorow).

Don't worry, a CLI won't represent much trouble (i easily "see" the algorithm in my mind).
About arguments, that was just an old idea, in the middle of a many.
That would imply handling specific headers, and such new formatting could be annoying for the developper, which will already have to adapt to hybrid basic rules.
Instead, i could, later on, create a program that automatically handles data input/output such as parameters, file names, etc...
I will probably go for that solution, cause i'm sure parameters will complicate the CLI way too much for me
But i must say a batch system (without params, just to automate the run of multiple programs) sounds really appealing to me =P

2 new routines, used by the kernel, but which will also be available to the developper who wishes to use the system CLI for input/output, for simple interactions with the user :
hybdispchr : displays a character at the current cursor location (scrolling handled). That one will actually be called every time you type something.
hybdispstr : same thing but for strings (wrapping+scrolling handled).
I will code hybnextline and hybclr tonight (easy), and the output part of the CLI will pretty much be ready.
More to come...

EDIT :
Alright, the output part is now done (so far : hybclr, hybclrin, hybnextline, hybdispchr, hybdispstr).
Despite those routines are initially for output, some are also designed to make the main input code easier (especially hybclrin & hybdispchr).
During the coding, i also had to decide which pointers i'll use.
Only 3 will be needed : the cursor (only one value), the start of the current input, and the end of it.
I made things so that the programmer should not need to adjust them.
The system is currently using a 144 bytes text shadow (128 + 16 spaces only used for scrolling).

Will the utility have routines to make it easier to use sound inside games and perhaps Calcnet stuff?

Well, i don't intend to implement such routines in the early release, but that would sound great in the future, if it's possible =]

Just make sure to not accidentally overwrite part of the Flash, especially the certificate or OS

Ah right, although I would say test mode is safer than erasing both the certificate and OS simultaneously. At least with test mode you just need to remove a battery fast enough and not trigger test mode too often in a short period of time.