Re: LZ: Multi-string shell aka PSOII shell
[Prev][Next][Index][Thread]
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) .
. .
. . . .
. . . . . . . .
. . . . . .
.
References: