Cycle accurate delay loop

[paraj]

Say you have some classic 7MHz code that does a standard, stupid busy loop:

Loop:     DBF D0,Loop

Assume it's running from ROM (so no memory access contention to worry about). How could you best replace it with something that takes the (roughly) same amount of time on a wide range of 020+ Amigas even for smallish (32) values?


Came up when I wanted to quickly extract A1000 startup sound as a more normal executable. This seems to work OK (empirically) on my machine:

        lsr.w   #1,\1
.\@
        tst.b   $bfe001
        dbf     \1,.\@

But CIA access speed varies (I think in principle with as fast as possible CIA access should work great: 1/10th 7MHz per iteration running from fast ram should be ~10 7Mhz cycles per DBF, but you can't do them back to back or maybe my accelerator card can't...).

[ross]

CIA Timer?

[paraj]

Originally Posted by ross

CIA Timer?

That'll work. Could be setup beforehand, but what values do I need? Is this the best we can do?

[Thomas Richter]

timer.device TR_ADDREQUEST and DoIO()?

[ross]

Originally Posted by paraj

That'll work. Could be setup beforehand, but what values do I need? Is this the best we can do?

I normally use the greatest common divisor between the values that I will use as delay factors (and I insert this value into the Timer prescaler).
Then I pass the multiplier as a parameter and do a dbf of that value (with a loop checking the underflow bit).

[paraj]

Originally Posted by Thomas Richter

timer.device TR_ADDREQUEST and DoIO()?

33 iterations of the loop is <5usec, I'll test (later) but I'm guessing it will be way off for small numbers.

Originally Posted by ross

I normally use the greatest common divisor between the values that I will use as delay factors (and I insert this value into the Timer prescaler).
Then I pass the multiplier as a parameter and do a dbf of that value (with a loop checking the underflow bit).

Seems very reasonable. Bonus points to solutions that don't require setup though. Even if you do require setup, but use CIA for small numbers setup/check factors in...


Difference of e.g. 10 CIA ticks doesn't matter too much, but if anyone can do better...

[Toni Wilen]

Manual audio mode and audio interrupts?

[paraj]

Originally Posted by Toni Wilen

Manual audio mode and audio interrupts?

Love it, but not for general use (already a bit ugly for A1000 startup sound as that uses all channels, though only one at a time)

[jotd]

here's what I use (Harry provided that code ages ago)

; < D0: value of D0 in line
; .x: DBF D0,x
emulate_dbf
	swap	D0
	clr.w	D0
	swap	D0
	divu.w	#$28,D0
	swap	D0
	clr.w	D0
	swap	D0
	bsr	beamdelay
	move.w	#$FFFF,d0
	rts
; < D0: numbers of vertical positions to wait
beamdelay
.bd_loop1
	move.w  d0,-(a7)
        move.b	$dff006,d0	; VPOS
.bd_loop2
	cmp.b	$dff006,d0
	beq.s	.bd_loop2
	move.w	(a7)+,d0
	dbf	d0,.bd_loop1
	rts

I often use beamdelay alone with pre-computed values. Mostly for keyboard (2) or DMA write (4 to 7 depending on how it really sounds).

Those busy waits end up having an impact on performance, so code rewrite would be better (with cia timers) but it's not trivial on an existing game code without source!

[paraj]

Yes, I've seen your beam delay function quite a bit I trust that the $28 divisor probably works well in practice given how often you guys have used it. And yeah, when doing whdload stuff it's not easy to know in general which CIA timers are available though I often see one used for disk stuff that I imagine would then be free later on (though you never know).

Guess it should be possible to also use the HPOS part to improve the precision a bit (though in the the end it probably won't matter much). Mostly idle curiosity.

[Bruce Abbott]

Originally Posted by paraj

Say you have some classic 7MHz code that does a standard, stupid busy loop:

Loop:     DBF D0,Loop

Assume it's running from ROM

Which ROM in which machine?

[Photon]

Originally Posted by paraj

That'll work. Could be setup beforehand, but what values do I need? Is this the best we can do?

Umm. The dbf value is an empirical value, so that was the best they could do.

ROM, custom register, chip ram access speed is not enough.

Raster is not enough, it will fail in productivity mode.

CIA clock timing is the only accurate option for waits longer than 2-3us, if you don't use audio interrupts/requests.

Busy-wait is still lazy and wasting resources, but you can use a one-shot CIA timer. Value set according to HRM. Between NTSC/PAL, the difference is small enough that you can use the largest value of the two.