[68000 ASM] Move memory to memory

[AmigaBoy]

I know this is extremely trivial but I wanted to see other solutions. Mine works, but it feels wrong. I guess the ultimate aim is a solution that uses the minimal number of bytes.

Assume the following code (obviously some type of check):

	203a 0f2c        MOVE.L $0F2C(PC),D0
	223a fe6c        MOVE.L $FE6C(PC),D1
	b081             CMP.L D1,D0

What I would like to know is what's the best way to move the value in $0F2C(PC) into $FE6C(PC)? That way when these 2 lines are encountered, D0 and D1 will be equal and the check will be passed.

[pmc]

Is your code segment indicative only? I'm not getting the purpose of moving an absolute pc relatively, if you see what I mean? Plus, that's illegal of course.

Assuming that the absolutes represent labels, wouldn't you just move one of the labels twice to the two different registers?

move.l     label(pc),d0
move.l     d0,d1
cmp.l       d0,d1

that way, always the same value in both regs, always evaluating to equal - but why bother? If you always want the check to pass why not just amend the cmp / bcc to a bra?

[Kalms]

If you can use absolute addressing, then the following location would do the job for you:

MOVE.L <location1>,<location2>

However, you probably can't do that. So you need a PC relative version. You can read from a PC-relative location, and you can catch the address to it, but you cannot write directly to a PC-relative location. Therefore, the following piece of code copies a value from one PC-relative location to another:

MOVE.L offset1(PC),D0
LEA offset2(PC),A0
MOVE.L D0,(A0)

You need to work out offset1 and offset2 such that they map to the correct locations in the file though. The offsets are relative to (start address of current instruction + 2 bytes). Assemblers help you with this job, by assigning symbolic names to locations, and automating the offset calculations. Won't help you much if you want to hexedit an existing executable, though.

[Photon]

Unless you need the memory values later, you could ofc replace

cmp.l d0,d1

with

cmp.l d0,d0

and the test will evaluate as true every time. But I guess you can't use that?

[AmigaBoy]

Whoops. Forgot about this thread

pmc: You're right. What I'm trying to do is not best practice and should be avoided whenever possible. However this isn't my code I'm looking at a simple protection, hence why I have to conform to their absolute PC addressing.

pmc and Photon: Yes, both of your suggestions can, and do work. The game I'm looking at is Captain Dynamo. Implementing your suggestions both work fine, however I never patch that way because I fear later on in the game there will be another check. Granted, my method isn't 100% either, but it gives peace of mind knowing that if there is another check, both memory addresses will contain the same value so it's likely that any future checks will pass.

Kalms: Your suggestion is exactly what I had, so I assume that's the best way. I was hoping I could use MOVE.L <location1>,<location2>, however as you said, it's for absolute addressing only.

Anyway, the ultimate goal was to create a patch that used as little bytes as possible. I've managed to get it down to around 12 or so, so I guess that's fine.

Thanks for the help everyone.

[marty]

Jason; Remember that this game also checks for changes on the bootblock, in some versions.

[a4k-oerx]

... both memory addresses will contain the same value so it's likely that any future checks will pass.

Possible problem with the copy approach: Which is the "correct" value? Like copy from $0F2C(PC) to $FE6C(PC) or from $FE6C(PC) to $0F2C(PC)?

Other checks, which might compare only one of these offsets to something else may fail if you copy it in the wrong "direction".

Not related to exactly this game, but more a general thought...

[AmigaBoy]

marty: Codetapper also suggested once that a bad patch will cause level 3 to not work, so I'll keep your suggestion and his in mind when I get to the bootblock stuff. At the moment I'm just messing around to get more 68000 and Amiga knowledge.

a4k-oerx: True. The game may regenerate the correct value later and if I copied the wrong value, it would fail. However in this case, I already know which is correct