| |
Krill
Registered: Apr 2002
Posts: 2989 |
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. |
|
... 4 posts hidden. Click here to view all posts....
|
| |
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: 2989 |
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: 3207 |
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: 1106 |
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: 3207 |
> 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. |
| |
Burglar
Registered: Dec 2004
Posts: 1106 |
Quoting iAN CooG> 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. okok :) I still thought it was funny. and I get your point, I keep important dev versions with unique version numbers too and bump after release immediately. |
| |
spider-j
Registered: Oct 2004
Posts: 503 |
I'not sure if I should put this in the goofs section, but on linux the Python and Go versions do behave differently when providing the start address as hex number for the -x option:
tscrunch -x 0x3b53 framework.o framework.prg
It works with Python, but not with Go.
After looking into the code:
Imho you shouldn't parse that param as string just to allow that C64 style of hex numbers starting with $ behaviour.
On linux you can't just use $3b53 without escaping the $ sign anyway and the 0x prefix should work perfectly fine on windows and linux.
An integer should be an integer.
Just my 5 cents.
Anyway: after finally converting my demo framework for usage with tscrunch instead of exomizer I must say, this one is really nice. The -i option is so easy and straight forward and automagically produces files that can directly be fed into the krill loader. Cool! |
| |
Burglar
Registered: Dec 2004
Posts: 1106 |
Quoting spider-j
tscrunch -x 0x3b53 framework.o framework.prg
It works with Python, but not with Go.
After looking into the code:
Imho you shouldn't parse that param as string just to allow that C64 style of hex numbers starting with $ behaviour.
On linux you can't just use $3b53 without escaping the $ sign anyway and the 0x prefix should work perfectly fine on windows and linux.
An integer should be an integer.
Just my 5 cents.
agreed, I hacked it into my fork, so it supports all. but yes, the clean way is indeed using an int and not supporting $xxxx
https://github.com/staD020/TSCrunch/commit/7d8d1ddd3819dd863132.. |
| |
spider-j
Registered: Oct 2004
Posts: 503 |
Quoting Burglaragreed, I hacked it into my fork, so it supports all. but yes, the clean way is indeed using an int and not supporting $xxxx
https://github.com/staD020/TSCrunch/commit/7d8d1ddd3819dd863132..
Cool. Thanks for pointing me to your fork! |
| Previous - 1 | 2 - Next |
