Re: LZ: Compression program
[Prev][Next][Index][Thread]
At 12:20 PM 9/8/96 -0700, you wrote:
>barrym wrote:
>>
>> On Sat, 7 Sep 1996, Scott J. Rein wrote:
>>
>> > >about the loss of highscores...
>> > >what if it went this way?
>> > >
>> > >1.uncompress
>> > >2.run
>> > >3.copy the highscores to a separate var.
>> > >4.delete uncompressed
>> > >5.somehow edit the compressed file(and add the highscores)
>> > >6.when the zipped has been highscore edited, delete the high score vars
>> > >7.return to zshell menu
>> > >
>> > >this might not be possible and also there would have to be a standard
>> > >highscore keeper. it also might take a while but, if it's possible, it
>> > >might be nice.
>> >
>> > Actually it might not be too hard if the decompression program searches
>> > for any new variables and simply compresses them back into the archive.
>> > Unfortunately, for this or any other way of keeping high scores, the
>> > compression algorithm must be on the calculator.
>>
>> You could write the compressor so that it leaves the first
>> 10 bytes of the program alone. The first 2 or 3 bytes of a
>> program would have to be a jump, but after that you would
>> have room for high scores. I'm just picking the number 10
>> out of the air. That would allow 7 or 8 bytes that could
>> be modified. Enough for high score and level for one person.
>>
>> Barry
>
>That's a good idea, there's the ZShell header the first two bytes, and
>then the desription of the program next, so it might be 15 or so. But
>maybe the first byte after the description could tell the unzipper and
>zipper how many bytes to skip, like this:
>
>$02, $FF,$FF <this is the high score, and then comes the acrtual code
>^
>skip two bytes
>This could take some refining, but it's a start
>Alan B.
>NEW E-mail- bailala@mw.sisna.com
maybe, the first byte after the description should be $C9 because that is
the opcode for RET. That way, if someone ran it without the decompressor,
then it would simple return to ZShell. Then could come the number of bytes
to skip, then the actual bytes, then the rest of the program. Then there
would still be two problems:
1) How does the decompressed program access the those saved bytes?
2) How does a programmer actually specify the number of bytes to save and
their starting value when writing the program?
For problem #1, the decompressor could place those bytes immediately before
the start of the decompressed program. That way, the program could access
them by taking PROGRAM_ADDR and subracting the neccessary offset instead of
adding it. (There is still the question of how to allocate the memory to
put the decompressed program in, unless this whole project waits for ZS4.5. :-)
For problem #2, one possible way of doing this could be to have the
compressor (running on the computer) actually ask the user how many bytes to
save and what their initial value should be. A better way would be to put
it in the ASM source, but I do not know how the compressor would extract it
correctly.
Sorry for rambling, :-) but this idea of compression looks to useful to pass up.
Ben Shakal
shakal@ns.net
Follow-Ups:
References: