LZ-Adv: PSOII Libraries
[Prev][Next][Index][Thread]
LZ-Adv: 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)