LZ: New idea for compression program!
[Prev][Next][Index][Thread]
LZ: New idea for compression program!
-
Subject: LZ: New idea for compression program!
-
From: Scott J. Rein <srein@rain.org>
-
Date: Sun, 08 Sep 1996 19:15:24 -0700
-
In-Reply-To: <>
Please read the entire message. I need all of your comments! I ended up
changing my mind almost entirely at the end, but you poeple might like the
original idea better.
This is being sent out to anybody who wants to help me with this program.
Any suggestions... please feel free. Tell me what you think (it is kinda
messy though):
What we need to do though is not only get a compression algorithm, but write
a compressor for the PC and then make up a nice shell for the calc. The
shell will actually read the compressed file (one big one because it will be
compressed on the PC... if we ever decide to put the compression program on
the calculator, we could actually compress files recieved from others).
After the programs have been listed, the user selects the program and then
it runs. When the program is finished, the program returns to the shell and
the file is deleted.
There are two glitches here: no saved games and no high scores. This can be
worked on in a later version though.
Last, we have a choice: either the program can be run like a normal ZShell
program, or we can give the shell out as an 85B file so that it contains
both a pointer to ZShell AND the shell. We would have to get permission
from whoever made ZShell (to be able to distribute ZShell with our program)
for the latter choice. This would be my choice though.
Of course, all compressed programs would have to be stored as strings which
would not show up on ZShell.
Actually, I just thought of one more choice. What if we made all of the
strings compressed automatically run the decompressor. All of the programs
would be compressed and put into a string as a bunch of .db's. Then we have
a call to the decompression routine (which would be NOT be stored in each
individual string, but as one program). A temporary string is then created
out of the .db's which is run and then deleted when the program ends.
Anyone who knows ASM well enough to pull some of this hacking off? Please
send me some mail. I should be able to do some of it (the big stuff), but
there will be some parts such as a call to ZShell to run the temporary
variable and then to bring it back to the calling program so that it may be
deleted.
Thanks for listening to me babble! :)
-- Scott Rein
srein@rain.org
Follow-Ups: