[drx]

http://www.hacking-cult.org/?news/c/48

Enjoy.

PS. I tried to use Hive's terminology in that one, for compatibility reasons.

[Lath]

drx, on Dec 3 2006, 12:17 AM, said:

http://www.hacking-cult.org/?news/c/48

Enjoy.

PS. I tried to use Hive's terminology in that one, for compatibility reasons.

Nice going DRX, let's see who the first to port over the wall crashing thing to S2 final XD

Oh, pin please.

[Hivebrain]

Nice work! I'll have a good look at this tomorrow.

drx, on Dec 3 2006, 06:17 AM, said:

PS. I tried to use Hive's terminology in that one, for compatibility reasons.

If you mean labels, I'm changing a lot of them for the next S1 disassembly.

[Rika Chou]

Awesome, I will be looking though this later for sure. Thanks drx!

[Dracula]

Nice work! How did you dig this up so fast? =P

This post has been edited by Neo the Hedgehog: 03 December 2006 - 10:25 AM

[Weird Person]

Nice. Very interesting!

Code from ROM: (Vertical Blank code...)

		move.l	#$C0000000,4(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)
		move.l	(a0)+,(a1)

Yuji Naka isn't the organized programmer I tough he was. =P

[StephenUK]

Actually, that's done quite a few times in the S2 Final disassembly and is quicker to execute than looping over the same line X amount of times.

[Weird Person]

StephenUK, on Dec 3 2006, 05:42 AM, said:

Actually, that's done quite a few times in the S2 Final disassembly and is quicker to execute than looping over the same line X amount of times.

I agree it's quicker, but the difference between a "dbra" loop and a lot of lines with the same instruction is desprezive, right?

[drx]

Emily Sapphire, on Dec 3 2006, 07:23 AM, said:

drx, on Dec 3 2006, 12:17 AM, said:

http://www.hacking-cult.org/?news/c/48

Enjoy.

PS. I tried to use Hive's terminology in that one, for compatibility reasons.

Nice going DRX, let's see who the first to port over the wall crashing thing to S2 final XD

Oh, pin please.

The whole wall crashing thingy is the Sonic_WallRecoil subroutine. And of course, you need to port the animation, frame and graphics.

[Quickman]

Weird Person, on Dec 3 2006, 01:53 PM, said:

StephenUK, on Dec 3 2006, 05:42 AM, said:

Actually, that's done quite a few times in the S2 Final disassembly and is quicker to execute than looping over the same line X amount of times.

I agree it's quicker, but the difference between a "dbra" loop and a lot of lines with the same instruction is desprezive, right?

Using my ninja context-fu I am predicting the content of this post, since "desprezive" did not translate.

"I agree it's quicker, but isn't a dbra loop quicker?"

The answer is no, a dbra loop is a lot slower in terms of processor cycles than just doing the same thing over and over the requisite number of times.

This post has been edited by Quickman: 03 December 2006 - 09:46 AM

[Weird Person]

Quickman, on Dec 3 2006, 06:46 AM, said:

Weird Person, on Dec 3 2006, 01:53 PM, said:

StephenUK, on Dec 3 2006, 05:42 AM, said:

Actually, that's done quite a few times in the S2 Final disassembly and is quicker to execute than looping over the same line X amount of times.

I agree it's quicker, but the difference between a "dbra" loop and a lot of lines with the same instruction is desprezive isn't big, right?

Using my ninja context-fu I am predicting the content of this post, since "desprezive" did not translate.

"I agree it's quicker, but isn't a dbra loop quicker?"

The answer is no, a dbra loop is a lot slower in terms of processor cycles than just doing the same thing over and over the requisite number of times.

Fixed.

By the way, I hate you Quickman.

[drx]

Let me review the case:

Using so many move.l:

Each instruction takes 20 CPU cycles (3 read cycles, 2 write cycle). * 32 = 640 CPU cycles (96 read cycles and 64 write cycles).

Now using dbra, the code would have to look like this:

	move.w	#31,d1
loop:
	move.l	(a0)+,(a1)
	dbra	d1,loop

move.w #31,d1 - 8 cycles (2 read cycles, 0 write cycles)
move.l (a0)+,(a1) - 640 cycles (96 read cycles and 64 write cycles), like above
dbra d1,loop - 31 * branch taken timing - 310 cpu cycles (62 read cycles, 0 write cycles)
branch not taken, counter expired - 14 cpu cycles, 3 read cycles, 0 write cycles.

Let's sum it up:

using dbra - 972 cpu cycles, 163 read cycles, 64 write cycles
not using dbra - 640 CPU cycles, 96 read cycles and 64 write cycles.

using dbra, you would waste 25% cpu cycles in total, and 70% read cycles. Remember, this is done during the VBlank - so the timing DOES count.

Hope that clears the matter a little.

[Rika Chou]

What would you recommend as the best assembeler to use for this?

[drx]

I use snams68k 2.1d. I know it's not the best one, but it works for me.

I hear others use AS, but I haven't used it, so I can't tell you if it's good or not.

Also, if you're using snasm68k, use this:

snasm68k.exe -emax 0 -p -o ae- s2a.asm, s2a.bin

[ICEknight]

Hm? What's this?

Quote

Object 43 - HPZ Roller enemy

Or did you mean SYZ?