Understanding ASM Routine

Crackersixx · 03 February 2006, 05:59

I am working on a WHDLoad install in order to teach myself ASM, some cracking, aga fixing (as this game doesnt seem to work on my 1200), and obviously how to do an installer.

The target game is a playable demo (T2:the arcade game) that was included on some magazine. I have disassembled the bootblock and figured out what it's doing for the most part.

The bootblock loads another file from the disk (NDOS Disk), enters supervisor mode, the jumps to the loaded file. Attached is my interpretation of the bootblock code (bootblock.txt)

The file that is loaded is causing me a bit of trouble, and I dont really know why it does what it seems to. This is what I am hoping someone could help me out with. (file1.txt, just beginning portion)

What is confusing me is that the loaded file copies a portion of itself to another location in memory (70000), then jumps to a location a bit further on (7098A).

The portion that is copied starts at label "lbC00001A", why would it move it rather than just jumping to it's original location?

How would I go about tracing this further? Do I have to calculate the size of all the instructions starting at label "lbC00001A" in order to figure out what line of code is being jumped to after its copied to 70K?

Maybe I have misinterpreted something?

Any help appreciated...

btw, once I complete this I will have written a full tutorial that even a beginner could understand as I have to do this in order to figure stuff out. Maybe someone else will find it useful.

Codetapper · 03 February 2006, 07:24

OK a few mistakes:

Code:

	MOVE.L	A1,-(SP)		;Set initial stack pointer

This actually pushes A1 onto the stack. A1 holds the IORequest structure which is passed to a bootblock.

Code:

	MOVE.L	#$10002,D1		;Move $10002 into D1

If you use Resource to disassemble the code, you can hit "m" for memory type, and it will change to a useful description such as MOVE.L #(MEMF_CHIP|MEMF_CLEAR),D1.

Code:

	MOVEA.L	(SP)+,A1		;Move stack pointer to A1 and inc

This restores A1 by grabbing the value off the stack. A1 now holds the IORequest structure address once again.

Code:

	MOVE.W	#2,($1C,A1)		; ??

This is filling the command structure to indicate we want to read data. If you use resource, you can go into symbols, choose Exec/IO and fill it in as: MOVE.W #CMD_READ,(IO_COMMAND,A1)

Code:

	MOVE.B	($1F,A1),D0		; ??
	BNE.B	lbC00002C		; ??

Once again, let Resource do your work for you! Go into symbols, Exec/IO and choose IO Standard, and you'll get MOVE.B (IO_ERROR,A1),D0 instead. If an error occurs, D0 will not be 0 and so it will attempt to reload the data.

Onto the next file:

Code:

***************** Disassembled "File1" *************************

	;---- Copy 563 words from lbC00001A to addy 70000 -----------------
	LEA	($70000).L,A1		;get $70000 in A1
	LEA	(lbC00001A,PC),A0	;get address of lbc00001a in A0
	MOVE.W	#$563,D7		;get $563 in D7

lbC00000E	
	MOVE.W	(A0)+,(A1)+		;move word from A0 into A1 and inc
	DBRA	D7,lbC00000E		;decrease D7, if > -1 loop
	JMP	($7098A).L		;when finished, jump to $7098a
	;------------------------------------------------------------------


lbC00001A	
	MOVEM.L	D1-D7/A0-A5,-(SP)
	LINK.W	A6,#-$24
	MOVE.W	D0,D4
	ANDI.W	#3,D4
	MOVE.W	D4,(-$24,A6)
	MOVE.W	D1,(-$22,A6)
	MOVE.W	D2,(-$20,A6)
	MOVE.W	D3,(-$1E,A6)
	MOVE.L	A0,(-$1C,A6)
	MOVE.L	A1,(-$18,A6)
******************************************************************

The file is relocated to $70000 and then it continues at $7098a. The reason you copy it is that the code could be absolutely anywhere in memory, and simply executing it will cause problems later.

The programmer has worked out where he will fit the code, graphics, music etc in memory so that everything fits nicely and all 512k of chip memory is used effectively. If you let the Amiga decide where to load it, it might end up at say $20000 and that would be a problem as you then have to squeeze the game around and avoid that block of memory. Instead you simply copy it to a safe location you know about.

lbC00001A is the Rob Northen loading routine. After you've been in the cracking business for a while you can sniff those a mile off

D0 = Disk drive to load from
D1 = Offset (sectors)
D2 = Length (sectors)
D3 = Function (0 = read, 1 = write, bit #15 controls whether the motor is left on)
A0 = Disk buffer address for transfer
A1 = Workspace buffer ($3300 bytes of chip memory)

On exit, D0 returns the error number. If it's 0, everything was OK.

What you should do is grab that file which you have called file1 (I recommend my utility called grab to do it: Grab game.adf ram:file1 from $5200 length $c00) and load it into resource. Go into the * menu, Origin, Specify and set it to $70000. Now Resource will be able to disassemble the code as the beginning of the file is now where the game expects it, so the code JMP $7098A will change to JMP lbC0007098A and you can keep going.

Good luck!

Crackersixx · 03 February 2006, 08:09

Great info codetapper.

I did use ReSource to disassemble the code but I'm not to sure how to use all of the features just yet

I'll definately check out your suggestions.

And I am using your Grab utility as well as your HDInstalling tutorial from your website as a guide.

Setting the origin in ReSource is exactly what I was needing. I'll continue again on this tomorrow nite

Crackersixx · 05 February 2006, 11:42

ok, so I have what I think is a decent start on a slave file.

When i launch it i get an error ( address error $200C) at $70abe. At $70abe is a call to _lvoAllocMem.

I have tried patching the routine that this address is a part of, but no matter what I do, it doesnt change, I still get the same error.

I can give a zip file of all the files that I am working with if someone has the time to have a look for where I may be going wrong.

-c6

Codetapper · 05 February 2006, 12:07

When WHDLoad is running, the operating system is completely dead. Therefore all functions in libraries such as _LVOAllocMem will fail. You have a few choices:

1. If the game is using the memory as just a temporary block (ie. loading a file in, and later destroying all memory) you can just hardwire the game so it loads to a particular (safe) address. Change jsr _LVOAllocMem(a6) to say lea $20000,a0 (from memory AllocMem returns the memory in a0 and d0? Have to check your docs!)

2. If the game uses the operating system for only a few basic tasks, you can write your own AllocMem routine that tracks how much memory you have left and allocates it to the game. If the game only allocates memory and never frees anything, this is quite an easy task.

3. If the game uses the operating system a lot, you can choose to make it load the WB1.3 or WB3.1 ROMs into memory using the kickstart emulation features in WHDLoad.

In the case of this particular game (and bearing in mind I haven't seen it), I would guess that the game is simply using AllocMem to find 512k of extra memory. It's most likely a 1Mb only game and is using the O/S just at the beginning to find the extra memory. So method 1 is probably a safe bet.

And to test how heavily the game relies on the operating system, have a quick look through a memory dump for the words library and device. Also look near the start of the code for lots of calls to graphics.library and intuition.library. And of course good old exec ($4) needs to be checked too.

Asman · 05 February 2006, 12:38

Quote:

Originally Posted by Crackersixx

The target game is a playable demo (T2:the arcade game) that was included on some magazine. I have disassembled the bootblock and figured out what it's doing for the most part.

Hi,

Maybe better way is start with small game ( one file ) , you may find in aminet some games. And after few small games try do DOS like game. Ofcoz you dont must agree with this, its only proposition.

gretz

Crackersixx · 07 February 2006, 21:57

Ok, I've got the game to load and display the title screen.

The RNC Loader is still confusing me a bit.

Codetapper: in your HDInstalling tutorial on Action, You have a RNC Loader function.
Can you explain what the $200 is that you multiply the offset with to get the byte offset...

mulu #$200,d1 ;offset (sectors)
mulu #$200,d2 ;length (sectors)

Is that just how the game you were using as a tutorial was laid out on disk, or does $200 work for all rnc loaders?

Galahad/FLT · 07 February 2006, 22:47

The Rob Northen AmigaDOS and PDOS (Protection DOS MFM) are Sector loaders, each sector is $200 bytes in size (512bytes decimal).

WHDLoad expects you to pass the correct disk offset (where to start loading from) and the correct size length of data to read.

By multiplying the value in D1 (Sector start) by $200, this converts the sector value to a number that WHDLoad can work with.

We know that an AmigaDOS disk is $dc000 bytes in length. The maximum sector that the RNC AmigaDOS loader will read is $6e0. If you multiply $6e0X$200, you get..... $dc000

Similarly, the PDOS system which is used on Rob Northens MFM protected disks are larger capacity disks, and thus have more sectors ($780 in total, mulu $200 = $f0000).

Crackersixx · 08 February 2006, 02:08

Thanks Galahad

Crackersixx · 08 February 2006, 19:32

What tools do you guys use when trying to debug some of this stuff?

I have my slave working to the point that it loads/displays the title screen. Afterwards it loads and processes (Propack decrypting) three other files. After that, it is apparently jumping off to a bad location that contains no code just linef commands.

Whdload stops and reports the linef error.

I have tried HRTMon but it doesnt break in and aside from trying to trace three 100k(ish) files, I dont know how else to locate the bad jump.

Codetapper · 09 February 2006, 12:48

You hit DEBUG in the WHDLoad crash window that appears, look in the .whdl_register file to look at the stack and see where the routine is going to return to and look around there.

I don't use any monitor myself, simply Resourcing the memory dump that WHDLoad produces.

Galahad/FLT · 09 February 2006, 23:01

To get HRTMon to activate, do the following:

WHLOAD game.slave preload nocache D

The 'D' command will get WHDLoad to detect if HRTMon is active and will activate HRTMon on the first instruction in the slave.

You should find debugging from there easier, because now HRTMon 'should' be able to be activated with a button press. Or, use Breakpoints, thats how I determine what is screwing up.

Galahad/FLT · 09 February 2006, 23:01

To get HRTMon to activate, do the following:

WHLOAD game.slave preload nocache D

The 'D' command will get WHDLoad to detect if HRTMon is active and will activate HRTMon on the first instruction in the slave.

You should find debugging from there easier, because now HRTMon 'should' be able to be activated with a button press. Or, use Breakpoints, thats how I determine what is screwing up.

Crackersixx · 10 February 2006, 02:58

You guys are awesome, thanks tons for the help... Both of you.

I have managed to get the game fully working via my slave. Which was quite a task for me not knowing much about 680x0 asm, whdload, RNC, or cracking on the amiga

Not to mention, even from the floppy, the game would not work on my 040 A1200.

It was great fun tho hehe... All I have to do now is put in the quit key functionality.

Tutorial is half way complete also and is written to be easy for a complete newbie (like myself) to understand. I think its a really good example of what the others here have been asking for. Hopefully it will help others out.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Understanding DIWHIGH register	jman	Coders. Tutorials	6	11 June 2011 12:29
Understanding the Copper	BippyM	Coders. Tutorials	38	04 September 2010 12:18
(ASM) Looking for TFMX replay routine	Asman	Coders. General	3	21 May 2009 14:26
Anyone like to help understanding this bootblock ???	Joe Maroni	Coders. Tutorials	2	15 February 2007 17:33
understanding the COLORXX regs...	Joe Maroni	Coders. General	2	14 February 2005 07:50

03 February 2006, 07:24	#2
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	A few mistakes... OK a few mistakes: Code: MOVE.L A1,-(SP) ;Set initial stack pointer This actually pushes A1 onto the stack. A1 holds the IORequest structure which is passed to a bootblock. Code: MOVE.L #$10002,D1 ;Move $10002 into D1 If you use Resource to disassemble the code, you can hit "m" for memory type, and it will change to a useful description such as MOVE.L #(MEMF_CHIP\|MEMF_CLEAR),D1. Code: MOVEA.L (SP)+,A1 ;Move stack pointer to A1 and inc This restores A1 by grabbing the value off the stack. A1 now holds the IORequest structure address once again. Code: MOVE.W #2,($1C,A1) ; ?? This is filling the command structure to indicate we want to read data. If you use resource, you can go into symbols, choose Exec/IO and fill it in as: MOVE.W #CMD_READ,(IO_COMMAND,A1) Code: MOVE.B ($1F,A1),D0 ; ?? BNE.B lbC00002C ; ?? Once again, let Resource do your work for you! Go into symbols, Exec/IO and choose IO Standard, and you'll get MOVE.B (IO_ERROR,A1),D0 instead. If an error occurs, D0 will not be 0 and so it will attempt to reload the data. Onto the next file: Code: *************** Disassembled "File1" ********************* ;---- Copy 563 words from lbC00001A to addy 70000 ----------------- LEA ($70000).L,A1 ;get $70000 in A1 LEA (lbC00001A,PC),A0 ;get address of lbc00001a in A0 MOVE.W #$563,D7 ;get $563 in D7 lbC00000E MOVE.W (A0)+,(A1)+ ;move word from A0 into A1 and inc DBRA D7,lbC00000E ;decrease D7, if > -1 loop JMP ($7098A).L ;when finished, jump to $7098a ;------------------------------------------------------------------ lbC00001A MOVEM.L D1-D7/A0-A5,-(SP) LINK.W A6,#-$24 MOVE.W D0,D4 ANDI.W #3,D4 MOVE.W D4,(-$24,A6) MOVE.W D1,(-$22,A6) MOVE.W D2,(-$20,A6) MOVE.W D3,(-$1E,A6) MOVE.L A0,(-$1C,A6) MOVE.L A1,(-$18,A6) **************************************************************** The file is relocated to $70000 and then it continues at $7098a. The reason you copy it is that the code could be absolutely anywhere in memory, and simply executing it will cause problems later. The programmer has worked out where he will fit the code, graphics, music etc in memory so that everything fits nicely and all 512k of chip memory is used effectively. If you let the Amiga decide where to load it, it might end up at say $20000 and that would be a problem as you then have to squeeze the game around and avoid that block of memory. Instead you simply copy it to a safe location you know about. lbC00001A is the Rob Northen loading routine. After you've been in the cracking business for a while you can sniff those a mile off D0 = Disk drive to load from D1 = Offset (sectors) D2 = Length (sectors) D3 = Function (0 = read, 1 = write, bit #15 controls whether the motor is left on) A0 = Disk buffer address for transfer A1 = Workspace buffer ($3300 bytes of chip memory) On exit, D0 returns the error number. If it's 0, everything was OK. What you should do is grab that file which you have called file1 (I recommend my utility called grab to do it: Grab game.adf ram:file1 from $5200 length $c00) and load it into resource. Go into the * menu, Origin, Specify and set it to $70000. Now Resource will be able to disassemble the code as the beginning of the file is now where the game expects it, so the code JMP $7098A will change to JMP lbC0007098A and you can keep going. Good luck!

03 February 2006, 08:09	#3
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	Great info codetapper. I did use ReSource to disassemble the code but I'm not to sure how to use all of the features just yet I'll definately check out your suggestions. And I am using your Grab utility as well as your HDInstalling tutorial from your website as a guide. Setting the origin in ReSource is exactly what I was needing. I'll continue again on this tomorrow nite

05 February 2006, 11:42	#4
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	ok, so I have what I think is a decent start on a slave file. When i launch it i get an error ( address error $200C) at $70abe. At $70abe is a call to _lvoAllocMem. I have tried patching the routine that this address is a part of, but no matter what I do, it doesnt change, I still get the same error. I can give a zip file of all the files that I am working with if someone has the time to have a look for where I may be going wrong. -c6

05 February 2006, 12:07	#5
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	When WHDLoad is running, the operating system is completely dead. Therefore all functions in libraries such as _LVOAllocMem will fail. You have a few choices: 1. If the game is using the memory as just a temporary block (ie. loading a file in, and later destroying all memory) you can just hardwire the game so it loads to a particular (safe) address. Change jsr _LVOAllocMem(a6) to say lea $20000,a0 (from memory AllocMem returns the memory in a0 and d0? Have to check your docs!) 2. If the game uses the operating system for only a few basic tasks, you can write your own AllocMem routine that tracks how much memory you have left and allocates it to the game. If the game only allocates memory and never frees anything, this is quite an easy task. 3. If the game uses the operating system a lot, you can choose to make it load the WB1.3 or WB3.1 ROMs into memory using the kickstart emulation features in WHDLoad. In the case of this particular game (and bearing in mind I haven't seen it), I would guess that the game is simply using AllocMem to find 512k of extra memory. It's most likely a 1Mb only game and is using the O/S just at the beginning to find the extra memory. So method 1 is probably a safe bet. And to test how heavily the game relies on the operating system, have a quick look through a memory dump for the words library and device. Also look near the start of the code for lots of calls to graphics.library and intuition.library. And of course good old exec ($4) needs to be checked too.

07 February 2006, 21:57	#7
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	Ok, I've got the game to load and display the title screen. The RNC Loader is still confusing me a bit. Codetapper: in your HDInstalling tutorial on Action, You have a RNC Loader function. Can you explain what the $200 is that you multiply the offset with to get the byte offset... mulu #$200,d1 ;offset (sectors) mulu #$200,d2 ;length (sectors) Is that just how the game you were using as a tutorial was laid out on disk, or does $200 work for all rnc loaders?

07 February 2006, 22:47	#8
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	The Rob Northen AmigaDOS and PDOS (Protection DOS MFM) are Sector loaders, each sector is $200 bytes in size (512bytes decimal). WHDLoad expects you to pass the correct disk offset (where to start loading from) and the correct size length of data to read. By multiplying the value in D1 (Sector start) by $200, this converts the sector value to a number that WHDLoad can work with. We know that an AmigaDOS disk is $dc000 bytes in length. The maximum sector that the RNC AmigaDOS loader will read is $6e0. If you multiply $6e0X$200, you get..... $dc000 Similarly, the PDOS system which is used on Rob Northens MFM protected disks are larger capacity disks, and thus have more sectors ($780 in total, mulu $200 = $f0000).

08 February 2006, 02:08	#9
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	Thanks Galahad

08 February 2006, 19:32	#10
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	What tools do you guys use when trying to debug some of this stuff? I have my slave working to the point that it loads/displays the title screen. Afterwards it loads and processes (Propack decrypting) three other files. After that, it is apparently jumping off to a bad location that contains no code just linef commands. Whdload stops and reports the linef error. I have tried HRTMon but it doesnt break in and aside from trying to trace three 100k(ish) files, I dont know how else to locate the bad jump.

09 February 2006, 12:48	#11
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	You hit DEBUG in the WHDLoad crash window that appears, look in the .whdl_register file to look at the stack and see where the routine is going to return to and look around there. I don't use any monitor myself, simply Resourcing the memory dump that WHDLoad produces.

09 February 2006, 23:01	#12
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	To get HRTMon to activate, do the following: WHLOAD game.slave preload nocache D The 'D' command will get WHDLoad to detect if HRTMon is active and will activate HRTMon on the first instruction in the slave. You should find debugging from there easier, because now HRTMon 'should' be able to be activated with a button press. Or, use Breakpoints, thats how I determine what is screwing up.

10 February 2006, 02:58	#14
Crackersixx Registered User Join Date: Nov 2005 Location: Seattle, wa Age: 50 Posts: 65	You guys are awesome, thanks tons for the help... Both of you. I have managed to get the game fully working via my slave. Which was quite a task for me not knowing much about 680x0 asm, whdload, RNC, or cracking on the amiga Not to mention, even from the floppy, the game would not work on my 040 A1200. It was great fun tho hehe... All I have to do now is put in the quit key functionality. Tutorial is half way complete also and is written to be easy for a complete newbie (like myself) to understand. I think its a really good example of what the others here have been asking for. Hopefully it will help others out.

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