Re: LZ: Compression program


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

Re: LZ: Compression program



The programs that weren't written to support this just wouldn't
keep high scores if they were compressed.  The user could decide
if he wanted compression or high scores for those programs.


Barry


On Sun, 8 Sep 1996, Scott J. Rein wrote:


> At 06:51 PM 9/8/96 -0500, you wrote:
> >On Sun, 8 Sep 1996, Ben Shakal wrote:
> >
> >> >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?
> >
> >Find the address of the compressed program string and write into
> >the decompressed portion.  This should be fairly simple.
> >
> >>    2) How does a programmer actually specify the number of bytes to save and
> >> their starting value when writing the program?
> >
> >The programmer wouldn't have to worry about it.  All programs would
> >be compressed beginning at a certain offset and the bytes before that
> >would be uncompressed.  That offset would be the same for all programs.
> >
> >> 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. :-)
> >I may be mistaken but I think PROGRAM_ADDR gives you the address
> >of the executing program, which would be the decompressed program.
> >The address of the compressed string is what would be needed.
> >
> >> 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.
> >
> >That could be done by imbedding the number in, say byte 3 of the
> >executable.  But that would only work for new programs so it wouldn't
> >really be practical.  The sensible way is to have a fixed number of
> >uncompressed bytes for all programs.  It would waste a few bytes per
> >program, possibly, but would save a lot more bytes in the reduced code
> >for the decompressor.  It also avoids the temptation some programmers
> >might have to leave large uncompressed areas for whatever reason.
> 
> You guys are speaking as though every program will have to be tailored to
> the compression program.  Well, actually that is true.  I will (if I ever
> make the damned program) set it up so that if the program is set to my
> standards for high scores, etc. it will accept it.  Otherwise, do you people
> like seeing your names that badly???  :)
> 
> --	Scott Rein
> 	srein@rain.org
> 
> 


References: