| |
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? =) |
|
... 10 posts hidden. Click here to view all posts....
|
| |
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: 11165 |
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. :) |
| Previous - 1 | 2 - Next |
