RE: LZ: Multi-string shell aka PSOII shell
[Prev][Next][Index][Thread]
RE: LZ: Multi-string shell aka PSOII shell
I hope I can make this. I've been having trouble figuring out exactly how the
rom calls & ZShell compatability system will work, but I have some ideas that
look promising. If anybody wants to help or to make it on his/her own, email
me.
(BY THE WAY: As of yet, I haven't figured out how to avoid a ~50 byte
addidtion to all programs for this system, to locate the libraries. I suppose
this space could be made up through relocation and library savings, but
programs would still not be quite compact as USGARD ones.)
--MZB (micahbro@msn.com)
----------
From: owner-list-zshell@lists.ticalc.org on behalf of Will Stokes
Sent: Monday, July 21, 1997 2:31 PM
To: list-zshell@lists.ticalc.org
Cc: shell-developers@lists.ticalc.org
Subject: Re: LZ: Multi-string shell aka PSOII shell
go for it. =)
On Mon, 21 Jul 1997, Micah/Richard Brodsky wrote:
> 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)
>
Biya! =)
. . .
. . . .
. . . .
. Will Stokes .
. wstokes@vertex.ucls.uchicago.edu .
. wstokes@geocities.com .
. http://www.geocities.com/SiliconValley/Pines/7360/will.htm .
. .
. .
. http://www.geocities.com/SiliconValley/Pines/7360/ .
. . (The TI-85 Calc. Center) .
. .
. . . .
. . . . . . . .
. . . . . .
.