LZ: Multi-string shell aka PSOII shell
[Prev][Next][Index][Thread]
LZ: Multi-string shell aka PSOII shell
Here's an idea: A shell consisting of multiple strings, most of which PSOII
style libraries. Programs would be written partially or wholly for this shell.
In other words, a program could rely entirely on this shell, or use only a few
components and still be a ZShell program. The system would be constructed as
such:
LOADER: a very simple string that would be in backups only, and would contain
a shell loader & custom menu entry. This would not be necessary except if you
wanted this shell to be the only shell on your calculator. I estimate this
would be between 50 and 150 bytes. This would be the only one requiring a
backup (excluding INTLIB, possibly).
SHELL: A shell interface. This would only be requred if you wanted an
interface to this shell, excluding via any other shell you might have on the
calculator. This would be required for LOADER.
TRANSMIT: A program that would determine which strings are necessary to run a
program and send them with TI protocol. I have no clue how big it would be,
but it would be a good idea to have on all calculators using this system.
REMAPLIB: a library containing a USGARD like remapper that would use tables
inside the program to be run's string to determine what to remap. It wouldn't
just remap internal CALLs, etc, but also calls to the shell's libraries. This
string would be required for all programs using the shell or its components. I
estimate that it would require between 150 and 250 bytes.
ROMLIB1: a library containing the necessary "stuff" to handle rom calls for
programs that use this shell. This would only be required if the program was
designed only for this shell, so few programs would need this. I can't
estimate too well, but I expect it would be between 150 and 300 bytes.
ROMLIB2: a library containing the new, non-ZShell rom calls. This library
would be used by programs that needed the new varibale creation/deletion, etc.
rom calls. Using REMAPLIB, these could be used as easily and quickly as
standard ZShell-based rom calls, and any program could use both. I can't
estimate too well, but I expect it would be between 100 and 250 bytes.
INTLIB: This is only hypothetical, and it could be done in a number of ways.
The thing in common would be that it would handle "installable interrupts,"
similar to the interrupt system in USGARD, but able to handle more handlers.
It could be written in any of these ways:
1-Backup based. It would be transferrable only via backups, and would reside
in a fixed spot in memory. I estimate it would be between 300 and 400 bytes.
2-GRAPH-MEM based: It would be a standard PSOII like library, using graph
memory, but thereby succeptable to crashing. I estimate it would be between 50
and 150 bytes.
3-Self-relocating: This is a method that does not yet exist, but I've been
toying with it, and will soon do experiments to test to see if it's possible.
I estimate it would require between 300 and 800 bytes.
Other libraries, such as NASR, graphics, or mouse ones could be made later.
The advantage of this system is that it would be universally compatible, able
to run with UShell, CShell-NT, USGARD, OS-85, and of course ZShell, as well as
standalone, without any changes necessary. Programs could just use what was
necessary of its features, thereby reducing their size and increasing their
speed, and the TRANSMIT program would take care of giving the necessary libs
to other calculators.
What do people think of this idea? Does someone want to make it? If not, I may
try.
--MZB (micahbro@msn.com)
Follow-Ups: