RE: LZ: PSOII Libraries

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

RE: LZ: PSOII Libraries

>Micah/Richard Brodsky wrote:
>> What I though of (here's where you skip to if you got bored):
>> -Most people use ZShell (I'm talking about in general, not just on this=
> list),
>> right?
>
>At the moment yes.
>
>> -USGARD is larger than ZShell, CShell, UShell, and OS-85, right?
>
>Yeah, it's 2k for the core, another 300 bytes for a shell. Not much bigge=
>r
>then CShell, and after only a few Usgard games you have saved space.

*** You mean not much bigger than OS-85? CShell is smaller than ZShell.

>> -People who don't have USGARD won't usually want to wipe their calc's m=
>emory
>> and sacrifice space just for a few games, right?
>
>No, but when Usgard games became many and when great games only exists fo=
>r
>Usgard...
>
>> -Libraries have the potential, if used well, to save quite a bit of mem=
>ory,
>> right?
>
>Yes. The problem however is that most people DISLIKE the whole idea of li=
>braries,
>believe it or not... having many strings on the calculator and without kn=
>owing
>what they do seems to confuse ppl, especially all diehard gamers (which m=
>ost
>ppl are) who have to figure out what libraries are needed for a game. If =
>you
>have a shell with libraries, it must be easy to find out which libraries =
>it
>requires.

*** I don't have a shell. I have a shell independant overlay system, not 
needing a backup or an installer PRGM. And because of the way RST 10h works, a 
program can detect whether a library is missing with 2 bytes. Also, one simply 
doesn't have to have the ZShell signature in them, thereby making them visible 
in TI-OS but not ZShell/CShell/OS-85. As for knowing what you can delete when 
deleting a program, well, I have never heard of a method for making that easy 
that will work with PSOII. All I can think of is listing it in programs' 
startup screens and/or in the docs.

>> -Why not make a Passive Shell Overlay library system that is Shell Inde=
>pendant
>> (theoretically, libraries should even work with UShell, which is incomp=
>atible
>> with ZShell), Hence PSOII?
>>  I did.
>
>You mean, a sort of add-on to ZShell/CShell etc which supports libraries?=
> Well,
>it would be possible of course. The problem will still arise that with th=
>e
>library support, it becomes a new OS sort of - games using libraries will
>be incompatible with plain ZShell.

*** That's the key! Their is no "plain ZShell" to PSOII. The libraries are all 
independant strings that you can place in an .85g with your program. If the 
library's already there, you just don't overwrite it. Simple as that. No 
change to the shell's string at all!

>>  I made a PSOII library for rudimentary remapping. Add 63 bytes and a
>> remapping table to your code. Have this 115 byte library packaged with =
>your
>> program. In other words, in about 5 minutes, your standard ZShell/CShel=
>l/OS-85
>> program can be a library-based remapping program, greatly increasing sp=
>eed and
>> reducing your size by 2 bytes per remap (including the table, not inclu=
>ding
>> the 63 byte loader and 115 byte shared PSOII library). If your code is =
>small,
>
>2 bytes per relocation? You save one byte for each CALL_ and JUMP_ (which=

*** DAMN! A major miscount here: for some reason, you don't save space (also, 
the loader is 45 bytes, not 63)?! At any rate, I have plan to up it to 2 bytes 
for sure, I just have to write the code. I have a plan that also won't save 
space, but will increase speed.

> are
>the most common places for relocating/remapping) and 3 byte whenever you
>add (PROGRAM_ADDR) to get the absolute address to a label. Btw, this piec=
>e
>of code should definately be inside the OS not the program. The whole ide=
>a
>of relocating is quite old also.

*** So what if it's old? This allows relocation without changing your shell! 
And you save space over having the code built in to programs if even 2 
programs use it. It's an independant string of 115 bytes. I may make it MUCH 
more efficient by bringing it up to about 170 bytes. (How's temporarily 
classified;)

>> you sacrifice a little size for speed. If your code is mediuim-sized, y=
>ou
>> simply gain speed. If your code is large, you gain speed and reduce siz=
>e. I've
>> tested this: ZD-Bug would knock off ~80 bytes (not including the librar=
>y) and
>> be faster. Bounce (actually an ancient demo, if you didn't know) would =
>gain
>> ~45 bytes, but it does not need speed, being simple. No need for USGARD=
>,
>> memory backups, or installation programs.
>
>The 'shell' (or whatever you call it) seems to be something between Zshel=
>l and
>Usgard - it has libraries, you suggest remapping (although each program u=
>ses
>it's own remapping routine!?). Usgard also has interrupt support (as you =
>probably
>know) which is something VERY great.

*** As I said before, no shell here, and this isn't exculsive with interrupts. 
I could build a non-PSOII library to add interrupt functionality, shell 
independant, to work with PSOII. Also, this is designed to be a near-painless 
and very compact implementation of some features that USGARD happens to have, 
but intended for people who don't want USGARD or don't have room for it. (And 
you could have as many libraries as you want, no limit of 256)

>--=20
>Jimmy M=E5rdell                   "Searching for shelter
>mailto:mja@algonet.se            My brain is on ice
>http://www.algonet.se/~mja       I'm scared of my own thoughts
>IRC: Yarin                       I can hear them cry" /Leather Strip
>
--MZB (micahbro@msn.com)
Follow-Ups: