Got a patch for Putty but having trouble initiating it.

[MethodGit]

After extensive playing about with this game, I managed to get a patch intended for placing at $C0 as follows:

ADDA.L #71110,A0       ;points to JMP instruction for copylock
MOVE.L #11FC00FF,(A0)  ;replaces code with MOVE.B #FF,100.S
MOVE.W #0100,4(A0)     ;replaces code with MOVE.B #FF,100.S
SUBA.L #71110,A0       ;restores A0 to original value
RTS                    ;returns to whre it left off

I insert a JSR C0.S to a spot just before the game determines which of two addresses to jump into (C68000 or E8000, depending on RAM setup) to start the game. I also insert my "insert new opcodes into $C0" patch into $6F6DE on the ADF.

If I insert a BRA loop in the spot on the bootblock where JMP 400.S resides, I can see that my patch instructions to insert my new opcodes into $C0 exists within memory at that time, somewhere in the $70000 region.

Only problem, my patch code never seems to start at a static address. It's like the loader code shuffles the data about into a random address in the $7A000-$7E000 range just before jumping to $400. Therefore there's only the odd chance that my code may be accessed upon bootup, with all other times causing a guru. Is there any specific tricks I should be using to rectify this?

Thanks.

[MethodGit]

Forget it. Turns out the address where my code starts is conveniently stored in A1 each time. A JMP (A1) later and one is home sailing.


So that leaves me with Silly Putty (yes, the other Putty 1 title in SPS) to deal with. I'm finding this a lot trickier to patch - it does things the same way but reads code differently and I can't seem to find a spot where I could load patch code from (my trick is usually to find all the long blank spaces in the ADF through a hex editor and fill them with a replicated byte of my choice, then find them within AR/HRTMon before a specific JMP). I can't even seem to get away with overwriting some of the starting boot code with a loader routine to load stuff from $400 or $1600 either.

Any solutions?

[marty]

I don't know how big your patch is, but its gotta be REALLY big!!!
You got the whole copylock track for your use

[musashi5150]

Maybe I'm old fashioned but I think you'd learn a lot more on these cracking adventures you're having if you worked more at finding the solution to all your questions by yourself. Sure it might take some time and it might drive you crazy for a while but it's a useful experience. I mean there is no time limit here... all these games are long cracked years ago so you must only be doing it for your own learning and amusement? (And there is absolutely nothing wrong with that - good stuff)

My first MFM crack took me a couple of days to get right but I did it myself without any help and I learnt valuable lessons. Sure Sting, Galahad, Codetapper and other guys here are good resources but I think all your threads requesting help and answers are missing the point.

Just my tuppence worth and anyway what do I know

[StingRay]

Well said Musashen, I totally agee.

Originally Posted by MethodGit

So that leaves me with Silly Putty (yes, the other Putty 1 title in SPS) to deal with. I'm finding this a lot trickier to patch - it does things the same way but reads code differently and I can't seem to find a spot where I could load patch code from (my trick is usually to find all the long blank spaces in the ADF through a hex editor and fill them with a replicated byte of my choice, then find them within AR/HRTMon before a specific JMP). I can't even seem to get away with overwriting some of the starting boot code with a loader routine to load stuff from $400 or $1600 either.

I already gave you the answer to your question in this thread! There is all info you need to solve that problem.

[MethodGit]

Originally Posted by StingRay

Well said Musashen, I totally agee.



I already gave you the answer to your question in this thread! There is all info you need to solve that problem.

Funnily enough, I've since found two other ways of cracking Rodland without resorting to that sort of patch.

Am without a working computer atm however, so I can't really look into Silly Putty as of this time.

[StingRay]

Originally Posted by MethodGit

Funnily enough, I've since found two other ways of cracking Rodland without resorting to that sort of patch.

That's totally irrelevant here since this thread is not about Rodland. And since you are so good you'll surely find a way to deal with Silly Putty too.

[MethodGit]

Sorry to bump an old thread, but I was looking into Silly Putty again today and decided that (since nothing else I could think of worked) a track loader routine at bootup would surely help. Here's how I've laid it out so far:

rt 0 1 70000

7000C = LEA DFF000,A0        (default start instruction by game, left here mainly as bumper)
70012 = CLR.W DFF180         (turns the screen black)
70018 = MOVE.L #C0,28(A1)    (set $C0 as target destination)
70020 = MOVE.L #400,2C(A1)   (copy code from offset $400 on disk)
70028 = MOVE.L #14,24(A1)    (copy 14 bytes worth of said code)
70030 = JSR -1C8(A6)         (start copy process)

I've put the code I want to copy at offset $400 on the disk, so it looks as if everything will go along okay. Exceeeeeeept...... it's not copying my code into C0 for some reason (it's still blank). I've combed through my code over and over, compared with similar track loader routines in cracks and tutorials, made sure I didn't get the functions of 24/28/2C completely mixed up, and it all looks fine. I don't think this game clears out low memory on startup either (which game ever does this in fact?) so I'm certainly stumped. I thought a track loader allowed you to copy code from any position on the disk you liked (compared to a traditional copy routine where you're limited to a certain range). Or have I missed something very important?

[WayneK]

I'm not going to go into why this is complete overkill for what you want to do, but afaik you can only specify sector-aligned file sizes here... so rather than #14, you probably want #$200 (512 decimal, the size of a normal sector) instead.

[Predseda]

Everything Putty related interests me, but I absolutelly have no idea what patch you guys are talking about. If it will be usefull we could share it through our Puttymoon website

[MethodGit]

Originally Posted by WayneK

I'm not going to go into why this is complete overkill for what you want to do

Perhaps you should take a look at Silly Putty (not Putty, Silly Putty) yourself at some point, as the bootblock is essentially packed with data and I was lucky to come across some minor/non-vital instructions at the very start of the boot routine that I could replace. I also couldn't find anywhere else on the disk I could put some code in that the game would conveniently copy to a remote spot for me (this is what worked for me in Putty).

, but afaik you can only specify sector-aligned file sizes here... so rather than #14, you probably want #$200 (512 decimal, the size of a normal sector) instead.

Yup, looks like that worked. Guess I misunderstood how the 'size' setting worked - I was worried it would copy 200 bytes or something!

However(!), it seems setting it to 200 has resulted in $2C0 bytes of data being copied, which is too much, and I think it's had an effect on the boot process as well, as I now find the game stuck in a BNE loop within the $400 area, something that had never happened before. What's the smallest possible working size I could set?

[musashi5150]

Originally Posted by Predseda

If it will be usefull we could share it through our Puttymoon website

No, it's nothing interesting for sharing. MethodGit is experimenting with different crack methods for the game.

[Codetapper]

MethodGit: It doesn't help that you are confusing decimal and hex numbers. Action Replay is a bit useless in my opinion due to it leaving the $ sign off disassembly. You yourself are confusing things when you write this:

70020 = MOVE.L #400,2C(A1) (copy code from offset $400 on disk)
70028 = MOVE.L #14,24(A1) (copy 14 bytes worth of said code)

One minute you say it's copying data from offset #400 (meaning hex), the next time you say #14 means 14 decimal. A real assembler will not let you get away with assuming # means hex numbers!

If you have told the game to load $200 of data, it will not load $2c0 bytes. Paste your code here and I'm sure the bug will be obvious. Or better, pretend you're explaining your code to your sister or something and as you step through it, you'll probably see the error in your code.

[marty]

Originally Posted by MethodGit

Perhaps you should take a look at Silly Putty (not Putty, Silly Putty) yourself at some point, as the bootblock is essentially packed with data and I was lucky to come across some minor/non-vital instructions at the very start of the boot routine that I could replace. I also couldn't find anywhere else on the disk I could put some code in that the game would conveniently copy to a remote spot for me (this is what worked for me in Putty).

Yup, looks like that worked. Guess I misunderstood how the 'size' setting worked - I was worried it would copy 200 bytes or something!

However(!), it seems setting it to 200 has resulted in $2C0 bytes of data being copied, which is too much, and I think it's had an effect on the boot process as well, as I now find the game stuck in a BNE loop within the $400 area, something that had never happened before. What's the smallest possible working size I could set?

Why dont you then move the bootblock to where the copylock track was ?

[StingRay]

Originally Posted by MethodGit

70018 = MOVE.L #C0,28(A1)    (set $C0 as target destination)
70020 = MOVE.L #400,2C(A1)   (copy code from offset $400 on disk)
70028 = MOVE.L #14,24(A1)    (copy 14 bytes worth of said code)
70030 = JSR -1C8(A6)         (start copy process)

I've put the code I

Your problem is the first line, you can't load to such low memory address using the normal trackdisk loader, you'll destroy important system stuff which resides there. Solution: load to high mem and then copy down to the real destination or use a hardware trackloader.

Edit: and you need to use a multiple of 512 for the length. Loading 14 bytes with trackdisk won't work either (which is why nothing is loaded at all).

[MethodGit]

Originally Posted by Codetapper

MethodGit: It doesn't help that you are confusing decimal and hex numbers. Action Replay is a bit useless in my opinion due to it leaving the $ sign off disassembly. You yourself are confusing things when you write this:

70020 = MOVE.L #400,2C(A1) (copy code from offset $400 on disk)
70028 = MOVE.L #14,24(A1) (copy 14 bytes worth of said code)

One minute you say it's copying data from offset #400 (meaning hex), the next time you say #14 means 14 decimal. A real assembler will not let you get away with assuming # means hex numbers!

Actually, I was counting 14 hexadecimal bytes (it would be 20 bytes in decimal). I should've made that clearer I guess. Apologies!

If you have told the game to load $200 of data, it will not load $2c0 bytes. Paste your code here and I'm sure the bug will be obvious. Or better, pretend you're explaining your code to your sister or something and as you step through it, you'll probably see the error in your code.

Yes, I realised after posting that it was starting from $C0 to begin with, so yes it would be $200 and not $2C0. Double apologies!

Originally Posted by StingRay

Your problem is the first line, you can't load to such low memory address using the normal trackdisk loader, you'll destroy important system stuff which resides there. Solution: load to high mem and then copy down to the real destination or use a hardware trackloader.

Aaaah okay. So perhaps someone could point out the flaw in a couple of Flashtro's tutorials?

Later update:
Arrrrggghhh. Still no luck.

Looks like I was wrong about my copying to $C0 causing the game to get stuck in a routine on track 14. I copied my code to $70000 and the same thing happens. I then tried putting my code in at $1600 (the former copylock track) on the disk and copying from there, and it didn't change the situation. I've tried examining the routine it loops around in and I can't notice anything unusual going on (this routine is accessed a lot during the loading process). Please don't tell me the bootblock is protected by a checksum of sorts?

This is how the start of the bootblock looks normally, without alterrations:

7000C = LEA DFF000,A0
70012 = MOVE.W #7FFF,96(A0)
70018 = MOVE.W #7FFF,9A(A0)
7001E = MOVE.W #7FFF,9C(A0)
70024 = MOVE.B #7F,BFED01
7002C = MOVE.B #7F,BFDD00
70034 = MOVE.W #0,180(A0)
7003A = LEA 70054(PC),A0
7003E = LEA 7A800,A1
70044 = MOVE.W #3FF,D0
70048 = MOVE.B (A0)+,(A1)+
7004A = DBF D0,70048
7004E = JMP 7A800
...

I would've thought that anything to do with screenmem could be replaced without a problem? I always make sure everything from 7003A onwards remains intact.

[8bitbubsy]

Originally Posted by MethodGit

Aaaah okay. So perhaps someone could point out the flaw in a couple of Flashtro's tutorials?

What Flahstro tutorial, specifically? Can you link it?
No, I don't know anything about it, but I want to see if a tut on Flashtro really would do such an obvious mistake.

[MethodGit]

Originally Posted by 8bitbubsy

What Flahstro tutorial, specifically? Can you link it?
No, I don't know anything about it, but I want to see if a tut on Flashtro really would do such an obvious mistake.

Just a couple of them (Assassin, Whizz) use a trackloader routine to copy to $C0, which StingRay pointed out is not recommended.

And now my last post looks funny due to my later words being combined into it.

[TCD]

Originally Posted by MethodGit

And now my last post looks funny due to my later words being combined into it.

In case you haven't noticed : There's an edit button...

[StingRay]

Originally Posted by MethodGit

Just a couple of them (Assassin, Whizz) use a trackloader routine to copy to $C0, which StingRay pointed out is not recommended.

Read carefully, I didn't say that using a trackloader to load data to low mem is bad, I wrote that using the trackdisk.device for that is a bad idea. With a normal hardware trackloader (which doesn't need any OS functions) you can load data to any address you want.