| |
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....
|
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
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: 646 |
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: 629 |
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: 646 |
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: 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: 646 |
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: 11149 |
That's a non issue though, unless you are being lame enough to do reset cracking :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
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: 11149 |
Tell us more about proper cracking >_< |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
