Re: LZ: Multi-string shell aka PSOII shell

[Prev][Next][Index][Thread]

Re: LZ: Multi-string shell aka PSOII shell

do this:

	make a TRANSMIT program like you were saying but REWRITE THE
ROUTINES YOURSELF FOR A FEW REASONS:

		crasing is bad, we don't want it to happen
		BIG REASON: when Mel Tsai made the SF expander software he
pused the transmission speed to the limit. His software, which I use,
works great and transmissions are FAST!!! This would actually replace the
ti linking feature ENTIRELY and would be great. People might use it even
if they don't play games!!
		Will Stokes =)



On Tue, 22 Jul 1997, Terry Peng wrote:

> Micah/Richard Brodsky wrote:
> > 
> > Here's an idea: A shell consisting of multiple strings, most of which PSOII
> > style libraries. 
> 
> I don't want to sound too negative, but remember the problems Usgard had as a 
> result of all those library strings?
> 
> 
> > 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.
> 
> This is a great idea. The only problem is how are you going to access the TI 
> Protocol? You would have to rewrite the source code because the ROM has error 
> handlers that will cause the calc to crash.
> 
>  
> > 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.Too susceptible. Too many programs use the graph mem.
> 
> >         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.Interesting... I would go with the backup idea, it is much easier to 
> implement.
> 
> > 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 UShell is inferior to ZShell. ZShell is inferior to CShell. OS-85 is inferior 
> to all of those. The only two major contenders are CShell and Usgard, and 
> Usgard supports everything the multi-string shell does. If someone can 
> download the multi-string shell they probably have access to Usgard as well.
> 
> One of the great things about Usgard is that it will support ANY shell 
> interface which is written for it. I especially like Cool Shell- IMHO it is 
> better than the Cshell interface, and I think someone has made a CShell 
> clone. Most people's complaint about Usgard is that they don't know which 
> libs they need- clearly, TRANSMIT will address that problem. But the multi 
> string interface kind of offsets TRANSMIT- and the new programming interface 
> will be yet another heeadache for users and programmers alike. 
> 
> I think you should make a TRANSMIT program for Usgard- you will probably not 
> be able to use the ROM, but it will be worth it. 
> 
> Of course, if you could make the multi-string system SMALLER than Usgard it 
> might be worth implementing, provided that it has no major weaknesses.
> Best of luck if you decide to go for it.
> 
> -- 
> Terry Peng
> email-	tpeng@geocities.com
> web-	http://www.geocities.com/SiliconValley/Bay/5104/index.html
> This site always has the latest versions of my software.
> 


				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: