| |
Knight Rider
Registered: Mar 2005 Posts: 116 |
If it were 1987 again....
I was watching Robin's video https://youtu.be/yVtKKb3wkYc regarding cracking from an original cassette. And it stirred a little interest in me again. To be honest I can't even remember how now but I cracked Wizball from original cassette using a Trilogic Expert (2nd version with botched ESM daughter board) and very likely V2.9 of the monitor software.
I did this again now on real hardware (as I wasn't having much luck with WinVICE 3.7), just for laughs and to try to stir up memories of way back then. Defeating Freeload now was much easier for me than back then.
I used the following packers:
MCC Compressor
then
Card Cruncher V4 (no idea who lent me this cartridge, but probably Tork&Torky)
(usual one was Matcham Time Cruncher V3.1 or a hacked version which ended up becoming Time Cruncher V3.1)
I ended up with 182 blocks incl. intro in Wizball
So it leads me to the next question, back in the day (for me) the best cracks had the smallest disk block size.
What packers did you use then on a real C64 in 1987, and what would you use now on real hardware (a. released upto 1987 and then anytime). What block size can you achieve ?
Exomizer V3.02 gives 144 blocks when no additional parameters are given.
TRIAD Wizball + is 166 with intro
Krejzi Packer $005E-$FFFF + Matcham Time Cruncher V3.1 gives 161 blocks
MCC Compressor + Matcham Time Cruncher V3.1 gives 165 blocks
Beast-Link/64k + Byte Boiler 256k V1.0 gives 148 blocks
Byte-Buster V4.1 + Byte Boiler 256k V1.0 gives 148 blocks |
|
... 84 posts hidden. Click here to view all posts.... |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1381 |
Ah, true - I missed the REU part somehow.
Still, very cool. |
| |
Knight Rider
Registered: Mar 2005 Posts: 116 |
The packers took 253 to 217 blocks and then the REU cruncher did the rest |
| |
Bacchus
Registered: Jan 2002 Posts: 154 |
First - I have done a Fairlight Tv video on tape cracking as well, and there will be another one that also shows the production of a tape transfer. Available on friday.
I have gone through multiple stages of RLE + Cruncher.
Back in the days, on the native platform, any RLE + CruelCrunch was second to none. Easily 8 hours of crunch time but still the best result.
I then moved to EBC + DarkSqueezer 4 (for the REU support)
Last was the Skyflash range of crunchers - The AB Crunch and those.
Then I moved to PC and used Exomizer.
/Bacchus |
| |
Martin Piper
Registered: Nov 2007 Posts: 645 |
Currently the smallest I can compress a working Wizball to is 147 blocks. 37527 prg file bytes |
| |
Knight Rider
Registered: Mar 2005 Posts: 116 |
Quote: Currently the smallest I can compress a working Wizball to is 147 blocks. 37527 prg file bytes
Tell more.... which cruncher |
| |
iAN CooG
Registered: May 2002 Posts: 3137 |
Quote: Currently the smallest I can compress a working Wizball to is 147 blocks. 37527 prg file bytes
wizball_ripped.6389 │ 64258
dali 0.3.2 small
wizball_ripped.dali-s.prg │ 35314
In this case it's even better than Exo 3.11, but it's not a guarantee, always test both.
Why bothering using surpassed packers & crunchers =) |
| |
ws
Registered: Apr 2012 Posts: 229 |
on isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack) |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1381 |
Well, truly random data is uncompressible by definition. The fun part would be getting the game to care if the random data has been tampered with (eg zeroed out, or replaced with some pseudorandom data that looks like noise but is easy to regenerate with a small code fragment) |
| |
Boogaloo
Registered: Aug 2019 Posts: 21 |
Quote: on isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack)
Wasn't that pattern used to detect the parts or RAM that were untouched? |
| |
Bansai
Registered: Feb 2023 Posts: 34 |
Quoting wson isepics and some other freezes i noticed that ram was actually entirely filled with "garbage" (noticeable through repeating patterns and garbage in areas that were actually unused by the code).. my guess was, this was done to hamper any repack effort.
are there famous tools that attempt to create "uncrunchable" data?
would it be possible to fill ram with a pattern that would serve as some kind of "freeze+crunch" protection, even for exomizer?
(i always tried and cleaned those files manually for repack) I might be misremembering, but I thought some of the early freezers had a mem prep phase prior to loading of the protected software where they wrote some kind of well-defined pattern (to the freezer, that is) to tag uninitialized mem so they could spot the patterns at freeze time to identify usable working areas for the unfreeze code to work out of and use. |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |