Re: TI-H: Why make hardware upgrade? CMPRS!!!
[Prev][Next][Index][Thread]
Re: TI-H: Why make hardware upgrade? CMPRS!!!
Please read the whole thing or none at all, or else you might think I'm
just tearing down ideas.
I tried once, although I never told anyone about it. Some things to
consider:
* The compression/decompression algorithm takes space. They usually
need some memory to work with too. (Besides the memory to hold the
complete compressed and uncompressed work). You could maybe have a
program remove data as it worked, but it would be hard, and not all
compression algorithms would like it.
* You would need to store the compression algorithm. Decompression is
usually fairly fast and easy; on the other hand compression is slow and
needs more memory. No one wants to wait 10 minutes while their calc
compresses data. Why do you need the compressor? Programs that store
data such as high scores would need to change them, and you would have
to recompress the program. If you just compressed code and static data
and kept scores and such in another string, you would not need the
compressor, but all programs that modify themselves would have to be
edited/recompiled (and not all have source). Some programs already use
huffman or RLE for data such as levels and pictures that only have to be
decompressed.
* Incompatibility between calcs. You transfer a compressed program to a
friend's calc without the decompressor. That's a problem.
I know some of these arguments aren't too great (the last can be solved
by sending over the decompressor too), but compression would still be
very hard to be worth it.
If someone can overcome these difficulties, go for it. I wouldn't mind
seeing a compression program. Perhaps there is a quick, easy algorithm
that I didn't think of when I tried.
One other thing that might be possible is to make a "compression box"
that you connect to the link port. Send a command and then a program to
(de)compress on one line, then receive the (un)compressed version on the
other. That would be a job for the hardware list with something like an
AVR perhaps.
Joe Martis wrote:
>
> I don't get it... Everyone is trying to make a hardware memory
> expansion. It cost money... Why not use a logical way to solve the
> problem. Compress! I figure that if the programmers (I really sould have
> written this to the asm list, but I'm not gonna subscribe) would make a
> shell (I'm talking about 82) that takes up most of the memory, and it's
> mostly blank space. Then the shell and some homemade link software would
> use a protocal to transfer new files into the compressed space. The
> shell would decompress the file it's going to run and put it into the
> compressed/free space, uncompressed. So the shell never lets anything
> out of it's 'space.' The leftover space would have to be enough to allow
> the calculator to function normally. I don't understand why no one has
> tried it (and publicly announced it.)
>
> -Joe Martis
--
Jonathan Anderson
sarlok@geocities.com
"I can't be wrong - my modem is error correcting."
References: