| |
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....
|
| |
Fungus
Registered: Sep 2002
Posts: 629 |
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: 645 |
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: 11147 |
That's a non issue though, unless you are being lame enough to do reset cracking :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
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: 11147 |
Tell us more about proper cracking >_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
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: 11147 |
Are you saying bad crackers made bad cracks? WOW
(The screenshot police is sleeping?) |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
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
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
