| |
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 |
|
| |
Bansai
Registered: Feb 2023
Posts: 36 |
Quoting Knight RiderWhat 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 ? How aggressive for size reduction does someone want to go and how much time is to be spent on it? It's not completely a question of the compressor used. Unused bytes can be blanked out and an instrumented emulator can be used to identify and tag them in a manner similar to that found in the the table that sidreloc outputs. For example, if a music player doesn't use its entire frequency table or its complete set of commands, those code/data bytes are unreachable and can be zeroed out, saving space in the compressed version. |
| |
hedning
Registered: Mar 2009
Posts: 4618 |
Make a super small intro, and win the battle. And add trainers. |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
That small-size craze (due to modem trading, presumably) made for a lot of bad cracks missing loader screens and game intros and such, though. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Quote: That small-size craze (due to modem trading, presumably) made for a lot of bad cracks missing loader screens and game intros and such, though.
Maybe, but for me back in the day it was to fit as many games on one disk and possible about faster loading times.
I found some similar or relevant forum threads
History of Crunchers & Packers
What Packers and Crunchers?
which both reconfirm the findings above.
So the 1987 solution would probably have been MCC Compressor + Matcham Time Cruncher V3.1 and the best C64 packing would have been Byte-Buster V4.1 + Byte Boiler 256k V1.0 |
| |
6R6
Registered: Feb 2002
Posts: 244 |
The two byte packers was released in the 90's. Using them in 1987 would be cheating! |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Quoting 6R6The two byte packers was released in the 90's. Using them in 1987 would be cheating!
Both are 1987 ?
Quoting Knight Rider
So the 1987 solution would probably have been MCC Compressor + Matcham Time Cruncher V3.1
|
| |
TheRyk
Registered: Mar 2009
Posts: 2101 |
But Byte Boiler 256k V1.0 (1994) and Byte-Buster V4.1 (1997) ain't 1987, that's why it's a little confusing to find them in your list and even in your "1987 solution" |
| |
Ziaxx
Registered: Oct 2020
Posts: 15 |
Not confusing at all as he clearly asked in the first post what packers/crunchers you used back in 1987 AND what your choice would be if you could pick ANY packers/crunchers ever released (new or old) on real hardware (ie no Windows stuff etc)... |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Correct |
| |
TheRyk
Registered: Mar 2009
Posts: 2101 |
_NOW_ it's clear :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
What are you crunching that you are getting down to 144 blocks using exomiser?
If I start with the release at Wizball (a 46099 byte .prg) and unpack it with unp64 I get a 47098 byte .prg that exo 3.1 only crunches down as far as 42235 bytes (166 blocks). I'm clearly missing something :) |
| |
Bansai
Registered: Feb 2023
Posts: 36 |
Quoting Knight RiderCorrect Do you have the uncompressed version of that data (e.g., a 202 block or greater sized PRG starting at $0801) you can throw on MEGA or somewhere that can be downloaded and used for comparison? I have a couple of compressors/crunchers/squeezers I wrote in 89 that I recently found the prg and sourcecode for that I'd like to compare compression ratios against what was in common use back then.
At this point, running VICE in warp mode makes running C64-native compressors on big files a lot more tolerable, though I prefer PC-native utils when possible, simply because they're incredibly faster.
EDIT: OK, I didn't look at preserving the intro, but if you set a breakpoint in VICE for $0820 to stop before the Fanatic Duo decruncher, you can save memory from $0801-$DFA9 and that looks like it's the whole game. Exomizer 3.01 (as I have it laying around) for me without tweaking gets 149 blocks, pucrunch delta gets 158. There are a couple of stacked compressors in there so I'm not quite sure of the results you got simply because I don't know how much those 1001 compressors can inhibit compression ratio. It's definitely interesting seeing how far compression has come. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Here is the extracted game from original tape (0400-feff g 6389), exomized version and most of the packed+crunched versions
https://mega.nz/file/4oNQQBjL#fgGm7b6gO_PaoovDglS_3fuvzX4SJy8AP..
As you will see the packers got the 253 block ori down to 217-223 blocks. Then the crunchers got down to 148-16x depending on the one chosen.
Code this is how I stopped the original from starting (I already knew that the files spread 0400-feff). The saved the memory to 1541.
* = $1000
jsr $f72c ;Read program header off tape
ldx #<TREX1
ldy #>TREX1
stx $03ee+1 ;.C:03ee A9 00 LDA #<$0800
sty $03f3+1 ;.C:03f3 A9 08 LDA #>$0800
jmp $F56C ;Read rest of program off tape
TREX1
lda #$00
sta $09a0 ;.C:09a0 20 48 45 JSR $4548
- lda $09a0 ;.C:09a0 20 48 45 JSR $4548
beq -
lda #$18 ;ie CLC
ldx #$90 ;ie BNE -2
ldy #$fd ;ie BNE -2
sta $099d ;.C:099d 4C 89 63 JMP $6389
stx $099e ;.C:099d 4C 89 63 JMP $6389
sty $099f ;.C:099d 4C 89 63 JMP $6389
jmp $0800
|
| |
spider-j
Registered: Oct 2004
Posts: 450 |
If you guys compare against exomizer you really should all use the same (imho most recent) version. Doesn't make sense when someone uses 3.01, another one 3.02 and the third one 3.1.
Did just a quick test here with recent 3.1.1 vs. the version by Knight Rider:
[spider@misery wizball_knightrider]$ ls -Al wizball_exo*
-rw-rw-r-- 1 spider users 36391 20. Jul 15:39 wizball_exov3.02.prg
-rw-rw-r-- 1 spider users 35686 23. Jul 11:15 wizball_exov3.1.1.prg So of course the results will be different when not using the same version. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: Quoting Knight RiderWhat 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 ? How aggressive for size reduction does someone want to go and how much time is to be spent on it? It's not completely a question of the compressor used. Unused bytes can be blanked out and an instrumented emulator can be used to identify and tag them in a manner similar to that found in the the table that sidreloc outputs. For example, if a music player doesn't use its entire frequency table or its complete set of commands, those code/data bytes are unreachable and can be zeroed out, saving space in the compressed version.
Expert has been brilliant tool for cracking back in a day, especially tape games, for disk releases the lack of build-in turbo and disk drive monitor it could be harder to use than ActionReplay IMHO. Very few protection could kill Expert freeze and sometimes this was just a side effect of how NMI and IRQ were used by game code for effects.
Expert had all the commands like # and J in v2.9 to get file size, make SYS to lead header etc.
As a side note could elaborate more on what you mean by botched ESM daughter card please? Are you referring to addition of ESM button to the cartridge, so you didn't have to relay on RESTORE keyboard button only? |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
I posted pics here https://www.lemon64.com/forum/viewtopic.php?p=995493#p995493 |
| |
Bansai
Registered: Feb 2023
Posts: 36 |
Quoting Knight RiderHere is the extracted game from original tape (0400-feff g 6389), exomized version and most of the packed+crunched versions
https://mega.nz/file/4oNQQBjL#fgGm7b6gO_PaoovDglS_3fuvzX4SJy8AP..
[/code] Thanks for posting those. The file size alone is great for seeing if a packer will crash or if decrunch on run fails. Fortunately (you'll laugh), my old LZ-compressor generates 190 blocks which means I'll get to revisit compression theory in the future for personal experience gain on that topic as I'm sure how I encoded matches back in 89 can be greatly improved. :-)
Exomizer puts in a very good showing even versus modern tools such as gzip and xz, which is especially amazing given the decompressor is in the final byte count for Exo. It was actually smaller than bzip2. Of course, Exo is a modern tool...
One observation for me that I forgot about from all this is that in looking through old intros attached to these packers, I saw some of them in order to have some form of audio would have an ominous filtered flanging drone accompanying the intro scrolltext. That's one way to save on byte count. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
I didn't have any freezer/monitor/debug cartridge so I had to do it the old fashioned way of working through each code stage and disassembling. Funnily enough I just did a video about reverse engineering tape loaders: https://youtu.be/e9iU-OoIDwQ?t=1137
I show how I used to use IRQ hooks to tweak the Wizball tape auto-start code so it could be inspected. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quote: Quoting Knight RiderHere is the extracted game from original tape (0400-feff g 6389), exomized version and most of the packed+crunched versions
https://mega.nz/file/4oNQQBjL#fgGm7b6gO_PaoovDglS_3fuvzX4SJy8AP..
[/code] Thanks for posting those. The file size alone is great for seeing if a packer will crash or if decrunch on run fails. Fortunately (you'll laugh), my old LZ-compressor generates 190 blocks which means I'll get to revisit compression theory in the future for personal experience gain on that topic as I'm sure how I encoded matches back in 89 can be greatly improved. :-)
Exomizer puts in a very good showing even versus modern tools such as gzip and xz, which is especially amazing given the decompressor is in the final byte count for Exo. It was actually smaller than bzip2. Of course, Exo is a modern tool...
One observation for me that I forgot about from all this is that in looking through old intros attached to these packers, I saw some of them in order to have some form of audio would have an ominous filtered flanging drone accompanying the intro scrolltext. That's one way to save on byte count.
Thanks a lot. I have never seen this add-on, only heard about it up to today. Indeed this looks messy ;) |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
This will be the 3rd incarnation of the Expert. The 2nd needed a passthrough as seen in this pic (for 7.95):
https://rr.pokefinder.org/wiki/File:Your_Commodore_Issue_27_198..
The guy that recommended me the Expert had this version with expansion and he was pissed that I got the newest version. He went under the name Sputnik IV of XYZZY cracking, but there is no entry of the user or group on CSDB.
Also see here for the timeline of the 4 versions
https://rr.pokefinder.org/wiki/Hardware |
| |
chancer
Registered: Apr 2003
Posts: 346 |
funny you mention tork & torky, were they uk folks ? reason I ask I remember having 2 things from them , a compunet sending program and a sampler packer program IRC.
as for expert, I liked how it dealt with $0400 etc vs action replay.. and long before that how it packed games vs rivals.
not a fan of how the expert is in vice tbh.. which i find a shame, AR6 etc is far nicer / easier
I did upload the Mad mekon version of the expert software years ago. screen blanking in defreezing etc. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Tork&Torky are from the UK. I visited them a few times in Greater Manchester. They cross assembled at the time from a C128 connected by cable to a C64. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
Quoting Knight Rider
Beast-Link/64k + Byte Boiler 256k V1.0 gives 148 blocks
Byte-Buster V4.1 + Byte Boiler 256k V1.0 gives 148 blocks
Wait, is that compressing the full 253 block original? or something that's been trimmed down a bit? Because those ratios are seriously impressive for native tools. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Byteboiler was that good (remember: REU, that makes some things easier :)) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
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: 647 |
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: 3141 |
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: 235 |
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: 1382 |
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: 36 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: 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.
Some used to, but games started to test for this and fail. So eventually some used other methods, like tracking where RAM was written by using external RAM. :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Tell more.... which cruncher
Using this one with -c64b option: https://github.com/martinpiper/C64Public/blob/master/bin/LZMPi... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:So eventually some used other methods, like tracking where RAM was written by using external RAM. :)
There is no freezer that does this (it can't be done in the first place, not with classic cartridges anyway). There are easier and much more effective ways to protect against freezing too :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Quote:So eventually some used other methods, like tracking where RAM was written by using external RAM. :)
There is no freezer that does this (it can't be done in the first place, not with classic cartridges anyway). There are easier and much more effective ways to protect against freezing too :)
No hardware *that you know of* you mean...
Professional hardware debuggers could, back in the day.
Then even a few years ago there were things like this: https://www.lemon64.com/forum/viewtopic.php?t=75387
"64K ram spy mode:
all bus writes are stored on ram, so you can save memory to flash or to the upper 64K of the 128K ram"
etc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:No hardware *that you know of* you mean...
Professional hardware debuggers could, back in the day.
Oh boy >_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Yes, there were all sorts of debug systems back then. An in-circuit emulator (ICE) was really quite rare and expensive, but it would be able to tell you what the CPU was doing, or stop of a hardware breakpoint at a specific address. Even more fancy would be the ability to constantly record the RAM data bus and see what the memory was doing, which given enough debug RAM would be capable of recording the usage of the entire address range. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
No shit. I know all that. This is not "freezer" though. And its not what those pathetic ram-pattern detectors were trying to defeat either. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
It is a freezer, in the sense it can record RAM allowing it to be analysed, compressed and restored with self extracting code later on. It's just tools to do a job. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Yeah, whatever floats your boat >_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Yeah, whatever floats your boat >_<
I cannot help it if you lack the knowledge and imagination to provide factually accurate information about specific topics. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Yes, that's it! >_< |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
While we are debating memory freezeres definitions it would be worth mentioning that C128 via particular MMU configuration allowed to enter C64 mode, load program into memory, reset system, enter C128 mode and monitor and crack it from there if I remember correctly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Thats only slightly better than regular "reset cracking" though. But sure, people used that :) |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Sledgehammer 2 for RLE, Squeezer for crunching, usually an REU version from Antitrack for speed. Level Squeezer for level crunching levels.
Moved to AB Cruncher then Byteboiler. Level AB2 or Level Crusher later. Along with my own packers.
On PC used PUCruncher, then Exomizer.
Bacchus interesting, I'll have to look that up. I've considered doing videos on how to crack stuff, but I figured most of the world would find that extremely boring, haha.
Martin you have the biggest case of Dunning Kruger I've ever witnessed. Look, if you weren't there, have photos of, or used such systems back then which you already admitted you didn't, then hush and quit arguing with straw man nonsense and hypothesis.
SoftICE was a PC thing (and buggy as hell), not for 8 bit computers. Any kind of such hardware like that possibly existed, was in house only. A bunch of kids churning out budget titles for tape houses barely could afford a computer and disk drive let alone such development hardware. That kind of stuff didn't become normal until the 90s unless you were Nintendo or Atari using VAPS machines. Surely not for cracking games. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Fungus you don't seem to know I worked in the games industry where I used all sorts of hardware debuggers, including ICE systems. The older dev software and hardware was still very much available. So yes, I was there. That's how I know about this stuff. I don't know what you think "I admitted" because I didn't. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
You literally said you didn't have a freezer cart.
You weren't working as a software dev back then.
I don't get why you always argue with people about everything, and have to be right, and have to prove you're smart or something. It comes off really bad, and ME saying that is something...
Groepaz is and was a professional developer too, as are MANY MANY people here.
If you want some respect, try showing some.
Also not everything is about you and your experiences.
Back to on topic now, thanks. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: You literally said you didn't have a freezer cart.
You weren't working as a software dev back then.
I don't get why you always argue with people about everything, and have to be right, and have to prove you're smart or something. It comes off really bad, and ME saying that is something...
Groepaz is and was a professional developer too, as are MANY MANY people here.
If you want some respect, try showing some.
Also not everything is about you and your experiences.
Back to on topic now, thanks.
You don't seem to understand how time works. I didn't have a freezer cart when I was 13/14, but a few years later when I started working for Argonaut I did have access to hardware memory debugging tools. So I know how this stuff works by direct experience with it, which means you're incorrect.
My direct professional experience outweighs your lack of experience in the games industry from back then. Enough said really. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Cross development, even back in 1987, wasn't that unusual either.
Andrew Braybrook developed Morpheus using AVMAC65 cross-assembler on an Opus PC, which would send assembled data over to the C128. That hardware was mostly built by Steve Turner experimenting with connecting machines.
If you look at page 163 of Byte July 1987 issue you'll see that AVMAC65 cost around $349, which back then was quite a chunk of change. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Your experience doesn't discount anyone else's experience.
I never argued they didn't exist. Quite the contrary. They were not available to users and sceners generally. It's a corporate thing, duh. By all means if you were cracking games and releasing them with that hardware great, I'm sure your competition really appreciated undermining their well being.
Can you engage in a discussion anywhere without making it about you?
You present your opinions as facts.
You seem to be seeking recognition and respect from people who couldn't care less who you are. You're in the wrong place for that, you clearly don't understand what "scene" means. You're a developer, not a scener and as such you don't belong here and your account should be deleted according to the whatever rules this forum chooses to adhere to when ever it suits it.
From a scener standpoint, you are nobody, a nothing. Maybe people on lemon are impressed with your diatribes but no one here is, trust me.
I'm engaging in a pointless debate with someone who has a clear mental illness and should seek help. I'm going to have to bow out of this and just ignore all your pointless self aggrandizing posts. It is clearly a waste of energy.
Have a nice life. Grow up.
I apologize to the staff and users for making this extremely off topic post and I sincerely hope they recognize what I am saying is not to stir shit, but stating that I've seriously grown tired of this type of off topic bickering and fighting by grumpy old men when this isn't the place for it. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Correction, you're trying to make it about me by trying to use personal attacks instead of technical ones. You should stop.
I'm just relating first hand experience of the games industry and development practices back then. The facts are facts, not opinion. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Now back on topic.
As for shortness of cracks there is more to this than just crunchers and packers.
Optimization is a big part of that. You can do this without breaking things and/or removing anything from the game.
1) You can optimize bitmap pictures to have more equal data which will compress better.
2) You can remove garbage from memory, like 00 00 FF FF 00 00 FF FF and other similar garbage that memory is randomly initialized with.
3) You can remove source code and tool remnants from things that get left when the machine was soft reset.
4) You can clean the last byte of sprites many times to create longer sequences of equal bytes.
These are cursory things that anyone can do. You can go deeper too.
5) You can re-arrange data in memory to be more compressible.
6) You can create run time macros to make code that has similar structures and patterns that are repeated, such as large loops and unrolled code to be much smaller than a cruncher could make it.
7) You can recode routines to be more efficient and smaller.
8) Many times in a multi file game "levels" can have a lot of like data that can be extracted into other files to reduce data redundancy.
9) You can use different hand done compression techniques to further compress internal data such as making use of unused nybbels and separating them at runtime.
A) You can create things such as sine tables, note tables, and other such mathemtically generatable data at runtime.
There are many many ways to reduce the overall size and optimization of just about anything. It depends on how much effort and time you want to put into it.
I've used some or all of these techniques in everything I've done over the years, and many more depending on the game/data.
I'm sure Krill and others can attest to these techniques as well and offer other examples and suggestions. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Back in 1987 I was 16 years old and I coded in a cartridge monitor and had a black an white TV. All of the things you mentioned where simply unknown to me. There was one guy who had a dot matrix disassembly of the KERNAL, he was considered the king for having such an asset. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
There is an easier way. The title screen to game level transition code stores new character data into $fc00 onwards. So that data can be safely ignored from the final compression.
This difference can also be seen by comparing the original Ocean release to the hitsquad release: https://youtu.be/e9iU-OoIDwQ?t=1750
The prg file offset is from $400 which is why it appears at offset $f902 (two bytes header) in the comparison. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
That's a non issue though, unless you are being lame enough to do reset cracking :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: That's a non issue though, unless you are being lame enough to do reset cracking :)
Not quite. The original Ocean tape release, with the loader screen and music, did load data up at the end of memory so when the game code was started it looked like "used data" so it would normally be included in a compressed release. Knowing the title screen to game level start copied in new data over that "used data" helps to reduce that data from the final compressed release. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Tell us more about proper cracking >_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Tell us more about proper cracking >_<
Given that many of the releases on here include superfluous data (which isn't trivial to compress either), and are therefore larger than they need to be, it's rather important to clarify what is superfluous data to enable the file to get smaller.
Even this recent release included extra data at the end of memory: Wizball 2012 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Are you saying bad crackers made bad cracks? WOW
(The screenshot police is sleeping?) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote:
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 =)
dali.exe --sfx $6389 -o c:\temp\wb.prg "C:\temp\wizball_ocean_6389_min.prg"
dali v0.3.2 - a zx0-reencoder
Compressing from $0400 to $fd00 = $f900 bytes
Creating sfx with start-address $6389
original: $0400-$fd00 ($f900) 100%
packed: $0801-$9140 ($893f) 55.12%
35,135 bytes prg file. Impressive.
Why use other crunchers? I like the challenge of improving my algorithms. :) |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
Save some more bytes:
bank ram
load "wb_0460-feff.prg" 0
;Dynamic Sprites
fill e140 e43f 00
fill e800 e83f 00
;Starfield Chars
fill f800 fad7 00
;End Memory
fill fd00 feff 00
;Game
save "wizball_clean.prg" 0 0460 fcff
|
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Quote: Save some more bytes:
bank ram
load "wb_0460-feff.prg" 0
;Dynamic Sprites
fill e140 e43f 00
fill e800 e83f 00
;Starfield Chars
fill f800 fad7 00
;End Memory
fill fd00 feff 00
;Game
save "wizball_clean.prg" 0 0460 fcff
Exactly, screens that become initialize and stuff too. I haven't looked at Wizball, but that's a good start. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Save some more bytes:
bank ram
load "wb_0460-feff.prg" 0
;Dynamic Sprites
fill e140 e43f 00
fill e800 e83f 00
;Starfield Chars
fill f800 fad7 00
;End Memory
fill fd00 feff 00
;Game
save "wizball_clean.prg" 0 0460 fcff
It's worth noting however that if memory is saved from the original Ocean tape release using a breakpoint at 6389, before the game runs, then most of that memory is already clear or contains long compressible runs of c6/fe/ff. Which the exception of fd00- which doesn't need to be included in the compressed file, fd00 can be the end of file basically. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: It's worth noting however that if memory is saved from the original Ocean tape release using a breakpoint at 6389, before the game runs, then most of that memory is already clear or contains long compressible runs of c6/fe/ff. Which the exception of fd00- which doesn't need to be included in the compressed file, fd00 can be the end of file basically.
It's easier and more efficient just to clear out the temporary data before game execution, which includes partially corrupt screen and old colour bar effect data with:
f e000 ebff 00
f ed00 efff 00
This leaves the one time initialise code at $ec00 intact. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
After applying the following cleanups:
bank ram
load "wb_0400-feff_g6389.prg" 0
;Some $ee Memory
fill 4680 4716 00
;Shadow Highscore Table
fill bdb9 beb4 00
;Temporary Data Martin Piper
fill e000 ebff 00
fill eceb efff 00
;Starfield Chars
fill f800 fad7 00
;Game
save "wizball_clean.prg" 0 0460 fcff
I get the following results:
MCC Compressor + Matcham Time Cruncher V3.1 gives 160 blocks 40417 bytes
Byte-Buster V4.1 + Byte Boiler 256k V1.0 gives 143 blocks 36300 bytes
Dali V0.3.2 136 blocks or 34229 bytes
Exomizer V3.1.1 137 blocks or 34580 bytes |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Nice. That's a lot smaller.
There is also some duplicate wiz tips data which can be blanked out. Depending on the publisher release. |
| |
Mason
Registered: Dec 2001
Posts: 459 |
Quote: 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
Most people did a reset cracks as they couldn't do a transfer routine for it
You mention Mr. Z and he for sure did his own transfer routine to transfer the files |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
The Mr. Z one is the disk version and not the tape. |
| |
tlr
Registered: Sep 2003
Posts: 1730 |
Quote: The Mr. Z one is the disk version and not the tape.
What's different between the versions? I just assumed they are the same. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: What's different between the versions? I just assumed they are the same.
If you have a look at my video it notes some of the differences. Code and data changes resulting in different memory address offsets while opcodes are mostly the same.
What looks like different code builds. Some duplicate memory. |
| |
ws
Registered: Apr 2012
Posts: 235 |
Who carez, but i wanted to try. This is quite interesting.
I depacked the wizball FCG crack (?id=103990), did some shallow cleaning of some obvious freezer garbage in the e400+ area, and wrote a quick and dirty 0400-0800 restore and then tested the cruncher i liked back in the day, wich is not super, despite the name -
datel supercrunch: 187 blocks, 47.327 bytes - wow thats bad (but it is fast and easy to use).
then i just wanted to check what the exomizer does with my cleaned wiz:
exomizer: 140 blocks, 35.491 bytes
if i hadn't blindly ignored knight rider's nice cleanup tips, and my restore was - as usual - less superoldschoolsloppy,... maybemaybemaybe, but well...
nice crunchcompo. ;-)
@knight rider - that cracking from cassette video is superb. thank you! |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
After wathcing Bacchus video, I tried Fungus tool for FREELOAD to see Fungus Tape Transfers Disk
...of course it produces the same memory ($0400-$ffef) as a freezer crack, which I already knew. |
| |
tlr
Registered: Sep 2003
Posts: 1730 |
Quote: After wathcing Bacchus video, I tried Fungus tool for FREELOAD to see Fungus Tape Transfers Disk
...of course it produces the same memory ($0400-$ffef) as a freezer crack, which I already knew.
I guess that depends on what you mean by "freezer crack".
A "freeze" was typically a (bad) crack produced by pressing the freeze button right after the game started and letting the cart save a runnable result.
A "reset crack" was typically another (bad) crack produced by resetting the game into a monitor right after the game started. Then manually searching for where the relevant chunks of code/data is and a jmp address, then saving.
Both of these have the problem of a lot of initialization have already been done, clobbering memory, and that there may be a lot things that cannot be reinitialized correctly, resulting in a non-working game. |
| |
Knight Rider
Registered: Mar 2005
Posts: 116 |
I meant doing this, then entering Expert via restore and then saving all memory.
Quoting Knight Rider
* = $1000
jsr $f72c ;Read program header off tape
ldx #<TREX1
ldy #>TREX1
stx $03ee+1 ;.C:03ee A9 00 LDA #<$0800
sty $03f3+1 ;.C:03f3 A9 08 LDA #>$0800
jmp $F56C ;Read rest of program off tape
TREX1
lda #$00
sta $09a0 ;.C:09a0 20 48 45 JSR $4548
- lda $09a0 ;.C:09a0 20 48 45 JSR $4548
beq -
lda #$18 ;ie CLC
ldx #$90 ;ie BNE -2
ldy #$fd ;ie BNE -2
sta $099d ;.C:099d 4C 89 63 JMP $6389
stx $099e ;.C:099d 4C 89 63 JMP $6389
sty $099f ;.C:099d 4C 89 63 JMP $6389
jmp $0800
|
| |
tlr
Registered: Sep 2003
Posts: 1730 |
Quote: I meant doing this, then entering Expert via restore and then saving all memory.
Quoting Knight Rider
* = $1000
jsr $f72c ;Read program header off tape
ldx #<TREX1
ldy #>TREX1
stx $03ee+1 ;.C:03ee A9 00 LDA #<$0800
sty $03f3+1 ;.C:03f3 A9 08 LDA #>$0800
jmp $F56C ;Read rest of program off tape
TREX1
lda #$00
sta $09a0 ;.C:09a0 20 48 45 JSR $4548
- lda $09a0 ;.C:09a0 20 48 45 JSR $4548
beq -
lda #$18 ;ie CLC
ldx #$90 ;ie BNE -2
ldy #$fd ;ie BNE -2
sta $099d ;.C:099d 4C 89 63 JMP $6389
stx $099e ;.C:099d 4C 89 63 JMP $6389
sty $099f ;.C:099d 4C 89 63 JMP $6389
jmp $0800
without analysing the details of it, that is the strategy of a "clean" crack, i.e only loaded into memory, not started.
There could of course be crumbs you fail to capture this way but not sure if those were common together with freeload. |
| |
Mason
Registered: Dec 2001
Posts: 459 |
Quote: After wathcing Bacchus video, I tried Fungus tool for FREELOAD to see Fungus Tape Transfers Disk
...of course it produces the same memory ($0400-$ffef) as a freezer crack, which I already knew.
It's the Hitsquad release that uses Freeload. THe original Ocean release uses Ocean/Imagine loader
It might give a different picture |
| |
tlr
Registered: Sep 2003
Posts: 1730 |
Quote: It's the Hitsquad release that uses Freeload. THe original Ocean release uses Ocean/Imagine loader
It might give a different picture
Hmm, is that really true? I found a Hitsquad release and that used hitload. Several Ocean dumps seem to use freeload. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
The original Hitsquad tape doesn't have a loading picture or music. It just loads a single file that is a self extracting "freeze".
The original Ocean tape with loading screen and music loads several uncompressed chunks. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
For the hit squad tape put a breakpoint at $80d and you can see in the CPU history in Vice that the last part of the stack based tape loader will pretty much just call into $80d from the code at $154.
I say "freeze" for the hit squad tape version because it does a whole lot of typical "unfreeze" stuff, like expanding nybbles for the colour RAM at $840, restoring the end of RAM vectors at $81e, restoring SID, VIC, and other IO state $885-$8bf
It then does a couple of almost full memory copies, before jumping into code at $11, then to $2a7 restoring zero page, then clearing move of itself at $1e8, and using the usual RTI method at $1f9 to then start the game code cleanly at $6389.
So it's not quite a "freezer" that was restored from any entry point, it is actually going cleanly into the game start code at $6389.
Certainly however that self extracting archive can be made a lot smaller as it does not need to restore SID, VIC, IO. COLOURRAM before starting the game code at $6389. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Quote: It's the Hitsquad release that uses Freeload. THe original Ocean release uses Ocean/Imagine loader
It might give a different picture
There's three versions then if there is an Imagine loader version.
I have an Ocean with Freeload, and a Hit-Squad release with Hitload. Did you dump that tape Mason? Would be interested to check the differences between it and the Freeload one.
I found some other crap in the file that looks like leftovers from something else.
Quoting Knight Rider
After wathcing Bacchus video, I tried Fungus tool for FREELOAD to see Fungus Tape Transfers Disk
...of course it produces the same memory ($0400-$ffef) as a freezer crack, which I already knew.
The Freeload transfer was coded by 6R6, it produces clean files off the tape just like setting a freeze point and then saving the loaded memory would. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Had a look into this, got the tape with the Imagine Loader.
The code at EC00 is unfreezing code. This was common practice back then to freeze games just as they started. So will take some work to find the real entry point. Backtracking what's on the stack should point in the right direction.
Both versions are frozen, I'll take a look at the hitload one later. It's possible that it was remastered from original files.
$0400-$0460 is junk.
Load picture has a nasty reformat disk thing in it, haha.
I'd mention the funny string at the end of the high score entries but I don't want to get my access to the forums removed for mentioning a certain excrement. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
I already did all of that in the videos. The two original tapes result in identical code and data at the point it starts the game code at $6389. |
| |
Mason
Registered: Dec 2001
Posts: 459 |
Hmmm I don't remember that the version with Imagine loader was frozen
I have to admit I haven't looked at the game for many years |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Yeah it doesn't seem like it is, but it most certainly is. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
It's not really frozen. It depacks a lot. But it jumps into the standard game start code at 6389 just like the original uncompressed load. The game start at 6389 does all its initialisation so it doesn't rely on the decompression ZP IO state. |
| |
Weetibix
Registered: Aug 2023
Posts: 1 |
The Final Super-Compressor was the packer that changed the compression playing field in my own experience...before this I'd only come across "char packers". I'm guessing the selection options offer some form of RLE, LZW & Huffman implementations wrapped up in one. The scene changed quickly with the arrival of Matcham's Time Cruncher V3.1/V4 and the illusive 1001 Card Cruncher (never had it).They were followed by many more excellent and improved alternatives over the years (Cruel Cruncher, Bit Imploder, Exomizer, etc). It was always a balancing act between adding a cracktro vs final compressed file size.
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 ? |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
On the real thing, I would probably try to port Exomizer to the C64.
I'd definitely use my own packer now.
I'd have to figure out how equal sequence and lz works to try and make my own, but I'm sure I could if I got obsessed with it.
I can code my own Huffman as well, which might be interesting for certain things.
In 1987, I'd probably use Squeezer, and Sledgehammer. Since Byteboiler and Cruncher AB weren't available yet. |
| |
Bansai
Registered: Feb 2023
Posts: 36 |
Quoting FungusI'd have to figure out how equal sequence and lz works to try and make my own, but I'm sure I could if I got obsessed with it. It's fun to mess with, my favorite part being the "aha" moment when you see how patterns like ABCABCABC... can decompress on the fly in place without the whole string already being present in memory and with only a single length+distance pair referring back to where the sequence starts. Articles on the byte-based LZ77 are a good starting point for learning LZ. You could teach yourself very quickly.
Interestingly, LZ77 still sees modern usage in LZ4. Exomizer beats LZ4 with respect to compression ratio, but LZ4 was largely designed for raw speed balanced against good enough compression, not best case compression. |
| |
cbmeeks
Registered: Oct 2005
Posts: 73 |
I wished it was 1987 again. I would be 14. |
| |
tlr
Registered: Sep 2003
Posts: 1730 |
Quoting FungusOn the real thing, I would probably try to port Exomizer to the C64.
If it is to approach the gain of the regular exomizer compression would be prohibitively slow. The optimization routine for the length/offset encodings takes quite some CPU time on a modern machine.
You could of course make a version that uses the exact same depacker but produces less optimal compression. It might not gain much (if at all) over Byteboiler, Cruncher AB and friends, but it would still be much faster depacking. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Yeah it does, probably take months on a c64, but just for fun with REU. |
