This morning I was under the shower and I was wondering what algorithm did the C64 packers use... it must be a very tiny thing (but that's not a great issue with 8bit instructions) able to decompress stuff in place (no disk swapping of course) and booted from the BASIC space maybe? But I vaguely recall the ,1 parameter in LOAD"*",8,1 to be used to load directly executable code or something like that...

Another suspect I had is that decompressing probably ended up eating the BASIC interpreter memory (was it copied to ram on boot? why those 38911 bytes free at startup otherwise?) and some video memory too maybe? There are a lot of games that throw trash on the screen once loaded, before starting... so I guess the video memory was shared.

So, is it some kind of weird, quick and dirty algo? Or just a stripped down Huffman or LZ? Just out of curiosity.. I am still awed to see how many pirate intros with music and gfx fit, together with the game, in a 120-block file or so :P

Thanks in advance :)

load "*",8,1 just tells it to load the file to where it was saved from, if you miss out the ,1 it assumes it's a basic program and loads to the delevant address ( 2049 for c64 programs, it's different for c128's, pet's etc ).

The early crunchers were just run length encoding of duplicate bytes.

Later ones do all manner of things: http://www.cs.tut.fi/~albert/Dev/pucrunch/

quite often screen memory is used for storing the depacker or variables as the program you have packed doesn't usually need to be loaded there.

smf

> quite often screen memory is used for storing the depacker or variables as the
> program you have packed doesn't usually need to be loaded there.

That was common with Apple II crunchers and fastloaders as well. Made the screen look really odd while things loaded :)

> This morning I was under the shower and I was wondering what algorithm did the
> C64 packers use... it must be a very tiny thing (but that's not a great issue
> with 8bit instructions) able to decompress stuff in place (no disk swapping of
> course) and booted from the BASIC space maybe? But I vaguely recall the ,1
> parameter in LOAD"*",8,1 to be used to load directly executable code or
> something like that...
>
> Another suspect I had is that decompressing probably ended up eating the BASIC
> interpreter memory (was it copied to ram on boot? why those 38911 bytes free at
> startup otherwise?) and some video memory too maybe? There are a lot of games
> that throw trash on the screen once loaded, before starting... so I guess the
> video memory was shared.
>
> So, is it some kind of weird, quick and dirty algo? Or just a stripped down
> Huffman or LZ? Just out of curiosity.. I am still awed to see how many pirate
> intros with music and gfx fit, together with the game, in a 120-block file or so
> :P
>
> Thanks in advance :)
>
>

> That was common with Apple II crunchers and fastloaders as well. Made the
> screen look really odd while things loaded :)

Oh, THAT'S why it was always so funky!
Interesting to remember that with a whole different perspective...




[download a life]