English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General > Coders. Tutorials

 
 
Thread Tools
Old 29 September 2019, 19:40   #61
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,474
Apologies for ressrecting this thread after a couple of years but after some testing with Rygar on much faster cards I came a cropper of this... basically very fast routines such as fades and transitions would screw up because they all trigger and run on line 303.

Code:
.vpos:  move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.b   .vpos						 
        rts

I've modified the Wait for Vertical Blank routine to wait for the line and then to reach at least near to the end of the horizontal line. It seems OK but wondered if anyone else has insights on a better way, or even if this isn't a good way to do it?
Code:
move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.b   .vpos

.hpos:  move.w  VHPOSR(a5),d0
	cmp.b	#208,d0			; Horizontal position...
	blt.s	.hpos
[/CODE]

Geezer
mcgeezer is offline  
Old 29 September 2019, 20:06   #62
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,244
I usually simply wait for line x and then wait until line is not x.
Toni Wilen is online now  
Old 29 September 2019, 20:34   #63
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,474
Quote:
Originally Posted by Toni Wilen View Post
I usually simply wait for line x and then wait until line is not x.
Yup, I don't think it makes much difference...but I'll go with your method.

Code:
.vpos:  move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait for line 303
        bne.s   .vpos
	
.vposn:
	move.l  VPOSR(a5),d0
        and.l   #$1ff00,d0
        cmp.l   #303<<8,d0              ; Wait till line 303 finished.
        beq.s   .vposn
mcgeezer is offline  
Old 29 September 2019, 22:55   #64
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
I usually use this.

Code:
;-----------------------------------------------------------------------------

;; - wait for top of frame
;
;in	a5 - _custom
;out	-
;used	d0/a0/a5
;
	xdef	HwWaitTopOfFrame
HwWaitTopOfFrame:
		lea	vposr(a5),a0
.1		moveq	#1,d0
		and.w	(a0),d0
		beq.b	.1
.2		and.w	(a0),d0
		bne.b	.2
		rts

;-----------------------------------------------------------------------------

Last edited by Asman; 01 October 2019 at 13:09. Reason: edit: correcting bugs - thanks to ross.
Asman is offline  
Old 29 September 2019, 23:11   #65
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,143
Hi Asman!
This however does not wait for line 303 (although I don't know why line 303 )
ross is offline  
Old 29 September 2019, 23:15   #66
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
Hi ross!
Yeah right, I've forgot about that 303 line , just wait for top of frame. You know I don't like wasting cycles.
Asman is offline  
Old 29 September 2019, 23:23   #67
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,143
Quote:
Originally Posted by Asman View Post
You know I don't like wasting cycles.
yep, the 68k motto: every cycle worth the effort
ross is offline  
Old 30 September 2019, 00:34   #68
hitchhikr
Registered User

 
Join Date: Jun 2008
Location: somewhere
Posts: 402
I use this:

Code:
wait_sync:
    btst.b  #0,$dff005
    beq.b   wait_sync
wait_sync_line:
    btst.b  #0,$dff005
    bne.b   wait_sync_line
hitchhikr is offline  
Old 30 September 2019, 09:26   #69
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,588
If you really want to wait for the top of frame, why not just this :
Code:
 move.w #$20,$dff09c
.wait
 moveq #$20,d0
 and.w $dff01e,d0
 beq.s .wait
And if you use vert beam interrupt, it's even easier - set a flag there and wait for it to change.
meynaf is offline  
Old 30 September 2019, 11:21   #70
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,143
Ok, if you are in the dark side of the force:
Code:
	lea	$dff004,a0
	
.l1	lsr	(a0)
	bcc.b	.l1	
.l2	lsr	(a0)
	bcs.b	.l2
ross is offline  
Old 30 September 2019, 11:31   #71
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 981
Quote:
Originally Posted by ross View Post
Ok, if you are in the dark side of the force:
Code:
    lea    $dff004,a0
    
.l1    lsr    (a0)
    bcc.b    .l1    
.l2    lsr    (a0)
     bcs.b    .l2

Maybe it doesn't matter in practice, but this writes to a read-only register, which is not recommended.
hooverphonique is offline  
Old 30 September 2019, 11:36   #72
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,143
Quote:
Originally Posted by hooverphonique View Post
Maybe it doesn't matter in practice, but this writes to a read-only register, which is not recommended.
As specified only for those in the dark side of the force.
In practice it does not hurt, but really annoying during debugging

So don't try it at home!


I have never logically used it, I have put it only as a working case study not to be used.
ross is offline  
Old 30 September 2019, 15:04   #73
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,771
Quote:
Originally Posted by Toni Wilen View Post
I usually simply wait for line x and then wait until line is not x.
This is reliable, but the CPU would then do nothing but busy-wait for a whole scanline, i.e. 0.4% CPU time wasted.

Quote:
EOF vs TOF
Waiting for line $138 = EOF is essentially the same as waiting for line $1a = TOF, except for the flyback of the beam. So if you poll for these raster lines and execute code, any Vblank interrupt will interrupt that code after a very short while.

So if code is executed after a raster busy wait in main, that relies on values set by the int, read them at EOF quickly before the int hits (and never re-read them later in the code), because they may be changed by the int mid-execution.

Last edited by Photon; 30 September 2019 at 17:23.
Photon is offline  
Old 30 September 2019, 16:35   #74
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,143
Quote:
Originally Posted by Photon View Post
This is reliable, but the CPU would then do nothing but busy-wait for a whole scanline, i.e. 0.4% CPU time wasted.




Waiting for line $138 = EOF is the same as waiting for line $2a = TOF, there's just 1/3 of a scanline worth of cycles during the flyback of the beam. So if you poll for these raster lines and execute code, any Vblank interrupt will interrupt that code after a very short while.



So if code is executed after a raster busy wait in main, that relies on values set by the int, read them at EOF quickly before the int hits (and never re-read them later in the code), because they may be changed by the int mid-execution.
I apologize in advance because it may be that I did not understand exactly what you wrote.
But it seems you have made some confusion between vsync, vblank and VBI.
Excluding the vsync signals, which at the moment are not of interest to us as they are generated by the Amiga hardware (for a standard PAL or NTSC signal), we are interested in vblank and VBI.
Vblank because we have to exploit it to the maximum because nothing is put on video in that period, the VBI because it references us the position 0,0 of the internal video counters and the generation of a level 3 IRQ for the CPU.
The vblank is between lines 0 and $19. The first visible line in maximum overscan is the $1a.
The VBI is generated only once per frame at the beginning of line 0.
The copper execute little before the CPU because the IRQ response requires some machine cycles.
ross is offline  
Old 30 September 2019, 17:29   #75
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,771
I've edited my post. I will measure the time in CPU instructions executed across the vblank, and then I'll know exactly. I guess it should correspond to the $1a scanlines, but the actual time it takes for the monitor vsync pulse should be ~576ms = 9 rasterlines.

I guess my main point is that if you have interrupts running that change values you rely on, results could vary depending on when the interrupt hits in your running main code. And that if you have interrupts or a BLTPRI=1 blit running during a VPOS check with beq, it could be skipped so that you get a stagger.

Last edited by Photon; 02 October 2019 at 23:09.
Photon is offline  
Old 01 October 2019, 13:11   #76
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
@ross - Thanks for pointing me that stupid bugs in HwWaitTopOfFrame (post #66). I corrected and checked. Now works correctly. Thanks
Asman is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Removing the IDE Wait on Kickstart 3.1 Zetr0 support.Hardware 26 16 June 2010 09:31
'Wait' program that checks for a joy button press instead of 'Return' key... Heavy Stylus request.Apps 7 10 May 2009 20:01
timed wait using CIAs jotd support.Other 3 23 March 2008 15:55
HD won't boot now..wait failed returncode? Amigan25 project.ClassicWB 2 08 June 2007 19:21
Wait a sec - what about Macs? Computolio Amiga scene 10 02 June 2004 08:23

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 12:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10085 seconds with 15 queries