| |
Burglar
Registered: Dec 2004
Posts: 1090 |
Event id #2314 : C64 Cracking Competition 2015
Howdy Crackers!
These days the cracking scene is pretty active, but it seems most effort is spent on rushing out a version first with non-protected games.
Now that we found this nice original that hasn't been cracked, we thought, let's turn it around. Have a cracking competition with all of you with a full price EA game, including a nice protection. So here we go with the first C64 Cracking Competition 2015!
You are invited to crack "Return of Heracles" (C) 1983-1986 Electronic Arts.
Download the original here: http://sh.scs-trc.net/return_of_heracles.d64
Please read the rules carefully, and take all the time you need, quality over speed please :)
Rules:
- Submit your entry before or at 23:59 saturdayevening the 28th of March 2015 by email to c64crackingcompetition@hushmail.com
- Your release must fully run on a stock c64 + 1541.
- Your release must be filecopieable and packed.
- Your release must contain a crack intro, but you also must provide an introless version. This will be used to accurately measure size.
- Recracking is strictly forbidden, you must crack the original we provide. When in doubt, we will dig through your release and ask a few questions to confirm you really cracked it yourself.
- Individuals may only be part of a single release, so a group may enter multiple cracks, provided they are done by other members.
- You are allowed to use whatever tools you want.
Calculating Results:
50% of the result will be determined by public voting, either using or own voting system or on csdb. Stay tuned for additional info.
The other 50% of the result is calculated by the compo organizers using the following criteria:
- The shorter the better *)
- The faster it loads the better
- Proper saving capabilities
- Full PAL/NTSC compatibility
- Amount of bugfixes (if any bugs present in game)
- Amount of trainers (no double trainers)
- Minus points if you introduce bugs and need multiple versions
- The more devices besides 1541 (or compatible) you support, the better
- Optional REU support is also nice
*) We explicitly do not want to discourage the use of large intros, hence
the introless version requirement.
Most of all, have fun cracking this full price game!
The Organizers,
Peacemaker/Hitmen
Burglar/SCS*TRC |
|
... 158 posts hidden. Click here to view all posts....
|
| |
Burglar
Registered: Dec 2004
Posts: 1090 |
I'd say the rules and criteria we set up are quite clear, complete and to the point.
if not, gimme a shout :)
personally, I wouldn't do a multi-device loader, simply because I never built any. This would give me less points than the version that does support many devices, but so be it ;) I'd rather beat someone in size instead. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
My IFFL routine only supports 1541/1571 anyway. My issue then would be that the IFFL I have will not allow saving, and that's an integral part of the game to be able to do that. So I'm out of luck using my IFFL unless I rewrite it.
But F*CK what a mess this loader is.
Normally the game calls the loader with filename/number in A and then you can just replicate the loader so that calling the loader with a value in A you load that very file.
Now there is calling the loader with a number of different values. The part at $FC3E is difficult enough but when it's also called repeatedly from $85xx and stuff is moved around in memory I get mad.
Does it load blocks to $FB3E, and move it to $1700 whereafter the routine under $8500 moves it to another location or what the f*ck is happening here? |
| |
Burglar
Registered: Dec 2004
Posts: 1090 |
Quoting BacchusMy IFFL routine only supports 1541/1571 anyway. My issue then would be that the IFFL I have will not allow saving, and that's an integral part of the game to be able to do that. So I'm out of luck using my IFFL unless I rewrite it.
I have the same problem, my iffl only allows saving of a single sector (inside iffl), but these roh savegames are huge! problems problems ;) got good ideas to handle it though ;)
Quoting Bacchus
But F*CK what a mess this loader is.
Normally the game calls the loader with filename/number in A and then you can just replicate the loader so that calling the loader with a value in A you load that very file.
Now there is calling the loader with a number of different values. The part at $FC3E is difficult enough but when it's also called repeatedly from $85xx and stuff is moved around in memory I get mad.
Does it load blocks to $FB3E, and move it to $1700 whereafter the routine under $8500 moves it to another location or what the f*ck is happening here?
Think of the loader as a sector loader, cause that's what it is ;) sometimes it'll copy to 1700, sometimes to others, depending on what file ur loading.
Looks like RoH is really a huge challenge, even after cracking pirateslayer :P
I'm also starting to understand the game as well, it's pretty complex. Zeus already killed me for not fulfilling his wishes ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
Quote:Zeus already killed me for not fulfilling his wishes ;)
i hate when this happens =P |
| |
Peacemaker
Registered: Sep 2004
Posts: 249 |
The T/S-Loader copies to $1700 and $fb40 (i think) one sector each load, and then the memory gets from there moved where its "needed". only replacing the loader with another one wont work at all. you need to fix a lot of other things to get it working. and i also found out there is a kind of ingame protection. ;) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
[Edit]
Peacemaker;
Loads to $FB3E and the copies the page to 1700 which then copies to another location. This other location can be $9f80 from where it it's copied to YET another place. Give me a break! This is unlike anything I have seen before.
The first menu starts on 03,00 and that has a normal block chain (loading during the EOA blinking phase). Simple EOR protection of the data.
I just fail to find a table for references of the blocks. It's copying pointers across the shit, ROLing them and so on.
Hrm. Might have found the list of addresses stuff should be loaded to at least :-) |
| |
Fungus
Registered: Sep 2002
Posts: 681 |
Quote: The T/S-Loader copies to $1700 and $fb40 (i think) one sector each load, and then the memory gets from there moved where its "needed". only replacing the loader with another one wont work at all. you need to fix a lot of other things to get it working. and i also found out there is a kind of ingame protection. ;)
;)
You mean the loader has it's own block buffer for decrypting the sectors and then putting them into memory via it's own file management routines? *GASP* WOW, So technology, much idea, very protection. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Fungus
It's not a protection - it's just an implementation that makes the logic so messy to follow.
Just out of curiosity - who are working on this? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
didi and troublemaker i have heard |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Also;
Implementing a saver, one stands between two options;
# a new one that is all filebased and
# making it compatible with the old.
The first option is a lot cleaner of course, but people who played the game before will not be able to use their old save points.
Or are we meant to provide a tool to convert old saves? ;-) |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 17 - Next |
