Sonic and Sega Retro Message Board: Aurochs - Viewing Profile - Sonic and Sega Retro Message Board

Optimizing loops can often mean unrolling them. If the number of iterations is known at compile time, one could simply write the whole thing out (say, twenty <tt>move</tt> instructions rather than one <tt>move</tt> and a <tt>dbf</tt>). However, if you find yourself optimizing a loop, it may have hundreds of iterations, and completely unrolling it could inflate the module massively. In such cases, a good compromise is to partially unroll it (twenty <tt>move</tt> instructions and a <tt>dbf</tt> rather than 100 <tt>move</tt>s).

Things get more complex when the number of iterations isn't known until runtime. One must decide how to handle partial iterations. Usually the best way to do this in assembly is to construct a jump table and use it to branch into the middle of the loop, but the common practice in C was to write a whole bunch of different partial loops and choose the correct one at runtime.

Tom Duff found a rather curious method to create the assembly construct in C �€” he interlaced a switch structure with a do loop.

	send(to, from, count)
	register short *to, *from;
	register count;
	{
		register n=(count+7)/8;
		switch(count%8){
		case 0:	do{	*to = *from++;
		case 7:		*to = *from++;
		case 6:		*to = *from++;
		case 5:		*to = *from++;
		case 4:		*to = *from++;
		case 3:		*to = *from++;
		case 2:		*to = *from++;
		case 1:		*to = *from++;
			}while(--n>0);
		}
	}

This is perfectly valid C, and comiles and runs exactly as expected. The switch is only tested once, and is used to jump into the middle of the loop. Execution will continue through the rest of the switch until it reaches the loop's while() statement, at which point control is transfered to case 0: if it tests true.

Now, if you're writing your Genesis games in C (compilers do exist), this may be perfect. But us hackers will have to use assembly. So I decided to hack up a quick and dirty subroutine in 68k that should be roughly equivalent to the above C. (Note: errors probably exist)

; An implimentation of Duff's device for the 680x0 processor family.
; d0 = count
; a0 = destination pointer
; a1 = source pointer (array)

SECTION duffdev
PUBLIC	duff_device


duff_device:
	cmpi.w	#0,d0
	beq.s	return;count is zero; no need to go any further

	move.w	d0,d1
	addi.w	#7,d1
	lsl.w	#3,d1
	subi.w	#1,d1;d1 contains n (for loop iterations)
	
	lsl.w	#3,d0
	lsr.w   #1,d0;lsb must be clear for jump table to work
	move.w	jumpTbl(pc,d0.w),d2
	jmp	jumpTbl(pc,d2.w)

;******************************************************************
jumpTbl:
	dc.w	case0
	dc.w	case1
	dc.w	case2
	dc.w	case3
	dc.w	case4
	dc.w	case5
	dc.w	case6
	dc.w	case7
;******************************************************************

case0:	move.b	(a1)+,(a0)
case7:	move.b	(a1)+,(a0)
case6:	move.b	(a1)+,(a0)
case5:	move.b	(a1)+,(a0)
case4:	move.b	(a1)+,(a0)
case3:	move.b	(a1)+,(a0)
case2:	move.b	(a1)+,(a0)
case1:	move.b	(a1)+,(a0)
	dbf.s	d1,case0

return:	rts

ENDS	duffdev

Read more about Duff's device here.

If you have a question about AS that you want answered, post it here. If I can't answer it myself, and I'm sufficiently piqued, I'll email Alfred Arnold about it.

Any questions of the general form "yadda yadda yadda AS sucks yadda yadda" will be silently ignored.

http://stech68k.net/...?topic=45&page=

The YM2612 is basically two YM2203s shoved on the same die (The second one is slightly more special than that because of the DAC channel). So I wondered, would the datasheet for the YM2203 be sufficiently compatable with the YM2612?

And the answer is a resounding "yes". The register listing on the datasheet is almost precicely the same as the one in sega2.doc. The only major differences I found were below $30: registers $00-$09 (appear to be for controlling a noise generator - these may or may not exist in the 2612), register $21 (TEST in the datasheet but LFO control in sega2), $2A and $2B (DAC control), and $2D-$2F (clock divisors in the 2203, again, may or may not exist in the 2612).

Now what we need to do is hack something up to test out these new registers on real hardware.

I believe I've located the patent for the Genesis VDP (here). The "DESCRIPTION OF THE PREFERRED EMBODIMENTS" section is entirely consistent with the VDP's function, and it's crossreferenced from the patent for Sonic's 2 player mode. Unfortunately, I can't seem to download the images. Dunno why, but I can only see a small part of the page.

Does anybody feel like retrieving those images for me? This seems like it could reveal a lot about the inner workings of the video display processor, but without the figures, it's far less useful.

Download it from STech68k. Usage instructions and changelog are in the readme file, so be sure to check that out before starting. As before, feel free to mirror it so that it doesn't get lost to the Internet if any one server dies.

To assemble the listing, you need ASW, which can be found here. The latest Win32 binary will be fine.

MIRRORS (STech link may not work):
For Mac OSX PPC (includes a Mac version of AS)
Sixfifteen (UK)