English Amiga Board

Go Back   English Amiga Board > Coders > Coders. General

Thread Tools
Old 04 December 2009, 10:17   #1
Registered User

Join Date: Aug 2004
Location: 19 Jump Street
Posts: 227
[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):

	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.
AmigaBoy is offline  
AdSense AdSense  
Old 04 December 2009, 10:33   #2
pmc's Avatar
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
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?
pmc is offline  
Old 04 December 2009, 11:09   #3
Registered User
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 183
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.
Kalms is offline  
Old 06 December 2009, 20:31   #4
Photon's Avatar
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,499
Unless you need the memory values later, you could ofc replace

cmp.l d0,d1


cmp.l d0,d0

and the test will evaluate as true every time. But I guess you can't use that?
Photon is offline  
Old 07 December 2009, 08:06   #5
Registered User

Join Date: Aug 2004
Location: 19 Jump Street
Posts: 227
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.
AmigaBoy is offline  
Old 07 December 2009, 11:31   #6
Join Date: Aug 2008
Location: 1
Posts: 114
Jason; Remember that this game also checks for changes on the bootblock, in some versions.
marty is offline  
Old 07 December 2009, 12:19   #7
Registered User
Join Date: Oct 2008
Location: EU
Posts: 110

... 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...
a4k-oerx is offline  
Old 08 December 2009, 08:16   #8
Registered User

Join Date: Aug 2004
Location: 19 Jump Street
Posts: 227
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
AmigaBoy is offline  
AdSense AdSense  

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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Virtual Memory or Memory Compactor Leandro Jardim support.Apps 2 29 May 2012 23:12
Move it Move it... (68000) Gilloo Coders. Asm / Hardware 19 04 December 2011 17:36
Blizzard Turbo Memory - SMD memory chips doesn't work sanjyuubi Hardware mods 5 26 May 2010 15:40
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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 15:33.

Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.15923 seconds with 11 queries