| |
Krill
Registered: Apr 2002 Posts: 3003 |
Release id #216394 : TSCrunch 1.3
"Thanks to Krill for pushing me to squeeze that one last CPU cycle out of the decruncher and for adding TSCrunch to the list of crunchers supported by the Krill Loader."
My pleasure. :)
Here are some current figures (next loader release soonish):

So TSCrunch is now the first choice when going for performance, and that regardless of CPU load for other tasks concurrent to loading+decrunching. :)
If you need the size, ZX0 is your friend, as it's well-balanced with compression ratio on par with Exomizer 3, but so much faster decompression.
In-place decompression and loader+decruncher fitting at $0200-$0400 go without saying. |
|
| |
WVL
Registered: Mar 2002 Posts: 907 |
Now this is going somewhere! Should really open up some possibilities! |
| |
6R6
Registered: Feb 2002 Posts: 246 |
Just wondering - Does the
.label tsput
give the exact end adress after depack/decrunch at all times ? |
| |
tonysavon
Registered: Apr 2014 Posts: 25 |
Quote: Just wondering - Does the
.label tsput
give the exact end adress after depack/decrunch at all times ?
Yes, but only if you are not decrunching inplace. If you decrunch in place it gives you the end of the data that was decrunched, but there can be an uncompressed remainder that was not overwritten. |
| |
6R6
Registered: Feb 2002 Posts: 246 |
Okay, a different approach:
(I need to know the end address of inplace crunched files)
When you load the file from disk to the load address given by the file - the end address will also be the end address for the decrunched file. right ? Or will this also have a remainder ? |
| |
tonysavon
Registered: Apr 2014 Posts: 25 |
Quoting 6R6Okay, a different approach:
(I need to know the end address of inplace crunched files)
When you load the file from disk to the load address given by the file - the end address will also be the end address for the decrunched file. right ? Or will this also have a remainder ?
Yes in that case you load the file to disk decrunching on the fly the crunched part and then copying the reminder, so the last byte copied should be the last byte both of the crunched and the decrunched file, so the end address of the inplace crunched file.
I guess @krill can confirm, just to be double sure :-) |
| |
Krill
Registered: Apr 2002 Posts: 3003 |
Yes, in-place decrunching files end exactly where their uncompressed counterpoarts end.
The tsput pointer then points to the last byte (not the next one beyond it) after decrunching, where the crunched file's end-of-file token was overwritten with the final payload byte. |
| |
Richard
Registered: Dec 2001 Posts: 621 |
During the start of this year. I tried to use TSCrunch V1.3 on some games that used zeropages. There have been issues where zeropages didn't get restored to how they should. The good news is that the latest build of the TS Crunch V1.3 actually fixes that. You will need to use the Github binary version, which fixes this:
The new command for this is:
tscrunch -x2 $jump addr gamesource.prg gametarget.prg
I used this version of the cruncher for Synthia 2 (If I recall correctly). |
| |
iAN CooG
Registered: May 2002 Posts: 3210 |
The new github binary (as of 2 jan 2023) generates different binaries than 1.3 (and adds even 2 more variants by using different parameters) so it would be better increasing the version at least to 1.3.1 |
| |
Burglar
Registered: Dec 2004 Posts: 1114 |
Quoting iAN CooGThe new github binary (as of 2 jan 2023) generates different binaries than 1.3 (and adds even 2 more variants by using different parameters) so it would be better increasing the version at least to 1.3.1 Of course the binaries differ, but let's not use csdb as git commit history :D
I guess a new release version will come when Tony is ready. |
| |
iAN CooG
Registered: May 2002 Posts: 3210 |
> Of course the binaries differ, but let's not use csdb as git commit history
I don't get what's funny. For the sake of completeness, with "binaries" I meant "The generated crunched prg files", not the executable binaries of the cruncher itself.
In this moment there are 2 tscrunch 1.3 that produce different outputs.
It should be important to increase the version number when a program changes completely its output. I was only suggesting this. That's it. Hopefully it's clearer what I meant. |
... 4 posts hidden. Click here to view all posts.... |
Previous - 1 | 2 - Next |