| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Native crunch/decrunch code.
Do you know if the source code of a native crunch/decrunch routine for C64 exists somewhere?
Not a complete utility with interface etc...
just the compression/decompression code. |
|
... 13 posts hidden. Click here to view all posts....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting KrillWhy would you want to crunch natively?
And if you really must, why do you need the source code?
Just pick apart any of the crunchers from the olden days.
I have a program running, from $3000 to $FFFF that modifies itself.
I would like the user to be able to save a stand alone version.
I managed to get the working sources of Fast Cruncher 5.09 but as soon as I change a small thing I create a lot of problems.
I would like to avoid unnecessary waste of time by using existing code... if it exists somewhere.
that's all. |
| |
tlr
Registered: Sep 2003
Posts: 1727 |
Quote: No.
Preferably it should use little ram but I have some headroom to adapt.
Then I’d go for a simple RLE. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting tlrThen I’d go for a simple RLE. Indeed. Native LZ-style crunching would take hours like it did in the olden days.
RLE is not nearly as crunchy, but fast and might fit the bill, too. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Thank you!
If you can provide me with something I hope to be able to use it properly. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting FlaviowebIf you can provide me with something I hope to be able to use it properly. https://codebase64.org/doku.php?id=base:rle_pack_unpack perhaps. |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
Quote: Quoting FlaviowebIf you can provide me with something I hope to be able to use it properly. https://codebase64.org/doku.php?id=base:rle_pack_unpack perhaps.
I’m not the person for this, but, that code on Codebase64 looks a bit long for just RLE pack/depack doesn’t it..? It seems like something that could be coded with a really tight loop… |
| |
tlr
Registered: Sep 2003
Posts: 1727 |
Quoting RaistlinI’m not the person for this, but, that code on Codebase64 looks a bit long for just RLE pack/depack doesn’t it..? It seems like something that could be coded with a really tight loop…
Also it's missing the requested executable binary generation. I have some RLE code here, but that is for streamed input from disk which may not be optimal for this usecase. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11149 |
mmmh i remember some simple packer from the past... it loaded to $03xx-$0800 and was super easy to include in own programs (which many people did, i also used it for some "intromaker" stuff iirc). No idea how it was called though, maybe someone remembers... :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
For simple RLE, it should be relatively simple to write two position independent routines. One to compress a block of memory to an address, and the other one to decompress data to an address.
The decompression especially could then be copied to anywhere and just pointed at the data to decompress. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
I have collected some ideas in the last few days and I think I have reached a good compromise (at least on a theoretical level).
The "pure" RLE compression didn't convince me very much because, in practice, it doubled the space required for the code to be compressed, but it works well for the data part.
In my specific case I know the location of both the code and the data so I can create an ad hoc compression routine that compresses the data and leaves the code unchanged.
To overcome the problems of lack of RAM, I can save the compression result directly on disk while it is being processed, preceded by the decompression code so as not to worry about creating the entire file in ram before saving it.
It should work. I hope. |
| Previous - 1 | 2 | 3 - Next |
