| |
iAN CooG
Registered: May 2002
Posts: 3142 |
Release id #70940 : Exomizer v2.0beta7
didn't want to clobber the comments, better move this in forums:
Quote:
has anybody tested this one for viruses yet?
What the hell does this mean? Making viruses packed by exomizer or checking for presence of viruses inside the prebuilt exes? =) |
|
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
i tried packing an apple virus with exo. it worked. i would try with a cc64 virus, but i don't has any. wans't there a post about those? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I think this is bugged..
It has in the begin of the depacker this:
inc $01
tsx
lda 797a,x
...
...
thats pretty crap, as it cannot be sure what 01 is before doing the tsx.
i cant get my stuff working here, after a transfer in ram.
it only works on normal load from cold booted machine. |
| |
MagerValp
Registered: Dec 2001
Posts: 1060 |
No, the ram transfer routine is buggy. It should set $01 to $37 before launching apps that load at $0801.
|
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
Also make sure Stack Pointer is $f6 or more, if less expect the depack fail. As MV said, it's up to you to provide a correct environment for the depacker to work correctly because it assumes to be working from the direct mode after a load. You can always try other crunchers if Exo doesn't fit your needs, there is a shitload, hardly any crunch better than Exo but if you don't care saving every possible byte go with Pucrunch... no wait, weren't you using only native crunchers because you didn't want to use cross tools????? :D |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: Also make sure Stack Pointer is $f6 or more, if less expect the depack fail. As MV said, it's up to you to provide a correct environment for the depacker to work correctly because it assumes to be working from the direct mode after a load. You can always try other crunchers if Exo doesn't fit your needs, there is a shitload, hardly any crunch better than Exo but if you don't care saving every possible byte go with Pucrunch... no wait, weren't you using only native crunchers because you didn't want to use cross tools????? :D
It can't only be me who is doing things wrong..
I did the same as on all other multipart demos i ever made, and this one kept failing, this and that cruncher destroyed music, text etc. so in the end i decided to use exo, and even that fucks up LOL! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
clearly the crunchers fault then =) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Yes in fact, yes groepi.
This demo uses 99% RAM, and then its funny that 10 different crunchers all makes it fuck up, dont you think ?
It clearly shows, that when they promise "can crunch 00ff-ffff" is a lie! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
and clearly noone tried and noticed until now! |
| |
Zagon
Registered: Apr 2002
Posts: 14 |
You can control the $01 value the decruncher expects when starting and what value it will leave in $01 when exiting by defining the decruncher symbols i_ram_enter and i_ram_exit on the crunch-commandline.
example: -Di_ram_enter=$38
See the section "Reference for the sfx decruncher symbols" in exo20info.txt for more details about tweaking the behavior of the decruncher.
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote:Also make sure Stack Pointer is $f6 or more, if less expect the depack fail.
I'm currently decrunching from memory with SP relocated to $50, and it's worked with my test data. You're saying it's unreliable? :-( |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
The user shouldnt be doing anything.
A crunched prg should always work when run with 01=37
Here is what an anonymous guy wrote me:
-
I have also had the same crunch problems you talk about. I Noticed it a few years back when AB Cruncher and "The Cruncher" did not work. Tried other versions, but still got the same bugs when depacking. Then I changed the file somwhat and used more zeroes and other stuff and it worked.
I don't think it is a bug not with $01, etc. but perhaps that the crunchers crunches the data wrong, so when the decrunch routine tries to decrunch it, it just generates stupid data? But I have not checked the code or anything so I cannot be certain.
-
And to all this i can say, i tested all the 'good' crunchers that people recommended. byteboiler, cruncher ab, sledgehammer 2, whatever whatever, it was over 15 - and none of them works with a prg that has data from 0810-FFA8 (full ram), AND THATS THE END OF THE STORY!
|
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
You're just not good at it, fact is that you have to know what you're doing on C64, and considering the years you've been involved with this computer you should know this perfectly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
Quote:A crunched prg should always work when run with 01=37
why exactly do you think crunchers have this option? because it always works without it anyway? =) |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
It's always possible, that you have uncompressable data at the end of the memory and the needed safety margin isn't large enough to properly decrunch the data. Try to find an empty page in your file and move the page after decompression to $FF00 to $FFFF before exectution. Another solution is to use a good and safe rle packer before crunching with exomizer or pucrunch. |
| |
tlr
Registered: Sep 2003
Posts: 1737 |
I thought it checked the safety margin and added a wrap buffer if necessary?
I believe pucrunch does that at least. |
| |
Zagon
Registered: Apr 2002
Posts: 14 |
Quote:I'm currently decrunching from memory with SP relocated to $50, and it's worked with my test data. You're saying it's unreliable? :-(
The sfx decruncher copies itself to the start of the stack. The SP needs to be outside of that area, otherwise the decrunch won't work. If you're not using the sfx decruncher then you're safe.
Quote:I thought it checked the safety margin and added a wrap buffer if necessary?
It does. exomizer decrunches backwards so the safety buffer is before the data and no wrapping occurs.
|
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
I've crunched a shitload of games ranging $0400-ffff with exomizer without problems. Of course you have to make sure that you don't call fd15/fd50 in the previous intro/part;
if the decrunched code expects a clean ZP/stack/vectors at $0300, you HAVE to put them somewhere in the memory and restore them by hand with additional code. Using a zp packer like IDIOTS Fx Bytepacker V2.1 you CAN pack memory from $32 to ffff without loosing a single byte.
Check my release of Drax Evilblood Preview +2 , I did exactly that to ensure everything worked correctly after depack. |
| |
tlr
Registered: Sep 2003
Posts: 1737 |
Quoting iAN CooGI've crunched a shitload of games ranging $0400-ffff with exomizer without problems. Of course you have to make sure that you don't call fd15/fd50 in the previous intro/part;
Mistakingly corrupting $fd30 by calling $fd15 is just too classic. :) |
