LZ: PSOII Libraries

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

LZ: PSOII Libraries

OK, don't worry, you don't know what PSOII (Pronounced soh-ee) libraries are, 
because I just invented them today;)
PSOII stands for Passive Shell Overlay/Independant Implementation.

Here's the story (If you get tired of reading this, skip this paragraph):
A few weeks ago, I was having a great time on vacation, but I just couldn't 
put the TI-85 out of my mind. So I started designing an awesome shell in my 
head. I've never worked on a shell before, but, hey, I thought, there's a 
first time for everything. After a nice vacation, I came home and opened my 
email. OH, NO! 500+ messages from LZ, most of them about people doing odd 
things like putting ther calc into a 450 degree oven to repair it after it 
crashed with a nosebleed. As I started reading them, I learned just what 
USGARD was. DAMNIT! It was just like my "awesome shell," in fact, ~200 bytes 
away from my estimated size and sharing every feature except my idea for 
"properties sheets" and one that shall remain classified, including 
libs+multiple shells+more rom calls+int handler+remapping(yes), only USGARD 
exists, and mine was neuron-based vaporware. UGH! I couldn't think of enough 
swear words. The situation immediately forced me into the group of people I 
call "The group who wish they could fund Personal-H-Bomb research so that they 
can destroy every last F**ing vestige of USGARD and it's demonlike makers." 
Boy, that gives me a lot of enemies. At any rate, since I had no uranium 
refining facilities at my disposal, I realized I had to use my asm skills to 
do at least something.

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?
-USGARD is larger than ZShell, CShell, UShell, and OS-85, right?
-People who don't have USGARD won't usually want to wipe their calc's memory 
and sacrifice space just for a few games, right?
-Libraries have the potential, if used well, to save quite a bit of memory, 
right?
-Why not make a Passive Shell Overlay library system that is Shell Independant 
(theoretically, libraries should even work with UShell, which is incompatible 
with ZShell), Hence PSOII?
 I did.

What I did:
-What are the most obvious ideas for adding calls to TI-85 ASM?
 1-Placing something right after the shell in memory, hence fixed addresses.
 2-Writing your own shell, hence fixed addresses.
 3-Using USGARD libraries, hence requiring USGARD
 The idea that I came up with is this, using Self-Tweaking-Code: Have any old 
variable, even a ZShell program, with documented relative addresses. Your 
program uses a variable lookup/call routine using RST 20h and RST 10h (I got 
an approx. 60 byte one working), then remaps all it's library call addresses 
to this string's address, every time it loads. This is FAST, I've tested 
equivalent code. Hence, you add somewhere beween 50 and 100 bytes to your 
program to implement library calling, and everything else is automatic and 
fast. Your program's user doesn't have to know you did this, only not to 
delete the library!
-What did I make to test my ideas?
 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/CShell/OS-85 
program can be a library-based remapping program, greatly increasing speed and 
reducing your size by 2 bytes per remap (including the table, not including 
the 63 byte loader and 115 byte shared PSOII library). If your code is small, 
you sacrifice a little size for speed. If your code is mediuim-sized, you 
simply gain speed. If your code is large, you gain speed and reduce size. I've 
tested this: ZD-Bug would knock off ~80 bytes (not including the library) 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.

If you choose to use this system, please give me credit. I will release my 
remapping library after a little more work. Note that this library does not 
remap for calling itself because it doesn't need to. It remaps the JPs and 
CALLs that you've listed their relative addresses in a table.
--MZB (micahbro@msn.com)
Follow-Ups: