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)               .
          .                                                      .
               .               .                     .       .
                  .         .    .       .    .    .   .   .
                     .   .          .   .       .       .
                       .