RE: LZ: Multi-string shell aka PSOII shell

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

RE: LZ: Multi-string shell aka PSOII shell

1) My tentative analysis is that the multi-string shell would be larger than 
ZShell and smaller than USGARD.
2) The "TRANSMIT" program will be hell to write, but it could be done (anybody 
want to try?;). I have a similar, easier idea: Make a program that you have to 
send first, call it "RECEIVE." It would handle a simple dump protocol and 
create the necessary vars. Problem is that it would be a bit more of a pain to 
use.
3) The advantage of this shell would be that it is fragmentable: A program 
written for it could be simply transferred to a calc using another shell and 
it would run.

AGAIN, I may not be good enough to write this. I know for sure I can make the 
remapping and rom call systems, but it will be harder for me to do a 
vat-scanning shell, ZS compatability (I do have an idea, but it may be hard), 
and "TRANSMIT." If anyone wants to help, email me.
--MZB (micahbro@msn.com)

----------
From: 	owner-list-zshell@lists.ticalc.org on behalf of Terry Peng
Sent: 	Tuesday, July 22, 1997 11:56 AM
To: 	list-zshell@lists.ticalc.org
Subject: 	Re: LZ: Multi-string shell aka PSOII shell

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.