[68000 ASM] Move memory to memory

Jason · 04 December 2009, 10:17

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):

Code:

	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 · 04 December 2009, 10:33

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?

Code:

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 · 04 December 2009, 11:09

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 · 06 December 2009, 20:31

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?

Jason · 07 December 2009, 08:06

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 · 07 December 2009, 11:31

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

a4k-oerx · 07 December 2009, 12:19

Quote:

... 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...

Jason · 08 December 2009, 08:16

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

04 December 2009, 10:17	#1
Jason Registered User Join Date: Aug 2004 Location: 19 Jump Street Posts: 126	[68000 ASM] Move memory to memory 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): Code: 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.

04 December 2009, 10:33	#2
pmc is long gone Join Date: Apr 2007 Location: London Posts: 1,590	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? Code: 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?

06 December 2009, 20:31	#4
Photon Oldskool Demo Coder Join Date: Nov 2004 Location: Hult / Sweden Age: 41 Posts: 3,680	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? __________________ Henrik. Programs Amiga demos, iPhone apps, websites, etc. A1000/512k - A500 2.0/040@28/4M/.5M slowmem/8M/SCSI/CF - A600 portable II 3.1/ACA630/WiFi/CF - 'A1700' 3.1/68060@80/64M/IDE-Fix Express/CF - etc."The difference between PC and Amiga is that 10yo PCs are worth $0. 20yo Amigas are worth a lot, and Amigas that are only 15yo cost a fortune!" If you like Portal 2, try my >> single player and cooperation maps <<

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
For Sale Elbox CDTV/8MB 68000 DIP Memory Adapter	Zetr0	MarketPlace	11	05 August 2009 03:55
DMA memory to memory copy	BlueAchenar	Coders. General	14	22 January 2009 23:29
Old cache memory as a "base" for GVP memory	rkauer	Hardware pics	4	22 November 2008 06:23
Memory	numb	New to Emulation or Amiga scene	5	15 March 2005 16:08
Memory	Tazz	support.Hardware	5	04 June 2001 17:51

04 December 2009, 11:09	#3
Kalms Registered User Join Date: Nov 2006 Location: Stockholm, Sweden Posts: 121	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.

07 December 2009, 08:06	#5
Jason Registered User Join Date: Aug 2004 Location: 19 Jump Street Posts: 126	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.

07 December 2009, 11:31	#6
marty Banned Join Date: Aug 2008 Location: 1 Posts: 114	Jason; Remember that this game also checks for changes on the bootblock, in some versions.

08 December 2009, 08:16	#8
Jason Registered User Join Date: Aug 2004 Location: 19 Jump Street Posts: 126	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

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

AdSense
Advertisement:

AdSense
Advertisement: